Subject: Making Maxima be Mathematica compatible...
From: seberino at spawar
Date: Wed, 11 Dec 2002 13:21:42 -0800
Richard
Thanks again for the help. If I understand you correctly, it sounds
like the work involved in writing a wrapper for every
function of a Mathematica clone to call Maxima and handle
all the conversions is large. So large in fact that for most
functions it would probably be easier to just recode it and
not use Maxima. Is that right?
A Maxima shared object that someone could call from another
program with an API would still be nice for the really hard
things like Integrate[..].
It sounds like in order to pursue this that Symaxx is the best
if not the only code to peruse that already does something similar?
(i.e. talk to Maxima code with strings)
Chris
On Mon, Dec 09, 2002 at 05:16:21PM -0800, Richard Fateman wrote:
>
>
> seberino@spawar.navy.mil wrote:
> >>There is a free Lisp-language Mathematica parser
> >>(MockMMA) that I wrote. It includes a rudimentary
> >>evaluator and pattern matcher. It is roughly
> >>Mathematica 2.0 equivalent syntactically.
> >>
> >>But to make something really work like Mathematica,
> >>one would have to reverse-engineer hundreds of thousands
> >>of lines of code.
> >
> >
> > Forgetting about graphics for the moment and just
> > focusing on calculations....
> >
> > When you say that "one would have to reverse-engineer hundreds of thousands
> > of code" do you mean that a Mathematica /subset/ is easy to
> > do but that *full compatibility* would be a ton of work?
> >
> > I certainly agree with that.
>
> yes. Just because the 2 programs have the same command
> names does not mean the commands do the same things.
> Expand for example is different. So is cos.
>
> Even more significant is the fact that moving a program
> from one environment to the other would require, in some
> cases, a close imitation of the internal data structures
> of Mathematica.
>
> >
> > Maxima already is very mature apparently with respect
> > to integration, differentiation and other basic college
> > freshmen needs. I think all would agree that coding
> > the driver to convert Mathematica strings into Maxima
> > style strings is trivial in comparision to the
> > work *already done* on the mathematical engines
> > of Maxima itself (e.g. integration engine).
> >
> > A "Mathematica2Maxima" driver + existing Maxima code +
> > some polishing would certainly be quite a healthy
> > sized subset of Mathematica 2.0 don't you think?
>
> No, it would not be a subset. Except for exact computation
> on integers and polynomials in one variable with integer coefficients, and
> even there, they display in different orders... I'm not sure
> they do precisely the same thing. If all you want is
> a command language that looks like a subset of Mathematica but has
> semantics taken from Maxima, then that is trivially done already
> if the subset is small enough. You can build it up incrementally
> I guess... how are they the same??
> for example, these expressions are acceptable to either program:
> 1234
> 1+1
> x*y+z
> x^2+1/2
>
>
>
> >
> > Chris
> > _______________________________________________
> > Maxima mailing list
> > Maxima@www.math.utexas.edu
> > http://www.math.utexas.edu/mailman/listinfo/maxima
>
>
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
--
_______________________________________
Dr. Christian Seberino
SPAWAR Systems Center San Diego
Code 2363
49590 Lassing Road, Room A339
San Diego, CA 92152-6147
U.S.A.
Phone: (619) 553-7940
Fax: (619) 553-1269
Email: seberino@spawar.navy.mil
_______________________________________