Menu
▾
▴
sbml-arrays
|
From: Lucian S. <luc...@gm...> - 2014-03-21 23:08:00
|
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! -Lucian |
|
From: Chris J. M. <my...@ec...> - 2014-03-22 15:50:34
|
Hi, I vote for using the C/Java syntax exclusively for selectors. I don't like the idea of using parentheses as they can be confused with use with functions. I also prefer to use C/Java style construction with braces. We are using C/Java syntax for everything else, so why confuse things. As for functions, I'm okay with one short name and one long name for each though that is a bit unique as other functions in SBML I believe all just have one name. Are there exceptions to this? By the way, there are more functions than you listed. Please see the recently updated Arrays spec. Should be checked into SVN. I think we should restrict arithmetic to be between compatible sized objects. Namely, add and subtract should be same size objects while multiply requires number of columns of first object to match number of rows of second, if matrices. No strong feeling on transpose. However, single quote is likely problematic. I object to incorporating ANY of the odd Matlab syntax. I always found that tremendously confusing. Matlab is designed as a tool to manipulate matrices, and that is where the syntax grew out of. SBML is not, so it should still be easy to work with non-matrices. Chris On Mar 21, 2014, at 5:07 PM, Lucian Smith <luc...@gm...> 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! > > -Lucian > ------------------------------------------------------------------------------ > 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: Sarah K. <ske...@ca...> - 2014-03-25 11:41:52
|
> I vote for using the C/Java syntax I agree. I think we should consistently use C/Java syntax for arrays related math. Sarah |
|
From: Nicolas R. <rod...@eb...> - 2014-03-25 12:36:10
|
On 25/03/2014 11:42, Sarah Keating wrote: >> I vote for using the C/Java syntax > I agree. > > I think we should consistently use C/Java syntax for arrays related math. Same for me. Nico |
|
From: Michael H. <mh...@ca...> - 2014-03-25 20:46:43
|
On Tue, 25 Mar 2014 08:38:39 -0700, Lucian Smith wrote: > On Tue, Mar 25, 2014 at 01:42:22PM +0100, Frank T. Bergmann wrote: >> I'm not sure we ought to standardize an infix syntax as well. (Just >> consider >> again the C / Java syntax here ... if you actually want to initialize an >> array with values, you would use curly brackets). >> >> Just saying :) > > Wait, I don't know what you mean. Using curly brackets was explicitly > mentioned in the document already. And what do you mean by 'as well'? > Standardizing the infix syntax is explicitly and solely what we are > proposing, so I can't tell what you're talking about. 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? MH |
|
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 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: Frank T. B. <fbe...@ca...> - 2014-03-25 13:19:45
|
> > I think we should consistently use C/Java syntax for arrays related math. > > Same for me. > I'm not sure we ought to standardize an infix syntax as well. (Just consider again the C / Java syntax here ... if you actually want to initialize an array with values, you would use curly brackets). Just saying :) Cheers Frank |
|
From: Chris J. M. <my...@ec...> - 2014-03-25 13:30:35
|
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 :-). Chris On Mar 25, 2014, at 6:42 AM, "Frank T. Bergmann" <fbe...@ca...> wrote: >>> I think we should consistently use C/Java syntax for arrays related > math. >> >> Same for me. >> > > I'm not sure we ought to standardize an infix syntax as well. (Just consider > again the C / Java syntax here ... if you actually want to initialize an > array with values, you would use curly brackets). > > Just saying :) > > Cheers > 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: 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 |
|
From: Lucian S. <lp...@uw...> - 2014-03-25 15:38:47
|
On Tue, Mar 25, 2014 at 01:42:22PM +0100, Frank T. Bergmann wrote: > > > I think we should consistently use C/Java syntax for arrays related > math. > > > > Same for me. > > > > I'm not sure we ought to standardize an infix syntax as well. (Just consider > again the C / Java syntax here ... if you actually want to initialize an > array with values, you would use curly brackets). > > Just saying :) Wait, I don't know what you mean. Using curly brackets was explicitly mentioned in the document already. And what do you mean by 'as well'? Standardizing the infix syntax is explicitly and solely what we are proposing, so I can't tell what you're talking about. -Lucian |
|
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: 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 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: 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: 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 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. <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: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 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-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: 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: 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: 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: 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 |
×
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