First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] Content MathML editing language: Binary =>n-ary syntax


Chronological Thread 
  • From: alan.garny at physiol.ox.ac.uk (Alan Garny)
  • Subject: [cellml-discussion] Content MathML editing language: Binary =>n-ary syntax
  • Date: Mon, 20 Nov 2006 03:57:01 -0000
> -----Original Message-----
> From: cellml-discussion-bounces at cellml.org
> [mailto:cellml-discussion-bounces at cellml.org] On Behalf Of
> David Nickerson
> Sent: 20 November 2006 03:34
> To: For those interested in contributing to the development of CellML.
> Subject: Re: [cellml-discussion] Content MathML editing
> language: Binary =>n-ary syntax
>
> Andrew Miller wrote:
> > Hi all,
> >
> > I have been developing a plain-text input language for the content
> > MathML in CellML documents (so that it can be efficiently edited by
> > users). Although CellML is a declarative language rather than a
> > procedural one, much of the expression syntax from languages like
> > MATLAB and C-like languages can be re-used, and is likely to be
> > familiar to many users. I have therefore tried to make my input
> > language similar to these languages, where possible (for example, I
> > have in-order operators like +, -, *, and / for plus, minus, times,
> > divide, and a pre-order syntax, e.g. sin(x), for other operators).
> > Please ask off-list for my bison grammar (a work in
> progress) if you
> > would like to see it (I haven't checked it in to the public
> Subversion
> > yet). Any opinions or suggestions on the overall structure
> of the language would be welcome.
> >
> > I am also seeking opinions on the most intuitive way to
> deal with the
> > conversion between binary in-order operators like +. For
> example, if,
> > within the input language, you have x = a + b + c + d + e +
> f a naive
> > parser might create MathML like...
> >
> > <DEFANGED-APPly><eq/>
> > <ci>x</ci>
> > <DEFANGED-APPly><plus/>
> > <DEFANGED-APPly><plus/>
> > <DEFANGED-APPly><plus/>
> > <DEFANGED-APPly><plus/>
> > <DEFANGED-APPly><plus/>
> > <ci>a</ci>
> > <ci>b</ci>
> > </apply>
> > <ci>c</ci>
> > </apply>
> > <ci>d</ci>
> > </apply>
> > <ci>e</ci>
> > </apply>
> > <ci>f</ci>
> > </apply>
> > </apply>
> >
> > A slightly more complex parser might instead produce:
> > <DEFANGED-APPly><eq/>
> > <ci>x</ci>
> > <DEFANGED-APPly><plus/>
> > <ci>a</ci>
> > <ci>b</ci>
> > <ci>c</ci>
> > <ci>d</ci>
> > <ci>e</ci>
> > <ci>f</ci>
> > </apply>
> > </apply>
> >
> > I would be interested in opinions on whether you feel this
> automatic
> > translation from multiple binary in-order operators to a single
> > pre-order operation makes sense (note: all CellML tools
> available now
> > work with real numbers only, but future work could allow it to be
> > extended to support other mathematical constructs. Using a
> > definitionURL on an operator is technically valid CellML,
> but no tools
> > can do anything with this either).
> >
> > The issue is complicated by what to do with bracketed
> > expressions(which I currently allow, to override ambiguity). For
> > example, a user could enter...
> > x = (((((a + b) + c) + d) + e) + f)
> > I would be interested to know if you believe that the first content
> > MathML encoding or the second is more appropriate.
>
> I think if the user has specifically entered the brackets
> then they should be reflected in the generated MathML. If you
> think the second chunk of MathML is more efficient (in some
> manner), then it might be nice to prompt the user suggesting
> the removal of the brackets - i.e., present them with a
> display of the more efficient syntax and prompt for a simple
> yes or no to choose whether the more efficient version gets
> used. (and probably have an option to turn this feature on and off.)

For what it is worth, COR should (i.e. if there is no 'bug') remove all
unnecessary parentheses. It will also generate the second type of MathML
code.

Alan.



Archive powered by MHonArc 2.6.18.

Top of page