Chronological Thread 

< Chronological >      < Thread >

---

Randall Britten wrote:
> Hi
>
> I am aware of that. I think you may have missed my point though.
>
> This is my suggestion: If we just use "public" and "private", and discard
> the concept of directionality, then "public" variables could be deemed
> visible from encapsulated components.
>
> The analogy to c++/Java works for me, since encapsulated components are like
> members, purely from the visibility perspective. But if the c++/Java
> analogy doesn't work for you, ignore it, and just focus on the suggestion
> above.
>
Hi,

I think that perhaps in this case reasoning by analogy may be
counterproductive, so I think we should go back to the reason why we put
restrictions on visibility on interfaces, and decide from that if a
'visibility on private interface implies visibility on public interface'
rule makes sense.

I think that the reason why anyone would want to restrict visibility is
because it provides information about which variables it would make
sense to connect to something else, and which variables are so
internally tied to the component that it wouldn't make sense to connect
them up.

In the encapsulation model CellML uses, I think that, in light of the
previous rule, it can make sense not only to isolate variables which are
meaningful only to encapsulated components from other components, but
also to isolate variables which are meaningful to other components from
encapsulated components.

For example, the total sodium current in the Beeler-Reuter model is
meaningless to the parts which contribute to the sodium current, and
isolating them properly from each other helps prevent coding errors in
the encapsulated gate components. This makes the sodium current
variable, in the sodium current component, an example of when publicly
visible but privately hidden interfaces make sense.

Best regards,
Andrew

