| I want Nx1 and 1xN to act differently. It is a form of type safety. I would be fine with defaulting to Nx1x1...x1 as well and have everything be a tensor where you specify which side all the singleton dimensions proceed. Disagree, but they could do this better, matrix just happens to cover most cases. I consder default arguments code smell in every language. Or really more foot-guns than code smell. I discourage them whenever anyone will listen. Disagree on this one. Not super fond of kwargs either but they certainly have their place. If they are going to support it, they should do so well. Agreed I actually prefer to read vectorized notation, I wish it was more consistently performant in Julia, sometimes the for loops run faster, but they take longer for me to read and understand. The exception is if there is an einsum in there somewhere, or the equivalent auto expansions in Matlab, that takes me a few. Personal preference I guess? I've never come across a use for mixed arrays, but everytime I come across an api that returns them I begin cursing. Agreed Typecast rounds instead of floors? That is kinda odd, but not wrong I guess? I haven't ever run across this because I use floor or round explicitly. In 20 years ivrmever noticed the string thing. I'll jave to read about that, thanks! |
Yes. Of course you do. The problem is, you never know what you are going to get. What you actually want is a vector, but Matlab has no such thing, so then you have to write your code in a way that anticipates either Nx1 or 1xN, and handle both. Sounds, simple enough, but I have a lot of code lines dedicated to checking and handling row/column orientation. If only there were real 1D vectors!
> I consder default arguments code smell in every language. Or really more foot-guns than code smell.
I don't really understand what you mean here, but the problem is that in Matlab you handle 'default arg values' with `if nargin < 5, par5 = default_value` etc. It's just worse, and it's perfectly idiomatic matlab.
> I actually prefer to read vectorized notation
My argument is actually that vectorization works much more cleanly in Julia. If in Matlab you have `foo`, which calls `bar` which calls `baz`, etc, then you must make sure that each of these explicitly can handle array inputs. You have to think about arrays on every level, including what happens with axis broadcasting (and probably checking 1xN vs Nx1 orientations on multiple levels). In Julia, on the other hand, you can write your functions `foo`, `bar` and `baz` to handle scalar arguments, and then you vectorize the whole thing with `foo.(args)`.
So vectorized code in Julia is much simpler to write, and also simpler to read. (Just to be clear: writing vectorized Matlab code and vectorized Julia code are things I do all day, every day, so I have a decent basis for comparison.)
> sometimes the for loops run faster, but they take longer for me to read and understand.
Loops vs broadcasting should be basically the same for performance, but sometimes you can get extra performance from a loop, by exploiting algorithmic advantages. But a simple vectorization is just a dot away.
> mixed arrays
It's something one generally tries to avoid, but they are often necessary for passing along arguments to inner functions etc. Tuples are great for this, but it doesn't exist in Matlab.
> Typecast rounds instead of floors?
It's odd, but I don't mind. Mainly, I am annoyed that integers are not well supported in Matlab.
> In 20 years ivrmever noticed the string thing
The "strings" are new, a couple of versions back. Of course, you will notice that "string" is actually a 1x1 matrix of strings, so length("hello") equals 1. And indexing into strings is actually indexing into the array of strings. So `str = "hello"` then `str(1)` returns the string itself, and `str(2)` errors.