[Numpy-discussion] Matlab vs. Python (Was: Re: [SciPy-Dev] Good-bye, sort of (John Hunter)) (Sturla Molden)

[Ioan-Alexandru Lazar]

Hi everyone,

I've been pretty happy with how Spider went along when I tried it. I use
Emacs but I think Spyder is perfectly usable for someone used to Matlab. A
few HPC-centric of my reasons (I've shamelessly copy-pasted this because
I'm lazy right now):

1. Python is an expressive, full-fledged, general-purpose application
language. There is slightly more boilerplate for doing math-related 
operations (i.e. creating a matrix is not as simple as A=[[1, 2, 3]; [4,
5, 6]] but rather A=numpy.array([[1,2,3],[4,5,6]])). On the other hand,
everything other than math can be expressed without causing severe nausea
and vomiting to the user.

2. The package-module structure of Python allows me to obtain a
significantly less cluttered workspace.

3. There’s built-in support for automatically generating meaningful and
useful documentation

4. The wonderful FFI support allows me to easily work with external C
code. Writing MEX functions is a total mess, I hate that. On the other
hand, it’s easy for me to integrate Python with a custom-compiled version
of UMFPACK or any other solver, and wrappers can be automatically
generated with SWIG for a minimal amount of effort.

5. There is a Matlab wrapper called mlabwrap, so legacy code written in
Matlab is not lost effort.

6. I can use Emacs for my development rather than choosing between a)
working in half-assed environment without code completion or b) working
with Matlab’s incredibly slow and sloppy user interface on Unix systems.

7. I have built-in support for primitives like linked lists, queues,
stacks and tuples

8. I have standards-compliant support for MPI that does not look alien in
Python (there’s support for that in Matlab too, but it feels like you’re
coding on Mars in a library written somewhere in the Andromeda galaxy).
This is extremely important to me right now because the algorithm we’re
implementing will be presented in a conference in September, and I want to
have an implementation that uses standard tools, available to every HPC
developer. On the other hand, I will be able to further optimize
communication (if this will seem to be required) by using a good
distributed-object library like PyRO.

Some details about what exactly it is that I am using it for are on my
blog at http://zencoding.org/archives/137#more-137, although it's rather
sketchy -- I plan to write a slightly more detailed document about my
experience with Python for HPC and how it compares against Matlab's PCS
and DCS. I've been banging my head against Matlab for a while so I'll
gladly write a thing or two on the wiki if you think this sort of use case
is relevant.

One other observation -- Matlab does have some support for parallel
processing via PCS, but you have to pay for that, and it's not too
flexible. There's also DCS for distributed computing. Some of my
colleagues have been using those and aren't too happy about their
flexibility just yet. MathWorks is also not too verbose about what
particular parts of Matlab are parallelized and not, so we've been
randomly stumbling upon parts that were actually parallelized (e.g.
UMFPACK is linked against a multithreaded BLAS) even though we thought
they weren't. Their documentation is detailed, but as far as careful
details about under-the-hood issues and optimization methods, it's a bad
joke. If you need it as a glorified handheld calculator or as a
prototyping tool, it's great, but writing full-fledged apps in it is
painful.

Best regards,
Alexandru Lazar,

Numerical Modeling Laboratory, Politehnica University of Bucharest