Personally, matlab drives me absolutely up the wall when it comes to ANYTHING other that flipping big matricies around. As a domain-specific tool for linear algebra, I certainly prefer it over R, but as a general purpose tool it makes me want to pull my own teeth out.
It's just not designed to make good pipeline tools that are maintainable, easily tested, and easily refactored, and never was. Its ability to handle things like "easy and sensible string and path manipulations" are ... rudimentary, at best, and a weird pastiche of C, fortran, java, and whatever else language was faddish when that feature was added.
I have more or less one real annoyance with the technical content of matlab. (One-indexing i can live with):
size([1])
ans = [1 1]
which is flatly wrong, and numpy gets it right:
In[0] np.array([1]).shape
Out[0] (1,)
Python is actually a general purpose language which has a mature scientific stack, and i feel more secure in my numerical computations there because i can have a robust test suite and command line entry points into my code that increase my confidence that my code's doing what i think it should be, and makes it easy to use.
Packaging is more or less a coin-flip. Python packaging is a giant faff; matlab packaging is nonexistent (you have to vendor every dependency yourself) and expensive (your users have to shell out for the toolboxes you use, and/or have the MCR installed and can't edit your code).
I'll maintain matlab when i have to, but i don't enjoy it very much.
One behavior I like about Matlab is that functions are functions. Arguments are passed by value and there's no way a function can modify its arguments (well, except perhaps objects which are less common).
Matlab will try to optimize and avoid a copy if the function does not modify the argument. Matlab is also (sometimes) smart enough so that A=f(A) will modify A in place instead of making a copy.
This is what I expect from a math oriented language. Maintain the illusion of referential transparency but optimize under the hood if possible.
Also Matlab has a reasonable JIT compiler. And a good debugger.
I no longer use Matlab but it is a very productive environment for scientific computing (simulations, exploration).
Many numpy functions have an `inplace` (or maybe there’s an underscore there?) argument that tells whether to perform the operation in place or return a new array.
Yeah, I was more than a little surprised to see his perspective - I thought for sure he was going to rave about Julia, pick on Python a little, and skewer Matlab. My graduate thesis advisor forced me to use Matlab to do all of my master’s thesis work, and I found it to be about the most frustrating environment possible, at least for any actual programming. I’m a little shocked to read that anybody uses Matlab outside of a pure academic environment… I guess I just don’t work on sophisticated enough projects?
It's extremely popular in control engineering domains.
You would find it an impossible task to track down an automobile manufacturer or a platform level supplier which doesn't leverage Matlab & Simulink all over the place.
I know of a few major trading firms that use MATLAB for a lot of their analysis. In many companies that hire engineers they also often use MATLAB as it's sufficient for what they need those engineers to do (and programmers at those companies use different languages), and many engineers come out of their degree feeling most comfortable with MATLAB for scientific computation.
Historically, the free or cheap student licenses were believed to pay them back when those students moved into industry and were inclined to install what they were familiar with. There's still a lot of MATLAB in college teaching curricula.
Part of when I help on-board newly graduated colleagues (typically engineers and scientists, not hired as programmers) is to reassure them that they can get a MATLAB license if will help them get productive quickly. This has happened once or twice. Many of them never bother, as they get busy enough with CAD and basic design work, that they don't really find a use for scientific computation. But to an increasing extent, they're willing to make the hop to Python, possibly just because it's a popular buzzword, but in any event, they are able to get themselves up to speed pretty quickly.
> (...) ANYTHING other that flipping big matricies around.
but... what else is there, in life? Flipping big matrices around is nearly everything I do, and the python stuff seems too cumbersome for me to bother.
You cannot create a literal array without calling a function. You cannot concatenate arrays without calling a function, and moreover this function has a different name depending on whether your arrays are full or sparse. The @ notation for matrix products is horrendous (and .dot is even worse). Arrays are not first-class objects of the language, and you have to use an external library. This is more infuriating by the fact that other, more complex data structures like dictionaries or strings are natively supported, even if they are mostly useless for numerical computation.
Compare the clean matrix flipping in octave
z = [ kron(speye(rows(y)), x) ; kron(y, speye(cols(x))) ]
to the python monstrosity
z = scipy.sparse.vstack([
scipy.sparse.kron(scipy.sparse.eye(y.shape[0]), x),
scipy.sparse.kron(y, scipy.sparse.eye(x.shape[1]))
])
In and of itself, it's not wrong. Where it goes sideways is how Matlab chooses to allow matrix operations against these 1x1 matrices that should otherwise fail, how Matlab chooses to iterate (over columns, unless it's a "row-vector"), and how Matlab chooses to define length (the max dimension).
a 1-tensor is not a 2-tensor, and scalars have no area.
matlab:
size(1)
ans = [1,1]
python:
In[0]: np.array(1).shape
Out[0]: ()
0-tensors are not 2-tensors, either. You can read matlab's result as "scalars are matricies that have one row and one column", and that's nonsense -- matlab effectively lacks a scalar numeric type; under the covers, everything is a matrix.
Arrays are not tensors (except when they are, of course). If you want to talk about (n-dimensional) arrays of numbers why wouldn’t the word “array” be enough?
It's not about what nomenclature numpy uses, it's about the word tensor being used by some people to refer to arrays for no discernible reason at all (except the coolness factor, maybe?).
I guess i don't see your point. I'm a biomedical researcher, we do lots of numerical analysis in my part of the world, these are the words we use to unambiguously refer to different entities and concepts of linear algebra.
This is not a CS data structures 101 thing, this is a "there are proper names for mathematical entities" thing. I think you're confusing representation and existence, maybe.
yes, often. This comes up all the time in tissue mechanics, because continuum mechanics turns out to be quite useful for studying the mechanical properties of soft tissue.
In that case I think you can easily see my point. Numerical computing has done pretty well since the fifties using just "multidimensional arrays".
[Edit: You may care about vector algebra but 99.999% of the users of numerical arrays do not. I just think that the proper term in a general discussion about data structures in numerical computing like the one here is “array”.]
[Edit2: in case you’re really not familiar with the abuse of the term, people do now often use the word tensor to talk about multidimensional arrays that have nothing to do with the mathematical entity called tensor. And I don’t think either matlab or python pretend that they have tensors.]
It's just not designed to make good pipeline tools that are maintainable, easily tested, and easily refactored, and never was. Its ability to handle things like "easy and sensible string and path manipulations" are ... rudimentary, at best, and a weird pastiche of C, fortran, java, and whatever else language was faddish when that feature was added.
I have more or less one real annoyance with the technical content of matlab. (One-indexing i can live with):
which is flatly wrong, and numpy gets it right: Python is actually a general purpose language which has a mature scientific stack, and i feel more secure in my numerical computations there because i can have a robust test suite and command line entry points into my code that increase my confidence that my code's doing what i think it should be, and makes it easy to use.Packaging is more or less a coin-flip. Python packaging is a giant faff; matlab packaging is nonexistent (you have to vendor every dependency yourself) and expensive (your users have to shell out for the toolboxes you use, and/or have the MCR installed and can't edit your code).
I'll maintain matlab when i have to, but i don't enjoy it very much.