Menu
▾
▴
sbml-arrays — The SBML L3 Arrays and Sets package discussion list
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(27) |
Nov
|
Dec
(6) |
| 2014 |
Jan
(25) |
Feb
|
Mar
(44) |
Apr
(21) |
May
(1) |
Jun
(7) |
Jul
(3) |
Aug
(18) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(15) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(31) |
Jun
(4) |
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Sarah K. <ske...@ca...> - 2013-12-14 11:44:56
|
Hi Chris
This one is a query :-)
Spec states that only objects that have attributes of type SIdRef can
have a listOfIndices but what does an index mean when used with an
object that does not normally have a math element.
I'm clear on using the construct for
Rules/InitialAssigments/EventAssignments where you use the index to then
apply the math element to that instance of the variable but I am not
clear on the others.
For example:
Assume compartment c also has dimension 0 of size p
What would you expect to put in the math element of a species
<species id="s" compartment="c" >
<arrays:listOfDimensions>
<arrays:dimension arrays:size="p" arrays:dim="0"/>
</arrays:listOfDimensions>
<arrays:listOfIndices>
<arrays:index arrays:dim="0" arrays:attribute="compartment">
<math xmlns="http://www.w3.org/1998/Math/MathML">
</math>
</arrays:index>
</arrays:listOfIndices>
</species>
and what would it mean ???
Thanks
Sarah
|
|
From: Sarah K. <ske...@ca...> - 2013-12-14 11:43:50
|
Hi Chris I'm guessing these are typos but just making sure. 1. The for statement should read for (i=0; i < n; i++) since arrays are indexed from 0 2. The array in the example has size n = 10 so the number used for allocating the index in reverse should be 9 not 11. y[9-i] = x[i] and again in the actual math 11 should be 9 Thanks Sarah |
|
From: Chris J. M. <my...@ec...> - 2013-12-12 15:13:38
|
> On first glance the new 'dim' and 'attribute' attributes seem to work > well - although I might quibble with their names :-) > Please do quibble. I'm not fixed on them. > I can see that the examples section in the spec is out of date with this > scheme of things - should I just ignore them for now. Or indeed recreate > them using the new scheme whilst I try and get my head round it. > Creating examples by hand is tedious, so I did not want to update them until I received some feedback. I would be happy to have help updating them once we have agreed on names of the elements and that the basic approach is sound. Thanks, Chris |
|
From: Sarah K. <ske...@ca...> - 2013-12-12 14:38:05
|
Hi Chris Sorry this has sat so long; I was holding off until I was in a place where I could do some implementation - not quite there yet but almost ! I have started to look at your updated spec and will get back to you with more detailed stuff in separate threads over the next few days. [I prefer one topic per thread :-)] On first glance the new 'dim' and 'attribute' attributes seem to work well - although I might quibble with their names :-) I can see that the examples section in the spec is out of date with this scheme of things - should I just ignore them for now. Or indeed recreate them using the new scheme whilst I try and get my head round it. Thanks Sarah On 25/10/2013 14:43, Chris J. Myers wrote: > Thanks. > > Chris > > On Oct 25, 2013, at 4:18 AM, Nicolas Rodriguez <rod...@eb... > <mailto:rod...@eb...>> wrote: > >> Hi Chris, >> >> It look fine to me. >> >> cheers, >> Nico >> >> On 10/24/2013 08:46 PM, Chris J. Myers wrote: >>> Hi, >>> >>> I've not received any feedback on the arrays UML, so to help this process I've updated Section 3 of the arrays specification to describe the new UML. However, before updating the examples, I want to be sure we are all in agreement on the approach. So, please have a look at this and let me know what you think. Even if you are fine with it, please let me know so I have an idea that people have looked at it. >>> >>> Thanks for your help. >>> >>> Chris >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 > > > > ------------------------------------------------------------------------------ > 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-25 13:43:22
|
Thanks. Chris On Oct 25, 2013, at 4:18 AM, Nicolas Rodriguez <rod...@eb...> wrote: > Hi Chris, > > It look fine to me. > > cheers, > Nico > > On 10/24/2013 08:46 PM, Chris J. Myers wrote: >> Hi, >> >> I've not received any feedback on the arrays UML, so to help this process I've updated Section 3 of the arrays specification to describe the new UML. However, before updating the examples, I want to be sure we are all in agreement on the approach. So, please have a look at this and let me know what you think. Even if you are fine with it, please let me know so I have an idea that people have looked at it. >> >> Thanks for your help. >> >> Chris >> >> >> >> ------------------------------------------------------------------------------ >> 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: Nicolas R. <rod...@eb...> - 2013-10-25 10:18:42
|
Hi Chris, It look fine to me. cheers, Nico On 10/24/2013 08:46 PM, Chris J. Myers wrote: > Hi, > > I've not received any feedback on the arrays UML, so to help this process I've updated Section 3 of the arrays specification to describe the new UML. However, before updating the examples, I want to be sure we are all in agreement on the approach. So, please have a look at this and let me know what you think. Even if you are fine with it, please let me know so I have an idea that people have looked at it. > > Thanks for your help. > > Chris > > > > ------------------------------------------------------------------------------ > 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-24 19:46:24
|
Hi, I've not received any feedback on the arrays UML, so to help this process I've updated Section 3 of the arrays specification to describe the new UML. However, before updating the examples, I want to be sure we are all in agreement on the approach. So, please have a look at this and let me know what you think. Even if you are fine with it, please let me know so I have an idea that people have looked at it. Thanks for your help. 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: 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
>>
>>
>>
>>
|
|
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 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: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 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: 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: 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-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: 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: 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: Chris J. M. <my...@ec...> - 2013-10-17 20:44:06
|
Hi, Based on our recent discussions, I tried to come up with a UML diagram for the arrays package (see attached). Before adding it the specification and starting to write about it, I wanted to see if this looks good to people. Note that "dim" is used to indicate which dimension is referred to. The "attribute" is used to indicate what attribute is being indexed. The "id" in the dimension can be used in the index math, but it is locally scoped so cannot be used outside the element in which it is defined under. Comments? Chris |
|
From: Andreas D. <and...@un...> - 2013-10-03 19:48:57
|
Am 01.10.13 13:53, schrieb Chris J. Myers: > This looks like a good idea though I also hate the listOfListOf. Would this work for people? > > <species id="S1" compartment="C1" conversionFactor="P1"> > <listOfIndices> > <index attribute="compartment" dim="0"> > -- some math --- > </index> > <index attribute="compartment" dim="1"> > -- some math --- > </index> > <index attribute="conversionFactor" dim="0"> > -- some math --- > </index> > <index attribute="conversionFactor" dim="1"> > -- some math --- > </index> > </listOfIndices> > Hi, Since I missed the beginning of this discussion, I would like to ask why neither listOfIndices nor index have a namespace prefix? Don't both elements belong to a package? 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-03 19:13:09
|
Yes, they should have a namespace of arrays. This is just laziness on my part. Hacking XML by hand is tedious :-(. Chris On Oct 3, 2013, at 1:07 PM, Andreas Dräger <and...@un...> wrote: > Am 01.10.13 13:53, schrieb Chris J. Myers: >> This looks like a good idea though I also hate the listOfListOf. Would this work for people? >> >> <species id="S1" compartment="C1" conversionFactor="P1"> >> <listOfIndices> >> <index attribute="compartment" dim="0"> >> -- some math --- >> </index> >> <index attribute="compartment" dim="1"> >> -- some math --- >> </index> >> <index attribute="conversionFactor" dim="0"> >> -- some math --- >> </index> >> <index attribute="conversionFactor" dim="1"> >> -- some math --- >> </index> >> </listOfIndices> >> > > Hi, > > Since I missed the beginning of this discussion, I would like to ask why neither listOfIndices nor index have a namespace prefix? Don't both elements belong to a package? > > 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-01 20:53:51
|
This looks like a good idea though I also hate the listOfListOf. Would this work for people?
<species id="S1" compartment="C1" conversionFactor="P1">
<listOfIndices>
<index attribute="compartment" dim="0">
-- some math ---
</index>
<index attribute="compartment" dim="1">
-- some math ---
</index>
<index attribute="conversionFactor" dim="0">
-- some math ---
</index>
<index attribute="conversionFactor" dim="1">
-- some math ---
</index>
</listOfIndices>
Chris
On Oct 1, 2013, at 11:16 AM, Lucian Smith <luc...@gm...> wrote:
> Wait, I think 'groups' can answer this! Not using groups, using a
> similar thing that groups did.
>
> If 'listOfIndices' is tied to a particular attribute, the obvious
> solution is to give it an attribute that points to the attribute it
> extends:
>
> <species id="S1" compartment="C1" conversionFactor="P1">
> <listOfListOfIndices>
> <listOfIndices attribute="compartment">
> <!--the particular indices for the compartment-->
> </listOfIndices>
> <listOfIndices attribute="conversionFactor">
> <!--the particular indices for the conversionFactor-->
> </listOfIndices>
> </listOfListOfIndices>
>
> 'listOfListOfIndices' is a little awkward, but you get the idea.
>
> -Lucian
>
> On Tue, Oct 1, 2013 at 6:55 AM, Chris J. Myers <my...@ec...> wrote:
>> Hi Sarah,
>>
>> I'm okay with your plan to extend SBase with listOfDimensions and then having validation warnings for uses that we do not want to require support for initially.
>>
>> Note that listOfIndices though is different. You need an index on each SBaseRef attribute of an object. For an initial assignments, rate rules, assignment rules, species references, and event assignments, this is straightforward because there is just the one, the variable being assigned. However, for some other elements, there can be multiple references and thus multiple indices required. Consider, for example, a species. It has a compartment for which you may need an index if the compartment is an array. It also has a unit which may require an index. Finally, it has a conversion factor which may be an arrayed parameter. Another example which you will find in my slides I presented at COMBINE is for a replacement where you may need an index to say which species is replacing, an index to say in which model it is replaced, and even an index to say which species is being replaced. So, unfortunately, indices cannot be a simple extension of SBase, since the number indices!
>> required is different for various SBML elements.
>>
>> JSBML folks: I've added you to this list because we are using JSBML now and would love to see array support in JSBML as soon as possible :-).
>>
>> Chris
>>
>> On Oct 1, 2013, at 4:29 AM, Sarah Keating <ske...@ca...> wrote:
>>
>>> I would be happier with the approach of adding listfDimensions/listOfIndices to SBase and then explicitly stating in the spec that there is no current use case/meaning established for the use of these on particular (explicitly listed) elements. List the elements that should not have them rather than ones that the current list of elements that can have array elements.
>>>
>>> These could then indeed be stated as validation rules/warnings.
>>>
>>> This means if someone sees a use case that we currently have not considered the spec does not preclude them from using arrays; rather than them have to wait for a new version of the specification.
>>>
>>> The major advantage of extending SBase is that other packages automatically get the extension - and thus rather than wait for other packages to develop specifications that state what elements can have array elements; people could use arrays with other packages as they saw fit/necessary. The packages could then in their next iteration provide information about elements within that package on which it would not make sense to have array elements.
>>>
>>> Chris mentioned he really wants arrays of comp submodels. If SBase is not extended then technically he would have to wait for a new comp spec to detail that he could have arrays of submodels; I'm guessing he would rather not do that :-)
>>>
>>> Sarah
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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=60134791&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=60134791&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-01 17:16:39
|
Wait, I think 'groups' can answer this! Not using groups, using a
similar thing that groups did.
If 'listOfIndices' is tied to a particular attribute, the obvious
solution is to give it an attribute that points to the attribute it
extends:
<species id="S1" compartment="C1" conversionFactor="P1">
<listOfListOfIndices>
<listOfIndices attribute="compartment">
<!--the particular indices for the compartment-->
</listOfIndices>
<listOfIndices attribute="conversionFactor">
<!--the particular indices for the conversionFactor-->
</listOfIndices>
</listOfListOfIndices>
'listOfListOfIndices' is a little awkward, but you get the idea.
-Lucian
On Tue, Oct 1, 2013 at 6:55 AM, Chris J. Myers <my...@ec...> wrote:
> Hi Sarah,
>
> I'm okay with your plan to extend SBase with listOfDimensions and then having validation warnings for uses that we do not want to require support for initially.
>
> Note that listOfIndices though is different. You need an index on each SBaseRef attribute of an object. For an initial assignments, rate rules, assignment rules, species references, and event assignments, this is straightforward because there is just the one, the variable being assigned. However, for some other elements, there can be multiple references and thus multiple indices required. Consider, for example, a species. It has a compartment for which you may need an index if the compartment is an array. It also has a unit which may require an index. Finally, it has a conversion factor which may be an arrayed parameter. Another example which you will find in my slides I presented at COMBINE is for a replacement where you may need an index to say which species is replacing, an index to say in which model it is replaced, and even an index to say which species is being replaced. So, unfortunately, indices cannot be a simple extension of SBase, since the number indices!
> required is different for various SBML elements.
>
> JSBML folks: I've added you to this list because we are using JSBML now and would love to see array support in JSBML as soon as possible :-).
>
> Chris
>
> On Oct 1, 2013, at 4:29 AM, Sarah Keating <ske...@ca...> wrote:
>
>> I would be happier with the approach of adding listfDimensions/listOfIndices to SBase and then explicitly stating in the spec that there is no current use case/meaning established for the use of these on particular (explicitly listed) elements. List the elements that should not have them rather than ones that the current list of elements that can have array elements.
>>
>> These could then indeed be stated as validation rules/warnings.
>>
>> This means if someone sees a use case that we currently have not considered the spec does not preclude them from using arrays; rather than them have to wait for a new version of the specification.
>>
>> The major advantage of extending SBase is that other packages automatically get the extension - and thus rather than wait for other packages to develop specifications that state what elements can have array elements; people could use arrays with other packages as they saw fit/necessary. The packages could then in their next iteration provide information about elements within that package on which it would not make sense to have array elements.
>>
>> Chris mentioned he really wants arrays of comp submodels. If SBase is not extended then technically he would have to wait for a new comp spec to detail that he could have arrays of submodels; I'm guessing he would rather not do that :-)
>>
>> Sarah
>>
>
>
> ------------------------------------------------------------------------------
> 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=60134791&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-01 16:59:51
|
Guess I may have misunderstood what people thought removing the validity after reduction meant. I thought we simply were not going to require models to be valid after removing a package anymore. In other words, validity only makes sense when your software understands all required packages. This feeling comes from my belief that software really should not mess with models they do not understand. I know this is not a universal view. We can try harder. I'm just concerned the solution may become ugly. The example I'm really concerned with is again that last one from my talk at COMBINE and similar ones. I will try to come up with an example that illustrates my concern better. The initial assignment one is really not the greatest example as their are workarounds, but for comp+arrays, it can get ugly. Chris On Oct 1, 2013, at 9:49 AM, Sarah Keating <ske...@ca...> wrote: >> Sarah, in another thread, you have argued about >> allowing flexibility for modelers, and I think this is the same >> issue. > > I completely disagree. The xml structure of the SBML is not going to limit a modeller - who is likely to use some software interface to create/use a model and will not be at all concerned. > about whether there is a arraysElement inside an initialAssignment (as per Lucian's example) or not. > > I am arguing from the point of view of software reading/writing/parsing/validating the resulting files in a fashion that allows us to keep our assurance to people that their software does not have to support every package. I'm not saying we must try to keep validity after reduction in its entirety - I'm just saying that if packages can wholesale rewrite the validation rules of core that validation of any models with a package you do not understand becomes impossible. That is not necessarily helpful to software developers. > > > We should not put strong limitations on the arrays package >> simply to maintain validating after reduction as it makes the package >> less usable. > > I'm not suggesting a limitation; I'm arguing that we need to try harder to find a solution :-) > > Sarah |
|
From: Chris J. M. <my...@ec...> - 2013-10-01 16:54:25
|
> > Sorry I'm confused - since you can have a listOfIndices surely this encompasses the different indices. > Hmm, maybe it could. The reason for list of indices is you need an index for each dimension, but I guess we could have an additional attribute that indicates what the index refers too. This could work well. >> Another example which you will >> find in my slides I presented at COMBINE is for a replacement where >> you may need an index to say which species is replacing, an index to >> say in which model it is replaced, and even an index to say which >> species is being replaced. > > Actually since this slide does not actually explicitly show the indices it does not really make anything clear :-( > Because I did not know how to do it :-). Your hint above though may have fixed that. I will try to come up with something to show using your idea. This means we can extend SBase for list of indices as well. Cool! Chris |
