>>>>> "James" == James Amundson <amundson@fnal.gov> writes:
James> Writing reliable numerical software is a hard job. I think it is
James> completely unreasonable to think we can go about improving the numerical
James> part of Maxima one function at a time. Ray's work is fine as a stopgap
James> measure, but we need to think about a real long-term solution.
That's why I wanted to use TOMS or other packages available in netlib
(www.netlib.org). Apparently, TOMS is not compatible with the GPL,
but other packages in SLATEC say "public domain", whatever that means
in that context.
James> For me, the biggest issue is the foreign function interfaces in the
James> various Lisps on various platforms. Unfortunately, I don't know anything
James> about it! I hope someone on the list can enlighten me as to some of the
James> issues.
I'm familiar with CMUCL's FFI, so if this is the route we take, I can
help there.
>> For a random number generator you might even produce an array
>> of a whole bunch of these from one call.
>>
>> An idea which really capitalizes on the fact that we are
>> using lisp and maxima as open source is that we can patch in
>> any old stuff from a "subset domain". Thus any numerical
>> code should be simple. Octave, a Matlab clone, could be
>> swallowed whole, I think.
James> Interesting. Actually, I had a different idea for combining Maxima and
James> Octave, but I think we differ primarily in details. Maybe we can have
James> that conversation later...
How does SENAC (where f2cl came from) work? I think Richard Fateman
did some work on that.
James> These are all things to worry about. I propose we use the GNU Scientific
James> Library (GSL) to replace {X} in Maxima, where the set {X} includes at
James> least special functions and random number generators. GSL has the
James> following features:
James> - For most of what it does, it is the best such code I know of.
James> - It is actively maintained.
James> - It is documented.
Except, the last time I looked, they don't tell you what algorithms
are used, and the code is "self-documenting", i.e., like all good
code, has no comments.
I did look at it for computing elliptic functions. It took quite a
while to figure out how it worked. In the end, I implemented a
different method, which, I think, was better and faster, and extended
quite obviously to complex numbers. And then I commented the
algorithm with references.
I think it's a crime for mathematical software not to have references
to and comments on the algorithms.
If someone has the time to cook up a good common FFI for Clisp, gcl,
CMUCL, Allegro, Lispworks, etc., I'm all for it. I don't think it is
really difficult, but the details will get you, especially if you're
passing arrays in and out.
For a starter, you can look at matlisp (matlisp.sourceforge.net) which
has a common interface for CMUCL and Allegro to hook up Fortran
routines to Lisp. The only gotcha is that it cheats and has the
Fortran code read/write directly into Lisp arrays rather than copying
Lisp arrays to/from foreign arrays. This has also been a great source
of cool bugs, but was necessary at the time because CMUCL couldn't
allocate large foreign arrays. (The limitation is still there, but
the limits are higher now, but still quite a bit less than the
available Lisp heap).
This is why I prefer the f2cl route, but I'm open to good ideas.
Ray