Raymond Toy writes:
> 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.
So, this seems to be an easier way than to use the ffi.
> I only checked a few things, but some of those GSL routines are
> conversions of Fortran routines.
My impression is, that still most of the really good an tested
mathematical software is in Fortran - and why should we use via ffi a
piece of software that was translated from Fortran to C? Why not do it
in a more direct way and use f2cl?
> 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.
And if we really need it to be faster we can always look into the f2cl
generated lisp code and try to improve that, e.g. by adding proper
declarations. In a lot of the cases I looked into, it was easy to
rewrite the lisp code to be faster, because it was easy to spot for a
human eye, that all the macrology that f2cl uses to cater for the
strange Fortran ways wasn#t needed in that particular case.
> 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.
The more we do in lisp, the better. It is simply the better language
for programming and maintenance. Let us not depend on C code :-)
> In any case, if it is decided that FFI is the way to go, I
> volunteer to help with implementing and testing it.
I would volunteer to help with the f2cl way and rewrite performance
critical parts in lisp.
Andreas
--
Wherever I lay my .emacs, there´s my $HOME.