[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
does tricks like google earth.
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
- [Axiom-developer] browser front end, statement of plans and progress, daly, 2007/01/27
- Re: [Axiom-developer] browser front end, statement of plans and progress, Ralf Hemmecke, 2007/01/27
- Re: [Axiom-developer] browser front end, statement of plans and progress, Waldek Hebisch, 2007/01/27
- Re: [Axiom-developer] browser front end, statement of plans and progress,
Andrey G. Grozin <=
- Re: [Axiom-developer] browser front end, statement of plans and progress, Martin Rubey, 2007/01/27
- Re: [Axiom-developer] browser front end, statement of plans and progress, Andrey G. Grozin, 2007/01/29