I just got back from a trip, and only glanced at this thread, but perhaps
another approach would be to do this:
Allow a user to translate a mathematica definition (in a file) into a maxima
definition (also in a file).
This could access the mma-compatibility functions as needed, use similar
programs with different names, as needed, print warning messages like
(Solve and solve are not really the same; Limit and limit are not really
the same...)
and there might also be occasional runtime messages from the translated code
as
well.
A parser for the mathematica file is available (mockmma) in lisp.
One advantage to this approach is the "translated" file can be examined as
a tutorial of how to talk mma-ish in maxima.
RJF
> -----Original Message-----
> From: maxima-bounces at math.utexas.edu
> [mailto:maxima-bounces at math.utexas.edu] On Behalf Of Rupert Swarbrick
> Sent: Sunday, September 14, 2008 5:43 AM
> To: Maxima Mailing List
> Subject: Re: [Maxima] More Mathematica functions in Maxima
>
>
> [Because I wasn't concentrating when sending, this went to the wrong
> people, so I'm resending to the list]
>
> John Lapeyre <pdl at johnlapeyre.com> writes:
>
> > On Saturday 13 September 2008 03:04:50 am Rupert Swarbrick wrote:
> >> John Lapeyre <pdl at johnlapeyre.com> writes:
> >
> >> Mathematica in a similar way to how Octave "just supports"
> MATLAB, but
> >> there are a few things that I think you need to bear in mind.
> > I'm interested in this. I don't really know the relation
> > between them, except that somehow its supposed to be easy to
> > port Matlab code to Octave. All I hear about at the
> > University and industry in town is matlab mania.
> >
> ... so it's a very different application domain, but possibly
> a similar
> relationship between the two projects as you want between Maxima and
> Mathematica. As it stands, the languages of the two programs
> are similar
> enough that code written for MATLAB just works in octave, provided
> there's nothing truly crazy based on the graphics subsystem
> in the input
> code.
>
> Note that to get to this point, Octave basically had to decide to have
> an identical language (modulo a couple of minor syntactic
> improvements)
> to MATLAB. Otherwise, this could never work.
>
> >> the Mathematica options. Nice as it may be to have Mathematica code
> >> working, it seems to me that one shouldn't really change the Maxima
> >> API in order to reach that goal.
> >
> > I don't want to change the API (I don't really know what it
> > is, though). At least for the present, my idea is to write
> > something completely separate-- on top of Maxima. If this is
> > the goal, then I think reproducing Mma names is a good idea. If
> > there are no Maxima functions names that begin with
> capital letters,
> > and no plans to introduce them, then this seems as clean a solution
> > as I'll get easily. If you want to vet Maxima code for purity, check
> > for capitalized functions.
>
> OK, so I'm not sure how bothered I personally am about functions named
> like that appearing in the namespace. When I said API, I meant the API
> in the broad sense with which that anyone writing Maxima code or
> interacting with the program is presented.
>
> That said, what you haven't addressed from my email (reading
> again, I'm
> not sure how clear I was) was a major point: The way Maxima and
> Mathematica do things might be different enough that there
> isn't a nice
> 1-1 mapping between function names. For example, Maxima does
> a lot with
> global variables that one sets before calling functions. I don't know:
> is Mathematica the same? Moreover, simplification is handled by a
> rag-tag [1] bunch of functions to massage your expression in the
> direction you want. Does one work in the same way in Mathematica?
>
> What I'm trying to get at is that you really aren't going to
> end up with
> the Octave/MATLAB situation in this case, since the two languages are
> plain different. That's why I was banging on about my suggestion that
> maybe you'd be better off writing a translation layer, taking
> Mathematica code and transforming it into something that
> makes sense to
> Maxima. Of course, for bonus points, the translation software
> should be
> good at spotting when things are going to go pear-shaped
> (since it's not
> going to be able to translate everything) and warn the user about that
> too...
>
> Rupert
>
>
> [1] well, sort of.
>