Thanks, I'll take a look at it. However, I'm a chemical engineer doing
research in statistical mechanics. Adapting the code to read ASTnode
trees or arbitrary MathML dom trees is not straightforward for me.
To all: I still think a integer mapping scheme (or something similar)
would be useful for those who are more interesting in developing and
incorporating new algorithms into software and letting users try them
out vs. spending considerable effort supporting arbitrary MathML
expressions and other feats of programming required for full SBML
support. There are over 2 billion unique integers in a double precision
int. I think we can all agree that, no matter how opinionated everyone
is, we could all restrict the number of possible rate law forms to less
than 2 billion. ;)
Nicolas LE NOVÈRE wrote "If Systems Biology is to succeed, one need such a langua franca. ... The reactions, the species, the parameters; Not only to be able to exchange, and hopefully in a not too distant future, to merge models, but also to evaluate them. "
I agree. I like SBML for this purpose. That's why I'm making this one
suggestion, because I think it will be useful to the wider community for
now and in the future.
It would be much easier to evaluate the rate laws of each reaction if
they all had standard forms. A MathML expression is not unique. The same
algebraic expression can be manipulated innumerable ways. Given two
models with the same reactions, but different rate laws, it is still
possible that those models are exactly equivalent. If each rate law had
a standard form, not only would the expression and meaning of the rate
law be clear and concise, but it would also make it unique. The unique
identifier (it doesn't have to be an integer, it could be a string)
could be stored alongside the MathML expression so long as the program
which created the SBML file can match the expression with the
standardized form of the rate law.
Remember, the original poster made a different suggestion about
modifiers and I proposed this suggestion as a way to solve not only that
problem, but the problem in general.
Darren Wilkinson wrote:
> Howard Salis wrote:
>> 2) Encoding the rate law in MathML or other XML parsed format makes
>> it difficult to quickly convert into an internal representation and
>> repeatedly evaluate. For programs whose purpose is very fast
>> simulations of large reaction networks, this encoding format is not
>> adequate. If this is untrue, please give me an example piece of code.
>> (Preferably in C or Fortran77/90/95/2k)
> Actually the speed issue isn't such a big deal. I wrote a parser for
> sbml level 1 formula strings which constructs a parse tree designed
> for very fast evaluation (using function and variable pointers). It's
> C code (called "meparse", which you can pull from my software page).
> It would be relatively straightforward to adapt to ASTnode trees, or
> even a raw mathml dom tree (though I don't intend to do this any time