From: Chris J. M. <my...@ec...> - 2013-10-21 22:02:19
|
Hi, While not strictly part of the arrays specification, I was trying to figure how the extended mathML subset would be mapped to the string parser for mathML. Here are my observations and suggestions. 1) vector - used to express a vector explicitly in math. Suggest braces to group and commas to separate elements. Ex. { 1, 2, 3 } Note elements do not need to be constants but could be math expressions. 2) matrix/matrixrow - used to express a matrix explicitly in math. Natural extension of the above with braces and commas. Ex. { { 1, 0, 0 }, { 0, 1, 0 }, { 0, 0, 1 } } 3) selector - used to access an element in an array. Use square brackets. Ex. x[i+1] Note if x is 2-dimensional, this will return a vector composed of the first row. 4) determinant, transpose, vectorproduct, scalarproduct, and outerproduct - seems like function call simplest approach. Open to suggestions on names of functions. det(A) trans(A) vectorProd(A,B) scalarProd(A,B) outerProd(A,B) 5) sum, product, forall, exists - these were in the specification be looking at them more closely, they are not really just used for arrays. They use bvar, lowerlimit, uplimit, interval, and condition to setup an operation. I think sum and product should be candidates for a general MathML extension to the core. The forall and exists could also be such candidates, but they will be rather expensive to actually evaluate. Comments? Chris |
From: Lucian S. <luc...@gm...> - 2013-10-21 22:10:49
|
As far as the infix goes, I think I would just use square brackets everywhere. Parsers can distinguish between the two cases by whether or not there's a name in front of the first bracket: x = [a, b, c] vs. x = y[a] As far as the other functions, the L3 parser's current approach is to accept a variety of synonyms for several functions, so I'd accept any reasonable synonym: "determinant" and "det" would both probably be fine. I would be fine adding sum, etc. to the L3v2 core, too. We should probably have a conversation again about what specifically people would like to add. -Lucian On Mon, Oct 21, 2013 at 3:02 PM, Chris J. Myers <my...@ec...> wrote: > Hi, > > While not strictly part of the arrays specification, I was trying to figure how the extended mathML subset would be mapped to the string parser for mathML. Here are my observations and suggestions. > > 1) vector - used to express a vector explicitly in math. Suggest braces to group and commas to separate elements. > > Ex. { 1, 2, 3 } > > Note elements do not need to be constants but could be math expressions. > > 2) matrix/matrixrow - used to express a matrix explicitly in math. Natural extension of the above with braces and commas. > > Ex. { { 1, 0, 0 }, { 0, 1, 0 }, { 0, 0, 1 } } > > 3) selector - used to access an element in an array. Use square brackets. > > Ex. x[i+1] > > Note if x is 2-dimensional, this will return a vector composed of the first row. > > 4) determinant, transpose, vectorproduct, scalarproduct, and outerproduct - seems like function call simplest approach. Open to suggestions on names of functions. > > det(A) > trans(A) > vectorProd(A,B) > scalarProd(A,B) > outerProd(A,B) > > 5) sum, product, forall, exists - these were in the specification be looking at them more closely, they are not really just used for arrays. They use bvar, lowerlimit, uplimit, interval, and condition to setup an operation. I think sum and product should be candidates for a general MathML extension to the core. The forall and exists could also be such candidates, but they will be rather expensive to actually evaluate. > > Comments? > > Chris > |
From: Nicolas Le N. <n.l...@gm...> - 2013-10-22 18:20:21
|
On 22/10/13 16:48, Andreas Dräger wrote: >Braces are > more intuitive and also the regular mathematical notation in text books etc. Huh? In Germany then. In high school in France we used parenthesis. And from university we always used square brackets. Which are the two notations mentioned in the Wikipedia matrix page by the way (the arrays related pages only use square brackets). Braces were used for sets, which are something completely different. Until today If I saw {a, b, c}, I would never have thought of an array, but of an unordered list. Now I realise mathematics is maybe not a universal language after all. Programming is a different thing. It seems language inventors used everything they could find. -- 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...> - 2013-10-21 22:24:56
|
On Oct 21, 2013, at 4:10 PM, Lucian Smith <luc...@gm...> wrote: > As far as the infix goes, I think I would just use square brackets > everywhere. Parsers can distinguish between the two cases by whether > or not there's a name in front of the first bracket: > > x = [a, b, c] > > vs. > > x = y[a] I chose braces to match "C/Java" syntax as that is what you used for the other infix parser decisions. Seems like it is best to follow one accepted norm. > > As far as the other functions, the L3 parser's current approach is to > accept a variety of synonyms for several functions, so I'd accept any > reasonable synonym: "determinant" and "det" would both probably be > fine. > > I would be fine adding sum, etc. to the L3v2 core, too. We should > probably have a conversation again about what specifically people > would like to add. > There are many items such as sum in mathML which we omit that would be easy to compute so might as well include. There are many items though such as foall which would not be easy to compute and we should continue to avoid. Should likely move this one to sbml-discuss. Cheers, Chris |
From: Michael H. <mh...@ca...> - 2013-10-23 01:15:54
|
On Mon, 21 Oct 2013 16:24:42 -0600, Chris J. Myers wrote: > I chose braces to match "C/Java" syntax as that is what you used for > the other infix parser decisions. Seems like it is best to follow > one accepted norm. FWIW, I concur with this. MH |
From: Andreas D. <and...@en...> - 2013-10-22 15:48:44
|
Dear all, > As far as the infix goes, I think I would just use square brackets > everywhere. Parsers can distinguish between the two cases by whether > or not there's a name in front of the first bracket: > > x = [a, b, c] > > vs. > > x = y[a] IMHO, the braces are nicer and more intuitive for humans. The entire infix notation is intended to be written and read by humans and machines (in contrast to MathML code), so I would support Chris' proposal of using braces for arrays and matrices rather than square brackets (these I would only use for indices, just following Java/C syntax). Braces are more intuitive and also the regular mathematical notation in text books etc. > As far as the other functions, the L3 parser's current approach is to > accept a variety of synonyms for several functions, so I'd accept any > reasonable synonym: "determinant" and "det" would both probably be > fine. I agree and would also support using both keywords as synonyms. Similarly for other functions as well. > I would be fine adding sum, etc. to the L3v2 core, too. We should > probably have a conversation again about what specifically people > would like to add. > > -Lucian > > On Mon, Oct 21, 2013 at 3:02 PM, Chris J. Myers <my...@ec...> wrote: >> Hi, >> >> While not strictly part of the arrays specification, I was trying to figure how the extended mathML subset would be mapped to the string parser for mathML. Here are my observations and suggestions. >> >> 1) vector - used to express a vector explicitly in math. Suggest braces to group and commas to separate elements. >> >> Ex. { 1, 2, 3 } >> >> Note elements do not need to be constants but could be math expressions. >> >> 2) matrix/matrixrow - used to express a matrix explicitly in math. Natural extension of the above with braces and commas. >> >> Ex. { { 1, 0, 0 }, { 0, 1, 0 }, { 0, 0, 1 } } I would like the white spaces (blanks) to be optional. >> 3) selector - used to access an element in an array. Use square brackets. >> >> Ex. x[i+1] >> >> Note if x is 2-dimensional, this will return a vector composed of the first row. >> >> 4) determinant, transpose, vectorproduct, scalarproduct, and outerproduct - seems like function call simplest approach. Open to suggestions on names of functions. >> >> det(A) >> trans(A) >> vectorProd(A,B) >> scalarProd(A,B) >> outerProd(A,B) I would propose to use det/determinand(A) trans/transpose(A) cross(A,B) - instead of vectorProd, because this is the function's name in MATLAB and Mathematica and shorter, too. dot(A,B) - instead of scalarProd, because this is also used in MATLAB and shorter, too. outer(A,B) - instead of outerProd, because this is the name in Mathematica and shorter, too. >> 5) sum, product, forall, exists - these were in the specification be looking at them more closely, they are not really just used for arrays. They use bvar, lowerlimit, uplimit, interval, and condition to setup an operation. I think sum and product should be candidates for a general MathML extension to the core. The forall and exists could also be such candidates, but they will be rather expensive to actually evaluate. >> >> Comments? >> >> Chris >> Thanks for starting this discussion. Cheers Andreas -- Dr. Andreas Draeger University of California, San Diego, La Jolla, CA 92093-0412, USA Bioengineering Dept., Systems Biology Research Group, Office #2506 Phone: +1-858-534-9717, Fax: +1-858-822-3120, twitter: @dr_drae |
From: Chris J. M. <my...@ec...> - 2013-10-22 18:27:10
|
Remember this is just a libsbml/jsbml issue. Tools are free to have their own parsers with different syntax. Even libsbml has two different parsers now. I just wanted to make sure we get this straight as we just discovered that jsbml and libsbml did not agree on their string parser syntax (they do now). In Lucian's infix parser, he went with C/Java syntax (ex. using "&&" rather than "&" or "and"), so it is best to keep to it, I think. It is not too hard to make alternative ones for people who want different syntax. The mathML in the SBML remains the same. Cheers, Chris On Oct 22, 2013, at 12:20 PM, Nicolas Le Novere <n.l...@gm...> wrote: > On 22/10/13 16:48, Andreas Dräger wrote: >> Braces are >> more intuitive and also the regular mathematical notation in text books etc. > > Huh? In Germany then. In high school in France we used parenthesis. And from university we always used square brackets. Which are the two notations mentioned in the Wikipedia matrix page by the way (the arrays related pages only use square brackets). Braces were used for sets, which are something completely different. Until today If I saw {a, b, c}, I would never have thought of an array, but of an unordered list. Now I realise mathematics is maybe not a universal language after all. > > Programming is a different thing. It seems language inventors used everything they could find. > > -- > 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/ > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
From: Lucian S. <luc...@gm...> - 2013-10-22 19:00:49
|
Actually, if we're going to copy any other language's syntax for something, that something should almost certainly be Matlab, since that's what our audience will be most familiar with. It looks like matlab has both '&' and '&&', with subtly different meanings between the two. However, the latter is the more efficient term, so I would guess that 'best practices' would use that--does anyone familiar with Matlab models know if people actually do use '&&' more than '&'? Should we add '&' as alternate syntax meaning the same thing? Defining arrays in Matlab is done with square brackets, however, so I would think we definitely want to use that. We could theoretically *also* use {}'s, but I worry about 'stealing' too many characters from people's interpreters that might want to embed SBML infix-y things in it. Antimony is one example--I don't use []'s or {}'s yet, but I have so far tried to keep that to a minimum, so other systems can embed it as needed. -Lucian On Tue, Oct 22, 2013 at 11:27 AM, Chris J. Myers <my...@ec...> wrote: > Remember this is just a libsbml/jsbml issue. Tools are free to have their own parsers with different syntax. Even libsbml has two different parsers now. I just wanted to make sure we get this straight as we just discovered that jsbml and libsbml did not agree on their string parser syntax (they do now). In Lucian's infix parser, he went with C/Java syntax (ex. using "&&" rather than "&" or "and"), so it is best to keep to it, I think. It is not too hard to make alternative ones for people who want different syntax. The mathML in the SBML remains the same. > > Cheers, > > Chris > > On Oct 22, 2013, at 12:20 PM, Nicolas Le Novere <n.l...@gm...> wrote: > >> On 22/10/13 16:48, Andreas Dräger wrote: >>> Braces are >>> more intuitive and also the regular mathematical notation in text books etc. >> >> Huh? In Germany then. In high school in France we used parenthesis. And from university we always used square brackets. Which are the two notations mentioned in the Wikipedia matrix page by the way (the arrays related pages only use square brackets). Braces were used for sets, which are something completely different. Until today If I saw {a, b, c}, I would never have thought of an array, but of an unordered list. Now I realise mathematics is maybe not a universal language after all. >> >> Programming is a different thing. It seems language inventors used everything they could find. >> >> -- >> 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/ >> >> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
From: Chris J. M. <my...@ec...> - 2013-10-22 19:34:39
|
>>> > I would like the white spaces (blanks) to be optional. > Agreed. >>> > I would propose to use > > det/determinand(A) > trans/transpose(A) > cross(A,B) - instead of vectorProd, because this is the function's name in MATLAB and Mathematica and shorter, too. > dot(A,B) - instead of scalarProd, because this is also used in MATLAB and shorter, too. > outer(A,B) - instead of outerProd, because this is the name in Mathematica and shorter, too. > Assuming you meant "determinant", I like your names. As per Lucian's point about Matlab, I see the point, but I find matlab syntax pretty ugly at times. However, for matrix manipulation, it is likely the most well known. We could have a community poll of preferences like you did when you were working on your infix parser. However, ultimately these parsers are only helper functions for tool developers and tool developers can build their own for any syntax they like. The libraries could potentially have a C/Java version and a Matlab version much like libsbml has an infix and prefix version right now. The thing I want to make sure of is there is at least one version that is in agreement for both JSBML and libsbml to avoid the problem we had with no syntax that would work for both. Chris |
From: Lucian S. <luc...@gm...> - 2013-10-22 19:41:54
|
That is definitely a worthy goal ;-) When the arrays package has stabilized a bit and when it's possible to store the MathML in libSBML, I'll look into updating the infix parser. -Lucian On Tue, Oct 22, 2013 at 12:34 PM, Chris J. Myers <my...@ec...> wrote: >>>> >> I would like the white spaces (blanks) to be optional. >> > Agreed. >>>> >> I would propose to use >> >> det/determinand(A) >> trans/transpose(A) >> cross(A,B) - instead of vectorProd, because this is the function's name in MATLAB and Mathematica and shorter, too. >> dot(A,B) - instead of scalarProd, because this is also used in MATLAB and shorter, too. >> outer(A,B) - instead of outerProd, because this is the name in Mathematica and shorter, too. >> > Assuming you meant "determinant", I like your names. > > As per Lucian's point about Matlab, I see the point, but I find matlab syntax pretty ugly at times. However, for matrix manipulation, it is likely the most well known. We could have a community poll of preferences like you did when you were working on your infix parser. However, ultimately these parsers are only helper functions for tool developers and tool developers can build their own for any syntax they like. The libraries could potentially have a C/Java version and a Matlab version much like libsbml has an infix and prefix version right now. The thing I want to make sure of is there is at least one version that is in agreement for both JSBML and libsbml to avoid the problem we had with no syntax that would work for both. > > Chris > > > > |
From: Chris J. M. <my...@ec...> - 2013-10-22 20:47:04
|
Sounds good. Are we agreed on all the syntax except for {}'s versus []'s for specifying groups of values? If so, could we perhaps do a poll on that one to finalize the last bit? Or is it better to just go ahead and pick one and perhaps add support for both via an option? Chris On Oct 22, 2013, at 1:41 PM, Lucian Smith <luc...@gm...> wrote: > That is definitely a worthy goal ;-) > > When the arrays package has stabilized a bit and when it's possible to > store the MathML in libSBML, I'll look into updating the infix parser. > > -Lucian > > On Tue, Oct 22, 2013 at 12:34 PM, Chris J. Myers <my...@ec...> wrote: >>>>> >>> I would like the white spaces (blanks) to be optional. >>> >> Agreed. >>>>> >>> I would propose to use >>> >>> det/determinand(A) >>> trans/transpose(A) >>> cross(A,B) - instead of vectorProd, because this is the function's name in MATLAB and Mathematica and shorter, too. >>> dot(A,B) - instead of scalarProd, because this is also used in MATLAB and shorter, too. >>> outer(A,B) - instead of outerProd, because this is the name in Mathematica and shorter, too. >>> >> Assuming you meant "determinant", I like your names. >> >> As per Lucian's point about Matlab, I see the point, but I find matlab syntax pretty ugly at times. However, for matrix manipulation, it is likely the most well known. We could have a community poll of preferences like you did when you were working on your infix parser. However, ultimately these parsers are only helper functions for tool developers and tool developers can build their own for any syntax they like. The libraries could potentially have a C/Java version and a Matlab version much like libsbml has an infix and prefix version right now. The thing I want to make sure of is there is at least one version that is in agreement for both JSBML and libsbml to avoid the problem we had with no syntax that would work for both. >> >> Chris >> >> >> >> |