Chronological Thread 

< Chronological >      < Thread >

---

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.

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] 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.