Chronological Thread 

< Chronological >      < Thread >

---

Andrew Miller wrote:

> %left T_EQEQ T_NOTEQ T_GREATEREQUAL T_LESSEQUAL '<' '>'
> %left '!'
> %left '+' '-'
> %left '*' '/'
> expr: IDENTIFIER attrs '(' arglist ')' | '(' expr ')' | expr '*' attrs
> expr |
> expr '+' attrs expr | expr '-' attrs expr | expr T_EQEQ attrs expr |
> expr T_NOTEQ attrs expr | expr '<' attrs expr |
> expr '>' attrs expr | expr T_GREATEREQUAL attrs expr |
> expr T_LESSEQUAL attrs expr | expr '/' attrs expr | IDENTIFIER attrs |
> NUMBER attrs | PIECEWISE attrs '(' caselist maybeelse ')' | '!' attrs
> expr |
> '-' attrs expr;
>
The precedence of in-order operators in that parser is not what I think
the final precedence should be, I guess we should try to match the rules
from C or MATLAB more closely.
How about...
%left T_EQEQ T_NOTEQ T_GREATEREQUAL T_LESSEQUAL '<' '>'
%left '+' '-'
%left '*' '/'
%left '!'

This means that = has the lowest precedence (describing the equations).

== is next (and has exactly the same precedence as !=, <= <= < >, with
left association) , so you can write things like a*b+c == d*e + f. The
only issue with this is that if you write x <= y <= z, it means (x <= y)
<= z, (i.e. you are comparing z with 0 if x > y, or 1 otherwise), which
is not what the author intended. We could transform these cases in the
parse tree to in(y, interval{type="closed"}(x, z)), but I think this is
a ugly. Another option would be to make all these comparison operators
non-associative, so that attempting to write x <= y <= z would be a
parse error.

Next is + and -, associating left, as per the standard precedence and
associativity rules in mathematics.
Finally, * and / have the highest precedence, again with left
associativity, to match the commonly accepted rules.

We will need to do transformations on the parse tree to ensure that we
do not create unnecessary nesting for n-ary operators like plus. For
example, if we have a + b + c + d, we want...
<apply><plus/>
<ci>a</ci>
<ci>b</ci>
<ci>c</ci>
<ci>d</ci>
</apply>
not...
<apply><plus/>
<apply><plus/>
<apply></plus/>
<ci>a</ci>
<ci>b</ci>
</apply>
<ci>c</ci>
</apply>
<ci>d</ci>
</apply>

I'm not sure if we should allow brackets to disrupt this (standard
parsing practice is to let brackets override precedence, but not
actually put them in the parse tree, so a + (b + c) + d would result in
the first example above too. The only problem here is that our code
might not generalise to all abstract types that could theoretically be
put in CellML models, as they might not be rings / fields).

I would welcome any opinions you may have on how we should deal with
operator precedence in our input language. I would also be interested in
opinions on how we should handle the CellML => Input Language direction.
Would you like to see brackets around every in-order operator, or only
where they are strictly needed for the semantics not to change, or
somewhere in between?

Best regards,
Andrew

---

• [cellml-discussion] User input language for MathML in CellML, Andrew Miller, 11/17/2006
  • [cellml-discussion] User input language for MathML in CellML, Andrew Miller, 11/17/2006

---

Archive powered by MHonArc 2.6.18.