(This message was oringally sent to a long list of people. The message
was rejected by the maxima mailing list because there were too many
recpients.)
On Fri, 2002-05-17 at 01:28, Daniel Duparc wrote:
> Thank you, Jim, for this extra work !
Actually, I said I would put together two presentations. I just put the
second one on the web. Really, it is just a collection of thoughts I
have. I would have expressed them at the conference had I been able to
attend. I don't know what, if anything, you want to do with it.
The presentation is available at
http://maxima.sf.net/os-cas-thoughts.pdf
Please let me know if another file format would be more convenient. This
file is *much* smaller than the previous one, partially because I have
no screenshots in this one.
> 2 questions:
> 1. Can you add your opinion about the ability of
> the future Maxima to incorporate code from other
> GPLed CAS (I think mainly of Pari/gp, since Maxima
> is very poor in Number Theory, but this is not
> limitative) or at least launch all or some compiled
> parts of these CAS.
Yes. I am strongly in favor of incorporating other code such as Pari/gp
into Maxima. However, in general, there are interesting technical
problems in getting a Maxima to talk to other programs. Here are some
possibilities:
1) Use a Lisp foreign function interface.
I am interested in this solution for many reasons, not the least of
which being that I would like to incorporate some or all of the GNU
Scientific Library code in Maxima. Unfortunately, there is no standard
for foreign function interfaces in Lisp. Implementing just one would
interfere with our new-found Lisp implementation independence. I am
determined to find a solution to this problem. The best hope to date is
the UFFI project.
2) Automatically convert code to Lisp.
Raymond Toy has used this approach very successfully with f2cl, a
Fortran to Common Lisp converter.
3) Run two processes and communicate through files.
This is what we currently do for plotting. I feel as though we might as
well be writing punchcards. It is simple, though, and it works for a
simple set of problems.
4) Run two processes and communicate through pipes.
This is better than (3), but it really means cooking up a protocol from
scratch. The various maxima GUIs do this right now, but the protocol is
pretty simple because they don't do much with the output. If the
interaction becomes more complex, the protocol will have to become more
complex.
5) Interact through CORBA.
I have done some experimental work on a CORBA interface to Maxima, but
it has never (before) been discussed in public.
We plan to address these issues after Maxima 6.0 is released. We will
find a way to make it possible to integrate Pari/gp into Maxima.
> 2. Would it be interesting, in your opinion, to write
> some Maple -> Maxima or MuPAD -> Maxima translator
> (i.e. to Maxima language, not to lisp)
> similar to the Maple -> MuPAD translator of
> Fran\c{c}ois Thomasset
> htttp://www-rocq.inria.fr/~thomasse/Maple-MuPad/
Honestly, I've never tried this kind of code conversion, so I don't know
how useful it really is. However, I believe it has already been done for
Maple -> Maxima by Dan Stanger. He can tell us more.
There has also been some discussion on the list of Mathematica to Maxima
translation. The hard part of writing a translator is parsing the input
language. Richard Fateman's MockMMA parses a subset of the Mathematica
language. Writing a translator based on MockMMA would be a valuable
exercise.
> > P.S. I know the DOE letter appears upside down.
> (so appears the screenshot page 18)
I rotated a couple of pages so that they would fit better. Since the
talk is going to be given on transparencies, I left it up to Marc to get
the orientation right for the audience.
Best of luck with the conference. Please let us know what happens!
--Jim