Matlab versus Python

Without too much of a preamble, here’s a rather subjective comparison of Matlab and Python. To at least compare apples to oranges, rather than vineyards to farming complexes, let’s approach the issue with the design of electric machines in mind.

Here goes, pros and cons of each.

Matlab

+Huge user base

Matlab has a huge user page. Meaning, whenever you have a problem with syntax or how-to-do-this-and-that, you have a 95 % change of finding your answer behind the first google result.

The situation isn’t much worse for Python, true, but in my experience there’s still a notable difference in favour of Matlab.

Mind you, I’m speaking specifically about number-crunching-related issues here. An exception will follow.

+‎Fast

Matlab can often be quite a bit faster than Python, and seems to be getting faster while we speak. This is largely due to its quite advanced just-in-time (JIT) compiler. Meaning, your code gets compiled (on some level) into machine instructions before it’s run, yielding significant speedups in loops etc over purely-interpreted code.

Now, Python does have the Numba module (at least for the Anaconda distribution), providing some JIT functionality. In some cases, it may even result in faster execution compared to Matlab. However, using Numba properly is still one level harder than simply typing code into Matlab.

+‎Easy profiling

Matlab ships with a built-in profiler, which makes code optimization 9000 times easier. And I’m being very conservative with that figure.

By contrast, standard Python’s profiling functionality is much more limited, restricted to evaluating functions as a whole. Luckily, there’s a user/community made package (called line_profile(r) if I remember right), offering capabilities somewhat close to Matlab’s level. Still, I find its use a little more clumsy compared to Matlab’s awesomeness.

Profiling beauty. And by that, I mean the profiler. And the Femshep-fanart on the background, too. Obviously.
+‎Variable output arguments

Matlab supports a variable number of output arguments by default. Moreover, you can know the number of handled outputs from inside the function being called.

This can be extremely handy. For instance, by computing an optional high-cost second output argument only when it’s actually used somewhere. By contrast, achieving the same thing in Python requires specifying it as an input flag (which, in turn, is much easier to do than in Matlab – see later).

On the other hand, it can get confusing, too. So it’s a double-edged sword, really.

+Dummy arguments

Matlab supports skipping an input or output argument with the tilde character ~. Python’s None can achieve the same thing (as input), but I personally find Matlab’s way easier. Futhermore, skipping an output argument isn’t possible at all in Python. Instead, you’ll have to use a dummy argument (often _ by convention), that’ll then have to be garbage-collected later.

+Numerical packages

Matlab ships with the UMFPACK sparse matrix solver, as well as the MKL linear algebra library. This means very high performance computations.

By contrast, using UMFPACK from Python requires installing or compiling (which can be a huge pain in the backside on Windows) it separately. Alternatively, you can use the default SuperLU library that ships with Python. In small problems (<4000) it doesn’t lose badly, but on anything larger UMFPACK will give it the ass-whooping of the century.

Problems with second-order elements count as “anything larger”.

Likewise, linking to a linear algebra library can be a installation-time mess (although I think Anaconda nowadays ships with MKL, too).

-Costs a little

Matlab requires moneyz to use. I think a standard single-person license is in the order of 150 EUR, or 800-2000 EUR for businesses. Not very much for people/businesses of stable finances.‎

-Can cost a lot

Matlab can cost a lot if you start piling on all the toolboxes (easily the price of a single basic license, each) and additional licenses.

-‎Interfacing problematic

Linking Matlab to external C/C++/FORTRAN functions can be problematic. Doing the same for DLLs even more so.

-Poor access to data types

Matlab hides much from you. Want to modify the values of a sparse matrix directly, while keeping the row&column indices intact? Write a piece of C code for that.

-‎Variable input arguments

Writing functions with optional input arguments is plain awful. Be prepared with lots of text parsing.

-Default input arguments

K-k-killl meeee.


So that was Matlab, but what about Python then?

A wild snek appears!

Python

+Free

Python is free to use, that much is clear. Furthermore, the license is non-infectious, meaning you can even use it to write commercial software. Which is a huge plus in my opinion.

Sidenote: I nowadays approach pretty much anything with the business side in mind. Thus, I’m not very fond of GPL and similar licenses.

“Oh hey Colossal Corporation Inc, here’s the custom code snippet you ordered. Just don’t use it in anything that a customer might see – that would mean you’d have to expose your entire codebase since I used a GPL-licensed line inside mine!”

+‎Actual language

Python is a very versatile language, not limited to numerical analysis at all. Of course, from the point of numerical analysis specifically, this matters relatively little.

+‎Variable input arguments

Python’s support for variable, optional, and default input arguments is just great. (On the other hand, I think like Java’s approach even more. But I digress.)

+‎Interfacing

Using pieces of C code is very well supported even within Python itself. Furthermore, linking to external DLLs is easy, and for instance Numpy will readily provide you with all the pointers you need.

+‎Access to data

Unlike Matlab, you CAN access the low-level arrays underlaying all the (sparse) matrix datatypes.

-‎High-performing installation

Getting the most (or even 80%) of your computer’s number-crunching capabilities is not given. No install and forget here. Instead, you have to specifically make sure / specify which linear algebra libraries to use, and linking them properly might or might not work. And like mentioned, getting the sparse matrix package UMFPACK to work on a Windows computer can be a huge pain.

Another business example:

“Here’s your code snippet. To make sure you get most out of it, remember to download and compile OpenBLAS or MKL and make sure you have LAPACK installed before that!”

-‎Speed

Even with Numpy and folks, Python can fall a way behind Matlab in terms of execution speed. This is the case especially with long or repeated loops.

An example relevant to myself would be the nonlinear analysis of an electrical machine. It doesn’t matter how well you vectorize your code, updating the material properties, then assembling the Jacobian matrix, and then assembling and solving the linear system, and finally updating the solution – that’ll be dozens of lines of code, easily.

Extra + | Data science and machine learning

Python is the language for data analytics, statistics, and machine learning. (Of course R is the number one language for statistics, and lower-level neural network stuff etc. is written in C(++), but this is a comparison between Python and Matlab here.) It’s got all you need, and more.

It even goes so far that if you google for some completely general intro-level stuff, all the examples and tutorials are in Python. Admittedly, the reason for this is most likely the exploding interest in all things data. After all, Python is a rather beginner-friendly language compared to others, and it’s a far better business to teach people something easy rather than hard. But no matter the cause, my point still stands.

Conclusion

So there you have it – a largely subjective comparison between Python and Matlab, written from the point of numerical analysis.

All things considered, I’d call it a draw. What’s your opinion?


Have enough R&D resources to tackle everything that comes up? No? Let's get in touch - satisfaction guaranteed!
Matlab versus Python – in numerical analysis

Leave a Reply

Your email address will not be published. Required fields are marked *