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: [EMAIL PROTECTED] [mailto:cellml-discussion- > [EMAIL PROTECTED] 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:* [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] *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: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > www: jonc.me.uk/ > > > > We are tribbles of Borg. Prepare to be replicated. > > > > _______________________________________________ > > > > cellml-discussion mailing list > > > > [email protected] <mailto:cellml- > [EMAIL PROTECTED]> > > > > http://www.cellml.org/mailman/listinfo/cellml-discussion > > > > _______________________________________________ > > > > cellml-discussion mailing list > > > > [email protected] <mailto:[email protected]> > > > > http://www.cellml.org/mailman/listinfo/cellml-discussion > > > > -- > > > > Jonathan Cooper MSN: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> www: > > jonc.me.uk/ > > > > I haven't lost my mind... It's backed up on tape somewhere. > > > > _______________________________________________ > > > > cellml-discussion mailing list > > > > [email protected] <mailto:[email protected]> > > > > http://www.cellml.org/mailman/listinfo/cellml-discussion > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > cellml-discussion mailing list > > [email protected] > > http://www.cellml.org/mailman/listinfo/cellml-discussion > > > > > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
