>>>>> "Ray" == Raymond Toy <toy@rtp.ericsson.se> writes:
>>>>> "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?
Ray> Well, I was just correcting an error. And yes, conditions signalled
Ray> in foreign code is a much bigger problem especially if it stops the
Ray> 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
Ray> Why do you say that? Look at the developers for matlisp
Ray> (matlisp.sourceforge.net) and note that it's an interface to BLAS and
Ray> LAPACK (or ATLAS), FFTPACK, and a few other things.. :-)
You're right, of course. I was thinking of special functions -
they're more on my mind these days!
Liam> the amount of effort that they are putting into the C library. The
Ray> Since I'm just converting existing Fortran code to Lisp, I don't see
Ray> that there's any real work involved, unless f2cl is broken. All of
Ray> the Fortran code I've converted has test drivers, and the converted
Ray> code has produced the expected results.
In my experience, conversions of this type end up being a whole lot
harder than one would like, but it's good that you've had success.
And, there is the ongoing maintenance/synchronization issue. This
requires active knowledgeable participation, lest the different
language versions get skewed.
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.
Ray> I only checked a few things, but some of those GSL routines are
Ray> 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?
Ray> Sorry for being unclear. I think it's a pain to hook up foreign code,
Ray> and it's a great source of some very obscure crashes that wouldn't
Ray> happen in Lisp, especially if they cause GC to crash at some much
Ray> later unrelated time. So if f2cl converted code that works but is
Ray> somewhat slower than the original Fortran code, I can live with that
Ray> in maxima.
Agreed on the pain of hooking up foreign code. But once hooked up,
it's done - someone else keeps things correct/uptodate etc. With a
conversion, you need to constantly monitor upstream and make sure you're
in synch. With a library, you do need to monitor, but just to install
the latest version. (OK, if interfaces change, there's an issue.)
Also, having looked at some of the GSL code (which is in C not
Fortran, by the way, so woudn't be amenable to f2cl - is there a
c2cl?), I find it cleanly laid out but using quite a bit of C
abstractions that I find hard to follow (I'm no C expert though).
Converting this would be hard.
Ray> If maxima only ran on one platform (that I use, of course!), I would
Ray> have no problem with FFI. But since people want at least 4 Lisps on
Ray> many, many different hardware platforms, I think it's getting to be a
Ray> maintenance nightmare for what I see as a relatively minor part of
Ray> maxima. Why do you think the cl-info stuff uses a Lisp regex when we
Ray> already had a perfectly working regex via FFI for clisp and cmulisp?
Ray> I also do some significant number crunching in Lisp, including a
Ray> fairly complete cellular system interference simulation and a fairly
Ray> complete 3G cellular physical layer. These are all in Lisp, with no
Ray> foreign code, and I haven't had any reason not to do that.
Ray> In any case, if it is decided that FFI is the way to go, I
Ray> volunteer to help with implementing and testing it.
Don't get me wrong - I'd love to see the conversions done. I just
think the cost/benefit ratio is higher than FFI into existing
libraries.
I'm volunteering where I can as well, but probably not in the context
of Maxima.
Ray> A truly common FFI would be a great service to the Lisp community.
Agreed. Unfortunately, I see no movement from the CL implementations
to make this happen. Maybe something's happening behind the scenes.
Liam