From: Nicolas R. <rod...@eb...> - 2014-04-02 14:01:17
|
On 04/02/2014 02:21 PM, Chris J. Myers wrote: > This is great! I like your choices. > > JSBML folks: can we get something that matches? :-) Yes, should be fine. But at the moment I stopped doing anything on arrays as one of your student might take care of it through GSOC. > Will make sure to talk about additional MathML constructs at HARMONY. They were actually in an earlier version of the spec, then we cut them but recently realized that was likely a mistake. > > Thanks for doing this. > > Chris > > On Apr 1, 2014, at 2:38 PM, Lucian Smith <luc...@gm...> wrote: > >> OK, in a branch of libsbml, I now have roundtripping of mostly-C/Java infix to and from ASTNodes and MathML. Special thanks to Sarah for getting all the basics set up, and all the ASTNode/MathML translations in. >> >> Here's what I went with: >> >> Selectors: >> * Accepted input syntax: both A[x][y] and A[x, y] mean the same thing. >> * Standard output syntax: A[x][y] >> * 'A' doesn't have to only be a string; it can be anything: "transpose(A)[x, y]" works fine. >> * The produced MathML always created nested selectors, and never uses the special matrix syntax with two arguments. This lets 'A' be either a vector of vectors or a matrix, and the user doesn't need to know the difference. >> >> Vectors: >> * Curly braces with commas: {a, b, c}; vectors of vectors as {{a, b, c}, {d, e, f}, {g, h, i}} (both input and output) >> >> Matrices: >> * Curly braces with commas and semicolons: {a, b, c; d, e, f; g, h, i} (both input and output). >> >> Note that this means you can create 3D elements unambiguously however you want: >> {{{a, b}, {c, d}}, {{e, f}, {g, h}}} <--vector of vector of vectors >> {{a, b; c, d}, {e, f; g, h}} <--vector of matrices >> {{a, b}, {c, d}; {e, f}, {g, h}} <--matrix of vectors >> >> These will all produce different MathML structures, but should otherwise be treated the same within the other SBML constructs. >> >> There is no problem from the infix side to produce vectors and/or matrices of arbitrary dimensions; the Arrays package itself will have to decide what specifically is allowed. Personally, I would advocate starting off allowing anything, and then pulling back before finalization of the spec if all the implementations were restricted in some way, but that's just a suggestion. >> >> For the other arrays functions (as they were defined in the previous version of the spec, which Sarah used to create all the back-end things), we have: >> >> * determinant, det >> * transpose, trans >> * vectorproduct, vectorProd, cross >> * scalarproduct, scalarProd, dot >> * outerproduct, outerProd, outer >> >> with all options accepted as infix input, and the first of each line being produced for infix output (since this matches the MathML exactly). >> >> Because making this work involved changes to core libsbml, this makes it different from what we promised would be in the 'experimental' branch, and therefore won't be in the next experimental release. However, a special 'arrays' version of the code will be available for HARMONY, and if anyone wants to experiment with it before then, you can check it out from SVN directly from branches/libsbml-ast-infix, or you can request a bundle for your system, and we'll see what we can do. >> >> Thank you! And if anyone has any further suggestions, please don't hesitate to make them! >> >> -Lucian >> ------------------------------------------------------------------------------ >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > ------------------------------------------------------------------------------ > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |