Python vs. Matlab
Alexander Schmolck
a.schmolck at gmx.net
Thu Jan 23 16:43:27 CET 2003
Mongryong <Mongryong at sympatico.ca> writes:
> Python vs Matlab (or any other similar language).
>
> Any opinions on this comparison? Benchmarks? Functionality?
>
Matlab
------
+ 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
Python
------
+ 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).
alex
More information about the Python-list
mailing list