2 ms·

Hi, those are great points and exactly the type of discussions I expect to have with the greater Elixir community over the next months. I will answer them with

Hi, those are great points and exactly the type of discussions I expect to have with the greater Elixir community over the next months. I will answer them with my current perspective. Given that Nx has its own numerical kernel, we can import whatever we want. :) I have decided to keep the imported keywords to be a subset of the Elixir's built-in Kernel but there is nothing stopping us from changing that. For example, if exp and ln are all automatically imported in Julia, Python, etc, then it is most likely more than enough to justify them being imported in `defn` too. Regarding custom operators, Elixir has a limited set of operators which have historically been expanded on demand. So it is a matter of looking at other communities, find what is the closest thing to a standard, and send a proposal to the language. :) If you are interested in driving this, you are welcome to submit an initial discussion comparing other languages and an initial set of operators on the Nx issues tracker, then we can discuss it upstream. Thank you!

elcritch 6y ago
Thanks for the response! Glad to hear it's on your radar and ready to foster those discussions. :-) > For example, if exp and ln are all automatically imported in Julia, Python, etc, then it is most likely more than enough to justify them being imported in `defn` too. Matlab and Julia import lots of math defaults because that's their primary target. In Python it varies, and it's pretty common to use `np` to avoid cluttering the namespace. Though partly it's because there isn't a good way (AFAICT) to make a scope with default custom namespace like `defn` gives you! It's a bit of taste really though. I'd suggest it's worth considering. > Regarding custom operators, Elixir has a limited set of operators which have historically been expanded on demand. So it is a matter of looking at other communities, find what is the closest thing to a standard, and send a proposal to the language. :) Well now, you give me way too many ideas. ;) I'll at least post some issues on the Nx tracker. My initial thought would be that perhaps a `<>` operator for "dot" operation would fit in with Elixir's other operators and is comparable to R's `%%` operators so there's a similarity and precedence. If it were low risk to add then it'd be a pretty decent option. It wouldn't solve the whole elementwise issue though. but with syntax trees there could be ways to use Einstein notation instead [1]. That'd be fun to play with! > If you are interested in driving this, you are welcome to submit an initial discussion comparing other languages and an initial set of operators on the Nx issues tracker, then we can discuss it upstream. I'll create an issue on Nx project and basically repost my thoughts there. Then see what other people are thinking! 1: https://en.wikipedia.org/wiki/Einstein_notation https://en.wikipedia.org/wiki/Einstein_notation
- wolf4earth 6y ago
  Just FYI `<>` is already the string concatenation operator. Just in case you're not aware. :)
  - elcritch 6y ago
    Ah thanks, I think HN ate my character. It’s ‘<*>’ with a asterisk in between.
elcritch 6y ago
P.S. a potential sweet spot for Elixir in the broader scientific computing community comes when you combine native numerical libraries _with_ Phoenix LiveView! Realtime scientific dashboards are amazing. There's nothing I've found that makes interactive dashboards as easy as with LiveView. Actually there are projects in R, Julia, and Python that are great but they're much more difficult to deploy and scale IMHO.

elcritch 6y ago

Thanks for the response! Glad to hear it's on your radar and ready to foster those discussions. :-) > For example, if exp and ln are all automatically imported in Julia, Python, etc, then it is most likely more than enough to justify them being imported in `defn` too. Matlab and Julia import lots of math defaults because that's their primary target. In Python it varies, and it's pretty common to use `np` to avoid cluttering the namespace. Though partly it's because there isn't a good way (AFAICT) to make a scope with default custom namespace like `defn` gives you! It's a bit of taste really though. I'd suggest it's worth considering. > Regarding custom operators, Elixir has a limited set of operators which have historically been expanded on demand. So it is a matter of looking at other communities, find what is the closest thing to a standard, and send a proposal to the language. :) Well now, you give me way too many ideas. ;) I'll at least post some issues on the Nx tracker. My initial thought would be that perhaps a `<>` operator for "dot" operation would fit in with Elixir's other operators and is comparable to R's `%%` operators so there's a similarity and precedence. If it were low risk to add then it'd be a pretty decent option. It wouldn't solve the whole elementwise issue though. but with syntax trees there could be ways to use Einstein notation instead [1]. That'd be fun to play with! > If you are interested in driving this, you are welcome to submit an initial discussion comparing other languages and an initial set of operators on the Nx issues tracker, then we can discuss it upstream. I'll create an issue on Nx project and basically repost my thoughts there. Then see what other people are thinking! 1: https://en.wikipedia.org/wiki/Einstein_notation https://en.wikipedia.org/wiki/Einstein_notation

wolf4earth 6y ago
Just FYI `<>` is already the string concatenation operator. Just in case you're not aware. :)
- elcritch 6y ago
  Ah thanks, I think HN ate my character. It’s ‘<*>’ with a asterisk in between.

elcritch 6y ago

P.S. a potential sweet spot for Elixir in the broader scientific computing community comes when you combine native numerical libraries _with_ Phoenix LiveView! Realtime scientific dashboards are amazing. There's nothing I've found that makes interactive dashboards as easy as with LiveView. Actually there are projects in R, Julia, and Python that are great but they're much more difficult to deploy and scale IMHO.