axiom-mail
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: C Y
Subject: [Axiom-mail] Re: Axiom and OpenMath/MathMl
Date: Fri, 6 Dec 2002 09:07:07 -0800 (PST)

--- Bill Page <address@hidden> wrote:
> On Thu, 5 Dec 2002 21:23:18 -0800 (PST) C Y
> <address@hidden> wrote:
> 
> > ... 
> > I have some slight confusion here - my understanding was
> > that OpenMath wasn't interface related so much as it is
> > a tool for communication between different systems.  If
> > your question is GUI work vs. communication work, I'd
> > most definitely say GUI first.  Presentation MathML as
> > an output format makes a lot of sense to support, since
> > it is/will be a standard for math display in modern
> > browsers, but otherwise I'd say wait on inter-system
> > communication issues until Axiom itself is a reasonably
> > stable, functioning package with a decent GUI.
> 
> My take is that OpenMath is the semantic layer between
> a program (e.g. Axiom) and the presentation layer *or*
> another program. Of course one need not separately define
> such a semantic layer if the goal is only presentation.

OK.  So you're thinking if Axiom goes ahead and uses OpenMath
for presentation, it will save work down the road?

> But the OpenMath content dictionaries already exist which
> map between OpenMath and LaTex or OpenMath and MathML. In
> this direction it is mostly a matter of "forgetting" some
> of the semantics. And there are maps to several other
> programs. If one implements this intermediate semantic
> layer, than their are a lot of (potential) options
> available.

You might want to read
http://www.cs.berkeley.edu/~fateman/papers/openmathcrit.pdf to see some
of his objections to OpenMath.  

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

That said, our game plan is to work on fixing the code and
documentation until we can produce a release which fixes all known
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.  

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.

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

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:

FLTK - small, lightweight, cross platform.  However, the language
doesn't have a native look on each platform and would have to be
integrated with lisp code in maxima.  Solution for Math display would
need to be developed.

WxWindows - very large feature set, cross platform.  Has the native
look and feel of the platform it is compiled for.  Very large, however,
and has the same problem as far as talking to maxima.  Also needs a
solution for math display.

GTK - cross platform.  Would allow use of scigraphica tools.  Possible
use of GthMathView for display of mathematics.  Problems are the look
is rather foreign to Windows users, would require the installation or
inclusion of Gtk for Windows, which I believe is rather large.  Also
has  the problem of communicating with lisp - no mature native
bindings, although a few do exist.

native Lisp interface - potentially cross platform, would need work. 
Possible specific toolkits are Garnet, currently the most promising in
the cross platform department, and McCLIM.  The drawbacks are that the
look and feel will be Unix unless a look and feel is created for each
platform. (Possible in Garnet but likely a lot of work.)  A math
display solution would need to be created.  In Garnet's case we would
effectively be maintining the toolkit ourselves.  The enormous
advantage, however, is that Maxima could communicate directly with this
interface - they would be in effect one program.  No bindings are
needed.  Internal maxima code for intelligently displaying equations
could be used much more easily with such an interface.  There is also
the advantage that once the interface is written, lisp is a very stable
target language and major rewriting will most likely not need to happen
to stay current with library versions. (Gtk1.2->2.0, KDE1-2-3 are
examples.) At most the clx and other low level interfaces might need to
be updated to handle changes in newer versions of core graphic systems.
 

I personally favor using a native Lisp toolkit.  I should note that in
choosing between Garnet and McCLIM there are the following issues to
consider:  1) Garnet is more feature complete.  2)  Garnet is showing a
good chance of being able to run on Windows, thanks to truly amazing
work by Dan Stanger.  3) McCLIM uses the CLOS (common lisp object
system) while Garnet has it's own solution.  4) CLIM is the closest
thing in the Lisp world to a GUI standard.  

McCLIM could in theory be made to work on Windows, but no work is
currently being done on the front.  Also, Maxima itself makes little
use of CLOS, so Garnet's lack of it isn't a killer issue for us, if we
decide to go that way. I anticipate a lively discussion on the Maxima
list in the future.

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.

CY

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]