> Regards,
> Randall
>
>
>> -----Original Message-----
>> From: cellml-discussion-bounces at cellml.org [mailto:cellml-discussion-
>> bounces at cellml.org] On Behalf Of Andrew Miller
>> Sent: Thursday, 10 January 2008 12:17 p.m.
>> To: CellML Discussion List
>> Subject: Re: [cellml-discussion] A list of proposed changes to
>> semantics to makein CellML 1.2
>>
>> Randall Britten wrote:
>>
>>> I don't think we would need attribute values like "public_private" or
>>> "both", since I think "public" access should imply "private" access,
>>> similar to say c++ or Java's use of those terms.
>>>
>>>
>> The usage of the words public and private in CellML is conceptually
>> different to how programming languages like C++ and Java use them. In
>> these programming languages, private means that a member can be
>> accessed
>> only from within the current class, whereas public means that the
>> member
>> may be accessed from outside of that class.
>>
>> In CellML, public and private interfaces are both ways in which
>> reference can be made to a variable from outside of the class. So for
>> example, public_interface="none" private_interface="none" in CellML
>> corresponds to private in C++, while public_interface="none"
>> private_interface="out" is really equivalent to a partially public
>> member in C++.
>>
>> Given this conceptual difference, I think that the claim that public
>> should imply private by analogy to programming languages does not
>> automatically hold. It is quite meaningful (and common) in CellML to
>> open the public interface but close the private interface.
>>
>> Randall Britten wrote:
>>
>>
>>> Hi all
>>>
>>> Another case that illustrates that perhaps the concept of uni-
>>>
>> directional
>>
>>> connections may be flawed in a declarative language:
>>>
>>> Component A has variables x and y that are both public, but only one
>>>
>> al> gebraic equation, hence insufficient maths to find values for x and
>> y
>>
>>> (e.g. x+y=5).
>>> Component B, virtually the same structure. Has public x,y. Has only
>>>
>> one
>>
>>> algebraic equation, so also, taken on its own, insufficient to solve
>>>
>> for x
>>
>>> or y (e.g. x-y=k(t), where k(t) is knows at each value of t, e.g.
>>> k(t=1)=1.).
>>>
>>> The application that attempts to solve the model has to solve the
>>>
>> linear
>>
>>> system, and it does not make sense to see x or y as owned by either A
>>>
>> or B.
>>
>> I think this depends on what the implications of 'ownership' are. If
>> ownership is a purely CellML concept which does not affect the final
>> mathematical model, then I think that it wouldn't prevent us from
>> defining things this way.
>>
>> I think that ownership is information which is strictly speaking,
>> superfluous to the mathematical interpretation of the model. The
>> current implementation of CCGS, for example, does not rely on it to
>> provide any interpretation of the mathematics, although it does provide
>> clues to help provide a human intuitive presentation of results. For
>> example, the variable with no out interfaces (referred to as 'the
>> source variable' in the code, which others have referred to as the
>> owning variable), is used as the master variable which sets the units
>> into which all other variables connected to the same variable are
>> connected. As an alternative, the 'master variable' could be chosen by
>> some other approach, such as randomly, or based on the first variable
>> to appear in the model, but this is somewhat less robust if we seek to
>> get consistent results from the model (to some extent, the
>> directionality of connections could be considered a form of metadata).
>>
>> Best regards,
>> Andrew
>>
>>
>>> Regards,
>>> Randall
>>>
>>
>>> *From:* cellml-discussion-bounces at cellml.org
>>> [mailto:cellml-discussion-bounces at cellml.org] *On Behalf Of *Poul
>>>
>> Nielsen
>>
>>> *Sent:* Sunday, 23 December 2007 10:25 p.m.
>>> *To:* CellML Discussion List
>>> *Subject:* Re: [cellml-discussion] A list of proposed changes to
>>> semantics to makein CellML 1.2
>>>
>>> Yes, the scheme that I proposed would not allow variables to 'pass
>>> through' the public_interface and private_interface of a component. I
>>> imagine that this could be inconvenient in some situations. We could
>>> enable this by adding a fourth value, 'public_private', to the
>>> attribute list.
>>>
>>> Best wishes
>>>
>>> Poul
>>>
>>> On 2007 Dec 22, at 20:21, Jonathan Cooper wrote:
>>>
>>>
>>>
>>> On Sat, Dec 22, 2007 at 11:19:52AM +1300, Poul Nielsen wrote:
>>>
>>> I think that Jonathan is correct - the concept of 'in' and 'out'
>>>
>>> does not make sense in a declarative description. One way to
>>>
>> remedy
>>
>>> this would be to remove the 'public_interface' and
>>>
>>> 'private_interface' attributes from the <variable> element and
>>>
>>> replace them with an 'interface' attribute which could assume
>>>
>> values
>>
>>> "public", "private", or "none". This is a pretty fundamental
>>>
>> change
>>
>>> to the specification but I think that it better reflects the
>>>
>>> declarative intent of CellML model descriptions.
>>>
>>> How would that work for a component like B below, which has both a
>>>
>> public
>>
>>> and private interface for the same variable?
>>>
>>> Jonathan.
>>>
>>> On 2007 Dec 22, at 03:20, Jonathan Cooper wrote:
>>>
>>> On Thu, Dec 20, 2007 at 12:30:32AM +0800, David Nickerson
>>>
>> wrote:
>>
>>> * The current specification says:
>>>
>>> "A variable with either a private_interface or
>>> public_interface
>>>
>>> attribute
>>>
>>> value of "in" must be mapped to no more than one
>>>
>> other
>>
>>> variable in the
>>>
>>> model. [ Note that a similar restriction does not
>>> apply to
>>>
>>> variables with
>>>
>>> interface values of "out". An output variable can be
>>> mapped to
>>>
>>> multiple
>>>
>>> input variables in various components in the current
>>> model. ]"
>>>
>>> The problem with this is that it doesn't properly
>>> account for
>>>
>>> mappings where a variable is forwarded into an
>>> encapsulated
>>>
>>> block. As
>>>
>>> an example, consider the following encapsulation
>>> hierarchy (higher
>>>
>>> components encapsulate lower ones)...
>>>
>>> A
>>>
>>> |
>>>
>>> B
>>>
>>> / \
>>>
>>> C D
>>>
>>> Suppose that component A has, for variable v,
>>>
>>> public_interface="none", private_interface="out", and
>>> B has for
>>>
>>> variable v, public_interface="in",
>>>
>> private_interface="out"
>>
>>> (connected to A), and C and D have
>>>
>> public_interface="in",
>>
>>> private_interface="none", both of which are connected
>>> to B.
>>>
>>> There is no reason why this should not be valid.
>>> However, the
>>>
>>> specification contradicts itself on whether this is
>>> allowed. On
>>>
>>> one
>>>
>>> hand, because B has private_interface="out", it "can
>>> be mapped to
>>>
>>> multiple input variables in various components in the
>>> current
>>>
>>> model.", but because it has a public interface of in,
>>> it "must be
>>>
>>> mapped to no more than one other variable in the
>>>
>> model".
>>
>>> This can be fixed by firstly defining the
>>> interpretation of
>>>
>>> connections and interfaces, and then adding
>>> constraints based on
>>>
>>> that which actually describe which connections are
>>> allowed to each
>>>
>>> set of variables.
>>>
>>> will be interesting to see how such a definition ties in
>>> with the
>>>
>>> idea
>>>
>>> of input variables becoming output variables based on the
>>> way the
>>>
>>> components are hooked together :)
>>>
>>> Indeed.
>>>
>>> The use of "in" and "out" on interfaces very strongly implies
>>>
>> that
>>
>>> connections have a directionality, and this is also reflected
>>> in the
>>>
>>> quote from the specification above - it assumes that
>>>
>> variables
>>
>>> are
>>>
>>> only
>>>
>>> defined in one place, and hence it doesn't make sense to
>>>
>> import a
>>
>>> variable (via an "in" interface) from multiple locations. It
>>>
>> does
>>
>>> however make sense to export a variable to multiple locations,
>>>
>> or
>>
>>> forward
>>>
>>> an imported variable to multiple locations (the example
>>>
>> Andrew
>>
>>> gives).
>>>
>>> If we don't want connections to have directionality, then I
>>> think this
>>>
>>> requires quite a major change in the specification, even if
>>> only to
>>>
>>> avoid
>>>
>>> user confusion. For example, I would want to deprecate the
>>>
>> use of
>>
>>> "in"
>>>
>>> and "out", and instead allow public_interface="yes" or
>>>
>>> public_interface="no" (perhaps a synonym for "none") and
>>> similarly for
>>>
>>> private interfaces. The terms used in the language then
>>> reflect the
>>>
>>> nature of the interfaces - if connections are bidirectional,
>>> then it
>>>
>>> doesn't make sense to talk of an "in" interface, since it may
>>> function
>>>
>>> either as input or output depending on the other components
>>>
>> in the
>>
>>> system.
>>>
>>> Jonathan.
>>>
>>> --
>>>
>>> Jonathan Cooper MSN: msn at jonc.me.uk <mailto:msn at jonc.me.uk>
>>> www: jonc.me.uk/
>>>
>>> We are tribbles of Borg. Prepare to be replicated.
>>>
>>> _______________________________________________
>>>
>>> cellml-discussion mailing list
>>>
>>> cellml-discussion at cellml.org <mailto:cellml-
>>>
>> discussion at cellml.org>
>>
>>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>>
>>> _______________________________________________
>>>
>>> cellml-discussion mailing list
>>>
>>> cellml-discussion at cellml.org <mailto:cellml-discussion at
>>> cellml.org>
>>>
>>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>>
>>> --
>>>
>>> Jonathan Cooper MSN: msn at jonc.me.uk <mailto:msn at jonc.me.uk> www:
>>> jonc.me.uk/
>>>
>>> I haven't lost my mind... It's backed up on tape somewhere.
>>>
>>> _______________________________________________
>>>
>>> cellml-discussion mailing list
>>>
>>> cellml-discussion at cellml.org <mailto:cellml-discussion at cellml.org>
>>>
>>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>>
>>> ---------------------------------------------------------------------
>>>
>> ---
>>
>>> _______________________________________________
>>> cellml-discussion mailing list
>>> cellml-discussion at cellml.org
>>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>>
>>>
>> _______________________________________________
>> cellml-discussion mailing list
>> cellml-discussion at cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>

---

• [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Randall Britten, 01/10/2008
  • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Andrew Miller, 01/10/2008
    • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Randall Britten, 01/10/2008
      • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Andrew Miller, 01/10/2008
        • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Randall Britten, 01/10/2008
          • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Andrew Miller, 01/10/2008
            • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Randall Britten, 01/10/2008

---

Archive powered by MHonArc 2.6.18.