[SciPy-dev] mlabwrap and scipy -- calling matlab from python

[Alexander Schmolck]

Hi,

I'm the author of mlabwrap a very high-level python to matlab bridge that's
currently hosted at <http://mlabwrap.sourceforge.net>. There has been talk
off-list about integrating mlabwrap into scipy and I'm following up on Jarrod
Millman's suggestion to move this on-list.

Robert Kern has suggested that mlabwrap could be the first scikit package
hosted under scikits.scipy.org and I think it would be great to have mlabwrap
integrated into the greater scipy-cosmos -- whilst mlabwrap is clearly too
specific to go into scipy proper, matlab is very widely used and as python is
getting increasingly popular for scientific computing I think there should be
considerably demand for painlessly integrating matlab and python and being
somehow part of scipy should increase exposure and help maintenance.

The only caveat is that I myself have limited resources (I'm currently writing
up a thesis and am also looking for a job [1]), so I can't pour much time
into helping to set up the scikits infrastructure.

I have however spent a good chunk of this weekend to bring mlabwrap up to
scratch and just uploaded a new (alpha) version of mlabwrap to above
sourceforge page; numpy and 64bit machines ought to work now (Numeric is also
still supported) and thanks to Matthew Brett installation should be even
easier (under linux that is; I have only been able to test the new version
under 32 and 64-bit linux, confirmation that windows and OS-X installs also
work would be very welcome).

Mlabwrap has been pretty stable so far (no major bug reports as of yet and it
has been around for a few years with users on all major platforms), but
unfortunately I haven't had as much time to test this release as I'd like to,
hence the alpha -- the unittests pass fine but there might be unspotted memory
violations etc.

There are 2 changes related to 64-bit readiness that might have introduced
issues 

* I've changed the handle for the matlab session (lHandle) from int to a
  Py(C)Object

* I've changed int to npy_intp at various places; I'm still effectively using
  ints and PyArray_FromDims in the matlab-array->ndarray direction -- as far
  as I can tell The Mathworks haven't yet properly nailed 64 bit support yet;
  there are mwSize and mwIndex types analogous to npy_intp, only that the docs
  in most places claim they are the same as int (somewhat implausibly, since
  it appears that from 7.3 you need to use them for 64-bit sparse arrays:
  <http://www.mathworks.com/access/helpdesk/help/techdoc/rn/index.html?/access/helpdesk/help/techdoc/rn/bqx0fzj-1.html&http://www.google.com/search?&q=7.3%20mwsize>).

  What I've done is that I've used mwSize and mwIndex in place of int where
  appropriate (and #define'd them as int if they are undefined), but cast to
  int (or int*) on calling PyArray_FromDims. I'm not sure what a better
  solution would currently be; this appears to work on 32 and 64-bit linux.

I'd be grateful if people could give it a spin and even more for any code
reviews or improvements (the code isn't very long -- about 500 non-comment
lines of C++ and python each and only the C++ is problematic); valgrinding
would also be very welcome (I haven't got around to it so far with the newest
version). If you have experience porting Numeric code to numpy and with 64-bit
issues and you'd like to use existing matlab code from python, now would be a
great time to try mlabwrap out and/or have a look at the code. The sooner a
shiny new mlabwrap 1.0 version ends up wherever it's meant to end up, the
better.

cheers,

alexander schmolck


Footnotes: 
[1]  So should you happen to be currently looking for someone with scientific
     computing, pattern recognition and cognitive science expertise and pretty
     strong skills in python, matlab as well as a number of other languages...