Menu
▾
▴
sbml-arrays
|
From: Lucian S. <luc...@gm...> - 2014-04-01 20:39:01
|
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
|
|
From: Michael H. <mh...@ca...> - 2014-04-02 20:22:43
|
Hi Lucian,
This is an impressive bit of work :-). Bravo.
MH
On Tue, 1 Apr 2014 13:38:53 -0700, Lucian Smith 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
|
|
From: Chris J. M. <my...@ec...> - 2014-04-02 13:21:32
|
This is great! I like your choices.
JSBML folks: can we get something that matches? :-)
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
|
|
From: Lucian S. <lp...@uw...> - 2014-04-07 18:46:13
|
On Mon, Apr 07, 2014 at 12:24:46PM -0600, Chris J. Myers wrote: > I did not realize that we will also support "selector", but it makes sense and as you say gives the flexibility that Sarah desires. I assume that it can have two or three arguments, but not more, right? Correct. Actually, it can also have just one argument (the vector/matrix itself), which as far as I can tell means 'select this vector' and returns that vector. So, not very useful, but technically valid MathML. But I went ahead and made 'selector' with 0 or 4+ arguments illegal. > I would be okay if: > > A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to selector(A,i,j). > > However, if we make that change, then I would prefer that A[i,j,k] is illegal. Instead, you must either do: > > A[i][j][k] OR A[i,j][k] OR A[i][j,k] Yeah, I agree. All these changes are relatively trivial to make in the code, so whatever people want, we can give them. Perhaps an informal survey at HARMONY would work? > to make it explicit how to compile it into selectors. > > I'm curious though if we see there being any actual performance difference of selector(selector(A,i)) and selector(A,i,j). That would be implementation-dependent, one presumes. And it seems like it would be relatively straightforward to convert from one to the other if it turned out to be a serious slowdown in someone's code. -Lucian |
|
From: Sarah K. <ske...@ca...> - 2014-04-08 07:22:36
|
>> I would be okay if: >> >> A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to selector(A,i,j). >> >> However, if we make that change, then I would prefer that A[i,j,k] is illegal. Instead, you must either do: >> >> A[i][j][k] OR A[i,j][k] OR A[i][j,k] I agree. My point was really not to do with creating invalid (or indeed ambiguous stuff) but was focussed on the point that one of the thinks the new parser allowed (which was a good beneficial thing) was for the user to get what they put in rather than a libsbml imposed version of what they entered. It just seemed to me that by saying that A[i,j] would become a nested selector equivalent to A[i][j] we were going back on this principle :-) Sarah |
|
From: Nicolas Le N. <n.l...@gm...> - 2014-03-26 15:50:53
|
On 26/03/14 15:36, Nicolas Rodriguez wrote: > On 03/26/2014 02:53 PM, Chris J. Myers wrote: >> For the Version 1 of arrays, we decided to include only: >> >> 1-dimensional vectors >> 2-dimensional matrices >> >> We felt that these two types of objects would cover a lot of the interesting use cases, and it avoided some MathML issues with higher dimensions. >> >> However, as you point out, higher dimension objects may be useful. > > For those decisions, we also have to consider if some software are ready > to support them. It depends what you mean by ready. The position of people using lattice models is that currently SBML does not support their models. As a consequence, the software tools do not support SBML at all, even for the part that could (e.g. reaction schemes). At least with 1, 2, and 3D lattice, we would cover the immense majority of relevant software. With only 2D, we cover a few interesting models and a lot of toys models. But cellular and physiological models use 3D lattice. -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 n.l...@gm... orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/ Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ |
|
From: Chris J. M. <my...@ec...> - 2014-04-07 18:24:55
|
I did not realize that we will also support "selector", but it makes sense and as you say gives the flexibility that Sarah desires. I assume that it can have two or three arguments, but not more, right? I would be okay if: A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to selector(A,i,j). However, if we make that change, then I would prefer that A[i,j,k] is illegal. Instead, you must either do: A[i][j][k] OR A[i,j][k] OR A[i][j,k] to make it explicit how to compile it into selectors. I'm curious though if we see there being any actual performance difference of selector(selector(A,i)) and selector(A,i,j). Chris On Apr 7, 2014, at 9:19 AM, Lucian Smith <lp...@uw...> wrote: > On Mon, Apr 07, 2014 at 02:16:04PM +0100, Sarah Keating wrote: >> >>> 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. >> >> The last point about nested selectors worries me slightly. >> >> One of the main benefits of the new parser was that if you used >> >> (a + b) + c >> >> you got different ASTNode structure than if you wrote >> >> a + b + c >> >> i.e. the user was choosing to nest in the first instance and choosing >> not to in the second instance. >> >> But you are now saying that >> >> selector(A, i, j) >> >> would produce a nested AST which would basically be the same as if the >> user put >> >> selector(selector(A,i), j) >> >> But the user may want the first (un-nested form). >> >> It just seems that this is counter-intuitive to the first example ... > > Actually, if you use 'selector', you get what you input exactly. If you > input "seletor(A, i, j)", you get a single selector that only works for > a matrix. It's only the '[]' syntax that combines the two: > > A[i][j] > > is the same as: > > A[i, j] > > and does the 'nested selector' thing. > > I did that so that whether A is implemented as a vector of vectors or as > a matrix, the produced 'selector' mathML will always work. It also > means that: > > A[i][j][k] > > is the same as: > > A[i, j, k] > > meaning it will work for any form of 3-d arrays. > > However, this can be revisited! If we decide it's more important to > preserve user intent, we can make: > > A[i][j] > > nested selectors, and > > A[i, j] > > the matrix selector. > > -Lucian > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees_APR > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Chris J. M. <my...@ec...> - 2014-04-08 14:34:34
|
Seems a reasonable point to me. I was not keen on allowing A[i,j] as well as A[i][j], but assuming we do, it does seem like it would be nice to get that back when you parse as well. I always found it a bit odd when you have aliases for things because you don't get back what you typed in. Chris On Apr 8, 2014, at 1:23 AM, Sarah Keating <ske...@ca...> wrote: > >>> I would be okay if: >>> >>> A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to selector(A,i,j). >>> >>> However, if we make that change, then I would prefer that A[i,j,k] is illegal. Instead, you must either do: >>> >>> A[i][j][k] OR A[i,j][k] OR A[i][j,k] > > I agree. > > My point was really not to do with creating invalid (or indeed ambiguous > stuff) but was focussed on the point that one of the thinks the new > parser allowed (which was a good beneficial thing) was for the user to > get what they put in rather than a libsbml imposed version of what they > entered. > > It just seemed to me that by saying that A[i,j] would become a nested > selector equivalent to A[i][j] we were going back on this principle :-) > > Sarah > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Lucian S. <luc...@gm...> - 2014-04-15 18:25:24
|
OK, the 'libsbml-ast-infix' branch of SVN now doesn't try to do anything tricky and convert things like "A[x, y, z, p, d]" to "A[x][y][z][p][d]"; instead, it just parses it as a selector with too many arguments, and returns an error. Similarly, "A[x, y]" roundtrips as "A[x, y]", and can only be used for matrices (not vectors of vectors), exactly like the underlying MathML. At this point, I can say that at least on the ASTNode side of things, libsbml is ready to support multi-dimensional arrays, if you decide that you do indeed want to handle 3D or higher arrays in the rest of the spec. -Lucian On Tue, Apr 8, 2014 at 7:34 AM, Chris J. Myers <my...@ec...> wrote: > Seems a reasonable point to me. I was not keen on allowing A[i,j] as well > as A[i][j], but assuming we do, it does seem like it would be nice to get > that back when you parse as well. I always found it a bit odd when you > have aliases for things because you don't get back what you typed in. > > Chris > > On Apr 8, 2014, at 1:23 AM, Sarah Keating <ske...@ca...> wrote: > > > > >>> I would be okay if: > >>> > >>> A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to > selector(A,i,j). > >>> > >>> However, if we make that change, then I would prefer that A[i,j,k] is > illegal. Instead, you must either do: > >>> > >>> A[i][j][k] OR A[i,j][k] OR A[i][j,k] > > > > I agree. > > > > My point was really not to do with creating invalid (or indeed ambiguous > > stuff) but was focussed on the point that one of the thinks the new > > parser allowed (which was a good beneficial thing) was for the user to > > get what they put in rather than a libsbml imposed version of what they > > entered. > > > > It just seemed to me that by saying that A[i,j] would become a nested > > selector equivalent to A[i][j] we were going back on this principle :-) > > > > Sarah > > > > > ------------------------------------------------------------------------------ > > Put Bad Developers to Shame > > Dominate Development with Jenkins Continuous Integration > > Continuously Automate Build, Test & Deployment > > Start a new project now. Try Jenkins in the cloud. > > http://p.sf.net/sfu/13600_Cloudbees > > _______________________________________________ > > sbml-arrays mailing list > > sbm...@li... > > https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays > |
|
From: Chris J. M. <my...@ec...> - 2014-04-15 22:05:12
|
Cool. Something we should discuss next Tuesday. Chris Sent from my iPhone On Apr 15, 2014, at 2:25 PM, Lucian Smith <luc...@gm...> wrote: > OK, the 'libsbml-ast-infix' branch of SVN now doesn't try to do anything tricky and convert things like "A[x, y, z, p, d]" to "A[x][y][z][p][d]"; instead, it just parses it as a selector with too many arguments, and returns an error. Similarly, "A[x, y]" roundtrips as "A[x, y]", and can only be used for matrices (not vectors of vectors), exactly like the underlying MathML. > > At this point, I can say that at least on the ASTNode side of things, libsbml is ready to support multi-dimensional arrays, if you decide that you do indeed want to handle 3D or higher arrays in the rest of the spec. > > -Lucian > > > On Tue, Apr 8, 2014 at 7:34 AM, Chris J. Myers <my...@ec...> wrote: >> Seems a reasonable point to me. I was not keen on allowing A[i,j] as well as A[i][j], but assuming we do, it does seem like it would be nice to get that back when you parse as well. I always found it a bit odd when you have aliases for things because you don't get back what you typed in. >> >> Chris >> >> On Apr 8, 2014, at 1:23 AM, Sarah Keating <ske...@ca...> wrote: >> >> > >> >>> I would be okay if: >> >>> >> >>> A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to selector(A,i,j). >> >>> >> >>> However, if we make that change, then I would prefer that A[i,j,k] is illegal. Instead, you must either do: >> >>> >> >>> A[i][j][k] OR A[i,j][k] OR A[i][j,k] >> > >> > I agree. >> > >> > My point was really not to do with creating invalid (or indeed ambiguous >> > stuff) but was focussed on the point that one of the thinks the new >> > parser allowed (which was a good beneficial thing) was for the user to >> > get what they put in rather than a libsbml imposed version of what they >> > entered. >> > >> > It just seemed to me that by saying that A[i,j] would become a nested >> > selector equivalent to A[i][j] we were going back on this principle :-) >> > >> > Sarah >> > >> > ------------------------------------------------------------------------------ >> > Put Bad Developers to Shame >> > Dominate Development with Jenkins Continuous Integration >> > Continuously Automate Build, Test & Deployment >> > Start a new project now. Try Jenkins in the cloud. >> > http://p.sf.net/sfu/13600_Cloudbees >> > _______________________________________________ >> > sbml-arrays mailing list >> > sbm...@li... >> > https://lists.sourceforge.net/lists/listinfo/sbml-arrays >> >> >> ------------------------------------------------------------------------------ >> Put Bad Developers to Shame >> Dominate Development with Jenkins Continuous Integration >> Continuously Automate Build, Test & Deployment >> Start a new project now. Try Jenkins in the cloud. >> http://p.sf.net/sfu/13600_Cloudbees >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Sarah K. <ske...@ca...> - 2014-04-07 13:14:58
|
> 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. The last point about nested selectors worries me slightly. One of the main benefits of the new parser was that if you used (a + b) + c you got different ASTNode structure than if you wrote a + b + c i.e. the user was choosing to nest in the first instance and choosing not to in the second instance. But you are now saying that selector(A, i, j) would produce a nested AST which would basically be the same as if the user put selector(selector(A,i), j) But the user may want the first (un-nested form). It just seems that this is counter-intuitive to the first example ... Sarah |
|
From: Lucian S. <lp...@uw...> - 2014-04-07 15:19:15
|
On Mon, Apr 07, 2014 at 02:16:04PM +0100, Sarah Keating wrote: > > > 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. > > The last point about nested selectors worries me slightly. > > One of the main benefits of the new parser was that if you used > > (a + b) + c > > you got different ASTNode structure than if you wrote > > a + b + c > > i.e. the user was choosing to nest in the first instance and choosing > not to in the second instance. > > But you are now saying that > > selector(A, i, j) > > would produce a nested AST which would basically be the same as if the > user put > > selector(selector(A,i), j) > > But the user may want the first (un-nested form). > > It just seems that this is counter-intuitive to the first example ... Actually, if you use 'selector', you get what you input exactly. If you input "seletor(A, i, j)", you get a single selector that only works for a matrix. It's only the '[]' syntax that combines the two: A[i][j] is the same as: A[i, j] and does the 'nested selector' thing. I did that so that whether A is implemented as a vector of vectors or as a matrix, the produced 'selector' mathML will always work. It also means that: A[i][j][k] is the same as: A[i, j, k] meaning it will work for any form of 3-d arrays. However, this can be revisited! If we decide it's more important to preserve user intent, we can make: A[i][j] nested selectors, and A[i, j] the matrix selector. -Lucian |
|
From: Chris J. M. <my...@ec...> - 2014-03-26 18:35:29
|
In that case, maybe we should allow 3 dimensions. I would advocate then that we support:
1-dimensional vectors
2-dimensional matrices
3-dimensional vectors of matrices
We can allow vectors of vectors to alias as a matrix for the purpose of mathML, or we could disallow them. I don't think we should differentiate between them though.
One more issue about infix notation. Assume you have a matrix X, then:
X[i,j] returns the (i,j)th entry of X.
X[i] returns the ith row of matrix X.
What if you want the jth column of matrix X? In Matlab, I believe it is:
X(:,j)
Do we want to come up with something? Possibilities:
X[*][j]
X[ ][j]
Now, the real problem is that I don't know how we can do this with selector unless we introduce some sort of wild card for the row also. Thoughts?
By the way, this is only really a problem for right-hand-side. The left-hand-side is fetched using the index data structure, and it would not really be a problem to allow the index to only specify dimension 1 and leave dimension 0 unspecified. For example,
Parameter n = 3
Parameter X
Dimension dim=0, size=n
Dimension dim=1, size=n
Rule
Dimension: i, dim=0, size=n
Variable X
Index: attribute=variable, dim=1, math=i
Math: { i, 2*i, 3*i }
This would result in:
X = { {0,1,2}, {0,2,4}, {0,3,6} }
For the same example, with:
Index: attribute=variable, dim=0, math=i
You get:
X = { {0,0,0}, {1,2,3}, {2,4,6} }
Thoughts?
Chris
On Mar 26, 2014, at 9:50 AM, Nicolas Le Novere <n.l...@gm...> wrote:
> On 26/03/14 15:36, Nicolas Rodriguez wrote:
>> On 03/26/2014 02:53 PM, Chris J. Myers wrote:
>>> For the Version 1 of arrays, we decided to include only:
>>>
>>> 1-dimensional vectors
>>> 2-dimensional matrices
>>>
>>> We felt that these two types of objects would cover a lot of the interesting use cases, and it avoided some MathML issues with higher dimensions.
>>>
>>> However, as you point out, higher dimension objects may be useful.
>>
>> For those decisions, we also have to consider if some software are ready
>> to support them.
>
> It depends what you mean by ready. The position of people using lattice models is that currently SBML does not support their models. As a consequence, the software tools do not support SBML at all, even for the part that could (e.g. reaction schemes). At least with 1, 2, and 3D lattice, we would cover the immense majority of relevant software. With only 2D, we cover a few interesting models and a lot of toys models. But cellular and physiological models use 3D lattice.
>
> --
> Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
> Tel: +441223496433 Mob:+447833147074 n.l...@gm...
> orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/
> Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays
|
|
From: Lucian S. <lp...@uw...> - 2014-03-26 19:48:07
|
On Wed, Mar 26, 2014 at 12:35:32PM -0600, Chris J. Myers wrote:
> In that case, maybe we should allow 3 dimensions. I would advocate then that we support:
>
> 1-dimensional vectors
> 2-dimensional matrices
> 3-dimensional vectors of matrices
>
> We can allow vectors of vectors to alias as a matrix for the purpose of mathML, or we could disallow them. I don't think we should differentiate between them though.
>
> One more issue about infix notation. Assume you have a matrix X, then:
>
> X[i,j] returns the (i,j)th entry of X.
> X[i] returns the ith row of matrix X.
Yup, that all works for me, unless you wanted to always have people use
X[i][j].
> What if you want the jth column of matrix X? In Matlab, I believe it is:
>
> X(:,j)
>
> Do we want to come up with something?
I don't think we need anything more than:
transpose(X)[j]
It would be fewer characters to allow the ' notation:
X'[j]
but as mentioned, that starts to conflict with the "derivative" meaning
of ' elsewhere, which might be added in L3v2.
MathML itself doesn't have any concept of 'selecting a column from a
matrix', so I would shy away from allowing a direct way to use it from
the infix that we then had to translate to MathML. (I did this with the
'%' operator, and it was a pain. It could be done, but it was a pain.)
> By the way, this is only really a problem for right-hand-side. The left-hand-side is fetched using the index data structure, and it would not really be a problem to allow the index to only specify dimension 1 and leave dimension 0 unspecified. For example,
>
> Parameter n = 3
>
> Parameter X
> Dimension dim=0, size=n
> Dimension dim=1, size=n
>
> Rule
> Dimension: i, dim=0, size=n
> Variable X
> Index: attribute=variable, dim=1, math=i
> Math: { i, 2*i, 3*i }
>
> This would result in:
>
> X = { {0,1,2}, {0,2,4}, {0,3,6} }
>
> For the same example, with:
>
> Index: attribute=variable, dim=0, math=i
>
> You get:
>
> X = { {0,0,0}, {1,2,3}, {2,4,6} }
I'm not quite following this example. Is 'Rule' an assignment rule?
What is 'dim' and 'math' and 'Math'?
-Lucian
|
|
From: Chris J. M. <my...@ec...> - 2014-03-26 20:29:33
|
>
>> What if you want the jth column of matrix X? In Matlab, I believe it is:
>>
>> X(:,j)
>>
>> Do we want to come up with something?
>
>
> I don't think we need anything more than:
>
> transpose(X)[j]
>
Ah, tricky. Nice. I like that.
>
>> By the way, this is only really a problem for right-hand-side. The left-hand-side is fetched using the index data structure, and it would not really be a problem to allow the index to only specify dimension 1 and leave dimension 0 unspecified. For example,
>>
>> Parameter n = 3
>>
>> Parameter X
>> Dimension dim=0, size=n
>> Dimension dim=1, size=n
>>
>> Rule
>> Dimension: i, dim=0, size=n
>> Variable X
>> Index: attribute=variable, dim=1, math=i
>> Math: { i, 2*i, 3*i }
>>
>> This would result in:
>>
>> X = { {0,1,2}, {0,2,4}, {0,3,6} }
>>
>> For the same example, with:
>>
>> Index: attribute=variable, dim=0, math=i
>>
>> You get:
>>
>> X = { {0,0,0}, {1,2,3}, {2,4,6} }
>
> I'm not quite following this example. Is 'Rule' an assignment rule?
> What is 'dim' and 'math' and 'Math'?
>
This is just shorthand. Yes, rule is an assignment rule. Dim stands for the dimension. Math is the index math. Have a look at the arrays specification which I think will help.
Chris
|
|
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
|
|
From: Chris J. M. <my...@ec...> - 2014-04-02 19:33:37
|
That is true. When will you know if he got it?
Chris
Sent from my iPhone
On Apr 2, 2014, at 10:00 AM, Nicolas Rodriguez <rod...@eb...> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X