axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] axiom opportunity


From: Page, Bill
Subject: RE: [Axiom-developer] axiom opportunity
Date: Tue, 25 Apr 2006 15:07:40 -0400

Bob, 

On Tuesday, April 25, 2006 1:45 PM you wrote:
> 
> Bill Page wrote:
> > Could you point me to some examples of these benchmarks?
> > Identical pages rendered as MathML and jsMath? Are there
> > some cases that are especially bad? Worse case?
> 
> I've never written down any numbers because jsMath pages take
> many seconds, while MathML is always unnoticably fast.
> 
> Attached is one of my test pages, to be compared with:
>     http://www.math.union.edu/~dpvc/jsMath/examples/TeXbook16.html

Thanks. Here are the same pages loaded on axiom-developer for
easier comparison:

jsMath (2529 bytes) ->
http://page.axiom-developer.org/TeXbook16.html

MathML (5861 bytes) ->
http://page.axiom-developer.org/texbookch16.xhtml

Of course the actual number of bytes transferred in the case
of jsMath can be quite a bit higher because of sending the
font information.

> 
> > I have not done any rigorous tests but my experiments using
> > FireFox 1.5.0.2 on Windows makes me feel jsMath has the lead -
> > although both seem likely "fast enough" for the kinds of uses
> > I have in mind, e.g. rendering a single "page" of HTML online -
> > either from a web site or from a local copy of Axiom. Such a
> > "page" might contain say at most 10 equations and maybe 20
> > embedded symbols.
> 
> I find this statement very difficult to believe.  On the above
> example page I can watch it render each expression.  It takes
> ~4s to render the whole page.  The MathML version (attached)
> has the Firefox cursor in the "busy" state for ~0.5s.  I think
> most of that time is spent loading the file and parsing it.
> It's about 0.5s for much much larger pages too.
>

Measuring this case more carefully, I have to admit that I agree
with your estimates. These times can be considerable improved
(about 1s to render jsMath) by making sure that you have the Tex
Fonts installed on your system and clicking the "don't show page
until complete" option.

Even so, if these examples were generated from the result of
an Axiom calculation I believe I might still judge the result
"adequate". I suppose that just goes to show that performance
is to some extent subjective - it's what you get used to ...
 
> jsMath is at least an order of magnatude slower.  I don't
> understand how you haven't noticed this...  On my TiddlyWiki
> I have many wiki nodes that take several seconds just to
> render the math...

But the math and the pages themselves are very pretty. :)

> 
> ... 
> > > In the long term the solution to math on the web is
> > > MathML.
> > 
> > In spite of all the effort, I remain sceptical.
> 
> Why?

Because we have LaTeX now and it works now. As hardware gets
faster, software remains just as difficult to write as ever.

> 
> > > Axiom should jump on this opportunity.
> > 
> > On the contrary, I think Axiom should continue to make use
> > of the most expedient solution available now. Axiom needs a
> > better user interface now. I think a possibly (much?) better
> > interface in the future (even the relatively near future,
> > say 2 years) is likely to be too late.
> 
> A better user interface needs a fast, standardized way to
> render math. MathML is that solution.
>

I can agree at least that it probably will be. :)
 
> Rendering images or jsMath will never allow:
>     1) subexpression interactivity
>     2) cut and paste
>     3) graphical equation editing
> which one wangs for a UI.
> 

Hmmm... I have been testing this kind of thing using the new
java-based Maple graphical user interface for almost two years
now and the limitations of the current Maple implementation
notwithstanding, I am even more convinced than I was before
this "gui devolution" of Maple that this sort of user interface
has little real value for users with even moderate experience.
It just doesn't really have much to do with the "mathematics"
that one actually does with these tools (at least what I do
with them).

Regards,
Bill Page.




reply via email to

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