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 algebraic 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. Regards, Randall > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:cellml-discussion- > [EMAIL PROTECTED] On Behalf Of Justin Marsh > Sent: Monday, 24 December 2007 4:09 p.m. > To: [email protected] > Subject: Re: [cellml-discussion] A list of proposed changes to > semantics to makein CellML 1.2 > > Hi all, > I hope that I haven't missed the point of bidirectionality, > but the way it is suggested seems not to be a declarative way to > do things. > > As far as I can tell, in a procedural language it makes sense > to modify variables in multiple locations, as application is > essentially sequential; the seperation between 'big ticks' > and 'little ticks' allows one to flatten the calculation for > each time step. In a declarative language however, > there is essentially no application; this means that we want > to group every part of a definition of something together. > When we want to have parts of the definition of a thing in several > places, > the thing becomes that which explicitly joins together the > definitions into one definition, via mappings and maths. > > In a declarative language, this should not explicitly be done by order; > explicit grouping is accomplished by containment, or something like > tagging, which is just a flattened form of containment. > > The 'in' and 'out' interface values are a form of tagging, specifying > that the 'out' version of the variable is where its definition is > grouped, > with all of the 'in' versions using that definition to > specify other definitions. > > The purpose that I see bidirectionality being put to is to allow > for a certain kind of notational laziness, two cases of which stand out. > > The first is the variable forwarding case, which is not terribly > problematic. It could be unambiguously > resolved by explicitly separating the 'in' variable from the 'out' > variable, for instance. > > Suppose we have encapsulated components like so: > > A > | > B > / \ > C D > > We wish to forward variable v through component B. > What we can do is have a variable v_in, mapped to variable v > in component A, and a variable v_out, which is set equal > to v_in in the Maths element of component B. The variable > v_out can then be mapped to v in both C and D without > ambiguity. This is a rather longhand way of doing this, > but it could be done automatically fairly easily. > > The second case that springs to mind is where someone > implicitly uses a procedural methodology in their model. > For example, suppose you have a variable in a component, > and that variable represented the level of a particular > compound that was metabolised in the body. It may be > necessary to add a stimulus protocol in order to get > oscillation, and it may be desirous for the stimulus protocol to > be in a separate component; to do that in a procedural language one > would simply > perturb the value of the variable at particular time points, by > effectively having the variable sometimes have an 'in' > interface and sometimes have an 'out' interface. > A declarative way of doing this would be to create a variable > defined by a piecewise equation within a separate > stimulus protocol component, map that variable onto a variable > in the compound component, and add the stimulus protocol variable into > the maths that defines the levels of the compound; this is how > these models are currently built. > > Best regards, > Justin. > > > > Quoting Andrew Miller <[EMAIL PROTECTED]>: > > > 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". > > > > I think we also need "both" for the forwarding case if we were going > to > > take this approach. > > > > This is a pretty fundamental change > >> to the specification but I think that it better reflects the > >> declarative intent of CellML model descriptions. > > > > I think that if we want the bulk of valid CellML 1.1 models to be > valid > > CellML 1.2 models, we would need to at least keep the directionality > as > > an option, even if it carries information which is not meaningful in > > CellML 1.2. This would mean 1.2 software could process most 1.1 > models > > without having to implement the two specifications separately, which > is > > probably a good goal to have. > > > > I think that it all depends on how much we are prepared to change the > > specification for CellML 1.2 - I have so far been aiming to get > forwards > > and backwards compatibility unless the model actually uses some > feature > > available in one version that isn't in another. > > > > Best regards, > > Andrew > > > >> > >> Best wishes > >> Poul > >> > >> 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] www: jonc.me.uk/ > >>> > >>> We are tribbles of Borg. Prepare to be replicated. > >>> _______________________________________________ > >>> 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 > > > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > 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
