[OLPC library] MATLAB for OLPC?

[Mel Chua]

I happened to mention this email thread to a friend who works at
Mathworks on MATLAB and related code. The part of the conversation
that contains some notes on MATLAB and the possibility of a port or a
release of the earlier version follows.

The short version is that port/earlier-version-release is probably not
going to happen at this company from his impression of how the
corporation runs, it would be very tough technically speaking to make
MATLAB work on the XO, and we're probably better off using Octave or
something similar since we'd end up rewriting pretty much all of
MATLAB to port it to the XO anyway, but when we're working on a
solution we should consider compatibility with existing similar tools
of both open and closed source varieties (so kids can use existing
libraries and datasets from a wider range of places).

-Mel

"For starters, MATLAB software is programmed in three main languages.
The core computing and numerical analysis routines are optimized in
C/C++, probably hand tuned in assembler at a few crucial junctures but
that's beside the point. The programming environment is built up
largely in MATLAB code, which serves to implement high-level language
features as well as the gazillion and one global functions. The GUI
layer and, increasingly, things like XML parsing and file I/O, are
handled by an internal Java VM controlled by the MATLAB interpreter.
This blend of technologies is, of course, a design choice. But it's a
very effective one.

Command-line MATLAB does exist (on Linux at least), and it does not
require Java nor quite as much of the foundation M-code. I'm not sure
how much space that saves, but I'll grant that it significantly cuts
down on the problems of code migration, many of which are GUI-related.
I will caution that doing this not only removes some capabilities, but
reduces the number of M-files from sites like MATLAB Central that work
properly.

Taking the GUI off the table entirely might seem like a reasonable way
to get corporate to sign-off on open sourcing components, but is the
wrong approach, for two reasons besides the above. First, this is
still a very IP-conservative company, and my suspicion is that if they
ever did come to the bargaining table it'd be after striking much of
the remaining language features that separate the product from
lookalikes. Secondly, the GUI is important. We get away with charging
$2000 a seat because most scientists aren't really programmers, and of
those who are, 90% hate emacs-style development and will take every
convenience feature they can get.

On the subject of transcribing MATLAB to numpy, aside from the
aforementioned smattering of dependencies on MATLAB environmental
features, I would say the answer to your question is: very hard. Not
only are the numpy types not a one-to-one mapping with MATLAB types;
MATLAB syntax is optimized around certain assumptions about matrix
iteration at a deep level. I don't fully understand the inner
workings, but my impression is it would require tweaks in the Python
interpreter and stack to get it running MATLAB computations at a
reasonable efficiency.

If your grand plan for this M-to-Python interpreter is to bring in
utilities that help make up for what they don't give us, I'd say take
another look at Octave. I believe they are doing this the right
way--they recognize that, besides being a language and a software
product, MATLAB is also an architecture. Even an M-interpreter and
runtime with incomplete compatibility is probably better than
attempting source translation. And they do make compatibility a goal.
I don't know if you remember, but when I did <a project in college> I
was able to tweak my original M-code (which used the DSP toolbox) to
also run on Octave with the Octave-Forge library. As I understand it,
this next release of Octave is another step in that direction,
especially in the area of graphics.

One minor caveat to all of this is that unless you're handed a working
implementation of the language layer of R2008a, you won't get the
newly introduced classdef syntax. Mostly irrelevant, since it won't be
in widespread use for some time. I just happen to find it pretty
spiffy :-)"