[GSLL-devel] FLAME and possible next library ports using grids

[Liam Healy]

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.

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 (http://z.cs.utexas.edu/wiki/flame.wiki/FrontPage).  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.

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.

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

Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/gsll-devel/attachments/20121117/e840f11a/attachment.html>