# Among Matlab and Python, which language is good for statistical analysis?

Among Matlab and Python, which language is good for general statistical data analysis? What are the pros and cons, other than accessibility, for each?

• This should be community wiki, IMO. – Shane Sep 25 '10 at 12:01
• Would you care to explain why you couldn't also look at R? – Dirk Eddelbuettel Sep 25 '10 at 23:32
• @DirK: I've hardly heard of R. Moreover I wanted to learn some programming language like Python, and then again too I don't think R is anywhere close to python, IMO. I hope it answers your question. – user1102 Sep 25 '10 at 23:37
• Poke around a little here and at StackOverflow in terms of what people recommend for statistical analysis and programming. Many of us feel that there is no real alternative to R. But just like beauty, this is in the eye of the beholder, so good luck. – Dirk Eddelbuettel Sep 25 '10 at 23:41
• In terms of geostatistics (in which I did my PhD), I think that R is very well equiped (see gstat, geoR etc). At least I do not know of such complete coverage of geostatistical techniques in python. And why is R "nowhere near close to python"? I've used both and for geostats I feel R is quite clearly superior. – Paul Hiemstra Dec 16 '11 at 8:56

As a diehard Matlab user for the last 10+ years, I recommend you learn Python. Once you are sufficiently skilled in a language, when you work in a language you are learning, it will seem like you are not being productive enough, and you will fall back to using your default best language. At the very least, I would suggest you try to become equally proficient in a number of languages (I would suggest R as well).

• I am proficient in it.
• It is the lingua franca among numerical analysts.
• the profiling tool is very good. This is the only reason I use Matlab instead of octave.
• There is a freeware clone, octave, which has good compliance with the reference implementation.

What I do not like about Matlab:

• There is not a good system to manage third party (free or otherwise) packages and scripts. Mathworks controls the 'central file exchange', and installation of add-on packages seems very clunky, nothing like the excellent system that R has. Furthermore, Mathworks has no incentive to improve this situation, because they make money on selling toolboxes, which compete with freeware packages;
• Licenses for parallel computation in Matlab are insanely expensive;
• Much of the m-code, including many of the toolbox functions, and some builtins, were designed to be obviously correct, at the expense of efficiency and/or usability. The most glaring example of this is Matlab's median function, which performs a sort of the data, then takes the middle value. This has been the wrong algorithm since the 70's.
• saving graphs to file is dodgy at best in Matlab.
• I have not found my user experience to have improved over the last 5 years (when I started using Matlab instead of octave), even though Mathworks continues to add bells and whistles. This indicates that I am not their target customer, rather they are looking to expand market share by making things worse for power users.
• There are now 2 ways to do object-oriented programming in Matlab, which is confusing at best. Legacy code using the old style will persist for some time.
• The Matlab UI is written in Java, which has unpleasant ideas about memory management.
• +1, good points. On this: "unpleasant ideas about memory management" .. interesting, can you elaborate? – ars Sep 25 '10 at 5:27
• my memory is going somewhere; my experience with Java outside of Matlab usage indicate it is the likely culprit, and running in -nojvm appears to help... – shabbychef Sep 25 '10 at 5:42
• My favorite example of MATLAB strange built-in codes is shuffle, which reorders the data with the ordering returned by sorting a freshly created random vector. – user88 Sep 25 '10 at 8:49
• @mbq: shuffle might be in a toolbox, is not stock matlab. could hardly be worse than builtin randperm which returns sort index of a random vector. Again, this is probably the wrong algorithm (I just learned about the Knuth-Fisher-Yates shuffle here on stats.SE).. – shabbychef Sep 27 '10 at 5:14
• @mbq: the other good part about randperm is that it is affected by the seeding of randn, whereas a mex'ed version of Knuth-Fisher-Yates perhaps cannot access the randn seed 'internally', and a pure .m version of shuffle would probably be too slow. – shabbychef Sep 27 '10 at 16:38

Lets break it down into three areas (off the top of my head) where programming meets statistics: data crunching, numerical routines (optimization and such) and statistical libraries (modeling, etc).

On the first, the biggest difference is that Python is a general purpose programming language. Matlab is great as long as your world is roughly isomorphic to a fortran numeric array. Once you start dealing with data munging and related issues, Python outshines Matlab. For example, see Greg Wilson's book: Data Crunching: Solve Everyday Problems Using Java, Python, and more.

