Making Maxima be Mathematica compatible...



seberino@spawar.navy.mil wrote:
> 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. 

Not so hard "in the small", but given that each function would
probably have to be considered by a human, there are thousands
of functions to look at.   Here, though is a first cut on
what would be done for hooking up macsyma's integrate program to
mockmma..

The new function could be called MacsymaIntegrate[e,x] from the
top level.  Naturally you could redefine Mockmma's Integrate[] etc using 
this.

(defun MacsymaIntegrate(e x)
    (convert2mma(maxima::$integrate(convert2max e)(convert2max x))))

the convert programs, to be written once, would take data back and forth.

And the results would not be the same exactly as mathematica's, in
general.


  So large in fact that for most
> functions it would probably be easier to just recode it and
> not use Maxima.  Is that right?

No, I disagree.  For stuff like factoring polynomials, integration,
general simplification,  there are thousands of lines of code embodying
lots of thought by lots of people.

> 
> 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[..].

I think this is a fragile kind of interface, but one that
had already been implemented repeatedly.

> 
> 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)

Not at all the way I would do this.  1. Symaxx is certainly not
the only code. What about Xmaxima, Texmacs, xemacs, ...
   2. Setting up 2 lisp programs in separate processes
communicating with strings is really much inferior to having them
loaded into the same process and communicating with lisp data
structures. The only way this might be worthwhile
is if they are running on different computers.

RJF

> 
> 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
> 
>