axiom-developer
[Top][All Lists]

## Re: [Axiom-developer] browser front end, statement of plans and progres

 From: Andrey G. Grozin Subject: Re: [Axiom-developer] browser front end, statement of plans and progress Date: Sat, 27 Jan 2007 13:32:02 +0600 (NOVT)

On Fri, 26 Jan 2007, address@hidden wrote:

I've been looking deeply into the problem of using a web browser
as the front end for axiom. There are 3 components:

1) replace the graphics
2) replace hyperdoc
3) make an interactive front end

I still think that there is a better alternative than using a browser as a front-end - GNU TeXmacs. Browsers are big and inefficient (especially things like javascript); the quality of formulas is not really good. There are exactly 2 programs which cac display high-quality maths - TeX and TeXmacs, but TeX is non-interactive (attempts to run latex on each output line are terribly inefficient). TeXmacs can easily replace hyperdoc - it already has practically all the needed functionality, though sending commands to Axiom for execution will require some programming (not very much).


About graphics: the current graphics has a good feature that I can interact with a plot (to a limited extent) by mouse and menus, without re-running Axiom commands. I think this is very valuable, and should be much extended. Ideally, I should be able to rotate, zoom, change scale along each axis, change axis labelling, place light sources, chenge textures of surfaces, etc. etc., and produce a live plot of a ray-tracer quality. All of this is not possible in a browser. This requires opengl. So, moving to a browser interface seems to me a big step backwards.


Architecturally the choice of making the graphics engine exist outside
of the underlying lisp system has limitations. I would much rather see
a closer integration between the computations and their display so that
the display could be dynamic instead of static graphs. And it should be
possible to create new domains that directly manipulate axiom data
structures that can be drawn directly. A standalone C program is not
a good choice for this.

Yes, a more close coupling between graphics and computations is very valuable. But why a browser? Its connection to Axiom computation engine is very week.


Recently a new html tag <canvas> has been implemented. I've been playing
with this tag and it appears to support all of the drawing primitives we
need to do the 2D graphics. Axiom already does the 3D->2D work.

This is by far insufficient for highly interactive high-quality graphics.


Another recent (well, recent to me) development has been the AJAX
architecture. This allows a web page to dynamically and periodically
communicate to a host without changing the page. This is how google

Isn't it a way to spend a lot of resources (CPU, memory, bandwidth) for nothing?


So combining these two technologies will allow us to run an axiom
process that communicates with a local or remote browser and can
dynamically draw shapes on the webpage.

Yes, if you are prepared to wait as long as for getting some responce from google earth (with network bandwidths outside USA, it is terrible).


The low level task is to refactor the C code into display and
data handling. The display primitives get pushed out to javascript.
The data handling gets sucked into lisp. The C code disappears.

Javascript is 100 - 1000 times less efficient than C. Also, no opengl, no interactivity, etc.


Consider problem 2, replace hyperdoc.

As I said, TeXmacs can do everything hyperdoc does. Now. A few lines of scheme code are needed to send commands back to Axiom.


Hyperdoc used to have its own language for display but this is dead
and gone. I've been recoding the hyperdoc pages into html so they
use a standard format. This will allow anyone to code web pages without
any training. It should also allow us to embed pamphlets as pdf in pages.

Pamphlets are LaTeX (or at least they should be, if your excellent idea of \begin{chunk} ... \end{chunk} will become reality). TeXmacs can display LaTeX (and hence pamphlets) directly, without pdf. It can also edit them in a wysiwyg fashiom, which you cannot do with pdf.


Also, re-coding hyperdoc pages to LaTeX should be easier than to html, and LaTeX is (from my point of view) a better language. It is already used in pamphlet files. Why introduce html for the help system? Why not to use LaTeX here too?


Hyperdoc can display both static (easy) and dynamic (somewhat harder)
graphics output so I'm stalled on the conversion while I work thru
the graphics details.

TeXmacs can display static and dynamic graphics with equal ease, if it's .eps (or can be converted to .eps).


Consider problem 3, make an interactive front end

Given AJAX it should be possible to type into a web page, send the
input to axiom, html (mathml?) the output, and display the result.
This will take a bit of surgery on the axiom display internals and
is queued behind the first two problems.

So much inefficient machinery for so simple task!


TeXmacs can send commands to Axiom right now. Currently, the communication in the opposite direction is done by Axiom generating LaTeX and TeXmacs displaying it. This should be changed. Serialization of formulas produced by Axiom via LaTeX, mathml or whatever is inefficient and loses important information. Parsing this text stream in a front-end is a senseless work, and should be eliminated. It is easy to output Axiom expressions as s-expressions, and to send them to TeXmacs, without losing any information about their internal structure and semantics. TeXmacs can understand and display formulas sent as s-expressions. Some small adjustments are needed, of course: TeXmacs expects s-expressions formed according to some (rather natural) rules. But it is, of course, *much* easier to write generation of such s-expressions than generation of LaTeX or mathml.


The goal is to have a working browser-based front end to axiom
that works on any platform or across the net by next year.

By design all of the C code disappears and all work is done
inside the lisp image. The actual functions will be implemented
at the axiom/spad language level so that users can have complete
control of I/O directly in spad.

So the overall redesign calls for a lisp-only, browser fronted
axiom which uses html (maybe mathml, undecided), javascript and
a general browser (or any network program). All of the C code dies.
All of the hyperdoc language/machinery dies. Sman dies. All axiom
code is just a single lisp image.

Deth of C code, Lisp image only - this is good. But I am against browsers, mathml, javascript (which is as bad as C and *very* inefficient).


GNU TeXmacs is free and available on all platforms (recently, a Mac port with a native MacOS interface appeared, but I cannot comment on it because I don't have a Mac). It has an additional advantage: it is used as an interface to Axiom, maxima, yacas, Mathematica, Maple, REDUCE, MuPAD, Pari/GP, macaulay2, octave, scilab, matlab, R, ... (the list is too long to continue). A user can cut-and-paste between systems (for example, I can derive some large matrix in Axiom, and then to copy the Axiom output to Octave input for further efficient numerical diagonalization). Some improvements in TeXmacs will benefit many systems, not just Axiom. For example, I am sure that intelligent line-breaking for long output formulas should be written in scheme inside TeXmacs, then it will be used by Axiom, maxima, etc. etc.


To conclude: I think TeXmacs should become an official front-end for Axiom. If a browser front-end is an inevitable evil in our age, TeXmacs should become an official front-end number 2.

Best wishes and many thanks,
Andrey