On this and other mailing lists, there have been recent discussions of "numerical lisp" which in one aspect or another has been the vision of many of us, some for many years.  My approach is to write libraries I think will form a piece of the overall solution, with the hope that others will join in and write compatible libraries that form another piece.  So, I initially wrote GSLL and then split the grid part out into Antik (which has other features I adapted from my personal libraries).  The grid functions can use enhancement, but they are usable now for developing library ports.<br>

<br>I have thought about and had discussions with others about what would be a good candidate library for the next port.  These thoughts have revolved mainly around an FFT library (like fftw) or a linear algebra library (like *lapack) because those are widely used and, since GSL already provides some of that capability, offers a good opportunity to compare features and make a unified interface.  Recently, I came across the FLAME linear algebra library (<a href="http://z.cs.utexas.edu/wiki/flame.wiki/FrontPage">http://z.cs.utexas.edu/wiki/flame.wiki/FrontPage</a>).  It is designed with an intriguing modularity concept.  I think it would be a good library to port to grid/Antik.  Unfortunately, I don't have the time to work on this, but if anyone (particularly someone who needs linear algebra capability like this) wants to take it up, I encourage that and will help as much as I can.  <br>

<br>A big challenge I foresee in any foreign library interface is the allocation of arrays.  If it is a "closed box," it makes it hard to use e.g. static-vectors and therefore the arrays have to be copied back and forth between the foreign side and the CL side.  GSL has the advantage that there are functions that allow building GSL arrays out of supplied C arrays, so regular CL arrays can be allocated with a C pointer passed to these functions to wrap them with GSL metadata.  I'm not sure many other libraries are that flexible; many (e.g. C++ libraries) consider it a virtue to seal off the raw storage (C arrays) from the user, and force you to go through a foreign interface to do the allocation.  Since there are almost no CLs that permit construction of CL arrays using foreign data, copying is the only option left.<br>

<br>So, if anyone has thoughts on FLAME or any other library, I'll be happy to contribute my ideas if it will help.<br><br>Liam<br><br>