Comment by jacobolus | Hacker News Reader

Comment by jacobolus | Hacker News Reader

Parent Full thread

Interesting. In my own experience trying to implement the same image processing algorithms in Matlab vs. numpy, the work took about the same amount of effort any time arrays were limited to 1-2 dimensions, all the code was simple numerical stuff, and it wasn’t necessary to break the code up into multiple functions.

The Matlab one-file-per-function thing, the lack of namespaces, and general lack of code structuring primitives makes it much less pleasant than Python for programs bigger than about 100 LOC though.

Dealing with higher-dimensional arrays, more sophisticated plotting, data munging, string processing, interfaces with external systems, etc. all left me banging my head in Matlab though, whereas Python makes it all a breeze.

Numpy’s broadcasting feature is also super nice, compared to wrapping everything in bsxfun calls in Matlab.

I wonder how much the @ operator in Python 3.5 will help students. Hopefully numpy can deprecate and phase out their "Matrix" object, and end the confusion about the meaning of basic operators.

I would imagine, for a beginner, in Python the difference between a list and a numpy array can be confusing. And in numpy, column vectors and row vectors are a different thing. Whereas in Octave/Matlab "everything just works" in the do-what-I-mean sense.

> The Matlab one-file-per-function thing

By the way, Octave does not have that limitation.

> And in numpy, column vectors and row vectors are a different thing. Whereas in Octave/Matlab "everything just works" in the do-what-I-mean sense.

I think this is actually one of MATLAB's biggest flaws. Without a true 1D array like numpy has, there is no way in MATLAB to tell the difference between a 1D sequence of values, and a 2D sequence of values with only one value along one of the dimensions.

This has led function developers to try to guess. But they guess inconsistently. Some functions treat row and column vectors differently, some treat them the same. Of those that treat them the same, some return them with the same orientation, while other force a particular orientation. Some operations ignore dimensions (length), others don't (for loops). Some maintain dimensions (size), some don't ([:]).

So everything may seem to work, until your code that has been working fine for years suddenly breaks, and you realize it is choking up because one of your experiments has only one trial, or one of your experiments has multiple trials each with one result, and some of the functions you are using start reacting differently to this. Then you have to go through each function and figure out on a case-by-case basis how it handles row and column vectors.

Or worse yet, it seems to run fine, but is silently doing the wrong thing. Which you probably would never know, because most MATLAB code isn't unit-tested.

Just want to leave a comment about the "Matrix" object. I remember the first day I got started with NumPy. Coming from MATLAB, I really felt tempted to use it. However, I also saw an recommendation (can't remember if I read this in the NumPy documentation or in an online forum) that ndarrays are more widely supported. I never really bothered about `Matrix` then, and honestly, I have never ever seen anyone using it. Maybe you will find some examples on GitHub if you really search for it, but it is practically non-existend.

Reply on news.ycombinator.com