Playing with the slatec code a bit, I noticed that there are some
functions (like zabs) that already have a CL equivalent and have
much better performance than the included translated-from-Fortran
code. I wrote a few macros that replace the Fortran in those cases,
along with a patch to maxima.system to integrate the macros.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: basic-functions.lisp
Type: text/x-lisp-source
Size: 1060 bytes
Desc: not available
Url : http://www.math.utexas.edu/pipermail/maxima/attachments/20061128/1f0e822d/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: basic-functions.patch
Type: application/octet-stream
Size: 5315 bytes
Desc: not available
Url : http://www.math.utexas.edu/pipermail/maxima/attachments/20061128/1f0e822d/attachment.obj
-------------- next part --------------
What's the general policy on the Fortran, anyway? It seems like
translating it to Lisp is the worst of both worlds: it's not fast,
and it's hard to read. Hundreds of lines of SETF? Yikes. It seems
like two possible approaches are to compile the Fortran and link it
in using CFFI, or to leave it as it is and slowly transition the
Fortran to idiomatic CL. The CL code would then be both clear and
debuggable. I've translated a few of the functions, and they're often
1/10th the length or less, while improving the speed.
Using an FFI might give us better performance overall, but I think
the benefits of having easy-to-maintain code rank high, even when
talking about numerical code (and it's still faster than the f2cl
method).
Anyway, I'm interested in playing. Let me know what I can do. Thanks.