Chronological Thread 

< Chronological >      < Thread >

---

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.

Perhaps you could explain the reasons behind why you don't think we
should allow this type of use case?

> 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?).

> If we were to remove such rules, is there any need for the public and
> private interfaces at all?
>
We don't want to expose all variables, because some are intended to be
component-local.

We could have used a 'true' / 'false' type undirected system in which
variables are either exposed or hidden on each interface. However,
changing this now would create 100% forwards and backwards
incompatibility both theoretically and with the actual software
implementations available, as opposed to having a few models with
theoretical 1.1-1.2 forwards compatibility issues that work in practice
in all current software which such models needing minimisation steps
would work in anyway.

Best regards,
Andrew
>
> Andre.
>
>
> Andrew Miller wrote:
>
>> Hi all,
>>
>> The current (CellML 1.1) specification has some wording like the following:
>>
>> ''The variable must also be declared in these components, which can then
>> use the value of the variable in their own equations but must not modify
>> it." (3.2.3)
>>
>>
>> "
>> 4.4.4
>>
>> * A mathematical expression defined using MathML must only modify
>> the values of variables that belong to the current component.
>> [ Variables that belong to a component are those that are not
>> declared with a |public_interface| or |private_interface|
>> attribute value of |"||in||"|. ]
>>
>> "
>>
>> It doesn't really make a lot of sense to talk about a mathematical
>> expression modifying a variable, because an equation really only
>> describes the relationships between variables, and doesn't specify which
>> variable is to be modified. At least in the current CCGS implementation,
>> exactly how an equation is used will vary depending on what other
>> components are connected to a given component, and so it is possible
>> that the rules would sometimes be met depending on what is connected to
>> a particular component, which is obviously not a robust way to develop a
>> model.
>>
>> I suggest that this requirement be dropped in the next version of CellML
>> (I am also making a list of other changes from 1.1 I am proposing, which
>> I will send to the mailing list when it is completed).
>>
>> Best regards,
>> Andrew
>>
>> _______________________________________________
>> cellml-discussion mailing list
>> cellml-discussion at cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
>
>

---

• [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.