Chronological Thread 

< Chronological >      < Thread >

---

> not analogous to public and private in most object orientated
> programming languages

Quite right, I got confused.

> if both state variables have the same initial values and
> rates (which they would...

why should they have the same initial values? I agree if they did then
it makes
no difference to the correctness of the model but it seems very possible to
create a model of system 1 with substance_b and a model of system 2
with substance_b and give them
both different initial conditions, then try to combine them. In
practice I think this would happen more often than not, at least for
the systems I've dealt with so far.

Are you talking about AFTER you've realised the conflict and have
already decided which value(s) to go with? Or have I missed something?

> and that is a good assumption if you provide everything on the
> interface

Thanks, I see what you are doing with those now.




Quoting Andrew Miller <ak.miller at auckland.ac.nz>:

> Michael Cooling wrote:
>>> because if connections don't have directionality, then it makes no
>>> sense in the language to say
>>> that a connection is from A to B, as opposed to from B to A, and we
>>> wouldn't want to force users to duplicate information and provide both
>>>
>>
>> Oops I didn't mean to imply directionality. I shouldn't have used the
>> words 'from' and 'to', sorry. It's not the language that I want to
>> change.
>>
>>
>>> I'm not sure what you mean there. In CellML 1.1, there can be attributes
>>> like public_interface="in" private_interface="out", I have used
>>> something more like public_interface="yes" or public_interface="no"
>>> here, thereby removing the directionality - in and out correspond to
>>> yes, none corresponds to no.
>>>
>>
>> Ah I see. I suspect just having an optional public_interface="yes"
>> would be the way to go, private="yes" being always
>> implicit. I.e. private by default, and public includes private. As you
>> say this will no doubt be discussed later.
>>
>
> This particular aspect has already been discussed. See
> http://www.cellml.org/pipermail/cellml-discussion/2008-January/001144.html
> and the follow on discussion for why public and private interfaces are
> not analogous to public and private in most object orientated
> programming languages, and why public does not imply private.
>
> By default, we have public_interface="no" private_interface="no", which
> means that the variable cannot be used outside of the component.
> public_interface="yes" means that encapsulating components can connect
> to the variable, while private_interface="yes" means that encapsulated
> components can connect to the variable.
>
>>
>>> The mathematical model you get from this would be sub-optimal without
>>> some intelligence on the part of software tools - there would be two
>>> state variables with identical rates and initial values for the
>>> concentration of b and the concentration of y
>>>
>>
>> This is why I am wary of such convenience components....they imply an
>> interface that doesn't really exist - I think they can be useful but
>> since one never
>> knows what might get connected to what....
>>
>
> Removing directionality, and using sets for the list of all fluxes mean
> that it doesn't matter what the flux set is connected to behind the
> interface. The duplication of state variables is unfortunate, but it
> doesn't actually have any theoretical implications for the correctness
> of the model, if both state variables have the same initial values and
> rates (which they would, since they are the sum over the same set of
> fluxes). This means that the model should just work in all cases.
>
>> If one tries to use them as an interface to the system that MUST be
>> used (not that you were doing this)
>> then you limit the usefulness of your model...essentially you are
>> assuming that your interface is sufficient for all future
>> requirements.
>
> Yes, and that is a good assumption if you provide everything on the
> interface.
>
>> Even for ion channels, that might not be true in the future.
>> I think duplications may also be resolved by chosing a particular
>> substance_b
>> (ie human decision) at model aggregation-time facilitated by tools
>> identifying this situation.
>>
>
> I don't think we want to do that manually. The duplication is only a
> problem because it artificially inflates the dimensionality of the
> model, creating a performance problem, and the algorithm to detect this
> artificial inflation of dimensionality and merge the state variables for
> computational purposes should be tractable if we limit it to the case
> where identical variables are being put through an identical equations,
> rather than going for a more general and costly isomorphic mathematical
> structure detection.
>
> Best regards,
> Andrew
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

• [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Andrew Miller, 01/30/2008
  • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Michael Cooling, 01/31/2008
    • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Andrew Miller, 01/31/2008
      • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Michael Cooling, 01/31/2008
        • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Andrew Miller, 01/31/2008
          • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Michael Cooling, 01/31/2008
            • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Andrew Miller, 01/31/2008
            • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Michael Cooling, 01/31/2008
  • [cellml-discussion] Using proposed CellML 1.2 features to createmore re-usable metabolic models, David Nickerson, 01/31/2008
    • [cellml-discussion] Using proposed CellML 1.2 features to createmore re-usable metabolic models, Andrew Miller, 01/31/2008

---

Archive powered by MHonArc 2.6.18.