axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] OpenMath


From: C Y
Subject: Re: [Axiom-developer] OpenMath
Date: Thu, 13 May 2004 16:54:27 -0700 (PDT)

--- root <address@hidden> wrote:
> 
> It is clear from numerous discussions that Axiom needs to develop a
> notebook-like interface. Several people told me that they don't use
> Axiom specifically because it lacks a notebook.

Perhaps a GUI developed for one CAS, if it uses a sufficiently open
license, could become the "standard" UI that everyone can plug their
programs into?  I've thought about this when considering an McCLIM GUI
for Maxima - if it is written without using Maxima code itself, and
licensed under the BSD license, Axiom could then use the same UI code
and just make the bridge between the interface graphics and the Axiom
syntax.  Indeed, if sockets communication is used, in theory ANY system
could use it as an interface. 
 
> So, what are the choices? 
> 
> MMA uses ascii text as their notebook representation. It would be
> useful to generate "compatible" input/output so we could use the 
> same front-end. However, the front-end is closed, proprietary, and 
> expensive. Donating the representation of the math to W3C doesn't 
> address the real issue.

I think we can scratch any commercial GUI as a potential interface.

> I can't use the Maple front-end for the same reasons.
> 
> I'd like to use Integre's (formerly IBM's) techexplorer and MathML
> editor but their license specifically states that I can't:

[snip]

> Thus I'm left with no choice but to waste a year of my life drawing
> pretty pictures of characters on a screen.

Here's my opinion, for what it's worth.  Don't worry about a notebook
interface anytime soon - there's a lot more to do on the Axiom core
first.  An interface should be considered when Axiom is stable and
feature complete enough for a major push into end user territory, at
least IMHO.  Maxima has essentially chosen to set the priorities on
making a completely solid math core (at least as much as possible :-) 
and THEN worrying about a GUI to sell it to the users.  Axiom may be
further along on the math core part, so perhaps y'all are already
there.  Anyway, if you feel it would be a waste of your time to do a
GUI then my advice is don't worry about it - do what you like and/or
think is a good use of your time.  Serious users will be fine with the
text interface, and adding a GUI too early might lead people to expect
more than is currently there.  Just some thoughts.

> OpenMath and MathML only
> address a very small portion of the problem and, worse yet, add
> limits to the data representation I can choose. And I don't see how 
> to carry Axiom's Types in OpenMath's data representation. Another 
> incompatible notebook simply fragments the computational mathematics 
> domain into yet another pointless "camp". Believe me, I'd much rather

> spend my time using other people's work and get on with making the 
> math better.

I don't think the notebooks fragment the community any more than the
systems themselves do - it isn't reasonable to, say, expect Mathematica
to open a Maple notebook since the feature sets are different.  My
ideal answer to the open source math notebook question (probably
different from everyone else's ;-) would be:

a) be lisp based (since the two largest open source symbolic CASs are
in lisp, and they will have the most incentive to maintain them, it
makes a certain amount of sense.  Plus all the goodness of doing it in
lisp in the first place.)

b) would utilize things like cl-typesetting and cl-pdf to have native
ability to export nicely formatted documents, and also export to clean
LaTeX for TeX fans and MathML for web.  Any math expression the
interface doesn't know how to render is simply rendered as it is see in
the input.

c) would have all the logic dealing with communication with and
translation of various CASs contained in one place, and well documented
to allow for easily adapting the system to another CAS.

d) would have its own interactive graphing capabilities tuned to CAS
oriented tasks, both for better graphing and to eliminate cross
platform plotting issues.

e) more stuff I'm not thinking of right now, and any brilliant UI ideas
anybody has had but has had no framework to try them out.  Another
benefit of Lisp would be that extensions would be simple to write and
add, if the codebase and apis are clean and well defined.  For example,
a package like Feyncalc could load interface elements specifically
designed to help with high energy physics type work.  Or for a lab a
package could be coded where the interface essentially becomes whatever
is ideal for each stage of the lab - the instructor could limit the UI
to show only the relevant components, and define some custom ones if
desired. I'm guessing doing such things in a non lisp language in a
cross platform matter wouldn't be so straightforward, but that's just a
guess.

Drawbacks - lots of people don't know lisp and don't want to learn,
which might limit people from wanting to customize the GUI, McCLIM
would need to have backends implimented on platforms the CASs are
interested in running on, implimenting 3D interactive plotting would
take some work (probably true anywhere though).

TeXmacs is very, very nice for editing a document and inserting some
math here and there.  But from what I understand it doesn't have the
flexibility to do things like Mathematica's button panels (pros may not
like em but they're a godsend when new users are working), interactive
graphics, or 2D input.  Perhaps it will eventually become the frontend
of choice, but my instincts tell me that an interface designed
specifically to be an interface to a CAS might be better for certain
types of use.

CY


        
                
__________________________________
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861 




reply via email to

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