Redoing Matlisp?
in [Lisp]
|
From: mark.hoemmen@gmail.com on 19 Sep 2006 01:05 Greetings! I'm thinking of reworking / redoing Matlisp to support a whole framework for optimized linear algebra that exploits the BLAS and LAPACK. Here are some features that I'd like to see: 1. Matrix views (like in the GSL) -- handy for the recursively-structured approach to linear algebra that's popular nowadays, and also handy for my research. I want strided matrix views too (GSL only has "window" matrix views which are like subblocks). 2. In-place operations -- Matlab doesn't support the in-place factorizations that I want to do in order to save memory. 3. Different (implicit) representations of things like matrix factorizations -- Matlab doesn't give me access to things like the Householder vector representation of a Q factor in a QR factorization, which I want because it's a compact representation of the _entire_ Q factor for a tall and skinny matrix. 4. Using macros and series operations to enable efficient iteration-over of things like strided matrix views (the scanner does the indexing so you don't have to pay for index overhead every time you call a matrix-aref kind of function). 5. Exploiting CLOS to get automatic and efficient handling of matrices of different data types. 6. Potential for parallelization (e.g. interface to ScaLAPACK or my own parallel routines, or even an MPI interface). Matlab is going that way too (There's Matlab*P, plus Cleve has been giving talks about the MathWorks' parallel Matlab (that crashed during one of his demos -- heh ;p). 7. Can transform Matlab code into a native representation. (Matlab parser returns interpretable native code, plus you can feed it into Lisp's COMPILE and get compiled Matlab for free!) The perhaps overly ambitious goal is to make something almost as easy to use as Matlab that is much more efficient. We want interactive scientific computing that presents a programming model which avoids sacrificing efficiency, especially for very large problems. The shorter-term goal is to make a better Matlisp. I've got a goodly amount of code sketched out with #1 and #4, and I've written up a number of ideas. If you are interested in participating in the project, please let me know. I have connections with folks who write optimized numerical software (LAPACK, OSKI for sparse matrices) so we have potential for incorporating a lot of cool stuff. I could use some experienced Lisp developers as I've only been into Lisp seriously for a year and a half or so (though I've been coding since I was yea high *holds hand not too far above the floor* ;) ). Please contact me directly if you are interested. We can set up a separate mailing list and a code repository. Best, Mark Hoemmen http://www.cs.berkeley.edu/~mhoemmen/
From: Glenn.Ehrlich on 19 Sep 2006 18:53 mark.hoemmen(a)gmail.com wrote: > Greetings! > > I'm thinking of reworking / redoing Matlisp to support a whole > framework for optimized linear algebra that exploits the BLAS and > LAPACK. Here are some features that I'd like to see: You might find these two hard-to-find papers interesting: "Object-oriented design in numerical linear algebra" http://jamcdonald0.home.att.net/cactus-tr.pdf and "Object-oriented programming for linear algebra" http://jamcdonald1.home.att.net/papers/oopsla89.pdf McDonald's other publications might have some relevance as well. http://home.att.net/~jamcdonald/publications.html The two referenced papers above take a more linear algebraic approach, rather than just providing a matrix API. Glenn
From: Juanjo on 20 Sep 2006 04:44 mark.hoemmen(a)gmail.com schrieb: > I'm thinking of reworking / redoing Matlisp to support a whole > framework for optimized linear algebra that exploits the BLAS and > LAPACK. Here are some features that I'd like to see: > > 1. Matrix views (like in the GSL) -- handy for the > recursively-structured approach to linear algebra that's popular > nowadays, and also handy for my research. I want strided matrix views > too (GSL only has "window" matrix views which are like subblocks). Forget about matrices. Use tensors, i.e. n-dimensional arrays. Common-Lisp already has them, so use them. Create a function (I call it FOLD) to contract arbitrary indices of two tensors. Implement matrix multiplication on top of that. I have done it, using BLAS/LAPACK cleverly (it detects when it can use multiplication by transpose) and it is just as fast as Matlab's routines, and allows me to treat 3D meshes and even 6D problems. Once you have tensors, strided views are also easy and can be done for any number of indices. I have done all this in C++ and there you miss closures: if you want to loop over strided views, either you have to expose all the inner guts of strides using templates, or you have to pass a pointer to a function. In Common-Lisp you could benefit from macros. > 7. Can transform Matlab code into a native representation. (Matlab > parser returns interpretable native code, plus you can feed it into > Lisp's COMPILE and get compiled Matlab for free!) That would be nice, and probably easy. The most complicated part is probably plotting and all the associated libraries that come with Matlab: optimization, interface to Maple, etc. Those are the only reason why I end up using Matlab. Juanjo
From: mark.hoemmen@gmail.com on 20 Sep 2006 11:36 Juanjo wrote: > > 7. Can transform Matlab code into a native representation. (Matlab > > parser returns interpretable native code, plus you can feed it into > > Lisp's COMPILE and get compiled Matlab for free!) > > That would be nice, and probably easy. The most complicated part is > probably plotting and all the associated libraries that come with > Matlab: optimization, interface to Maple, etc. Those are the only > reason why I end up using Matlab. Oh, I don't want to step on Cleve Moler's toes ;p The GUI / plotting / toolbox stuff is why people pay for Matlab licenses; otherwise Octave or Scilab or whatever would be good enough. I'd be happy just making the computations really fast and the programming model more sensible, though if someone else wants to add the pretty pictures and tools, I'm all for it :) About the tensors -- I like the idea, and I'd love to see what your expertise could contribute towards such a system! I'm just a little concerned that people who are used to thinking of problems in terms of matrices and vectors may find the learning curve too steep for a general tensor system. Would there be much sacrifice in matrix / vector performance if a matrix / vector system were implemented on top of a general tensor system? In particular, I'm hoping that the equivalent of AREF doesn't involve a branch in fully optimized, compiled code. Best, mfh
From: mark.hoemmen@gmail.com on 20 Sep 2006 11:40
Juanjo wrote: > > 7. Can transform Matlab code into a native representation. (Matlab > > parser returns interpretable native code, plus you can feed it into > > Lisp's COMPILE and get compiled Matlab for free!) > > That would be nice, and probably easy. The most complicated part is > probably plotting and all the associated libraries that come with > Matlab: optimization, interface to Maple, etc. Those are the only > reason why I end up using Matlab. Oh, I don't want to step on Cleve Moler's toes ;p The GUI / plotting / toolbox stuff is why people pay for Matlab licenses; otherwise Octave or Scilab or whatever would be good enough. I'd be happy just making the computations really fast and the programming model more sensible, though if someone else wants to add the pretty pictures and tools, I'm all for it :) About the tensors -- I like the idea, and I'd love to see what your expertise could contribute towards such a system! I'm just a little concerned that people who are used to thinking of problems in terms of matrices and vectors may find the learning curve too steep for a general tensor system. Would there be much sacrifice in matrix / vector performance if a matrix / vector system were implemented on top of a general tensor system? In particular, I'm hoping that the equivalent of AREF doesn't involve a branch in fully optimized, compiled code. Best, mfh |