[GSoC] [jsbml-team] [GSoC Idea#4] Redesign the implementation of mathematical formulas
Nicolas Rodriguez
rodrigue at ebi.ac.uk
Mon Mar 10 16:44:46 UTC 2014
On 03/10/2014 04:20 PM, Andreas Dräger wrote:
> Am 08.03.14 19:30, schrieb kofiavic at mail.utoronto.ca:
>> In a previous email I think I mentioned that I was able to successfully check the code out from the svn repo. Since JSBML is new to me, I’m still trying to find my sea legs with it so to speak. I’ve done a whole lot of passive observation thus far. With the free time I’ve had on the weekend though, I’ve been able to do more (i.e. slap on a few hacks). In the process I’venoticed a couple of things.
> Hi Victor,
>
> Playing with the code is definitely a great way to get started.
>
>> (b) I’ve been trying to make sense of how FormulaParser creates Abstract Syntax Trees, but my efforts have left me at an impasse. A few things are confusing me. For example, what’s the purpose of the ’jj’ family of variables?
Note that Abstract Syntax Trees are created in two ways in JSBML. Either
from the SBML file itself, using StaX to parse the XML, with the class
trunk/core/src/org/sbml/jsbml/xml/parsers/MathMLStaxParser.java
Then, the ASTNode can also be created from an infix math formula, we
have 2 different parsers define with javaCC for different syntaxes.
> Please do not care about the FormulaParser - in particular, do not edit
> it. This class is completely automatically generated by the Java
> Compiler Compiler (JavaCC). We have only specified the grammar of the
> equations to be parsed and the rest has been done by JavaCC. The entire
> package where the FormulaParser is located only contains automatically
> created files.
>
> When your in-memory ASTNodes are implemented, we will have to also
> implement a new Grammar for JavaCC and re-generate all these classes for
> the formula parser.
>
> You can find the definition files for the FormulaParser in /core/files/.
>
>> (c ) Also, I made a couple of modifications to the code. I’ve attached some of the alterations I’ve made. For the new classes, I merely extended the ASTNode class and hid the specific types of changes being made to the nodes (~ I know this is stupid).
> This is actually one way to do it. Inheriting from ASTNode ensures that
> existing programs will still be able to work with your new classes.
>
> However, what we propose in our project is to start from scratch and to
> design a complete new ASTNode interface. This can be based on what is
> currently being done in the library libSBML (see the document attached).
>
> What we should do:
>
> 1) Design a new package structure with identical functionality as given
> by the current class but with improved structure.
>
> 2) Implement this package.
>
> 3) Make the current ASTNode a wrapper around the new package, i.e., let
> all ASTNode functions call methods in the new classes - not the other way.
>
> 4) Change the JavaCompilerCompiler files to build the new data structure.
>
>> I’m hoping to get feedback on whether or not the modifications I made to the formula parser class are in line with this project’s aims (look at the Primary() class).
>>
>>
>> i.e.
>>
>>
>> node = new IntegerNode(i);
>> node = new DoubleNode(d);
> I hope this makes it clearer.
>
> Best wishes
> Andreas
>
More information about the GSoC
mailing list