Python vs. Matlab

Alexander Schmolck a.schmolck at
Thu Jan 23 16:43:27 CET 2003

Mongryong <Mongryong at> writes:

> Python vs Matlab (or any other similar language).
> Any opinions on this comparison?  Benchmarks? Functionality?


+ very good plotting
+ the "standard" in many fields that do extensive number crunching. Free code
  published by scientists in several areas (e.g. pattern recognition) is
  likely to be matlab and there is lots of it.
+ relating to the above point: large codebase (both free and commercial) and
  large supply of builtin functionality (Numeric and Scipy cover quite a lot,
  too, but not as much yet).
+ stable and mature. More so than either Scipy (currently v0.10, I think) and
  Numeric (currently not properly maintained and about to be superseded by
  numarray; I hasn't to say that Numeric isn't dead or abandonned, but as
  numarray was supposed to take over sooner than now seems likely, there are
  currently inadequate ressources for its maintenance).
+ convinient notation for linear algebra (M * N' == matrixmultiply M and the
  transpose of N)
+ nice output formatting for matrices (much more convienient than that for
  Numeric arrays, if you are using them for matrices)
+ pretty good "IDE"
- relatively unpleasant and crummy language
- few non-numbercrunching libraries and facilities
- therefore often a bad choice if you need to do things other than linear
  algebra, even if you also need to do plenty of number crunching.
- braindead C-interface
- proprietary and expensive


+ well designed language
+ loads of free general purpose programming libraries
+ Numeric and Scipy deliver pretty good (however more array than matrix
  oriented) Numerics packages and many people are using them intensively for
  all their work. Although matlab is still more popular, python is rapidly
  gaining ground in the scientific community and in many aspects the design of
  Numeric and Scipy is IMO superior to matlab's.
+ free in every sense of the word
+ rapidly gaining popularity as an alternative to matlab
+ reasonable C-interface as well as many projects that aim at painlessly
  interleaving C or C++ code (e.g. weave) in python code or other ways of
  boosting performance (psyco). My guess therfore is that it is easier to get
  code to run faster if you must in python than in matlab, but I have no
  benchmarks to back this up.
- no decent plotting right now (but chaco looks promising)
- awkward notation for many important matrix manipulations (partly due to a
  lack of available operators in the language)
- not as many number crunching and scientific libraries and code available as
  for matlab

R and Octave

- I don't know much about those, so I take this with a grain of salt: Neither
  appears a good choice to me compared to either matlab or python, because
  they both suffer from their special purpose nature (unlike python), but
  don't offer as rich a functionality as matlab and are not (I think) anywhere
  near as popular as either matlab or python, even for scientifc computing. I
  might be wrong, so best have a look yourself.
In summary, although matlab still seems to be the more popular number
crunching choice right now, for people who can afford it, my guess would be
that python's popularity for such purposes will increase considerably over the
next couple of years, especially as it doesn't suffer from matlab's inherent
design flaws that limit its further growth.

My solution for the moment is to use both: I wrote a transparent wrapper for
from python to matlab that lets you use matlab's functions as if they were
just another python library (taking care of most of the conversions and
intricacies behind the scenes). This allows me to quickly leverage and
evaluate existing matlab code while working within python (and it is easy to
replace those bits with python code later). I also wrote a general plotting
wrapper on top of that that is designed to use different backends, so that
once chaco is ready I could in principle just change the backend without
rewriting any of the code that uses plotting functionality (well, in theory at
least:). Since I mainly deal with matrices I also wrote a library to make
their use more convinient than Numeric arrays (or Numeric's Matrix).

All this code is free, but I haven't yet got around to publish it, but am
willing to supply it as preview version (just email me).


More information about the Python-list mailing list