David Nickerson wrote:
>>   3) Do you agree with the basic premise of the proposal, that is that 
>> it is better to have a model which is partly expressed in CellML, than 
>> to have a model which is entirely expressed in a more general 
>> programming language?
> yes.
>>   4) Do the best practice guidelines for CellML authors adequately 
>> protect the utility of CellML as a model interchange format?
> I think so.
>>   5) Does the proposed approach fit well with the design of CellML?
> not really. The design philosophy of CellML is to utilise existing 
> standards where possible. I seem to recall the original intention for 
> the inclusion of required procedural code in a model was through the 
> csymbol mechanism you describe, but the code referenced is defined in a 
> standard format - with ECMAScript the preferred choice at that time. And 
> I see now there is a ECMAScript for XML extension, E4X, which might be 
> useful?
ECMAScript is not practical for use in modelling, because it is an 
interpreted, non-typed language, which necessarily means that it cannot 
be compiled and will be slower than compiled code.
> By using a standard format for the external code (particularly if 
> available support for that format is good), you could reasonably expect 
> multiple applications to support your model. Although, similarly, if the 
> support you describe is built into the CellML API (CCGS?) then you could 
> also expect multiple applications to support a given model with external 
> code.
> Maybe some examples of where the use of external code is required would 
> be useful?
External code needs to be extensible, and hence outside the scope of the 
CellML specifications, for several reasons:
1) Performance. Code may need to be written in a way which is specific 
to a particular platform in order to be able to perform well.
2) Access to existing libraries. There are often extensive libraries and 
other software packages into which a model needs to be integrated. This 
could be in practically any language, and so it would be necessary to 
access to data structures of these libraries to have the model work. I 
believe that this is the case for much of the CMISS-CellML work (I don't 
really think that a proposal to re-write CMISS in ECMAScript would be 
very popular!).
3) Access to specialised hardware. A model could potentially even 
require that a function is evaluated by some sort of online experimental 
procedure (perhaps automated probing of a hardware model) for a given 
set of inputs.
4) Multiple standards, with different communities who favour them. It 
would not be practical to get everyone involved with CellML to agree on 
a certain procedural programming language (even deciding on Fortran vs 
C++ etc... has been a challenge at this institute, and will probably be 
impossible for the wider CellML community).

As an example, consider my PhD project, where I plan to put machine 
learning components into CellML models:
1) Performance is likely to be important. If it is too slow, it might 
not be feasible to do at all.
2) I plan to use existing libraries, in a range of different languages.
3) I also have another (perhaps not as common) gain from specifying the 
external functions without describing their details: I need to run 
different code in 'training' and 'simulation' modes, and if I just wrote 
generic ECMAscript for the simulation case, there would be no simple way 
to deduce the training case. Because of this, it is probably good to 
keep the non-algebraic parts of the model completely separate, and leave 
it up to whoever implements the specific CellML processor.

That said, I think we could have multiple levels of degeneracy away from 
standardised code, where you only go down to the next item if the 
current one is impossible:
1) Pure CellML.
2) CellML with standardised Turing-complete code support.
3) CellML with external (non-standardised) code.

Best regards,
Andrew Miller

cellml-discussion mailing list

Reply via email to