3 ms·

Having never written any Julia, I have to ask: is this snippet hard to follow because it's doing a strange thing, or is this just "normal" Julia?

dnautics 8y ago
It's doing a very strange thing. Did you read the op? Arbitrary matrix reop takes a 2-ary functions and reassigns the *,+ operations for matrix multiplication to those operations. Was it just the results you couldn't follow or were other things confusing? Typically I find Julia to be one of the easiest PLs to read.... Another confusing aspect is that my function is returning a lambda and assigning it to a unicode symbol (valid identifier name in Julia). That's a bit bad in terms of code clarity but aligns with the intent of the author. The only other confusing thing could be that comma arrays are column vectors, because I deleted some REPL responses for brevity.... If you actually use the Julia repl, this would be clear.
- semi-extrinsic 8y ago
  The (abstract) operator itself and the results were understandable. It was more stuff like: how do I see the function returns a lambda? What is foldr? Groking the typing, which is somehow reversed of what I expect (m::int instead of int::m). The list comprehension-like indexing, and why one for is outside the foldr, not zero or both -- and why you can't write this as implicit vectorization like on a Numpy array or in Fortran, instead of explicitly iterating.
  - dnautics 8y ago
    gotcha. I was writing for terseness and timepressure in the small hn box, so I would say that this is not representative of how one should or even, I generally would have written. 1) I probably should have put an explicit "return" on the lambda statement, since it's unclear with the strange tabbing. 2) foldr is reduce, with an order guarantee (I think reduce might do a binary or parallel reduction if given the chance). I probably should have done reduce. 3) the type-first technique is a C-and-friends thing - found in C, Java, Go. Functional languages Typescript, F# do type-second, as does pascal if we reach far back enough (albeit they do it with the single colon operator) I think type-first contributes to the difficulty of reading C types but i don't have evidence (http://unixwiz.net/techtips/reading-cdecl.html http://unixwiz.net/techtips/reading-cdecl.html) 4) now that I think about it, julia has a dot broadcast notation which I probably should have used. This might have been better (but possibly too terse? I don't know) function matmul_reop(mulop::Function, addop::Function)::Function return (m::Matrix, v::Vector) -> [ reduce(addop, mulop.(m[row,:], v)) for row in 1:size(m,1) ] end I wish julia had a row iterator, (and once wrote one myself) because that would make it even more terse... That is on the issues tracker, so it will probably make the standard library.

dnautics 8y ago

It's doing a very strange thing. Did you read the op? Arbitrary matrix reop takes a 2-ary functions and reassigns the *,+ operations for matrix multiplication to those operations. Was it just the results you couldn't follow or were other things confusing? Typically I find Julia to be one of the easiest PLs to read.... Another confusing aspect is that my function is returning a lambda and assigning it to a unicode symbol (valid identifier name in Julia). That's a bit bad in terms of code clarity but aligns with the intent of the author. The only other confusing thing could be that comma arrays are column vectors, because I deleted some REPL responses for brevity.... If you actually use the Julia repl, this would be clear.

semi-extrinsic 8y ago
The (abstract) operator itself and the results were understandable. It was more stuff like: how do I see the function returns a lambda? What is foldr? Groking the typing, which is somehow reversed of what I expect (m::int instead of int::m). The list comprehension-like indexing, and why one for is outside the foldr, not zero or both -- and why you can't write this as implicit vectorization like on a Numpy array or in Fortran, instead of explicitly iterating.
- dnautics 8y ago
  gotcha. I was writing for terseness and timepressure in the small hn box, so I would say that this is not representative of how one should or even, I generally would have written. 1) I probably should have put an explicit "return" on the lambda statement, since it's unclear with the strange tabbing. 2) foldr is reduce, with an order guarantee (I think reduce might do a binary or parallel reduction if given the chance). I probably should have done reduce. 3) the type-first technique is a C-and-friends thing - found in C, Java, Go. Functional languages Typescript, F# do type-second, as does pascal if we reach far back enough (albeit they do it with the single colon operator) I think type-first contributes to the difficulty of reading C types but i don't have evidence (http://unixwiz.net/techtips/reading-cdecl.html http://unixwiz.net/techtips/reading-cdecl.html) 4) now that I think about it, julia has a dot broadcast notation which I probably should have used. This might have been better (but possibly too terse? I don't know) function matmul_reop(mulop::Function, addop::Function)::Function return (m::Matrix, v::Vector) -> [ reduce(addop, mulop.(m[row,:], v)) for row in 1:size(m,1) ] end I wish julia had a row iterator, (and once wrote one myself) because that would make it even more terse... That is on the issues tracker, so it will probably make the standard library.