Arthur Ralfs wrote:
>
> On 01/06/2011 01:39 PM, Waldek Hebisch wrote:
> > Arthur Ralfs wrote:
> >>
> >> I think I've corrected all the problems in mathml.spad.pamphlet and put
> >> the latest version here
> >>
> >> http://mathbrane.ca/axiom/index.html
> >>
> >> Every time I look at the code I think I should rewrite the whole thing
> >> but it will have to do for now.
> >>
> >
> > I wonder what would you like to change?
>
> At a basic level I would like to clean it up and simplify it.
> Originally I copied texFormat by Robert Sutor but by the time I finished
> I would have done it differently. texFormat uses binaryOps,
> specialOps, plexOps but I now think it would be simpler to switch on the
> operator in OutputForm. OutputForm has things looking like
>
> ((op)(arg1)(arg2)...(argn))
>
> so I would now prefer to do something like
>
> op = "SUM" => formatSum
> op = "INT" => formatInt
>
> etc.
>
> which I think would result in code much easier to read and modify.
>
> Also I copied operator precedences from texFormat but never used them
> and I don't think texFormat actually uses the precedences either. The
> precedences seem to be already encoded in OutputForm and could be
> eliminated. Or am I missing something?
Precedences are used to decide if output need extra parentheses.
Since MathML need no parentheses (structure is given directly by
MathML markers) you do not need precedences, but any linear format
will need them.
> FYI I would like to
> > revive OpenMath support in FriCAS. AFAICS at low level
> > OpenMath allows different encodings, but the most popular
> > seem to be XML. So I need XML support code in FriCAS and
> > I possible I would like to share this part with MathML
> > and HTML. OTOH structure of output formatters is quite
> > similar so I would like to share more code. So it would
> > be good to move into more table-drive approach with common
> > "driver" code and format specific extras in tables. However,
> > some concers are format specific, so I do not know how
> > much may be shared.
> >
>
> There is now a more pressing need for a general XML package/domain that
> can deliver html, mathml, svg, x3d, ...
> so my plans for mathml could be superseded by a more general approach.
> I looked once at the OpenMath stuff and there didn't seem to be much
> there beyond a bunch of stub functions but maybe that would be a good
> general approach for delivering output formats. I'll have another look
> at it.
>
My impression is that what is missing for OpenMath output is
a bunch of stub-like functions: we have code that translate
expressions into sequence of calls to primitives. Each primitive
is responsible for outputing corresponding element, for example
'OMputInteger' should emit something like '<OMI> -42 </OMI>'.
Of course big thing is making sure that each domian contains
correct routines for conversion to OpenMath...
OpenMath input looks more tricky, for this we would need XML
parser and some code to evaluate expressions.
> There's a difference between xml like mathml, (x)html, xml-like formats
> like texmacs and, for instance svg and x3d introduced my Martin Baker.
> Mathml, html and texmacs are simple translations of OutputForm whereas
> svg and x3d are generated from their own domains.
Actually, Content MathML should work like OpenMath, that each domain
should have its own convertor. More precisely, Content MathML
probably should be coded as a special OpenMath device (if IIUC
there is 1 to 1 mapping of semantics, but encoding details
differ).
> Right now I can already send the svg generated by Martin's Scenegraph
> framework to a browser (Firefox) and display it. This required adding a
> simple 'serializeSvg' to Martins framework which serializes the svg as a
> string which I then send to the browser as a mathml text string. On the
> browser side I check for svg content using javascript and strip away the
> mathml stuff. So this is a temporary hack and I'd certainly like to do
> something better.
>
> X3d is not supported yet in mainstream web browsers and I haven't
> noticed any plans to do so in the near future. But WebGL is and
> offers, finally, the ability to display good quality 3D plots in the
> browser. WebGL is a javascript binding for OpenGL ES 2.0 and so I would
> also like a domain to construct the javascript encoding of webgl
> material as an output format.
>
Yes, WebGL looks promising.
> Anyway it would be great if we could figure out some general approach to
> delivering any sort of output format. I think this is really important
> for the uptake of panaxiom and is probably an opportunity that only a
> totally free and open source CAS can take full advantage of.
>
> Arthur
>
> PS then there's an issue with OutputForm itself in that semantics are
> thrown away. The only way to know you've got a derivative is by the
> presence of a comma as an argument to SUPERSUB.
OutputForm was really designed as moderatly simple output format.
If you want meaning you need higher level representation. One
possibility is to create OpenMath-like internal represetation
with something like current OutputForm beeing annotation, so
that simple formatter would go down the tree and just print
annotations while complex routines would get full meaning
of the expression.
However, such high-level representation is likely to be bulky
so better approach may be to use fake OpenMath device for
high-level and continue with OutputForm for simpler cases.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
