Re: [Axiom-mail] Re: Axiom and OpenMath/MathMl

[root]

> C Y wrote:
> 
...(snip)...
> You might want to read
> http://www.cs.berkeley.edu/~fateman/papers/openmathcrit.pdf to see some
> of his objections to OpenMath.  

Well, I've read Fateman's objections and I tend to agree with him.
I don't see how a system like Axiom can send a complex type, say
List(Polynomial(Fraction(Integer))) to another system and get the
same type back. This is an important issue for Axiom as most of the
semantics of an expression depend on the type. Most of the other
computer algebra systems can't handle Axiom's complex type towers so 
I don't expect OpenMath or MathML to do it any time soon.

> > > This is more or less the approach the Maxima project
> > > is taking, so I admit I'm biased.  I guess it depends
> > > on what the potential user base desires.
> > > 
> > Since Maxima is also an open source project, it seems
> > appropriate to discuss it a little here. What more can
> > you say about the current Maxima approach?
> 
> Before I start, please remember that I am not the Maxima project leader
> or really even a significant developer as of this point.  I have done
> some documentation work and hope to do more, but I am not a coder.  I
> will probably try to be come one for the GUI part of the project, but
> that isn't here and now.  So take what I say with a grain of salt,
> since I am not an authoratitive voice and many of these points are in
> line for intense debate in future Maxima mailing list discussions. 
> 
> Maxima is a system which is a bit different from Axiom in its purpose. 
> Different developers probably have different visions of what it will
> become, but my take on it is that Maxima will aim in the long term to
> become to the open source community what Mathematica and Maple are to
> the commercial one - a powerful and friendly system with a low learning
> curve interface, but with more capabilities if one wants to take the
> time to learn.  It doesn't have Axiom's strong typing or literate
> programming style, but will likely be substantially easier to use for
> non-experts.

We're looking into using a Magnus-type of front end which has a
near-zero learning curve. It offers a completely different way of
thinking about the system than any other interface I've ever seen.
The casual user should find it easy to learn. I expect that the
more sophisticated user will want command-line or TeXmacs.


> That said, our game plan is to work on fixing the code and
> documentation until we can produce a release which fixes all known

.. perhaps we can use the same documenting technology. Certainly
if the Maxima people document their algorithms sufficiently well
we could stea...ummm, share them :-)


> mathematical bugs in the code.  Once that is achieved, and the
> documentation is brought up to a reasonable standard, we will look at
> adding a decent GUI, improving plotting and the possibility of
> integrating some specific pieces such as pari and the GNU Scientific
> Libraries.  Those tasks are a long way in the future, and will most
> likely be the subject of much debate, but if I had to guess I don't
> think we will be in a hurry to impliment OpenMath, with the exception
> of presentation MathML output for web publishing.  We are more likely
> to identify specific components we want or need and work to tightly
> integrate them into the system, either through foreign function
> interfaces or perhaps reimplimenting some smaller pieces directly into
> lisp.
> 
> These long term goals are not hardened yet, obviously, and may change
> as we continue to work on Maxima.  But I think it's pretty clear that
> the we aren't going to use OpenMath for an interface, and a GUI is
> going to be a higher priority than OpenMath. IIRC even if we were
> wanting to use it I think there are some significant conflicts between
> the OpenMath standard and Maxima's syntax.  

Since we both use Lisp as a base (indeed, GCL is a shared common lisp
base) we could, in principle, define the semantics of operations by
sending lambda expressions as well as syntax embedded in the
stream. Even in this case it is not clear what Maxima would do with
Axiom's type information. 

> As to the GUI itself, no definite plans have been formed yet.  We are
> putting off discussing that until after all the code cleanup and
> bugfixing are done to the point where we can do a stable release,
> mostly to stay focused.  That's a hot topic, and last time it came up
> we must have had 40 emails on the subject in a couple days.  I'll
> summarize a few highlights of the old discussion, but remember I was
> one of the ones in the discussion so I'm not a neutral third party.
> 
> 1.  Any GUI solution needs to be Cross Platform.  
>    This at least everyone agrees on.  Axiom also does, so nothing more
> need be said about that.  The trick is how.

One of the key reasons I've been pushing "command line" as the first
interface is that it works everywhere. I agree that it is primitive.

> 2.  The current interface (Xmaxima, a TCl application) will need to be
> totally replaced.
>      This is mostly agreed upon, although some new work has made
> Xmaxima more tolerable.  It just isn't flexible enough, and can't
> display formatted mathematics.  Not strictly related to Axiom, since
> TeXmacs seems to be the popular choice as an interface.  (With good
> reason - Maxima has a TeXmacs interface too, and it is currently the
> nicest one available.  That interface will be maintained and expanded,
> but I think we feel that we need the flexibility of a very tightly
> integrated interface.)

GCL has a tcl connection. We're not exploiting it but I see the code
there. I'm not in a great hurry to invent something specific. We did
that once with hypertex (we had hyperlinking before browsers were big)
and it was great at the time. Now it just looks primitive.

> 3.  There are many toolkit choices, and it is not immediately clear
> which is the best choice to impliment new work with.
> 
>     This was where most of our discussion centered.  Among the choices
> proposed were FLTK, WxWindows, GTK, and implimenting a native Lisp
> interface.  For plotting there is Gnuplot, plplot, implimenting a
> solution using the VTK toolkit, the Gtk plotting tools of Scigraphica,
> and possibly even resurrecting or reimplimenting the old IZIC plotting
> package, which had an interface to Maxima.  For plotting the solution
> is not necessarily unique = we already can use more than one plotting
> package.  We will likely need to pick one as the "official" solution
> and make sure it works well, but that doesn't necessarily exclude
> people integrating others.  The choice of toolkit, however, is a
> limiting choice.  It will decide much of what we can do, or rather how
> easily we can do it.  (Of course people can impliment others, but we
> don't have the resources to make all the parts work with multiple
> toolkits.)  Some of the pros and cons of each:
> 
...(snip)...

> Anyway I'm sure that's way more than you wanted, and if you are using
> TeXmacs then you won't be interested in the pros and cons of various
> toolkits.  I don't know if a native lisp interface for Axiom would make
> sense or not, even if you wanted to develop one.  But I though I'd
> outline where things stand.

If TeXmacs can grow to support pamphlet and booklets, can be driven
from Axiom as a "display control", can embed graphics, etc and works
cross-platform I think that it will be sufficient for our needs.
Hopefully the TeXmacs crowd will give us a good API from automation
as well as a good editor. Having done graphics all the way from
setting registers on hardware display chips to Java 3D I'd much
rather someone else figure it all out. 

Tim