3 ms·

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 t

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

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.