>>>>> "Stavros" == Stavros Macrakis <stavros.macrakis@verizon.net> writes:
>> With Matlisp (http://matlisp.sourceforge.net), we have an
>> interface to LAPACK freely available.
Stavros> That's great!
Stavros> Do you plan to port it to a free Lisp available on Windows? Right now
Stavros> Matlisp runs on CMUCL (no Windows support) and Allegro CL (not free).
Stavros> An important goal for Maxima is to be fully cross-platform, including
Stavros> Windows and Macintosh.
Stavros> If Matlisp can be ported to GCL, it would be great to integrate Matlisp
Stavros> and Maxima.
Matlisp currently makes a few assumptions about the underlying Lisp:
1. A foreign function interface.
2. The Lisp stores (simple-array double-float (*)) as consecutive
double-float numbers, just like C or Fortran would do.
3. There is some way to get at this actual storage address
4. Some way to disable GC when computing the addresses and calling an
LAPACK routine
5. CLOS.
The first assumption is, obviously, a requirement. I think all Lisps
have some version.
The assumptions 2-4 are needed so that Matlisp didn't have to
copy Lisp arrays in and out before calling LAPACK routines. Such
copying might have negated much of the speed gains of using LAPACK.
However, it's not required do this.
The last assumption of CLOS is needed if you want to use the matrix
package in Lisp. If you don't, and are only interested in the
interface to LAPACK, then CLOS isn't needed.
All of matlisp's FFI knowledge is contained in a few macros. So the
only thing stopping Matlisp from supporting more Lisps is someone
writing the necessary macrology. :-)
Oh, currently Matlisp doesn't have access to all of LAPACK mostly
because no one has yet needed them so the appropriate FFI hasn't been
written.
And one last thing. Matlisp is under a BSD license. I don't know how
that will fit in with Maxima, but I know the two authors are amenable[1]
to a GPL or LGPL type of license if necessary.
Ray
Footnotes:
[1] I know one is, and I think the author has said it was ok.