Transitioning to Python from Matlab – Day 1


People are fast to point out that transitioning from Matlab to Python is easy with NumPy and SciPy. That is, however, far from the case. Having become fed up with the arcane Matlab programming language I figured that the summer would be a great time to move my work to Python.

The setup

My main computer runs Snow Leopard and I have become a stickler to running all my applications in 64bit. Not for performance gains (although this does enable the use of OpenCL which  is 64bit only), but for consistency. Actual computations are left for my schools computer cluster which uses some linux distribution and are also 64bit machines.

  • Python-2.6
  • Matlab 2010a on the mac (64bit)
  • Matlab 7.6 on linux (32+64bit)

Great, but what about my old code

The first hurdle to the transition is making all that old Matlab code work. Once in 1999 someone discovered this problem and wrote PyMat which interfaced Python and Matlab by using Matlab’s shared libraries. While perhaps it still works, the code felt very antiquated. It has been over 10 years since the last update! So I wrote a new version from scratch which was a delight for learning more of the internals of Python.

The nice thing about the module I wrote is that is allows for all matlab functions to be called directly so that:

X = matlab.rand(numpy.array([100 100]), 1)

The following snippet calls Matlab’s native rand function and the result is stored in a numpy array in X. The 1 at the end of the snippet tells the python interface to expect a single return value. In the future this may not be required.

A difficulty in doing this interface is that each Matlab version has slightly different set of function names. This makes the interface have to be slightly tweaked for each version.

Functions that don’t exist

It surprises to see how many helpful functions Matlab has. Particularly saving and opening images and other assorted data types. Numpy while very good doesn’t have a easy to use save routine nor can Numpy natively open arbitrary images. While naturally this is because these features are not part of the project’s mission statement, it does mean more work for the valiant researcher.

Quickly you will see that a handful of functions must be written to do these simple tasks, and while there are plenty of stable modules including PIL and Pickle for opening images and saving data (respectively), it does mean more steps between you and your work.


Finally by the end of the day you will begin to miss the ugly, Java-esc, Windows-esc and X11-est IDE that Matlab has featured for probably over a decade. Being able to inspect variables, even see the variable names being used, and the ugly but useful debug features is badly missed as well.

By the end

By the end you realize why Matlab exists and is widely used. However, unless someone ventures out and fixes the wholes that exist with Python as a Matlab alternative, people will never have an alternative. Unifying the tools that exist for Python and adding interoperability with Matlab are the first steps to making a really good alternative to the most widely used piece of software in the sciences.