Chronological Thread 

< Chronological >      < Thread >

---

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: cellml-discussion-bounces at cellml.org [mailto:cellml-discussion-
> bounces at cellml.org] On Behalf Of Justin Marsh
> Sent: Monday, 24 December 2007 4:09 p.m.
> To: cellml-discussion at cellml.org
> 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 <ak.miller at auckland.ac.nz>:
>
> > 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: 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
> >>> 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
> >
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> 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 make in CellML 1.2, Randall Britten, 01/10/2008

---

Archive powered by MHonArc 2.6.18.