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 cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
