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 :-)" _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel