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!

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

Just FYI `<>` is already the string concatenation operator. Just in case you're not aware. :)

Ah thanks, I think HN ate my character. It’s ‘<*>’ with a asterisk in between.

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.

Elixir allows overloading the operators or creating custom ones, but only certain symbols are recognized in the parser, to add new operators the Elixir parser needs to be changed.

You can see them here https://github.com/elixir-lang/elixir/blob/master/lib/elixir...

Not all of them are defined in the language, the list of the unused infix operator includes

    \\, <-, |, ~>>, <<~, ~>, <~, <~>, <|>, <<<, >>>, |||, &&&, and ^^^

to define a custom infix operator you can use this syntax

    def left <|> right do
      IO.puts("#{left} <|> #{right}")
    end

    # usage
    left MyModule.<|> right

    # or
    import MyModule
    left <|> right

if the operator is already defined in Kernel, you can exclude it from import and use your own

    import Kernel, except: [{:+, 2}]
    import MyModule

    left + right

as you can see @ is not among them, @ it's not a binary operator and is defined as Kernel.@/1