Menu
▾
▴
sbml-arrays — The SBML L3 Arrays and Sets package discussion list
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(27) |
Nov
|
Dec
(6) |
| 2014 |
Jan
(25) |
Feb
|
Mar
(44) |
Apr
(21) |
May
(1) |
Jun
(7) |
Jul
(3) |
Aug
(18) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(15) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(31) |
Jun
(4) |
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
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
|
|
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 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. <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: 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: 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 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: 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: Lucian S. <lp...@uw...> - 2014-03-26 15:45:12
|
On Wed, Mar 26, 2014 at 03:36:32PM +0000, 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. Well, I could at least support it for the infix parser, and from there we could see where software tools went with it? We could start off more generous, and then pare back in the spec as needed? -Lucian |
|
From: Nicolas R. <rod...@eb...> - 2014-03-26 15:36:56
|
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.
> Therefore, do we want to reconsider allowing more dimensions for Version 1. If so, we need to resolve the following sticky issue which is what is a 3-dimensional object.
>
> The C/Java approach is there are no matrices. You only have vectors, but you can have vectors of vectors of vectors to produce objects with any number of dimensions. They also support ragged vectors.
>
> The Matlab approach is there are no vectors. You only have matrices, but you can have arrays of matrices to make multidimensional objects with any numbers of dimensions. The size of any dimension is fixed (ragged is not allowed).
>
> The questions I have, therefore, are:
>
> 1) Is it important to support ragged vectors? My opinion on this one is no.
> 2) Is it important to distinguish between a matrix and a vector of vectors? My opinion on this one is also no.
>
> If my assessment is correct, then I think the current data model can be allowed to include more than 2 dimensions. Some care would be needed to check that objects passed to matrix functions actually are valid (namely, only 1 or 2 dimensional objects can be transposed, have a determinant, etc.). Finally, as for the issue that started all this:
>
> { 1, 2, 3 }
>
> would translate to:
>
> <vector>
> <cn>1</cn>
> <cn>2</cn>
> <cn>3</cn>
> </vector>
>
> while
>
> { { 1, 2, 3 }, { 1, 2, 3 } }
>
> could translate to either of the following (it makes no difference):
>
> <matrix>
> <matrixrow>
> <cn>1</cn><cn>2</cn><cn>3</cn>
> </matrixrow>
> <matrixrow>
> <cn>1</cn><cn>2</cn><cn>3</cn>
> </matrixrow>
> </matrix>
>
> <vector>
> <vector>
> <cn>1</cn>
> <cn>2</cn>
> <cn>3</cn>
> </vector>
> <vector>
> <cn>1</cn>
> <cn>2</cn>
> <cn>3</cn>
> </vector>
> </vector>
>
> and finally
>
> { { { 1, 2, 3 }, { 1, 2, 3 } }, { { 1, 2, 3 }, { 1, 2, 3 } } }
>
> could translate either as a vector of matrices or vector of vector of vectors, again makes no difference. Though I suppose if we care to enforce one over the other, we could introduce Lucian's "matrix" keyword to do that in the infix parser. However, as far as the standard is concerned, we would not treat them differently.
>
> Chris
>
> On Mar 26, 2014, at 2:30 AM, Nicolas Le Novere <n.l...@gm...> wrote:
>
>> On 26/03/14 01:26, Chris J. Myers wrote:
>>> And I've been working more on the data model side of things. This is
>>> ringing some bells now. I believe that this is the reason that we
>>> limited ourselves to only 1-dimensional vectors and 2-dimensional
>>> matrices for the first version of arrays. Namely, that mathML really
>>> only supports these two constructs. I could not find any examples of
>>> vectors of vectors in the mathML documentation. Are we sure these
>>> are considered meaningful mathML?
>> Yes, I think they are. MathML is a language to represent mathematical *expressions* in a web document, not mathematical objects. In the mathematical language, there are no 3D matrices. Although the concept of a N-dimensional matrices and vectors exist, the only way to represent them on a piece of paper or a blackboard is a combination of vectors and matrices. MathML only covers what can be written on a piece of paper, and aims to cover everything that can be written in a mathematical expressions. Mathematicians use vectors of vectors and MathML provide the constructs for it.
>>
>> Using only 1 and 2D array cut us for a large part of the finite elements and 3D cell automata models.
>>
>>> So, we are left with where we started. Namely, the arrays packages
>>> supports two types of objects: vectors and matrices. While extending
>>> to more than two dimensions for the data model is relatively
>>> straightforward, the mathML situation is odd to say the least. It
>>> would seem strange that we use vector for 1-dimension, matrix for
>>> 2-dimensions, then vectors of vectors of vectors for 3-dimensions
>>> (assuming this is even legal mathML).
>> I do not think that is odd at all. This is mathematics. You can do things with matrices that you cannot with vectors. Those are different mathematical constructs.
>>
>> --
>> 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
>
> ------------------------------------------------------------------------------
> 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: Chris J. M. <my...@ec...> - 2014-03-26 14:54:00
|
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. Therefore, do we want to reconsider allowing more dimensions for Version 1. If so, we need to resolve the following sticky issue which is what is a 3-dimensional object.
The C/Java approach is there are no matrices. You only have vectors, but you can have vectors of vectors of vectors to produce objects with any number of dimensions. They also support ragged vectors.
The Matlab approach is there are no vectors. You only have matrices, but you can have arrays of matrices to make multidimensional objects with any numbers of dimensions. The size of any dimension is fixed (ragged is not allowed).
The questions I have, therefore, are:
1) Is it important to support ragged vectors? My opinion on this one is no.
2) Is it important to distinguish between a matrix and a vector of vectors? My opinion on this one is also no.
If my assessment is correct, then I think the current data model can be allowed to include more than 2 dimensions. Some care would be needed to check that objects passed to matrix functions actually are valid (namely, only 1 or 2 dimensional objects can be transposed, have a determinant, etc.). Finally, as for the issue that started all this:
{ 1, 2, 3 }
would translate to:
<vector>
<cn>1</cn>
<cn>2</cn>
<cn>3</cn>
</vector>
while
{ { 1, 2, 3 }, { 1, 2, 3 } }
could translate to either of the following (it makes no difference):
<matrix>
<matrixrow>
<cn>1</cn><cn>2</cn><cn>3</cn>
</matrixrow>
<matrixrow>
<cn>1</cn><cn>2</cn><cn>3</cn>
</matrixrow>
</matrix>
<vector>
<vector>
<cn>1</cn>
<cn>2</cn>
<cn>3</cn>
</vector>
<vector>
<cn>1</cn>
<cn>2</cn>
<cn>3</cn>
</vector>
</vector>
and finally
{ { { 1, 2, 3 }, { 1, 2, 3 } }, { { 1, 2, 3 }, { 1, 2, 3 } } }
could translate either as a vector of matrices or vector of vector of vectors, again makes no difference. Though I suppose if we care to enforce one over the other, we could introduce Lucian's "matrix" keyword to do that in the infix parser. However, as far as the standard is concerned, we would not treat them differently.
Chris
On Mar 26, 2014, at 2:30 AM, Nicolas Le Novere <n.l...@gm...> wrote:
> On 26/03/14 01:26, Chris J. Myers wrote:
>> And I've been working more on the data model side of things. This is
>> ringing some bells now. I believe that this is the reason that we
>> limited ourselves to only 1-dimensional vectors and 2-dimensional
>> matrices for the first version of arrays. Namely, that mathML really
>> only supports these two constructs. I could not find any examples of
>> vectors of vectors in the mathML documentation. Are we sure these
>> are considered meaningful mathML?
>
> Yes, I think they are. MathML is a language to represent mathematical *expressions* in a web document, not mathematical objects. In the mathematical language, there are no 3D matrices. Although the concept of a N-dimensional matrices and vectors exist, the only way to represent them on a piece of paper or a blackboard is a combination of vectors and matrices. MathML only covers what can be written on a piece of paper, and aims to cover everything that can be written in a mathematical expressions. Mathematicians use vectors of vectors and MathML provide the constructs for it.
>
> Using only 1 and 2D array cut us for a large part of the finite elements and 3D cell automata models.
>
>> So, we are left with where we started. Namely, the arrays packages
>> supports two types of objects: vectors and matrices. While extending
>> to more than two dimensions for the data model is relatively
>> straightforward, the mathML situation is odd to say the least. It
>> would seem strange that we use vector for 1-dimension, matrix for
>> 2-dimensions, then vectors of vectors of vectors for 3-dimensions
>> (assuming this is even legal mathML).
>
> I do not think that is odd at all. This is mathematics. You can do things with matrices that you cannot with vectors. Those are different mathematical constructs.
>
> --
> 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: Chris J. M. <my...@ec...> - 2014-03-26 13:39:53
|
The infix parser though is just an optional helper function being provided by libsbml/jsbml to those who want a semi-standard string format for math expressions. One is always free to create their own for their application. It is very nice though having one provided by the libraries for convenience. Chris On Mar 26, 2014, at 12:50 AM, "Frank T. Bergmann" <fbe...@ca...> wrote: >> Lucian stated it more brusquely than I would have, but actually, Frank, I > had >> the same confusion when I read your reply. Can you clarify what you > meant? >> > > My point was just, that I could see use cases for using different syntax. As > such it seems preferable to me to allow the infix parser / formatters to be > configurable by the application invoking it. It would also not involve much > more work in the implementation. > > So rather than specifying 'the one infix syntax' to be used to express > arrays, I would rather leave this to users later on. > > Frank > > > > > ------------------------------------------------------------------------------ > 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: Nicolas Le N. <n.l...@gm...> - 2014-03-26 08:30:51
|
On 26/03/14 01:26, Chris J. Myers wrote: > And I've been working more on the data model side of things. This is > ringing some bells now. I believe that this is the reason that we > limited ourselves to only 1-dimensional vectors and 2-dimensional > matrices for the first version of arrays. Namely, that mathML really > only supports these two constructs. I could not find any examples of > vectors of vectors in the mathML documentation. Are we sure these > are considered meaningful mathML? Yes, I think they are. MathML is a language to represent mathematical *expressions* in a web document, not mathematical objects. In the mathematical language, there are no 3D matrices. Although the concept of a N-dimensional matrices and vectors exist, the only way to represent them on a piece of paper or a blackboard is a combination of vectors and matrices. MathML only covers what can be written on a piece of paper, and aims to cover everything that can be written in a mathematical expressions. Mathematicians use vectors of vectors and MathML provide the constructs for it. Using only 1 and 2D array cut us for a large part of the finite elements and 3D cell automata models. > So, we are left with where we started. Namely, the arrays packages > supports two types of objects: vectors and matrices. While extending > to more than two dimensions for the data model is relatively > straightforward, the mathML situation is odd to say the least. It > would seem strange that we use vector for 1-dimension, matrix for > 2-dimensions, then vectors of vectors of vectors for 3-dimensions > (assuming this is even legal mathML). I do not think that is odd at all. This is mathematics. You can do things with matrices that you cannot with vectors. Those are different mathematical constructs. -- 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: Frank T. B. <fbe...@ca...> - 2014-03-26 06:50:51
|
> Lucian stated it more brusquely than I would have, but actually, Frank, I had > the same confusion when I read your reply. Can you clarify what you meant? > My point was just, that I could see use cases for using different syntax. As such it seems preferable to me to allow the infix parser / formatters to be configurable by the application invoking it. It would also not involve much more work in the implementation. So rather than specifying 'the one infix syntax' to be used to express arrays, I would rather leave this to users later on. Frank |
|
From: Chris J. M. <my...@ec...> - 2014-03-26 01:26:46
|
And I've been working more on the data model side of things. This is ringing some bells now. I believe that this is the reason that we limited ourselves to only 1-dimensional vectors and 2-dimensional matrices for the first version of arrays. Namely, that mathML really only supports these two constructs. I could not find any examples of vectors of vectors in the mathML documentation. Are we sure these are considered meaningful mathML?
The current data model has no means of constructing ragged objects, so it would require a significant change to support this. I would like a compelling use case for it, if we were to do this as I'm sure it would add a lot of complication. We also have no way of distinguishing a matrix from a vector of vectors. Again, this would mean a significant change in design, and again I would want a compelling use case.
So, we are left with where we started. Namely, the arrays packages supports two types of objects: vectors and matrices. While extending to more than two dimensions for the data model is relatively straightforward, the mathML situation is odd to say the least. It would seem strange that we use vector for 1-dimension, matrix for 2-dimensions, then vectors of vectors of vectors for 3-dimensions (assuming this is even legal mathML). So I now remember only too well why we punted this issue down the road, and I feel we should stick with that decision. This means we simply do not allow anything but vectors and matrices. So, with this in mind, I think:
{ {1,0,0},{0,1,0},{0,0,1} }
is a fine way to express an identity matrix. :-)
Cheers,
Chris
On Mar 25, 2014, at 5:31 PM, Lucian Smith <lp...@uw...> wrote:
> OK, I've been immersed more in the MathML side of things than the arrays
> package side of things, so that probably explains why I'm being
> confusing.
>
> The deal is that MathML has vectors and two-dimensional matrices. If
> you want something three-dimensional, you have to either make a <vector>
> of <vector> of <vector>'s or a <vector> of <matrix>'s, or a <matrix> of
> <vectors>. There is no definition, in MathML, that defines a <matrix>
> with three dimensions.
>
> Likewise, a <matrix> and a <vector> of <vector>s are two very different
> MathML constructs. You could interpret them both the same way if you
> wanted, but that's a choice you're making, not MathML.
>
> A 'ragged' vector of vecors I meant as something like:
>
> {
> {1, 2, 3},
> {4},
> {5, 6, 7, 8, 9}
> }
>
> which is not a matrix unless you have a rule that states that you're
> supposed to fill everything out with zeroes. (If you did, the above
> case would be a 3x5 matrix.)
>
> If the arrays package only allows 'non-ragged' 2d matrices, it would be
> relatively easy to reject (or fix) any ragged ones the parser was asked
> to parse, and to turn them into either matrices or vectors of vectors
> (as in, use the MathML contstructs of one or the other).
>
> This is why I suggested that {{1, 2}, {3, 4}} produce a vector of
> vectors, and that matrix({{1, 2}, {3, 4}}) produce a matrix. That way,
> there would be a way, in the infix, to distinguish between the two
> different MathML constructs. Interpreters might choose to treat them
> both the same, and that would be fine. It would also mean that in the
> future, you could produce 3d arrays in whatever form you wished,
> unambiguously.
>
> -Lucian
>
> On Tue, Mar 25, 2014 at 04:55:59PM -0600, Chris J. Myers wrote:
>> What do you mean by ragged? I don't think we can express this in the data model. The current data model just allows one size per dimension. I think 3-dimensions (or more) is easy in the data model, you just have more dimensions each with a size. I don't see this as a vector of vector of vectors. I see this as 3-dimensional matrix.
>>
>> Chris
>>
>> On Mar 25, 2014, at 4:47 PM, Lucian Smith <lp...@uw...> wrote:
>>
>>> On Tue, Mar 25, 2014 at 04:34:22PM -0600, Chris J. Myers wrote:
>>>> I don't envision that we will support both matrices and vectors of vectors. I think we only have one and two dimensional arrays period. We can call the two dimensional arrays vectors of vectors OR matrices, but I would prefer to think of them as one and the same. Indeed, I don't know how we would express a difference in the current proposed arrays data model.
>>>
>>> Well, the MathML is different, and that's what the infix parser
>>> produces. And, as noted, a vector of vectors can be ragged. Do you
>>> want that possibility? Also also, functions like 'transpose' behave
>>> differently if handed a vector vs. being handed a matrix. If you limit
>>> what's present to only one type, you preclude the other behavior.
>>>
>>>> However, I like your vector of vector assignment method below as the way to initialize a matrix (vector of vectors).
>>>
>>> So you would want to make it impossible, in the infix, to produce a
>>> vector of vectors, and instead make it always produce a matrix? I can
>>> do that, but it's non-extendable: if we ever want arrays of more than 2
>>> dimensions, we will need to have a way of expressing vectors of vectors
>>> of vectors (etc.).
>>>
>>> -Lucian
>>>
>>>> On Mar 25, 2014, at 4:04 PM, Lucian Smith <luc...@gm...> wrote:
>>>>
>>>>> Sounds like a plan, then: I'll use the C/Java syntax for the first pass, and keep in mind a MATLAB option going forward.
>>>>>
>>>>> I have one other question: C and Java don't have matrices, but only have vectors of vectors. The difference is that all the rows of a matrix must have the same dimension, but a vector of vectors might be 'ragged'.
>>>>>
>>>>> Without moving to MATLAB syntax, I can't think of any way syntactically (i.e. with []'s and {}'s) to distinguish between the two situations. What if we created vectors of vectors with []'s and {}'s, then, and if you wanted a matrix, you used it like a function, i.e.:
>>>>>
>>>>> {{1, 2, 3}, {2, 3, 4}, {3, 4, 5} } <--would make a vector of vectors
>>>>>
>>>>> matrix({{1, 2, 3}, {2, 3, 4}, {3, 4, 5} }) <--would make a matrix
>>>>>
>>>>> or:
>>>>>
>>>>> matrix({1, 2, 3}, {2, 3, 4}, {3, 4, 5}) <--would make a matrix
>>>>>
>>>>> Would we want to allow both syntaxes? i.e. "matrix(X)' would work if X was a vector of vectors, and 'matrix(x, y, z)' would work if x, y, and z were all vectors? And I assume that if you tried to construct a matrix out of a 'ragged' set of vectors, this would be an error, as opposed to being allowed to automatically fill in the blanks with zeroes?
>>>>>
>>>>> -Lucian
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Mar 25, 2014 at 2:24 PM, Chris J. Myers <my...@ec...> wrote:
>>>>> I also think we should focus on C/Java syntax first. I also agree that having a Matlab format option may be nice in the future as I agree that modelers likely are more familiar with that. However, I expect that we would need to look at all choices in format up to this point to make sure they are consistent with Matlab syntax. They may be. Matlab is similar to C/Java but it is just different enough to always confuse me :-).
>>>>>
>>>>> Chris
>>>>>
>>>>> On Mar 25, 2014, at 3:12 PM, Michael Hucka <mh...@ca...> wrote:
>>>>>
>>>>>> On Tue, 25 Mar 2014 14:09:13 -0700, Lucian Smith wrote:
>>>>>>> So, let's get a back-and-forth translator for the C/Java syntax up and
>>>>>>> running, and then I'll see about an alternate for MATLAB? I feel like a
>>>>>>> MATLAB syntax might be really useful for actual modelers; we're all
>>>>>>> programmers here, so are somewhat biased. But I have no actual modelers to
>>>>>>> point to who I know would like it; it's just my sense, based on the
>>>>>>> preponderance of MATLAB models in the literature.
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>> There wouldn't need to be a switch/option for the formats at this point, until such time as an alternative is implemented.
>>>>>>
>>>>>> MH
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
> ------------------------------------------------------------------------------
> 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-25 23:31:12
|
OK, I've been immersed more in the MathML side of things than the arrays
package side of things, so that probably explains why I'm being
confusing.
The deal is that MathML has vectors and two-dimensional matrices. If
you want something three-dimensional, you have to either make a <vector>
of <vector> of <vector>'s or a <vector> of <matrix>'s, or a <matrix> of
<vectors>. There is no definition, in MathML, that defines a <matrix>
with three dimensions.
Likewise, a <matrix> and a <vector> of <vector>s are two very different
MathML constructs. You could interpret them both the same way if you
wanted, but that's a choice you're making, not MathML.
A 'ragged' vector of vecors I meant as something like:
{
{1, 2, 3},
{4},
{5, 6, 7, 8, 9}
}
which is not a matrix unless you have a rule that states that you're
supposed to fill everything out with zeroes. (If you did, the above
case would be a 3x5 matrix.)
If the arrays package only allows 'non-ragged' 2d matrices, it would be
relatively easy to reject (or fix) any ragged ones the parser was asked
to parse, and to turn them into either matrices or vectors of vectors
(as in, use the MathML contstructs of one or the other).
This is why I suggested that {{1, 2}, {3, 4}} produce a vector of
vectors, and that matrix({{1, 2}, {3, 4}}) produce a matrix. That way,
there would be a way, in the infix, to distinguish between the two
different MathML constructs. Interpreters might choose to treat them
both the same, and that would be fine. It would also mean that in the
future, you could produce 3d arrays in whatever form you wished,
unambiguously.
-Lucian
On Tue, Mar 25, 2014 at 04:55:59PM -0600, Chris J. Myers wrote:
> What do you mean by ragged? I don't think we can express this in the data model. The current data model just allows one size per dimension. I think 3-dimensions (or more) is easy in the data model, you just have more dimensions each with a size. I don't see this as a vector of vector of vectors. I see this as 3-dimensional matrix.
>
> Chris
>
> On Mar 25, 2014, at 4:47 PM, Lucian Smith <lp...@uw...> wrote:
>
> > On Tue, Mar 25, 2014 at 04:34:22PM -0600, Chris J. Myers wrote:
> >> I don't envision that we will support both matrices and vectors of vectors. I think we only have one and two dimensional arrays period. We can call the two dimensional arrays vectors of vectors OR matrices, but I would prefer to think of them as one and the same. Indeed, I don't know how we would express a difference in the current proposed arrays data model.
> >
> > Well, the MathML is different, and that's what the infix parser
> > produces. And, as noted, a vector of vectors can be ragged. Do you
> > want that possibility? Also also, functions like 'transpose' behave
> > differently if handed a vector vs. being handed a matrix. If you limit
> > what's present to only one type, you preclude the other behavior.
> >
> >> However, I like your vector of vector assignment method below as the way to initialize a matrix (vector of vectors).
> >
> > So you would want to make it impossible, in the infix, to produce a
> > vector of vectors, and instead make it always produce a matrix? I can
> > do that, but it's non-extendable: if we ever want arrays of more than 2
> > dimensions, we will need to have a way of expressing vectors of vectors
> > of vectors (etc.).
> >
> > -Lucian
> >
> >> On Mar 25, 2014, at 4:04 PM, Lucian Smith <luc...@gm...> wrote:
> >>
> >>> Sounds like a plan, then: I'll use the C/Java syntax for the first pass, and keep in mind a MATLAB option going forward.
> >>>
> >>> I have one other question: C and Java don't have matrices, but only have vectors of vectors. The difference is that all the rows of a matrix must have the same dimension, but a vector of vectors might be 'ragged'.
> >>>
> >>> Without moving to MATLAB syntax, I can't think of any way syntactically (i.e. with []'s and {}'s) to distinguish between the two situations. What if we created vectors of vectors with []'s and {}'s, then, and if you wanted a matrix, you used it like a function, i.e.:
> >>>
> >>> {{1, 2, 3}, {2, 3, 4}, {3, 4, 5} } <--would make a vector of vectors
> >>>
> >>> matrix({{1, 2, 3}, {2, 3, 4}, {3, 4, 5} }) <--would make a matrix
> >>>
> >>> or:
> >>>
> >>> matrix({1, 2, 3}, {2, 3, 4}, {3, 4, 5}) <--would make a matrix
> >>>
> >>> Would we want to allow both syntaxes? i.e. "matrix(X)' would work if X was a vector of vectors, and 'matrix(x, y, z)' would work if x, y, and z were all vectors? And I assume that if you tried to construct a matrix out of a 'ragged' set of vectors, this would be an error, as opposed to being allowed to automatically fill in the blanks with zeroes?
> >>>
> >>> -Lucian
> >>>
> >>>
> >>>
> >>> On Tue, Mar 25, 2014 at 2:24 PM, Chris J. Myers <my...@ec...> wrote:
> >>> I also think we should focus on C/Java syntax first. I also agree that having a Matlab format option may be nice in the future as I agree that modelers likely are more familiar with that. However, I expect that we would need to look at all choices in format up to this point to make sure they are consistent with Matlab syntax. They may be. Matlab is similar to C/Java but it is just different enough to always confuse me :-).
> >>>
> >>> Chris
> >>>
> >>> On Mar 25, 2014, at 3:12 PM, Michael Hucka <mh...@ca...> wrote:
> >>>
> >>>> On Tue, 25 Mar 2014 14:09:13 -0700, Lucian Smith wrote:
> >>>>> So, let's get a back-and-forth translator for the C/Java syntax up and
> >>>>> running, and then I'll see about an alternate for MATLAB? I feel like a
> >>>>> MATLAB syntax might be really useful for actual modelers; we're all
> >>>>> programmers here, so are somewhat biased. But I have no actual modelers to
> >>>>> point to who I know would like it; it's just my sense, based on the
> >>>>> preponderance of MATLAB models in the literature.
> >>>>
> >>>> Agreed.
> >>>>
> >>>> There wouldn't need to be a switch/option for the formats at this point, until such time as an alternative is implemented.
> >>>>
> >>>> MH
> >>>>
> >>>> ------------------------------------------------------------------------------
> >>>> 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
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> 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
> >>>
> >>> ------------------------------------------------------------------------------
> >>> 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
> >>
> >
> >> ------------------------------------------------------------------------------
> >> 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
> >
> >
> > ------------------------------------------------------------------------------
> > 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
>
>
> ------------------------------------------------------------------------------
> 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: Chris J. M. <my...@ec...> - 2014-03-25 22:56:14
|
What do you mean by ragged? I don't think we can express this in the data model. The current data model just allows one size per dimension. I think 3-dimensions (or more) is easy in the data model, you just have more dimensions each with a size. I don't see this as a vector of vector of vectors. I see this as 3-dimensional matrix.
Chris
On Mar 25, 2014, at 4:47 PM, Lucian Smith <lp...@uw...> wrote:
> On Tue, Mar 25, 2014 at 04:34:22PM -0600, Chris J. Myers wrote:
>> I don't envision that we will support both matrices and vectors of vectors. I think we only have one and two dimensional arrays period. We can call the two dimensional arrays vectors of vectors OR matrices, but I would prefer to think of them as one and the same. Indeed, I don't know how we would express a difference in the current proposed arrays data model.
>
> Well, the MathML is different, and that's what the infix parser
> produces. And, as noted, a vector of vectors can be ragged. Do you
> want that possibility? Also also, functions like 'transpose' behave
> differently if handed a vector vs. being handed a matrix. If you limit
> what's present to only one type, you preclude the other behavior.
>
>> However, I like your vector of vector assignment method below as the way to initialize a matrix (vector of vectors).
>
> So you would want to make it impossible, in the infix, to produce a
> vector of vectors, and instead make it always produce a matrix? I can
> do that, but it's non-extendable: if we ever want arrays of more than 2
> dimensions, we will need to have a way of expressing vectors of vectors
> of vectors (etc.).
>
> -Lucian
>
>> On Mar 25, 2014, at 4:04 PM, Lucian Smith <luc...@gm...> wrote:
>>
>>> Sounds like a plan, then: I'll use the C/Java syntax for the first pass, and keep in mind a MATLAB option going forward.
>>>
>>> I have one other question: C and Java don't have matrices, but only have vectors of vectors. The difference is that all the rows of a matrix must have the same dimension, but a vector of vectors might be 'ragged'.
>>>
>>> Without moving to MATLAB syntax, I can't think of any way syntactically (i.e. with []'s and {}'s) to distinguish between the two situations. What if we created vectors of vectors with []'s and {}'s, then, and if you wanted a matrix, you used it like a function, i.e.:
>>>
>>> {{1, 2, 3}, {2, 3, 4}, {3, 4, 5} } <--would make a vector of vectors
>>>
>>> matrix({{1, 2, 3}, {2, 3, 4}, {3, 4, 5} }) <--would make a matrix
>>>
>>> or:
>>>
>>> matrix({1, 2, 3}, {2, 3, 4}, {3, 4, 5}) <--would make a matrix
>>>
>>> Would we want to allow both syntaxes? i.e. "matrix(X)' would work if X was a vector of vectors, and 'matrix(x, y, z)' would work if x, y, and z were all vectors? And I assume that if you tried to construct a matrix out of a 'ragged' set of vectors, this would be an error, as opposed to being allowed to automatically fill in the blanks with zeroes?
>>>
>>> -Lucian
>>>
>>>
>>>
>>> On Tue, Mar 25, 2014 at 2:24 PM, Chris J. Myers <my...@ec...> wrote:
>>> I also think we should focus on C/Java syntax first. I also agree that having a Matlab format option may be nice in the future as I agree that modelers likely are more familiar with that. However, I expect that we would need to look at all choices in format up to this point to make sure they are consistent with Matlab syntax. They may be. Matlab is similar to C/Java but it is just different enough to always confuse me :-).
>>>
>>> Chris
>>>
>>> On Mar 25, 2014, at 3:12 PM, Michael Hucka <mh...@ca...> wrote:
>>>
>>>> On Tue, 25 Mar 2014 14:09:13 -0700, Lucian Smith wrote:
>>>>> So, let's get a back-and-forth translator for the C/Java syntax up and
>>>>> running, and then I'll see about an alternate for MATLAB? I feel like a
>>>>> MATLAB syntax might be really useful for actual modelers; we're all
>>>>> programmers here, so are somewhat biased. But I have no actual modelers to
>>>>> point to who I know would like it; it's just my sense, based on the
>>>>> preponderance of MATLAB models in the literature.
>>>>
>>>> Agreed.
>>>>
>>>> There wouldn't need to be a switch/option for the formats at this point, until such time as an alternative is implemented.
>>>>
>>>> MH
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>
>
>> ------------------------------------------------------------------------------
>> 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
>
>
> ------------------------------------------------------------------------------
> 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-25 22:47:58
|
On Tue, Mar 25, 2014 at 04:34:22PM -0600, Chris J. Myers wrote:
> I don't envision that we will support both matrices and vectors of vectors. I think we only have one and two dimensional arrays period. We can call the two dimensional arrays vectors of vectors OR matrices, but I would prefer to think of them as one and the same. Indeed, I don't know how we would express a difference in the current proposed arrays data model.
Well, the MathML is different, and that's what the infix parser
produces. And, as noted, a vector of vectors can be ragged. Do you
want that possibility? Also also, functions like 'transpose' behave
differently if handed a vector vs. being handed a matrix. If you limit
what's present to only one type, you preclude the other behavior.
> However, I like your vector of vector assignment method below as the way to initialize a matrix (vector of vectors).
So you would want to make it impossible, in the infix, to produce a
vector of vectors, and instead make it always produce a matrix? I can
do that, but it's non-extendable: if we ever want arrays of more than 2
dimensions, we will need to have a way of expressing vectors of vectors
of vectors (etc.).
-Lucian
> On Mar 25, 2014, at 4:04 PM, Lucian Smith <luc...@gm...> wrote:
>
> > Sounds like a plan, then: I'll use the C/Java syntax for the first pass, and keep in mind a MATLAB option going forward.
> >
> > I have one other question: C and Java don't have matrices, but only have vectors of vectors. The difference is that all the rows of a matrix must have the same dimension, but a vector of vectors might be 'ragged'.
> >
> > Without moving to MATLAB syntax, I can't think of any way syntactically (i.e. with []'s and {}'s) to distinguish between the two situations. What if we created vectors of vectors with []'s and {}'s, then, and if you wanted a matrix, you used it like a function, i.e.:
> >
> > {{1, 2, 3}, {2, 3, 4}, {3, 4, 5} } <--would make a vector of vectors
> >
> > matrix({{1, 2, 3}, {2, 3, 4}, {3, 4, 5} }) <--would make a matrix
> >
> > or:
> >
> > matrix({1, 2, 3}, {2, 3, 4}, {3, 4, 5}) <--would make a matrix
> >
> > Would we want to allow both syntaxes? i.e. "matrix(X)' would work if X was a vector of vectors, and 'matrix(x, y, z)' would work if x, y, and z were all vectors? And I assume that if you tried to construct a matrix out of a 'ragged' set of vectors, this would be an error, as opposed to being allowed to automatically fill in the blanks with zeroes?
> >
> > -Lucian
> >
> >
> >
> > On Tue, Mar 25, 2014 at 2:24 PM, Chris J. Myers <my...@ec...> wrote:
> > I also think we should focus on C/Java syntax first. I also agree that having a Matlab format option may be nice in the future as I agree that modelers likely are more familiar with that. However, I expect that we would need to look at all choices in format up to this point to make sure they are consistent with Matlab syntax. They may be. Matlab is similar to C/Java but it is just different enough to always confuse me :-).
> >
> > Chris
> >
> > On Mar 25, 2014, at 3:12 PM, Michael Hucka <mh...@ca...> wrote:
> >
> > > On Tue, 25 Mar 2014 14:09:13 -0700, Lucian Smith wrote:
> > >> So, let's get a back-and-forth translator for the C/Java syntax up and
> > >> running, and then I'll see about an alternate for MATLAB? I feel like a
> > >> MATLAB syntax might be really useful for actual modelers; we're all
> > >> programmers here, so are somewhat biased. But I have no actual modelers to
> > >> point to who I know would like it; it's just my sense, based on the
> > >> preponderance of MATLAB models in the literature.
> > >
> > > Agreed.
> > >
> > > There wouldn't need to be a switch/option for the formats at this point, until such time as an alternative is implemented.
> > >
> > > MH
> > >
> > > ------------------------------------------------------------------------------
> > > 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
> >
> >
> > ------------------------------------------------------------------------------
> > 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
> >
> > ------------------------------------------------------------------------------
> > 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
>
> ------------------------------------------------------------------------------
> 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: Chris J. M. <my...@ec...> - 2014-03-25 22:34:37
|
I don't envision that we will support both matrices and vectors of vectors. I think we only have one and two dimensional arrays period. We can call the two dimensional arrays vectors of vectors OR matrices, but I would prefer to think of them as one and the same. Indeed, I don't know how we would express a difference in the current proposed arrays data model.
However, I like your vector of vector assignment method below as the way to initialize a matrix (vector of vectors).
Chris
On Mar 25, 2014, at 4:04 PM, Lucian Smith <luc...@gm...> wrote:
> Sounds like a plan, then: I'll use the C/Java syntax for the first pass, and keep in mind a MATLAB option going forward.
>
> I have one other question: C and Java don't have matrices, but only have vectors of vectors. The difference is that all the rows of a matrix must have the same dimension, but a vector of vectors might be 'ragged'.
>
> Without moving to MATLAB syntax, I can't think of any way syntactically (i.e. with []'s and {}'s) to distinguish between the two situations. What if we created vectors of vectors with []'s and {}'s, then, and if you wanted a matrix, you used it like a function, i.e.:
>
> {{1, 2, 3}, {2, 3, 4}, {3, 4, 5} } <--would make a vector of vectors
>
> matrix({{1, 2, 3}, {2, 3, 4}, {3, 4, 5} }) <--would make a matrix
>
> or:
>
> matrix({1, 2, 3}, {2, 3, 4}, {3, 4, 5}) <--would make a matrix
>
> Would we want to allow both syntaxes? i.e. "matrix(X)' would work if X was a vector of vectors, and 'matrix(x, y, z)' would work if x, y, and z were all vectors? And I assume that if you tried to construct a matrix out of a 'ragged' set of vectors, this would be an error, as opposed to being allowed to automatically fill in the blanks with zeroes?
>
> -Lucian
>
>
>
> On Tue, Mar 25, 2014 at 2:24 PM, Chris J. Myers <my...@ec...> wrote:
> I also think we should focus on C/Java syntax first. I also agree that having a Matlab format option may be nice in the future as I agree that modelers likely are more familiar with that. However, I expect that we would need to look at all choices in format up to this point to make sure they are consistent with Matlab syntax. They may be. Matlab is similar to C/Java but it is just different enough to always confuse me :-).
>
> Chris
>
> On Mar 25, 2014, at 3:12 PM, Michael Hucka <mh...@ca...> wrote:
>
> > On Tue, 25 Mar 2014 14:09:13 -0700, Lucian Smith wrote:
> >> So, let's get a back-and-forth translator for the C/Java syntax up and
> >> running, and then I'll see about an alternate for MATLAB? I feel like a
> >> MATLAB syntax might be really useful for actual modelers; we're all
> >> programmers here, so are somewhat biased. But I have no actual modelers to
> >> point to who I know would like it; it's just my sense, based on the
> >> preponderance of MATLAB models in the literature.
> >
> > Agreed.
> >
> > There wouldn't need to be a switch/option for the formats at this point, until such time as an alternative is implemented.
> >
> > MH
> >
> > ------------------------------------------------------------------------------
> > 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
>
>
> ------------------------------------------------------------------------------
> 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
>
> ------------------------------------------------------------------------------
> 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. <luc...@gm...> - 2014-03-25 22:04:10
|
Sounds like a plan, then: I'll use the C/Java syntax for the first pass,
and keep in mind a MATLAB option going forward.
I have one other question: C and Java don't have matrices, but only have
vectors of vectors. The difference is that all the rows of a matrix must
have the same dimension, but a vector of vectors might be 'ragged'.
Without moving to MATLAB syntax, I can't think of any way syntactically
(i.e. with []'s and {}'s) to distinguish between the two situations. What
if we created vectors of vectors with []'s and {}'s, then, and if you
wanted a matrix, you used it like a function, i.e.:
{{1, 2, 3}, {2, 3, 4}, {3, 4, 5} } <--would make a vector of vectors
matrix({{1, 2, 3}, {2, 3, 4}, {3, 4, 5} }) <--would make a matrix
or:
matrix({1, 2, 3}, {2, 3, 4}, {3, 4, 5}) <--would make a matrix
Would we want to allow both syntaxes? i.e. "matrix(X)' would work if X was
a vector of vectors, and 'matrix(x, y, z)' would work if x, y, and z were
all vectors? And I assume that if you tried to construct a matrix out of a
'ragged' set of vectors, this would be an error, as opposed to being
allowed to automatically fill in the blanks with zeroes?
-Lucian
On Tue, Mar 25, 2014 at 2:24 PM, Chris J. Myers <my...@ec...> wrote:
> I also think we should focus on C/Java syntax first. I also agree that
> having a Matlab format option may be nice in the future as I agree that
> modelers likely are more familiar with that. However, I expect that we
> would need to look at all choices in format up to this point to make sure
> they are consistent with Matlab syntax. They may be. Matlab is similar to
> C/Java but it is just different enough to always confuse me :-).
>
> Chris
>
> On Mar 25, 2014, at 3:12 PM, Michael Hucka <mh...@ca...> wrote:
>
> > On Tue, 25 Mar 2014 14:09:13 -0700, Lucian Smith wrote:
> >> So, let's get a back-and-forth translator for the C/Java syntax up and
> >> running, and then I'll see about an alternate for MATLAB? I feel like a
> >> MATLAB syntax might be really useful for actual modelers; we're all
> >> programmers here, so are somewhat biased. But I have no actual
> modelers to
> >> point to who I know would like it; it's just my sense, based on the
> >> preponderance of MATLAB models in the literature.
> >
> > Agreed.
> >
> > There wouldn't need to be a switch/option for the formats at this point,
> until such time as an alternative is implemented.
> >
> > MH
> >
> >
> ------------------------------------------------------------------------------
> > 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
>
>
>
> ------------------------------------------------------------------------------
> 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: Chris J. M. <my...@ec...> - 2014-03-25 21:24:17
|
I also think we should focus on C/Java syntax first. I also agree that having a Matlab format option may be nice in the future as I agree that modelers likely are more familiar with that. However, I expect that we would need to look at all choices in format up to this point to make sure they are consistent with Matlab syntax. They may be. Matlab is similar to C/Java but it is just different enough to always confuse me :-). Chris On Mar 25, 2014, at 3:12 PM, Michael Hucka <mh...@ca...> wrote: > On Tue, 25 Mar 2014 14:09:13 -0700, Lucian Smith wrote: >> So, let's get a back-and-forth translator for the C/Java syntax up and >> running, and then I'll see about an alternate for MATLAB? I feel like a >> MATLAB syntax might be really useful for actual modelers; we're all >> programmers here, so are somewhat biased. But I have no actual modelers to >> point to who I know would like it; it's just my sense, based on the >> preponderance of MATLAB models in the literature. > > Agreed. > > There wouldn't need to be a switch/option for the formats at this point, until such time as an alternative is implemented. > > MH > > ------------------------------------------------------------------------------ > 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: Michael H. <mh...@ca...> - 2014-03-25 21:13:12
|
On Tue, 25 Mar 2014 14:09:13 -0700, Lucian Smith wrote: > So, let's get a back-and-forth translator for the C/Java syntax up and > running, and then I'll see about an alternate for MATLAB? I feel like a > MATLAB syntax might be really useful for actual modelers; we're all > programmers here, so are somewhat biased. But I have no actual modelers to > point to who I know would like it; it's just my sense, based on the > preponderance of MATLAB models in the literature. Agreed. There wouldn't need to be a switch/option for the formats at this point, until such time as an alternative is implemented. MH |
|
From: Lucian S. <luc...@gm...> - 2014-03-25 21:09:20
|
There are two levels here: infix-to-ASTNodes, and ASTNodes-to-infix. The ASTNodes-to-MATLAB-infix would be relatively straightforward. A MATLAB-infix-to-ASTNode translator would be a little more work, but I believe it could be done. The main difficulty I forsee would be strings of the form "x(y)": In the C/Java syntax, strings like that are always functions; in MATLAB, they would sometimes be vector selectors, if 'x' was a vector in the model. However, we do have a way of providing a Model to the infix translator, so we could use that to find the vectors and translate appropriately. (Additionally, if 'x' was indeed a vector in the model, 'x(y)' could have no other useful interpretation.) So, let's get a back-and-forth translator for the C/Java syntax up and running, and then I'll see about an alternate for MATLAB? I feel like a MATLAB syntax might be really useful for actual modelers; we're all programmers here, so are somewhat biased. But I have no actual modelers to point to who I know would like it; it's just my sense, based on the preponderance of MATLAB models in the literature. -Lucian On Tue, Mar 25, 2014 at 1:50 PM, Michael Hucka <mh...@ca...> wrote: > On Fri, 21 Mar 2014 16:07:53 -0700, Lucian Smith wrote: > > So, we've had a couple different discussions about infix syntax for > arrays, > > but it's all been hypothetical up until now. At this point, after > Sarah's > > heroic efforts getting extended MathML into libSBML's 'ASTNode' system, I > > am actually in a position to implement infix support for it! So we need > to > > make some final decisions. > > > > I've written up a document of what all I think we need to decide at: > > > > > https://docs.google.com/document/d/1z9QLbmfltAIOkPcR883g4Ml5S7B5crJULXMX68ImL6k/edit# > > > > Feel free to comment, edit, and whatever else! > > Thanks for writing up the different options; that was really helpful. > > The fact that MATLAB is not that different from the others lead to the > following thought: could the parser provide a switch that would let the > caller chose between MATLAB syntax on the one hand and C/Java on the other? > Would that be difficult to implement? > > Because it might be quite useful for tools that interface to MATLAB. > > MH > > > ------------------------------------------------------------------------------ > 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: Michael H. <mh...@ca...> - 2014-03-25 20:50:19
|
On Fri, 21 Mar 2014 16:07:53 -0700, Lucian Smith wrote: > So, we've had a couple different discussions about infix syntax for arrays, > but it's all been hypothetical up until now. At this point, after Sarah's > heroic efforts getting extended MathML into libSBML's 'ASTNode' system, I > am actually in a position to implement infix support for it! So we need to > make some final decisions. > > I've written up a document of what all I think we need to decide at: > > https://docs.google.com/document/d/1z9QLbmfltAIOkPcR883g4Ml5S7B5crJULXMX68ImL6k/edit# > > Feel free to comment, edit, and whatever else! Thanks for writing up the different options; that was really helpful. The fact that MATLAB is not that different from the others lead to the following thought: could the parser provide a switch that would let the caller chose between MATLAB syntax on the one hand and C/Java on the other? Would that be difficult to implement? Because it might be quite useful for tools that interface to MATLAB. MH |
|
From: Michael H. <mh...@ca...> - 2014-03-25 20:47:12
|
On Tue, 25 Mar 2014 07:30:23 -0600, Chris J. Myers wrote: > Well, it is not part of the standard, it is just an agreement between > libsbml and jsbml for a helper parser for math strings. > > I think since there is general agreement on C/Java syntax, then that > is what the parser should use. I have no problems with curly braces > :-). FWIW, I also favor the C/Java syntax, if one had to be picked. MH |