On the second, Matlab really does shine with numeric work. A lot of the research community uses it and if you're looking for say, some algorithm related to a paper in compressed sensing, you're far more likely to find an implementation in Matlab. On the other hand, Matlab is kind of the PHP of scientific computing -- it strives to have a function for everything under the sun. The resulting aesthetics and architecture are maddening if you're a programming language geek, but in utilitarian terms, it gets the job done. A lot of this has become less relvant with the rise of Numpy/Scipy, you're just as likely to find optimization and machine learning libraries available for Python. Interfacing with C is about as easy in either language.

On the availability of statistical libraries for modeling and such, both are somewhat lacking when compared to something like R. (Though I suspect both will meet the needs for 80% of people doing statistical work.) For the Python side of things see this question: Python as a statistics workbench. For the Matlab side, I know there's a statistics toolbox, but I'll let someone more knowledgeable fill in the blanks (my experience with Matlab is limited to numerical work unrelated to statistics).

• The statistics toolboxes in Matlab are quite fun. Is there something similar for R, where for example you can quickly try out a bunch of different function fits (regressions)? – Alex R. Jul 12 '16 at 4:05

I also have been an avid Matlab user for 10+ years. For many of those years I had no reason to work beyond the toolbox I had created for my job. Although many functions were created for a toolbox, I often needed to create algorithms for quick turnaround analysis. Since these algorithms often utilize matrix math, Matlab was an ideal candidate for my job. In addition to my Matlab toolbox of code, others in my group worked extensively in Java since there was clear interoperability between the languages. For years I was completely happy with Matlab, but about 3 years ago I decided to start the slow transition away from Matlab and happy to say I haven't opened it in about a year now. Here are the reason for my move:

• I work with online and offline computing systems, the licensing system was always a headache. It always seemed to happen that when we most needed Matlab, the license would expire or suddenly have issues. This was always a headache. Also, if we ever needed to share code, and the other party did not have licenses for the same toolboxes, this created a headache. It's not free
• I often need to create presentations. Even though Matlab provides extensive tools for creating figures, which makes it very powerful for algorithm design, but saving the figure such that it could be inserted into a presentation and look nice is no simple task. I often had to insert an EPS file into Adobe illustrator to remove all the garbage, fix the fonts, and clean up the lines. There are some tools to help with this on the file exchange though (export_fig.m).
• I often get Matlab code from others. When this happens, I almost always rewrite it because: their API is not compatible with my data, their code doesn't make sense, it's slow, it doesn't output what I need,... Basically people who develop in Matlab are not software engineers and Matlab does not encourage any type of design principle.
• I'm a power user. I like terminals. I hate the GUI--hate it. And when they added the "windows" style ribbon, I hated it some more. Basically their tweaks to the GUI and terrible memory management pushed my last button and I decided to leave. Using the -nodesktop option is good most of the time, but has it's issues.
• Many possibilities to design of functions (using OO, or functional design), but none feel right, most feel adhoc. I do not get satisfaction from designing good functions in Matlab
• The community is big, but isn't easy to share and find good code. The file exchange isn't that great.

This is only a few of my many gripes with Matlab. It's one shining attribute: it's easy, really easy to write code quickly (if not ugly). I did leave it though, and my quest led me through Clojure->JavaScript->Python<->Julia ; yeah, I've been all over the place.

• Clojure: beautiful functional language. My reason for using Clojure was its ability to script Java. A lot of our "big" code base is in Java, so this made a lot of sense. At the time a lot of scientific processing was not readily available, and not a lot with visualization either. But I think this is changing.
• Javascript: after seeing the benchmarks at http://julialang.org/, and since I was definitely interested in the visualization capability of D3, I decided to try JavaScript. JavaScript is surprisingly very fast. But if you really want to hate yourself, learn JavaScript.
• Python: Python has an amazing community and has lots of great projects going on. The IPython Notebook is amazing for many reason (one of them being simple copy/past of figures into powerpoint). Projects like NumPy/SciPy/Scikit-Learn/Pandas have really made Python fun and easy to use. It's so easy to use on multiple cores or clusters. I've been really happy for the switch.
• Julia: Julia is amazing. Especially for Matlab users. It's in it's infancy though, so lots of changes going on. One of the major drawbacks to Python is it does not have all the built-in functionality that Matlab has. Sure NumPy/SciPy bring that functionality, but it's not built-in and you have to make decisions on whether to be pure python objects or numpy objects. Julia basically has everything you wish Python had coming from Matlab. I'd wait, but this is the best option for Matlab users in the future.