First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] A typed lambda calculus system for CellML


Chronological Thread 
  • From: alan.garny at dpag.ox.ac.uk (Alan Garny)
  • Subject: [cellml-discussion] A typed lambda calculus system for CellML
  • Date: Thu, 7 Aug 2008 14:44:13 +0100
> > In our case, we would also need to know the units associated with
> those
> > variables. So, again using a C/C++ syntax, we could have something
> like:
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > int_metre A;
> > double_millivolt V;
> > bool_dimensionless T;
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> Note that I only intended that real numbers have dimensions. I'm not
> sure that it makes sense to have dimensions on anything else.

Agreed, int_metre was a bad example of mine.

> > int_metre, double_millivolt and bool_dimensionless would, in CellML,
> be
> > defined in a similar way to how units are currently defined. In other
> words,
> > definition of types would be an extension of the definition of units.
> From
> > there, you could declare variables in a similar way to the one
> already used
> > in CellML.
> >
> This would simultaneously be more complicated and less powerful than
> the
> TLCS. We go to a great deal of effort to build such features as imports
> and encapsulation and define how it works for components, and if we
> store types in variables, we benefit from this immediately, allowing us
> to make more reusable components. If we invent a completely different
> system, then we have to devote a lot of specification space to defining
> how, for example, types can be imported (along the lines of how units
> work at the moment), we have to define a whole lot of extra elements,
> and we have to invent a new structured system for defining types when
> we
> could be just using MathML.

Agreed. All I was doing here was to suggest (silly?) ideas so you could
criticise them and argue your approach further, thus helping me to
understand better what you are proposing.

> > Just for information, how would you define the above in CellML using
> your
> > approach?
> >
> Something like...
> <variable name="A" type="real_metre" /> <!-- Note that integers can't
> have dimensions. -->
> <variable name="V" type="real_millivolt" />
> <variable name="T" type="boolean"/> <!-- boolean might need to be
> a
> built in type -->
> <variable name="real_millivolt" type="type" /> <!-- -This would
> probably
> normally be connected up from a type library in real models -->
> <m:math>
> <m:apply><m:eq/>
> <m:ci>real_millivolt</m:ci>
> <m:apply><m:times/>
> <m:cn units="dimensionless">0.001</m:cn>
> <m:ci>real_volt</m:ci>
> </m:apply>
> </m:apply>
> </m:math>
> Whether or not we would actually use times for this I'm not sure.

Ok, my understanding is improving, so those email exchanges will have been
useful!

> > I find this unnecessarily confusing. What is wrong with having:
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Component A:
> > Variable name = "Var1" type="real_metre"
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Rather than defining "T" as a variable of type "type", etc.?
> >
> That can be done too, if that is what the modeller wants. But in some
> cases, it is useful to build generic components which can be used with
> more than one type / unit. Examples:
> * A component which does something which works on more than one size
> of vector (where the vector size doesn't change dynamically with
> simulation time, but may be different each time the component is
> imported).
> * A component which can work with several different types of
> concentration units, such as 'concentration' per unit area or
> concentration in terms of volume, depending on whether it is being used
> to model reactions on a membrane or in the lumen.
> * Components which perform various types of scaling which don't
> depend
> on type / units.

Ok, I now understand better and I like it a lot! This could prove to be a
very powerful feature indeed!

Sorry that it took a few email exchanges for me to understand your proposal,
but hopefully those exchanges will help you improve your document (and help
others to understand your proposal).

Alan



Archive powered by MHonArc 2.6.18.

Top of page