Forums

So, I noticed R didn't make the binding list. Is this because no attempt was
made, or because an attempt was made but it ran into difficulties? I ask
because it seems the R folks only use the minGW compiler, and, I don't see
too much use of minGW with libsbml (the only use google came up with was
SBML ODEsolver, and there it looked like it took some extra effort).
Thanks,
Tom

----- Original Message -----
From: "Ben Bornstein" <ben.bornstein@jpl.nasa.gov>
To: "SBML Discussion List" <sbml-discuss@caltech.edu>
Sent: Wednesday, April 27, 2005 6:56 PM
Subject: Re: [sbml-discuss] stoichiometries of modifiers


> Hi All,
>
> I thought I'd stick in the obligatory plug for libSBML:
>
> With respect to formulas, libSBML (http://www.sbml.org/software/libsbml)
> reads, writes and interconverts MathML and infix. It also has an internal
> abstract syntax tree (AST) representation which you can programatically
> inspect and manipulate.
>
> As for programming language support, libSBML is written in C and C++ with
> language bindings for: straight C, C++, Java, Python, Matlab, Perl, and
> Lisp.
>
> Also the libSBML source tree recently underwent a reorganization to make
> its various components more independent. If all you're interested in is
> the MathML <=> AST <=> infix component, it shouldn't be too hard to build
> and use only that.
>
> Finally, I emailed Howard privately this morning about nascent support for
> a libSBML Fortran binding (spurred by a message he sent to libsbml-discuss
> last September). If anyone else is interested in a Fortran binding,
> please let me know, and I'll up it on the priority list.
>
> Thanks.
>
> Ben
>
>
> On Apr 27, 2005, at 2:55 PM, Howard Salis wrote:
>
>> 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.
>>
>> 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 soon).
>
>