Chronological Thread 

< Chronological >      < Thread >

---

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] Proposal: BCP for including external code in CellML models, Andrew Miller, 03/15/2007
  • [cellml-discussion] Proposal: BCP for including external code inCellML models, David Nickerson, 03/16/2007
    • [cellml-discussion] Proposal: BCP for including external code inCellML models, Andrew Miller, 03/16/2007
      • [cellml-discussion] Proposal: BCP for including external codeinCellML models, David Nickerson, 03/16/2007
        • [cellml-discussion] Proposal: BCP for including external codeinCellML models, Andrew Miller, 03/18/2007
          • [cellml-discussion] Proposal: BCP for including external codeinCellML models, Matt , 03/19/2007
            • [cellml-discussion] Proposal: BCP for including external codeinCellML models, Andrew Miller, 03/19/2007
              • [cellml-discussion] Proposal: BCP for including external codeinCellML models, Matt , 03/19/2007
          • [cellml-discussion] Proposal: BCP for including externalcodeinCellML models, David Nickerson, 03/19/2007

---

Archive powered by MHonArc 2.6.18.