>>>>> "Liam" == Liam M Healy <Liam.Healy@nrl.navy.mil> writes:
Liam> to do this by hand. Second, if m>1, the elliptic functions are
Liam> undefined. GSL signals an error, but it is handled by default by
Ray> A&S gives a transformation for m > 1 to the case where m < 1, but
Ray> there are constraints then on the range of u. This is one deficiency
Ray> of GSL: it doesn't handle complex elliptic functions. maxima should
Ray> strive for this whenever possible and reasonable.
Liam> Though interesting, that's not the issue, really. The question is,
Liam> how do you handle conditions signalled from the foreign code?
Well, I was just correcting an error. And yes, conditions signalled
in foreign code is a much bigger problem especially if it stops the
program for you.
Ray> I still think f2cl is a decent solution, but I guess I'm in the
Ray> minority here. There are Fortran implementations for just about
Ray> everything we would want and I suspect that f2cl could convert all of
Ray> them correctly.
Liam> I guess I won't convince you otherwise, but you will need to duplicate
Why do you say that? Look at the developers for matlisp
(matlisp.sourceforge.net) and note that it's an interface to BLAS and
LAPACK (or ATLAS), FFTPACK, and a few other things.. :-)
Liam> the amount of effort that they are putting into the C library. The
Since I'm just converting existing Fortran code to Lisp, I don't see
that there's any real work involved, unless f2cl is broken. All of
the Fortran code I've converted has test drivers, and the converted
code has produced the expected results.
Liam> amount of work put into GSL is impressive - I don't see any other
Liam> project trying to make a coherent, reasonably well-documented, up to
Liam> date, tested scientific/math library. And it appears there are a
Liam> dozen or so active (if not full time, significant time) participants.
Liam> I prefer, where possible, to build on others' work instead of
Liam> duplicating it.
I only checked a few things, but some of those GSL routines are
conversions of Fortran routines.
Liam> Though obviously there are serious obstacles to my approach as well!
Liam> I don't understand your statement about "slow, correct numbers". Why
Liam> not fast, correct numbers, from libraries that have widespread use,
Liam> and are documented and tested?
Sorry for being unclear. I think it's a pain to hook up foreign code,
and it's a great source of some very obscure crashes that wouldn't
happen in Lisp, especially if they cause GC to crash at some much
later unrelated time. So if f2cl converted code that works but is
somewhat slower than the original Fortran code, I can live with that
in maxima.
If maxima only ran on one platform (that I use, of course!), I would
have no problem with FFI. But since people want at least 4 Lisps on
many, many different hardware platforms, I think it's getting to be a
maintenance nightmare for what I see as a relatively minor part of
maxima. Why do you think the cl-info stuff uses a Lisp regex when we
already had a perfectly working regex via FFI for clisp and cmulisp?
I also do some significant number crunching in Lisp, including a
fairly complete cellular system interference simulation and a fairly
complete 3G cellular physical layer. These are all in Lisp, with no
foreign code, and I haven't had any reason not to do that.
In any case, if it is decided that FFI is the way to go, I
volunteer to help with implementing and testing it.
A truly common FFI would be a great service to the Lisp community.
Ray