Re: [cellml-discussion] Proposal: Refactoring the CCGS into smaller, re-usable components

2007-04-24 Thread David Nickerson
Hi Andrew,

This looks like a good thing to be doing, and I think #1 especially will 
be beneficial in terms of providing a basis for an authoritative 
reference implementation of how units are expected to be handled by 
CellML compliant tools (at least the tools which are not using CUSES 
directly).

I'm just wondering if ordering of equations should also be separated out 
from CCGS as you'd imagine most procedural languages would require the 
same ordering process. Maybe the actual ordering is too intricately 
linked to the specific language for it to make sense separating it out?

And in the code I originally did for CMISS I had some code which took 
care of the line length and indentation/prefix requirements of generated 
Fortran 77 code, while I'm sure its not very elegant it might be a place 
to start if we want to go down the track of generating F77 compatible code.


Andre.

PS - how'd you come up with all the names? :-)


Andrew Miller wrote:
 Hi,
 
 I have been wanting to use some functionality present in the CellML Code 
 Generation Service, for a quite different type of problem (not a system 
 of ODEs). The problem is, the functionality isn't exposed. I think there 
 is actually quite a lot of useful functionality in the CCGS which could 
 be exposed. I am therefore proposing that the CCGS be split into a 
 number of smaller, independently useful components...
 
 1) CUSES: The CellML Unit Simplification And Expansion Service.
 
 This service will allow a string, describing a unit, together with a 
 component or units element in which the unit appears, to be passed in. 
 It will then return another object, which represents the unit in a 
 special canonical. This canonical form will consist of an ordered 
 sequence of base units (for some unique ordering of base units). Base 
 units will include built-in base units as well as user-defined base 
 units. The canonical sequence will also carry multipliers, offsets, and 
 exponents for each base unit.
 
 It will be possible to compare to canonical forms of units.
 
 There will also be an option for whether to combine exponents when units 
 have a different multiplier, so that, for example, millimetre . 
 (millisecond ^ -1) . microsecond will only be simplified to micrometre 
 if you turn the option on. I think it is this specific type of 
 simplification that has lead to the recent debate over units.
 
 It is hoped that this module will be useful for editing tools, 
 validators, and code generators, as well as any other software that 
 needs to worked with units. If you work on such software, let me know if 
 this sounds useful.
 
 2) CeVAS: The CellML Variable Association Service.
 
 This service provides an efficient way to find all the variables which 
 are connected to each other, even if they are different components, and 
 perhaps in different imported models.
  It also allows annotations to be made per actual variable (i.e. group 
 of connected variables), and it uses CUSES to compute conversion factors 
 and offsets needed to convert between one CellML variable and another 
 one connected to it.
 
 This should be useful for a range of simulators and code generators, 
 hopefully even ones which are not ODE-based.
 
 3) MaLaES: The MathML to Language Expression Service.
 
 This provides facilities for translating individual MathML expressions 
 into code in a specific language. The code will provide a programmatic 
 interface for setting up tables used to drive the code generation, which 
 will aim to support a range of common languages (earlier FORTRANs being 
 the hardest, due to the line-length restrictions). The code will use 
 CeVAS annotations to look up the name of the variables, so you will be 
 able to use arbitrary variable names.
 
 This service will also be able to determine certain information about 
 the mathematics, such as returning a set of variables on each side of 
 the equation, and determining whether external code is used.
 
 The CCGS will keep the code used to determine the order of the 
 expressions, as well as generation of the actual expressions.
 
 I welcome any opinions on whether this is useful, suggested 
 improvements, and so on.
 
 Best regards,
 Andrew
 
 ___
 cellml-discussion mailing list
 cellml-discussion@cellml.org
 http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Proposal: Refactoring the CCGS into smaller, re-usable components

2007-04-23 Thread Andrew Miller
Hi,

I have been wanting to use some functionality present in the CellML Code 
Generation Service, for a quite different type of problem (not a system 
of ODEs). The problem is, the functionality isn't exposed. I think there 
is actually quite a lot of useful functionality in the CCGS which could 
be exposed. I am therefore proposing that the CCGS be split into a 
number of smaller, independently useful components...

1) CUSES: The CellML Unit Simplification And Expansion Service.

This service will allow a string, describing a unit, together with a 
component or units element in which the unit appears, to be passed in. 
It will then return another object, which represents the unit in a 
special canonical. This canonical form will consist of an ordered 
sequence of base units (for some unique ordering of base units). Base 
units will include built-in base units as well as user-defined base 
units. The canonical sequence will also carry multipliers, offsets, and 
exponents for each base unit.

It will be possible to compare to canonical forms of units.

There will also be an option for whether to combine exponents when units 
have a different multiplier, so that, for example, millimetre . 
(millisecond ^ -1) . microsecond will only be simplified to micrometre 
if you turn the option on. I think it is this specific type of 
simplification that has lead to the recent debate over units.

It is hoped that this module will be useful for editing tools, 
validators, and code generators, as well as any other software that 
needs to worked with units. If you work on such software, let me know if 
this sounds useful.

2) CeVAS: The CellML Variable Association Service.

This service provides an efficient way to find all the variables which 
are connected to each other, even if they are different components, and 
perhaps in different imported models.
 It also allows annotations to be made per actual variable (i.e. group 
of connected variables), and it uses CUSES to compute conversion factors 
and offsets needed to convert between one CellML variable and another 
one connected to it.

This should be useful for a range of simulators and code generators, 
hopefully even ones which are not ODE-based.

3) MaLaES: The MathML to Language Expression Service.

This provides facilities for translating individual MathML expressions 
into code in a specific language. The code will provide a programmatic 
interface for setting up tables used to drive the code generation, which 
will aim to support a range of common languages (earlier FORTRANs being 
the hardest, due to the line-length restrictions). The code will use 
CeVAS annotations to look up the name of the variables, so you will be 
able to use arbitrary variable names.

This service will also be able to determine certain information about 
the mathematics, such as returning a set of variables on each side of 
the equation, and determining whether external code is used.

The CCGS will keep the code used to determine the order of the 
expressions, as well as generation of the actual expressions.

I welcome any opinions on whether this is useful, suggested 
improvements, and so on.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion