Akshay Srinivasan wrote:
> On 03/18/2012 02:20 AM, Richard Fateman wrote:
>> You mention AD (automatic differentiation). Have you seen this?
>>
>> http://www.cs.berkeley.edu/~fateman/papers/overload-AD.pdf
>>
>>
> Yes, well sort of, I remember that I didn't read the paper completely
> or try the source code though.
>
> I think the trouble is, as it is now, I don't think I can rely on
> Maxima for doing efficient numerical calculations, and there really
> isn't a very usable lisp alternative for something like NumPy,
> although Matlisp comes close.
Indeed, from my experience with colnew, i don't think that Common Lisp
may really be used for extensive numerical computations, contrary to what
is claimed by lisp evangelists. Knowing how well NumPy works, i think
like you that the solution is to allow convenient translation of the numerical
intensive work from maxima to Fortran or C, automatic compilation of this code
and linking in the maxima process. Automatic translation can be helped by
primitive programs like fortran (or my cgrind), but also by more sophisticated
ones like contrib/gentran. Dan Stanger has recently contributed work to
gentran so i think it works now on recent Maxima, at least up to producing
fortran code. As far as i remember some work is still needed for producing C
code. If you are interested it should not be difficult to do: by comparing an
old version of gentran and a recent one you will see what Dan
has done to make fortran generation work. Basically the point is that gentran
has been written for old versions of lisp, and needs some adaptation to work
with sbcl, cmucl, etc. gentran is *very* sophisticated, it can translate whole
maxima programs to fortran programs (resp C) including the logical flow
operators, etc. so i think that with some polishing and testing, you have here
a tool which is as least as sophisticated as anything existing for python.
Arranging things so that gcc is invoked on the code produced from within lisp
is probably trivial. Arranging that the object can be linked into maxima is
perhaps less trivial, this has to do with foreign function interface in lisp,
which apparently may have variations from lisp to lisp. Unfortunately there
are several Common Lisp variants, with differences in the non normalized parts
of the language, but fortunately it seems that sbcl emerges as the only widely
used variant, at least in the free software world, which may help creating
equivalents of NumPy working with sbcl.
>
> Ray and I have been incorporating new stuff into Matlisp though,
> hopefully that will mature into something that I'd be happy using.
>
> Akshay
--
Michel Talon