Chronological Thread 

< Chronological >      < Thread >

---

> Andrew Miller wrote:
> > David Nickerson wrote:
> > The good thing about the existing rules is that you can see from the
> > variable interfaces for a given component what needs to be defined
> > externally and what may be used externally. While I can see your
> point
> > about the way mathematical expressions could end up modifying
> different
> > variables depending on how the entire model is defined, I'm not sure
> > that we want to start allowing variables with an interface off "in"
> to
> > be modified in any way.
> >
> > I guess I'd prefer a set of rules that somehow flag "in" variables as
> > constant within that component. If execution of the math in a
> particular
> > instantiation of the component would result in any such constants
> having
> > their value changed then that should be treated as an error.
>
> This would severely limit the re-usability of CellML components /
> imports, because it means that you have to decide ahead of time which
> variables are going to be used in which way, and if you then tried to
> use it in a different context for a different purpose, you would
> potentially end up changing something from an input to an output.
>
> If major recoding of a model is required to make minor changes to how
> the some mathematics are used, this does not fit well with the model
> sharing and reuse goals underlying the CellML project.

I have never used or implemented CellML 1.1, so my original view on the
'modification' of variables was that of David, but I can now see the
advantages of Andrew's view in a CellML 1.1 context and would therefore
favour Andrew's view on the sole basis that it would indeed make
re-usability much easier. Now, I have to force myself to 'accept' that new
view... :)

> > Essentially
> > what the current rules state, but perhaps not quite the way the rules
> > are being enforced in the CCGS?
> >
> I don't know if anyone has correctly enforced these rules - I have
> heard
> that COR simply expects that variable to be the second child element in
> the MathML apply element that is the child of the math element, which
> is
> rather arbitrary as the equations could be re-arranged and they would
> no
> longer pass this validation stage (perhaps Alan could confirm or
> correct
> this?).

For one, COR enforces most (if not all -- I cannot recall for certain, so I
prefer to be on the conservative side!) of the rules that are explicitly
mentioned in the CellML specifications. Secondly, COR will indeed require a
variable that is to be modified to be on the left hand side of an assignment
(i.e. be the second child element in the MathML apply element). In other
words, COR will accept something like:

A = B+C

Or in MathML:

<apply>
<eq/>
<ci>a</ci>
<apply>
<plus/>
<ci>b</ci>
<ci>c</ci>
</apply>
</apply>

But not:

B+C = A

Or in MathML:

<apply>
<eq/>
<apply>
<plus/>
<ci>b</ci>
<ci>c</ci>
</apply>
<ci>a</ci>
</apply>

Even though both are equivalent.

Alan.

---

• [cellml-discussion] 'Modification' of variables, Andrew Miller, 12/19/2007
  • [cellml-discussion] 'Modification' of variables, David Nickerson, 12/19/2007
    • [cellml-discussion] 'Modification' of variables, Andrew Miller, 12/19/2007
      • [cellml-discussion] 'Modification' of variables, David Nickerson, 12/19/2007
      • [cellml-discussion] 'Modification' of variables, Alan Garny, 12/20/2007

---

Archive powered by MHonArc 2.6.18.