3 ms·

IMO, doing matrix operations by default is the mathematically correct thing to do. E.g. having exp(M::Matrix) give anything other than the matrix exponential is

IMO, doing matrix operations by default is the mathematically correct thing to do. E.g. having exp(M::Matrix) give anything other than the matrix exponential is insanity. Same with A::Matrix * B::Matrix giving anything other than matrix multiplication. As far as the ‘.’ for elementwise operations, I don’t think it’s that hard to miss, but I guess my eyes are trained for it by now. There’s also an @. macro to make an entire expression element wise though if needed, e.g. @. h(f(x) + g(y)) is equivalent to h.(f.(x) .+ g.(y)) I think this broadcasting machinery is one of the closet parts of julia because you get to choose at the call site if you want the function to apply element-wise or to see the whole array, and it works on any container, with user customizable behaviour for user defined containers, and has all sorts of goodies like automatic loop fusion.

NegativeLatency 5y ago
Having zero experience with this I could see myself getting used to the notation. The dot before the addition sign is strange looking to unfamiliar eyes, is it calling + on the result of f.(x)?
- eigenspace 5y ago
  Yeah that’s eighth, it’s element wise addition between the results of f.(x) and g.(y) with loop fusion. the syntax for broadcasting a regular function is f.(x) but the syntax for broadcasting an infix function like +, is x .+ y so the dot goes at the start. I think there were some convincing reasons it ended up this way, but I forget what those reasons are. It’s just muscle memory for me at this point. You can also treat any infix function as a regular prefix one by wrapping it in parens, e.g. (+).(x, y)
bloaf 5y ago
I personally think a vector library that allowed some form of Einstein notation [1] would be a killer feature for a scientific computing environment. [1] https://en.wikipedia.org/wiki/Einstein_notation https://en.wikipedia.org/wiki/Einstein_notation
- eigenspace 5y ago
  Ask and ye shall receive (more than ye bargained for): https://github.com/mcabbott/Tullio.jl https://github.com/mcabbott/Tullio.jl https://github.com/Jutho/TensorOperations.jl https://github.com/Jutho/TensorOperations.jl https://github.com/under-Peter/OMEinsum.jl https://github.com/under-Peter/OMEinsum.jl Tullio.jl is the most powerful and interesting to me of the above libraries, but they all have cool strengths.
cycomanic 5y ago
I would argue that an array is something else than a matrix. It's a design decision that matlab (and julia) made, regard every multi-element variable as a matrix. I disagree with that decision, because for most of the code I'm exposed to I don't want matrix operations and it causes issues, e.g. when I move from a scalar implementation to an array implementation of a function.
- eigenspace 5y ago
  Ah sure, yes we did not need to conflate vectors and matrices with arrays and I sometimes wonder if we made the wrong choice there. I guess I'd say that then someone would get to own the syntax [a, b, c] it'd either be a vector of a non-mathematical array and whichever choice was made, someone would be unhappy. I think not too much was lost by having them be the same thing, but the ship has sailed anyways.

NegativeLatency 5y ago

Having zero experience with this I could see myself getting used to the notation. The dot before the addition sign is strange looking to unfamiliar eyes, is it calling + on the result of f.(x)?

eigenspace 5y ago
Yeah that’s eighth, it’s element wise addition between the results of f.(x) and g.(y) with loop fusion. the syntax for broadcasting a regular function is f.(x) but the syntax for broadcasting an infix function like +, is x .+ y so the dot goes at the start. I think there were some convincing reasons it ended up this way, but I forget what those reasons are. It’s just muscle memory for me at this point. You can also treat any infix function as a regular prefix one by wrapping it in parens, e.g. (+).(x, y)

bloaf 5y ago

I personally think a vector library that allowed some form of Einstein notation [1] would be a killer feature for a scientific computing environment. [1] https://en.wikipedia.org/wiki/Einstein_notation https://en.wikipedia.org/wiki/Einstein_notation

eigenspace 5y ago
Ask and ye shall receive (more than ye bargained for): https://github.com/mcabbott/Tullio.jl https://github.com/mcabbott/Tullio.jl https://github.com/Jutho/TensorOperations.jl https://github.com/Jutho/TensorOperations.jl https://github.com/under-Peter/OMEinsum.jl https://github.com/under-Peter/OMEinsum.jl Tullio.jl is the most powerful and interesting to me of the above libraries, but they all have cool strengths.

cycomanic 5y ago

I would argue that an array is something else than a matrix. It's a design decision that matlab (and julia) made, regard every multi-element variable as a matrix. I disagree with that decision, because for most of the code I'm exposed to I don't want matrix operations and it causes issues, e.g. when I move from a scalar implementation to an array implementation of a function.

eigenspace 5y ago
Ah sure, yes we did not need to conflate vectors and matrices with arrays and I sometimes wonder if we made the wrong choice there. I guess I'd say that then someone would get to own the syntax [a, b, c] it'd either be a vector of a non-mathematical array and whichever choice was made, someone would be unhappy. I think not too much was lost by having them be the same thing, but the ship has sailed anyways.