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: Lucian S. <luc...@gm...> - 2015-09-24 18:52:57
|
I was looking through them myself, and basically came to the same conclusions! For now, I went with 'non-negative', and adjusted some wording in the other places. The only thing I remember you wanting to revert at one point was the id's on the examples, but I think we eventually agreed that removing them was sufficiently helpful that it was OK that iBioSim didn't produce exactly that. At any rate, I've updated and checked in the new version. -Lucian On Thu, Sep 24, 2015 at 11:18 AM, Chris J. Myers <my...@ec...> wrote: > Here are the comments I found: > > Lucian: Check to see if ’non-zero’ is a requirement. It also might still > be worth having a discussion about the ’defined initial value’. > > Text says above “positive non-zero integer”, but this is redundant, since > positive does mean non-zero. We have gone back and forth about allowing > zero or not. Personally, I think 0 is strange since it basically means it > does not exist, but it is a quick way to “delete” something I guess. > Anyway, I think the text should either read, “positive integer” or > “non-negative integer” depending on our decision about 0. I can go either > way on this. > > Leandro: how is JSBML currently implemented? > > As for “defined initial value”, you are correct that we agreed to add a > flag that effectively disable the validation rules that required static > arrays. This would mean crazy things could happen like dynamic array > out-of-bounds problems, but we decided at Harmony to give people the option > to do this, if they like. If you have time to add to the specification > before COMBINE, that would be great. Hopefully we can convince you to > implement in Antimony and Ilya in BioUML, and we can finally ratify this > thing :-). > > Lucian: I removed the IDs of X and Y’s Dimension becuase they made this > example more confusing than it needed to be. > > This is okay. My only reservation is this means the XML has been edited > now after what came out of iBioSim. It introduces a slight risk of invalid > SBML. > > Lucian: This bit will have to change after we finally get the ’MathML > packages’ up and running, but we might as well leave it for now. > Agreed. > > Lucian: I don’t know what you mean here by ’invalid to have a value of > type vector’. In fact, it seems to me that things > > 3 could be a ton simpler if you allowed simple vector assignment, a la: 4 > > Lucian: Is there a reason you don’t want this? This (or something similar) > will also be necessary in the case of distrib, > > 26 where it needs vector input and output. 27 > > I agree that this would be simpler XML, but it makes validation and > flattening harder. Since it is software and not humans that generate the > XML, I do not think we should add this type of assignment for now. This, > in my opinion, violates our design decision of no implicit arrays. > > Finally, I also looked through all your text modifications and they look > good to me. Do you think any new validation rules are implied by these > changes? > > I could not find the change that I remember thinking you made was wrong. > Maybe I’m misremembering. Leandro: do you have any recollection of this? > > Cheers, > > Chris > > On Sep 24, 2015, at 11:59 AM, Lucian Smith <luc...@gm...> > wrote: > > Oh, right--we had discussed making a new 'strict' flag or something that > we would use for things like 'defined/fixed boundaries', etc. Should I > write that into this proposal? > > -Lucian > > On Thu, Sep 24, 2015 at 10:47 AM, Chris J. Myers <my...@ec...> > wrote: > >> This version still has some notes in there that you put in. I think we >> discussed them all in Germany. Can you remove or update based on this? >> Also, I seem to remember you made some changes that we said needed to be >> unwound, but I cannot remember what these were. Do you remember? >> >> Chris >> >> >> On Sep 24, 2015, at 11:45 AM, Lucian Smith <luc...@gm...> >> wrote: >> >> I went ahead and updated the version in SVN to be version 0.3 alpha, >> compiled it, and updated the arrays page to point to the new version. Let >> me know if anything else needs to be updated. >> >> -Lucian >> >> On Thu, Sep 24, 2015 at 10:22 AM, Ilya Kiselev < >> ax...@de...> wrote: >> >>> Hi. >>> >>> Well this version certainly looks more elaborate. I will read it and get >>> back to you. >>> >>> Thanks! >>> >>> Best regards, Ilya >>> >>> 2015-09-24 22:55 GMT+06:00 Chris J. Myers <my...@ec...>: >>> >>>> Hi, >>>> >>>> The latest version is attached. We really need to update the one >>>> online which is very old. I see your confusion now. >>>> >>>> Indices are actually on attributes of SBML elements. For example, the >>>> compartment attribute of a species can have an index. >>>> >>>> Leandro: maybe you can send your COMBINE 2014 slides as well, which I >>>> think might be easier to digest. >>>> >>>> Chris >>>> >>>> >>>> >>>> On Sep 24, 2015, at 10:01 AM, Ilya Kiselev < >>>> ax...@de...> wrote: >>>> >>>> Thanks for your answers and explanations! >>>> >>>> But it made me wonder if specification I have read is actually up to >>>> date because I have no Idea how you can set compartment of arbitrarty index >>>> to species like that (unless it is done implicitly by setting S[n] in C[m], >>>> where n = 2m, but you said nothing is done implicitly): >>>> >>>> >Another example with n != m, consider: >>>> >parameter n=8 >>>> >parameter m=4 >>>> >compartment C[m] >>>> >species S[n] with compartment C[floor(d0/2)] where d0 is the dimension >>>> id for dimension 0 of S >>>> >>>> Species can not have Index and even if ithey had - Index can not be >>>> applyed to attributes.... >>>> >>>> I took specification from here >>>> http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays. >>>> I have also attached it to this email. >>>> >>>>> >>>>> If you read the parts of the specification about flattening and the >>>>> validation rules, it should help. >>>>> >>>> >>>> Specification which I have read does not contain such parts. >>>> >>>> >>>>> 5.One thing that bothers me a bit is that multiple rules for the same >>>>> variable are allowed (for different components of the vector but still). >>>>> Hence if stripped from the extension, this file would not be valid SBML >>>>> document. >>>>> >>>>> That is not correct. We do not allow multiple rules for the same >>>>> variable. It still must be valid when stripped. >>>>> >>>> >>>> Specification that I have read has examples for that. Its in the >>>> paragraph 4.2., Array of Rate Rules >>>> >>>> <listOfRules> >>>> <!-- Create rate rules dx(i)/dt = y for i = 1,2,3,4,5 --> >>>> <rateRule variable="x"> >>>> <arrays:orderedListOfDimensions> >>>> <arrays:dimension id="i" size="m"/> >>>> </arrays:orderedListOfDimensions> >>>> <arrays:orderedListOfIndices> >>>> ... >>>> </rateRule> >>>> <!-- Create rate rules dx(i)/dt = 2*y for i = 6,7,8 --> >>>> <rateRule variable="x"> >>>> <arrays:orderedListOfDimensions> >>>> <arrays:dimension id="i" size="o"/> >>>> </arrays:orderedListOfDimensions> >>>> <arrays:orderedListOfIndices> >>>> ... >>>> </rateRule> >>>> </listOfRules> >>>> >>>> -- >>>> >>>> <arrays proposal.pdf> >>>> >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> sbml-arrays mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-arrays >>> >>> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays >> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > |
|
From: Chris J. M. <my...@ec...> - 2015-09-24 18:18:26
|
Here are the comments I found: Lucian: Check to see if ’non-zero’ is a requirement. It also might still be worth having a discussion about the ’defined initial value’. Text says above “positive non-zero integer”, but this is redundant, since positive does mean non-zero. We have gone back and forth about allowing zero or not. Personally, I think 0 is strange since it basically means it does not exist, but it is a quick way to “delete” something I guess. Anyway, I think the text should either read, “positive integer” or “non-negative integer” depending on our decision about 0. I can go either way on this. Leandro: how is JSBML currently implemented? As for “defined initial value”, you are correct that we agreed to add a flag that effectively disable the validation rules that required static arrays. This would mean crazy things could happen like dynamic array out-of-bounds problems, but we decided at Harmony to give people the option to do this, if they like. If you have time to add to the specification before COMBINE, that would be great. Hopefully we can convince you to implement in Antimony and Ilya in BioUML, and we can finally ratify this thing :-). Lucian: I removed the IDs of X and Y’s Dimension becuase they made this example more confusing than it needed to be. This is okay. My only reservation is this means the XML has been edited now after what came out of iBioSim. It introduces a slight risk of invalid SBML. Lucian: This bit will have to change after we finally get the ’MathML packages’ up and running, but we might as well leave it for now. Agreed. Lucian: I don’t know what you mean here by ’invalid to have a value of type vector’. In fact, it seems to me that things 3 could be a ton simpler if you allowed simple vector assignment, a la: 4 Lucian: Is there a reason you don’t want this? This (or something similar) will also be necessary in the case of distrib, 26 where it needs vector input and output. 27 I agree that this would be simpler XML, but it makes validation and flattening harder. Since it is software and not humans that generate the XML, I do not think we should add this type of assignment for now. This, in my opinion, violates our design decision of no implicit arrays. Finally, I also looked through all your text modifications and they look good to me. Do you think any new validation rules are implied by these changes? I could not find the change that I remember thinking you made was wrong. Maybe I’m misremembering. Leandro: do you have any recollection of this? Cheers, Chris > On Sep 24, 2015, at 11:59 AM, Lucian Smith <luc...@gm...> wrote: > > Oh, right--we had discussed making a new 'strict' flag or something that we would use for things like 'defined/fixed boundaries', etc. Should I write that into this proposal? > > -Lucian > > On Thu, Sep 24, 2015 at 10:47 AM, Chris J. Myers <my...@ec... <mailto:my...@ec...>> wrote: > This version still has some notes in there that you put in. I think we discussed them all in Germany. Can you remove or update based on this? Also, I seem to remember you made some changes that we said needed to be unwound, but I cannot remember what these were. Do you remember? > > Chris > > >> On Sep 24, 2015, at 11:45 AM, Lucian Smith <luc...@gm... <mailto:luc...@gm...>> wrote: >> >> I went ahead and updated the version in SVN to be version 0.3 alpha, compiled it, and updated the arrays page to point to the new version. Let me know if anything else needs to be updated. >> >> -Lucian >> >> On Thu, Sep 24, 2015 at 10:22 AM, Ilya Kiselev <ax...@de... <mailto:ax...@de...>> wrote: >> Hi. >> >> Well this version certainly looks more elaborate. I will read it and get back to you. >> >> Thanks! >> >> Best regards, Ilya >> >> 2015-09-24 22:55 GMT+06:00 Chris J. Myers <my...@ec... <mailto:my...@ec...>>: >> Hi, >> >> The latest version is attached. We really need to update the one online which is very old. I see your confusion now. >> >> Indices are actually on attributes of SBML elements. For example, the compartment attribute of a species can have an index. >> >> Leandro: maybe you can send your COMBINE 2014 slides as well, which I think might be easier to digest. >> >> Chris >> >> >> >>> On Sep 24, 2015, at 10:01 AM, Ilya Kiselev <ax...@de... <mailto:ax...@de...>> wrote: >>> >>> Thanks for your answers and explanations! >>> >>> But it made me wonder if specification I have read is actually up to date because I have no Idea how you can set compartment of arbitrarty index to species like that (unless it is done implicitly by setting S[n] in C[m], where n = 2m, but you said nothing is done implicitly): >>> >>> >Another example with n != m, consider: >>> >parameter n=8 >>> >parameter m=4 >>> >compartment C[m] >>> >species S[n] with compartment C[floor(d0/2)] where d0 is the dimension id for dimension 0 of S >>> >>> Species can not have Index and even if ithey had - Index can not be applyed to attributes.... >>> >>> I took specification from here http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays <http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays>. I have also attached it to this email. >>> >>> If you read the parts of the specification about flattening and the validation rules, it should help. >>> >>> Specification which I have read does not contain such parts. >>> >>>> 5.One thing that bothers me a bit is that multiple rules for the same variable are allowed (for different components of the vector but still). Hence if stripped from the extension, this file would not be valid SBML document. >>>> >>> >>> That is not correct. We do not allow multiple rules for the same variable. It still must be valid when stripped. >>> >>> Specification that I have read has examples for that. Its in the paragraph 4.2., Array of Rate Rules >>> >>> <listOfRules> >>> <!-- Create rate rules dx(i)/dt = y for i = 1,2,3,4,5 --> >>> <rateRule variable="x"> >>> <arrays:orderedListOfDimensions> >>> <arrays:dimension id="i" size="m"/> >>> </arrays:orderedListOfDimensions> >>> <arrays:orderedListOfIndices> >>> ... >>> </rateRule> >>> <!-- Create rate rules dx(i)/dt = 2*y for i = 6,7,8 --> >>> <rateRule variable="x"> >>> <arrays:orderedListOfDimensions> >>> <arrays:dimension id="i" size="o"/> >>> </arrays:orderedListOfDimensions> >>> <arrays:orderedListOfIndices> >>> ... >>> </rateRule> >>> </listOfRules> >>> >>> -- >>> >>> <arrays proposal.pdf> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... <mailto:sbm...@li...> >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays <https://lists.sourceforge.net/lists/listinfo/sbml-arrays> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... <mailto:sbm...@li...> >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays <https://lists.sourceforge.net/lists/listinfo/sbml-arrays> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > sbml-arrays mailing list > sbm...@li... <mailto:sbm...@li...> > https://lists.sourceforge.net/lists/listinfo/sbml-arrays <https://lists.sourceforge.net/lists/listinfo/sbml-arrays> > > > ------------------------------------------------------------------------------ > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Lucian S. <luc...@gm...> - 2015-09-24 18:00:03
|
Oh, right--we had discussed making a new 'strict' flag or something that we would use for things like 'defined/fixed boundaries', etc. Should I write that into this proposal? -Lucian On Thu, Sep 24, 2015 at 10:47 AM, Chris J. Myers <my...@ec...> wrote: > This version still has some notes in there that you put in. I think we > discussed them all in Germany. Can you remove or update based on this? > Also, I seem to remember you made some changes that we said needed to be > unwound, but I cannot remember what these were. Do you remember? > > Chris > > > On Sep 24, 2015, at 11:45 AM, Lucian Smith <luc...@gm...> > wrote: > > I went ahead and updated the version in SVN to be version 0.3 alpha, > compiled it, and updated the arrays page to point to the new version. Let > me know if anything else needs to be updated. > > -Lucian > > On Thu, Sep 24, 2015 at 10:22 AM, Ilya Kiselev < > ax...@de...> wrote: > >> Hi. >> >> Well this version certainly looks more elaborate. I will read it and get >> back to you. >> >> Thanks! >> >> Best regards, Ilya >> >> 2015-09-24 22:55 GMT+06:00 Chris J. Myers <my...@ec...>: >> >>> Hi, >>> >>> The latest version is attached. We really need to update the one online >>> which is very old. I see your confusion now. >>> >>> Indices are actually on attributes of SBML elements. For example, the >>> compartment attribute of a species can have an index. >>> >>> Leandro: maybe you can send your COMBINE 2014 slides as well, which I >>> think might be easier to digest. >>> >>> Chris >>> >>> >>> >>> On Sep 24, 2015, at 10:01 AM, Ilya Kiselev < >>> ax...@de...> wrote: >>> >>> Thanks for your answers and explanations! >>> >>> But it made me wonder if specification I have read is actually up to >>> date because I have no Idea how you can set compartment of arbitrarty index >>> to species like that (unless it is done implicitly by setting S[n] in C[m], >>> where n = 2m, but you said nothing is done implicitly): >>> >>> >Another example with n != m, consider: >>> >parameter n=8 >>> >parameter m=4 >>> >compartment C[m] >>> >species S[n] with compartment C[floor(d0/2)] where d0 is the dimension >>> id for dimension 0 of S >>> >>> Species can not have Index and even if ithey had - Index can not be >>> applyed to attributes.... >>> >>> I took specification from here >>> http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays. >>> I have also attached it to this email. >>> >>>> >>>> If you read the parts of the specification about flattening and the >>>> validation rules, it should help. >>>> >>> >>> Specification which I have read does not contain such parts. >>> >>> >>>> 5.One thing that bothers me a bit is that multiple rules for the same >>>> variable are allowed (for different components of the vector but still). >>>> Hence if stripped from the extension, this file would not be valid SBML >>>> document. >>>> >>>> That is not correct. We do not allow multiple rules for the same >>>> variable. It still must be valid when stripped. >>>> >>> >>> Specification that I have read has examples for that. Its in the >>> paragraph 4.2., Array of Rate Rules >>> >>> <listOfRules> >>> <!-- Create rate rules dx(i)/dt = y for i = 1,2,3,4,5 --> >>> <rateRule variable="x"> >>> <arrays:orderedListOfDimensions> >>> <arrays:dimension id="i" size="m"/> >>> </arrays:orderedListOfDimensions> >>> <arrays:orderedListOfIndices> >>> ... >>> </rateRule> >>> <!-- Create rate rules dx(i)/dt = 2*y for i = 6,7,8 --> >>> <rateRule variable="x"> >>> <arrays:orderedListOfDimensions> >>> <arrays:dimension id="i" size="o"/> >>> </arrays:orderedListOfDimensions> >>> <arrays:orderedListOfIndices> >>> ... >>> </rateRule> >>> </listOfRules> >>> >>> -- >>> >>> <arrays proposal.pdf> >>> >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays >> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > |
|
From: Leandro W. <lea...@gm...> - 2015-09-24 17:51:42
|
Here is the link for my slides from COMBINE 2014: http://co.mbine.org/events/COMBINE_2014/agenda?q=system/files/Watanabe_array.pdf <http://co.mbine.org/events/COMBINE_2014/agenda?q=system/files/Watanabe_array.pdf> Leandro > On Sep 24, 2015, at 11:47 AM, Chris J. Myers <my...@ec...> wrote: > > This version still has some notes in there that you put in. I think we discussed them all in Germany. Can you remove or update based on this? Also, I seem to remember you made some changes that we said needed to be unwound, but I cannot remember what these were. Do you remember? > > Chris > >> On Sep 24, 2015, at 11:45 AM, Lucian Smith <luc...@gm... <mailto:luc...@gm...>> wrote: >> >> I went ahead and updated the version in SVN to be version 0.3 alpha, compiled it, and updated the arrays page to point to the new version. Let me know if anything else needs to be updated. >> >> -Lucian >> >> On Thu, Sep 24, 2015 at 10:22 AM, Ilya Kiselev <ax...@de... <mailto:ax...@de...>> wrote: >> Hi. >> >> Well this version certainly looks more elaborate. I will read it and get back to you. >> >> Thanks! >> >> Best regards, Ilya >> >> 2015-09-24 22:55 GMT+06:00 Chris J. Myers <my...@ec... <mailto:my...@ec...>>: >> Hi, >> >> The latest version is attached. We really need to update the one online which is very old. I see your confusion now. >> >> Indices are actually on attributes of SBML elements. For example, the compartment attribute of a species can have an index. >> >> Leandro: maybe you can send your COMBINE 2014 slides as well, which I think might be easier to digest. >> >> Chris >> >> >> >>> On Sep 24, 2015, at 10:01 AM, Ilya Kiselev <ax...@de... <mailto:ax...@de...>> wrote: >>> >>> Thanks for your answers and explanations! >>> >>> But it made me wonder if specification I have read is actually up to date because I have no Idea how you can set compartment of arbitrarty index to species like that (unless it is done implicitly by setting S[n] in C[m], where n = 2m, but you said nothing is done implicitly): >>> >>> >Another example with n != m, consider: >>> >parameter n=8 >>> >parameter m=4 >>> >compartment C[m] >>> >species S[n] with compartment C[floor(d0/2)] where d0 is the dimension id for dimension 0 of S >>> >>> Species can not have Index and even if ithey had - Index can not be applyed to attributes.... >>> >>> I took specification from here http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays <http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays>. I have also attached it to this email. >>> >>> If you read the parts of the specification about flattening and the validation rules, it should help. >>> >>> Specification which I have read does not contain such parts. >>> >>>> 5.One thing that bothers me a bit is that multiple rules for the same variable are allowed (for different components of the vector but still). Hence if stripped from the extension, this file would not be valid SBML document. >>>> >>> >>> That is not correct. We do not allow multiple rules for the same variable. It still must be valid when stripped. >>> >>> Specification that I have read has examples for that. Its in the paragraph 4.2., Array of Rate Rules >>> >>> <listOfRules> >>> <!-- Create rate rules dx(i)/dt = y for i = 1,2,3,4,5 --> >>> <rateRule variable="x"> >>> <arrays:orderedListOfDimensions> >>> <arrays:dimension id="i" size="m"/> >>> </arrays:orderedListOfDimensions> >>> <arrays:orderedListOfIndices> >>> ... >>> </rateRule> >>> <!-- Create rate rules dx(i)/dt = 2*y for i = 6,7,8 --> >>> <rateRule variable="x"> >>> <arrays:orderedListOfDimensions> >>> <arrays:dimension id="i" size="o"/> >>> </arrays:orderedListOfDimensions> >>> <arrays:orderedListOfIndices> >>> ... >>> </rateRule> >>> </listOfRules> >>> >>> -- >>> >>> <arrays proposal.pdf> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... <mailto:sbm...@li...> >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays <https://lists.sourceforge.net/lists/listinfo/sbml-arrays> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... <mailto:sbm...@li...> >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > ------------------------------------------------------------------------------ > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Chris J. M. <my...@ec...> - 2015-09-24 17:47:27
|
This version still has some notes in there that you put in. I think we discussed them all in Germany. Can you remove or update based on this? Also, I seem to remember you made some changes that we said needed to be unwound, but I cannot remember what these were. Do you remember? Chris > On Sep 24, 2015, at 11:45 AM, Lucian Smith <luc...@gm...> wrote: > > I went ahead and updated the version in SVN to be version 0.3 alpha, compiled it, and updated the arrays page to point to the new version. Let me know if anything else needs to be updated. > > -Lucian > > On Thu, Sep 24, 2015 at 10:22 AM, Ilya Kiselev <ax...@de... <mailto:ax...@de...>> wrote: > Hi. > > Well this version certainly looks more elaborate. I will read it and get back to you. > > Thanks! > > Best regards, Ilya > > 2015-09-24 22:55 GMT+06:00 Chris J. Myers <my...@ec... <mailto:my...@ec...>>: > Hi, > > The latest version is attached. We really need to update the one online which is very old. I see your confusion now. > > Indices are actually on attributes of SBML elements. For example, the compartment attribute of a species can have an index. > > Leandro: maybe you can send your COMBINE 2014 slides as well, which I think might be easier to digest. > > Chris > > > >> On Sep 24, 2015, at 10:01 AM, Ilya Kiselev <ax...@de... <mailto:ax...@de...>> wrote: >> >> Thanks for your answers and explanations! >> >> But it made me wonder if specification I have read is actually up to date because I have no Idea how you can set compartment of arbitrarty index to species like that (unless it is done implicitly by setting S[n] in C[m], where n = 2m, but you said nothing is done implicitly): >> >> >Another example with n != m, consider: >> >parameter n=8 >> >parameter m=4 >> >compartment C[m] >> >species S[n] with compartment C[floor(d0/2)] where d0 is the dimension id for dimension 0 of S >> >> Species can not have Index and even if ithey had - Index can not be applyed to attributes.... >> >> I took specification from here http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays <http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays>. I have also attached it to this email. >> >> If you read the parts of the specification about flattening and the validation rules, it should help. >> >> Specification which I have read does not contain such parts. >> >>> 5.One thing that bothers me a bit is that multiple rules for the same variable are allowed (for different components of the vector but still). Hence if stripped from the extension, this file would not be valid SBML document. >>> >> >> That is not correct. We do not allow multiple rules for the same variable. It still must be valid when stripped. >> >> Specification that I have read has examples for that. Its in the paragraph 4.2., Array of Rate Rules >> >> <listOfRules> >> <!-- Create rate rules dx(i)/dt = y for i = 1,2,3,4,5 --> >> <rateRule variable="x"> >> <arrays:orderedListOfDimensions> >> <arrays:dimension id="i" size="m"/> >> </arrays:orderedListOfDimensions> >> <arrays:orderedListOfIndices> >> ... >> </rateRule> >> <!-- Create rate rules dx(i)/dt = 2*y for i = 6,7,8 --> >> <rateRule variable="x"> >> <arrays:orderedListOfDimensions> >> <arrays:dimension id="i" size="o"/> >> </arrays:orderedListOfDimensions> >> <arrays:orderedListOfIndices> >> ... >> </rateRule> >> </listOfRules> >> >> -- >> >> <arrays proposal.pdf> > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > sbml-arrays mailing list > sbm...@li... <mailto:sbm...@li...> > https://lists.sourceforge.net/lists/listinfo/sbml-arrays <https://lists.sourceforge.net/lists/listinfo/sbml-arrays> > > > ------------------------------------------------------------------------------ > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Lucian S. <luc...@gm...> - 2015-09-24 17:45:51
|
I went ahead and updated the version in SVN to be version 0.3 alpha, compiled it, and updated the arrays page to point to the new version. Let me know if anything else needs to be updated. -Lucian On Thu, Sep 24, 2015 at 10:22 AM, Ilya Kiselev < ax...@de...> wrote: > Hi. > > Well this version certainly looks more elaborate. I will read it and get > back to you. > > Thanks! > > Best regards, Ilya > > 2015-09-24 22:55 GMT+06:00 Chris J. Myers <my...@ec...>: > >> Hi, >> >> The latest version is attached. We really need to update the one online >> which is very old. I see your confusion now. >> >> Indices are actually on attributes of SBML elements. For example, the >> compartment attribute of a species can have an index. >> >> Leandro: maybe you can send your COMBINE 2014 slides as well, which I >> think might be easier to digest. >> >> Chris >> >> >> >> On Sep 24, 2015, at 10:01 AM, Ilya Kiselev <ax...@de...> >> wrote: >> >> Thanks for your answers and explanations! >> >> But it made me wonder if specification I have read is actually up to date >> because I have no Idea how you can set compartment of arbitrarty index to >> species like that (unless it is done implicitly by setting S[n] in C[m], >> where n = 2m, but you said nothing is done implicitly): >> >> >Another example with n != m, consider: >> >parameter n=8 >> >parameter m=4 >> >compartment C[m] >> >species S[n] with compartment C[floor(d0/2)] where d0 is the dimension >> id for dimension 0 of S >> >> Species can not have Index and even if ithey had - Index can not be >> applyed to attributes.... >> >> I took specification from here >> http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays. I >> have also attached it to this email. >> >>> >>> If you read the parts of the specification about flattening and the >>> validation rules, it should help. >>> >> >> Specification which I have read does not contain such parts. >> >> >>> 5.One thing that bothers me a bit is that multiple rules for the same >>> variable are allowed (for different components of the vector but still). >>> Hence if stripped from the extension, this file would not be valid SBML >>> document. >>> >>> That is not correct. We do not allow multiple rules for the same >>> variable. It still must be valid when stripped. >>> >> >> Specification that I have read has examples for that. Its in the >> paragraph 4.2., Array of Rate Rules >> >> <listOfRules> >> <!-- Create rate rules dx(i)/dt = y for i = 1,2,3,4,5 --> >> <rateRule variable="x"> >> <arrays:orderedListOfDimensions> >> <arrays:dimension id="i" size="m"/> >> </arrays:orderedListOfDimensions> >> <arrays:orderedListOfIndices> >> ... >> </rateRule> >> <!-- Create rate rules dx(i)/dt = 2*y for i = 6,7,8 --> >> <rateRule variable="x"> >> <arrays:orderedListOfDimensions> >> <arrays:dimension id="i" size="o"/> >> </arrays:orderedListOfDimensions> >> <arrays:orderedListOfIndices> >> ... >> </rateRule> >> </listOfRules> >> >> -- >> >> <arrays proposal.pdf> >> >> >> >> > > ------------------------------------------------------------------------------ > > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > |
|
From: Ilya K. <ax...@de...> - 2015-09-24 17:22:42
|
Hi. Well this version certainly looks more elaborate. I will read it and get back to you. Thanks! Best regards, Ilya 2015-09-24 22:55 GMT+06:00 Chris J. Myers <my...@ec...>: > Hi, > > The latest version is attached. We really need to update the one online > which is very old. I see your confusion now. > > Indices are actually on attributes of SBML elements. For example, the > compartment attribute of a species can have an index. > > Leandro: maybe you can send your COMBINE 2014 slides as well, which I > think might be easier to digest. > > Chris > > > > On Sep 24, 2015, at 10:01 AM, Ilya Kiselev <ax...@de...> > wrote: > > Thanks for your answers and explanations! > > But it made me wonder if specification I have read is actually up to date > because I have no Idea how you can set compartment of arbitrarty index to > species like that (unless it is done implicitly by setting S[n] in C[m], > where n = 2m, but you said nothing is done implicitly): > > >Another example with n != m, consider: > >parameter n=8 > >parameter m=4 > >compartment C[m] > >species S[n] with compartment C[floor(d0/2)] where d0 is the dimension id > for dimension 0 of S > > Species can not have Index and even if ithey had - Index can not be > applyed to attributes.... > > I took specification from here > http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays. I > have also attached it to this email. > >> >> If you read the parts of the specification about flattening and the >> validation rules, it should help. >> > > Specification which I have read does not contain such parts. > > >> 5.One thing that bothers me a bit is that multiple rules for the same >> variable are allowed (for different components of the vector but still). >> Hence if stripped from the extension, this file would not be valid SBML >> document. >> >> That is not correct. We do not allow multiple rules for the same >> variable. It still must be valid when stripped. >> > > Specification that I have read has examples for that. Its in the paragraph > 4.2., Array of Rate Rules > > <listOfRules> > <!-- Create rate rules dx(i)/dt = y for i = 1,2,3,4,5 --> > <rateRule variable="x"> > <arrays:orderedListOfDimensions> > <arrays:dimension id="i" size="m"/> > </arrays:orderedListOfDimensions> > <arrays:orderedListOfIndices> > ... > </rateRule> > <!-- Create rate rules dx(i)/dt = 2*y for i = 6,7,8 --> > <rateRule variable="x"> > <arrays:orderedListOfDimensions> > <arrays:dimension id="i" size="o"/> > </arrays:orderedListOfDimensions> > <arrays:orderedListOfIndices> > ... > </rateRule> > </listOfRules> > > -- > > <arrays proposal.pdf> > > > > |
|
From: Chris J. M. <my...@ec...> - 2015-09-24 16:55:34
|
Hi, The latest version is attached. We really need to update the one online which is very old. I see your confusion now. Indices are actually on attributes of SBML elements. For example, the compartment attribute of a species can have an index. Leandro: maybe you can send your COMBINE 2014 slides as well, which I think might be easier to digest. Chris > On Sep 24, 2015, at 10:01 AM, Ilya Kiselev <ax...@de...> wrote: > > Thanks for your answers and explanations! > > But it made me wonder if specification I have read is actually up to date because I have no Idea how you can set compartment of arbitrarty index to species like that (unless it is done implicitly by setting S[n] in C[m], where n = 2m, but you said nothing is done implicitly): > > >Another example with n != m, consider: > >parameter n=8 > >parameter m=4 > >compartment C[m] > >species S[n] with compartment C[floor(d0/2)] where d0 is the dimension id for dimension 0 of S > > Species can not have Index and even if ithey had - Index can not be applyed to attributes.... > > I took specification from here http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays <http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays>. I have also attached it to this email. > > If you read the parts of the specification about flattening and the validation rules, it should help. > > Specification which I have read does not contain such parts. > >> 5.One thing that bothers me a bit is that multiple rules for the same variable are allowed (for different components of the vector but still). Hence if stripped from the extension, this file would not be valid SBML document. >> > > That is not correct. We do not allow multiple rules for the same variable. It still must be valid when stripped. > > Specification that I have read has examples for that. Its in the paragraph 4.2., Array of Rate Rules > > <listOfRules> > <!-- Create rate rules dx(i)/dt = y for i = 1,2,3,4,5 --> > <rateRule variable="x"> > <arrays:orderedListOfDimensions> > <arrays:dimension id="i" size="m"/> > </arrays:orderedListOfDimensions> > <arrays:orderedListOfIndices> > ... > </rateRule> > <!-- Create rate rules dx(i)/dt = 2*y for i = 6,7,8 --> > <rateRule variable="x"> > <arrays:orderedListOfDimensions> > <arrays:dimension id="i" size="o"/> > </arrays:orderedListOfDimensions> > <arrays:orderedListOfIndices> > ... > </rateRule> > </listOfRules> > > -- > Best regards, Ilya > <arrays proposal.pdf> |
|
From: Leandro W. <lea...@gm...> - 2015-09-24 16:15:14
|
Hi Ilya, This is the old specification. The most up to date one can be found here: https://svn.code.sourceforge.net/p/sbml/code/trunk/specifications/sbml-level-3/version-1/arrays <https://svn.code.sourceforge.net/p/sbml/code/trunk/specifications/sbml-level-3/version-1/arrays> There has been some changes in the syntax of the package. The new version has validation rules, hopefully it will make it clear what you are allowed to do and not. Leandro > On Sep 24, 2015, at 10:01 AM, Ilya Kiselev <ax...@de...> wrote: > > Thanks for your answers and explanations! > > But it made me wonder if specification I have read is actually up to date because I have no Idea how you can set compartment of arbitrarty index to species like that (unless it is done implicitly by setting S[n] in C[m], where n = 2m, but you said nothing is done implicitly): > > >Another example with n != m, consider: > >parameter n=8 > >parameter m=4 > >compartment C[m] > >species S[n] with compartment C[floor(d0/2)] where d0 is the dimension id for dimension 0 of S > > Species can not have Index and even if ithey had - Index can not be applyed to attributes.... > > I took specification from here http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays <http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays>. I have also attached it to this email. > > If you read the parts of the specification about flattening and the validation rules, it should help. > > Specification which I have read does not contain such parts. > >> 5.One thing that bothers me a bit is that multiple rules for the same variable are allowed (for different components of the vector but still). Hence if stripped from the extension, this file would not be valid SBML document. >> > > That is not correct. We do not allow multiple rules for the same variable. It still must be valid when stripped. > > Specification that I have read has examples for that. Its in the paragraph 4.2., Array of Rate Rules > > <listOfRules> > <!-- Create rate rules dx(i)/dt = y for i = 1,2,3,4,5 --> > <rateRule variable="x"> > <arrays:orderedListOfDimensions> > <arrays:dimension id="i" size="m"/> > </arrays:orderedListOfDimensions> > <arrays:orderedListOfIndices> > ... > </rateRule> > <!-- Create rate rules dx(i)/dt = 2*y for i = 6,7,8 --> > <rateRule variable="x"> > <arrays:orderedListOfDimensions> > <arrays:dimension id="i" size="o"/> > </arrays:orderedListOfDimensions> > <arrays:orderedListOfIndices> > ... > </rateRule> > </listOfRules> > > -- > Best regards, Ilya > <arrays proposal.pdf>------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140_______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Ilya K. <ax...@de...> - 2015-09-24 16:01:39
|
Thanks for your answers and explanations! But it made me wonder if specification I have read is actually up to date because I have no Idea how you can set compartment of arbitrarty index to species like that (unless it is done implicitly by setting S[n] in C[m], where n = 2m, but you said nothing is done implicitly): >Another example with n != m, consider: >parameter n=8 >parameter m=4 >compartment C[m] >species S[n] with compartment C[floor(d0/2)] where d0 is the dimension id for dimension 0 of S Species can not have Index and even if ithey had - Index can not be applyed to attributes.... I took specification from here http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays. I have also attached it to this email. > > If you read the parts of the specification about flattening and the > validation rules, it should help. > Specification which I have read does not contain such parts. > 5.One thing that bothers me a bit is that multiple rules for the same > variable are allowed (for different components of the vector but still). > Hence if stripped from the extension, this file would not be valid SBML > document. > > That is not correct. We do not allow multiple rules for the same > variable. It still must be valid when stripped. > Specification that I have read has examples for that. Its in the paragraph 4.2., Array of Rate Rules <listOfRules> <!-- Create rate rules dx(i)/dt = y for i = 1,2,3,4,5 --> <rateRule variable="x"> <arrays:orderedListOfDimensions> <arrays:dimension id="i" size="m"/> </arrays:orderedListOfDimensions> <arrays:orderedListOfIndices> ... </rateRule> <!-- Create rate rules dx(i)/dt = 2*y for i = 6,7,8 --> <rateRule variable="x"> <arrays:orderedListOfDimensions> <arrays:dimension id="i" size="o"/> </arrays:orderedListOfDimensions> <arrays:orderedListOfIndices> ... </rateRule> </listOfRules> -- Best regards, Ilya |
|
From: Chris J. M. <my...@ec...> - 2015-09-24 14:57:35
|
Hi Ilya, > > I had more thorough look through arrays spec. Expression about lack of formality was due to the fact that spec defines only two classes but they add quite a bit of complexity to the SBML and it is not easy to understand which constructions from linear algebra can be created and which cannot. First, this is an arrays package and not an linear algebra package. Think of it like arrays in C. They create regular structures, but there is no implied vector/matrix interpretation. We have not introduced mathematical operators like inverting a matrix, matrix multiplication, etc. > E.g. It is possible to set that only some of species from array participate in certain rule, so what restricts (from mathematical standpoint) me from having some of these species in certain compartment and some (from the same array, I know that in the way SBML and arrays works it it is impossible) in another? Such little things are something that gets in the way when I try to imagine limits of object model behind arrays extension. Maybe some explanation of mathematical field covered with this extension at the beginning of the specification will help or maybe its just me. > > Nothing restricts rules like you describe. Indeed, nothing in SBML restricts a reaction, event, rule, constraint, etc. currently from having species in different compartments. > Here I have listed some questions I have for now; probably some of them were already discussed in this mailing list. For simplicity I will denote array X of size n: X(n), and i-th element of it : X[i]. > > 1. Say I have array of compartments C(m) and it includes array of species S(n) then it is mandatory to have n = m and each compartment would have one specie in it? What if I want array of species inside of each of the compartments? If I state that S is 2d array: S(n, k) and it is inside compartment which have one dimension – C(n), will this work? > No n does not need to be equal to m. The only restrictions are that when you assign species to compartments using indices on the compartment attribute that they fall within the array bounds. For your example, this is perfectly legal: parameter n = 5 parameter k = 10 compartment C[n] species S[n][k] with compartment C[d0] where d0 is the dimension id for dimension 0 of S This creates 50 species with 10 assigned to each compartment. Another example with n != m, consider: parameter n=8 parameter m=4 compartment C[m] species S[n] with compartment C[floor(d0/2)] where d0 is the dimension id for dimension 0 of S This creates 8 species with 2 assigned to each of 4 compartments. > Also what if C(n) includes one species S (without dimension)? Or is this illegal? > Vice versa – can single compartment C include array of species S(n)? Your first case does not make sense, since each species must be assigned to one compartment not many. This would be legal, however: parameter n=4 compartment C[n] species S with compartment C[1] The second case though is legal, for example: parameter n=4 compartment C species S[n] with compartment C This assigns 4 species all to compartment C. > > > 2. There are no examples of dimension for specie reference. If correspondent species is array then specie reference is array as well. But spec says that specie references may explicitly have orderedListOfDimensions. Is it possible to somehow define array of specie references each of which corresponds to single (not array) species? > There are NO implicit dimensions. Therefore, if a species is an array this does NOT mean that the species reference must also be an array. Consider, for example: parameter n=4 species S[n] reaction R reactant S[0] Namely, you can have a single reaction refer to a single element of an arrayed species. If, on the other hand, you want all the species to be reactants, then you must give the species reference a dimension, like this: parameter n=4 species S[n] reaction R reactant rid[n] S[d0] where d0 is the dimension id for dimension 0 for species reference rid. While it is possible to define an array of species references that each refer to a single species, it is not very interesting because it must be the same species, for example: parameter n=4 species S reaction R reactant rid[n] S This would create a reaction with 4 reactants S, which is the same as one reactant S with stoichiometry of 4. > What if I have species S[n] participating in reaction r[m], and specie reference which refer to S has dimension p? Which combinations of n, m and p are allowed? > > Basically, this is all set by the validation rules. Namely, you must be sure that you have no index out-of-bounds problems when it is flattened out. These are static arrays, so this can all be determined by the validator. If you read the parts of the specification about flattening and the validation rules, it should help. Though I agree that species references are one of the trickiest things to work your head around. So, for your example, one situation that would work is: parameter n = 8 parameter m = 4 parameter p = 2 species S[n] reaction R[m] dimension id is d0 reactant rid[p] dimension id is rd0 S[d0*2+rd0] This creates 8 species, 4 reactions where each reaction has two reactants. > 3. In array of rules it should be explicitly stated which of variable components are used on the left side by Index class. But index cannot be used in kinetik law and there are not examples for kinetic law for reaction rate. > Say I have array of reactions A+B->C, each of species is an array. How do I define kinetic law for it? > Probably something like “k * A[2i] * B[i-1]”? This is automatically mean (in absence of Index for kinetic law) that i-th reaction have kinetik law k * A[2i] * B[i-1]? Kinetic law does not need an index. You use selector in the math. There is never anything defined implicitly. This was a key design decision for this package. For example: parameter n=4 species S[n] reaction R[n] dimension id is d0 reactant S[d0] kinetic law: k*S[d0] > > I suppose Index can not be used in kinetik law because each reaction should have kinetik law, but it feels like inconsistency between rules and reactions. unless this also be done with rules. Say if we have rule y[i] = f(x[2 * i]) then can it be stated without Index like in the following example? > It is not an inconsistency. Rules assign to a variable that may be arrayed. Kinetic laws do not assign to any variable. > <assignmentRule variable=y> > <arrays:orderedListOfDimensions> > <arrays:dimension id="i" size="n"/> > </arrays:orderedListOfDimensions> > <math> > <apply> > <selector/> > <ci>x</ci> > <apply><times/><cn type="integer"> 2 </cn><cn>i</cn></apply> > </apply> > </math> > </assignmentRule> > > No, the above is illegal. There must be an index. Nothing can be done implicitly. This needs to be: parameter n=4 parameter m=8 parameter x[m] parameter y[n] rule r[n] with dimension id of d0 y[d0] := x[2*d0] > 4. Can Dimension id be used outside of selector? E.g. to define array of assignments: y[i] = i? > > <assignmentRule variable=y> > <arrays:orderedListOfDimensions> > <arrays:dimension id="i" size="n"/> > </arrays:orderedListOfDimensions> > <math>i</math> > </assignmentRule> > > Yes, it can, but your code above is still incorrect, there must be an index for y specified, like so: parameter n=4 parameter y[n] rule r[n] with dimension id of d0 y[d0] := d0 > Is this construct correct? Probably not, because then Dimension id may conflict with global parameter “i”…. > > 5.One thing that bothers me a bit is that multiple rules for the same variable are allowed (for different components of the vector but still). Hence if stripped from the extension, this file would not be valid SBML document. > That is not correct. We do not allow multiple rules for the same variable. It still must be valid when stripped. > 6.Other thing which concerns some people from our team is that using arrays one may easily create incorrect model with not matching dimensions (e.g. of species and compartments, or reactants and rections) but this is not a problem of language, I think. > > The nice thing about the arrays package is that since it is static that all these out-of-bounds problems are checked by the validator. > Also do you have already or plan to create tests for arrays? > > We don’t have a plan yet, but this is certainly a good idea. Let’s discuss this at COMBINE. Also, please try out arrays with iBioSim. I think this will help your understanding considerably. If you need help with this, we will be happy to do so. Leandro and I can also demo this for you when you are here. Cheers, Chris > Best regards, Ilya. > > |
|
From: Ilya K. <ax...@de...> - 2015-09-24 13:30:01
|
Hi Chris. I am also sending this to arrays mailing list rather then whole cell. >I’m not sure what you mean by “not formally describe extension”. We describe the arrays package at the same level of detail in the specification as any extension has done. What exactly do you think is missing in the description? >What limits are you concerned about? We would appreciate any feedback on the description. I had more thorough look through arrays spec. Expression about lack of formality was due to the fact that spec defines only two classes but they add quite a bit of complexity to the SBML and it is not easy to understand which constructions from linear algebra can be created and which cannot. E.g. It is possible to set that only some of species from array participate in certain rule, so what restricts (from mathematical standpoint) me from having some of these species in certain compartment and some (from the same array, I know that in the way SBML and arrays works it it is impossible) in another? Such little things are something that gets in the way when I try to imagine limits of object model behind arrays extension. Maybe some explanation of mathematical field covered with this extension at the beginning of the specification will help or maybe its just me. Here I have listed some questions I have for now; probably some of them were already discussed in this mailing list. For simplicity I will denote array X of size n: X(n), and i-th element of it : X[i]. 1. Say I have array of compartments C(m) and it includes array of species S(n) then it is mandatory to have n = m and each compartment would have one specie in it? What if I want array of species inside of each of the compartments? If I state that S is 2d array: S(n, k) and it is inside compartment which have one dimension – C(n), will this work? Also what if C(n) includes one species S (without dimension)? Or is this illegal? Vice versa – can single compartment C include array of species S(n)? 2. There are no examples of dimension for specie reference. If correspondent species is array then specie reference is array as well. But spec says that specie references may explicitly have orderedListOfDimensions. Is it possible to somehow define array of specie references each of which corresponds to single (not array) species? What if I have species S[n] participating in reaction r[m], and specie reference which refer to S has dimension p? Which combinations of n, m and p are allowed? 3. In array of rules it should be explicitly stated which of variable components are used on the left side by Index class. But index cannot be used in kinetik law and there are not examples for kinetic law for reaction rate. Say I have array of reactions A+B->C, each of species is an array. How do I define kinetic law for it? Probably something like “k * A[2i] * B[i-1]”? This is automatically mean (in absence of Index for kinetic law) that i-th reaction have kinetik law k * A[2i] * B[i-1]? I suppose Index can not be used in kinetik law because each reaction should have kinetik law, but it feels like inconsistency between rules and reactions. unless this also be done with rules. Say if we have rule y[i] = f(x[2 * i]) then can it be stated without Index like in the following example? <assignmentRule variable=y> <arrays:orderedListOfDimensions> <arrays:dimension id="i" size="n"/> </arrays:orderedListOfDimensions> <math> <apply> <selector/> <ci>x</ci> <apply><times/><cn type="integer"> 2 </cn><cn>i</cn></apply> </apply> </math> </assignmentRule> 4. Can Dimension id be used outside of selector? E.g. to define array of assignments: y[i] = i? <assignmentRule variable=y> <arrays:orderedListOfDimensions> <arrays:dimension id="i" size="n"/> </arrays:orderedListOfDimensions> <math>i</math> </assignmentRule> Is this construct correct? Probably not, because then Dimension id may conflict with global parameter “i”…. 5.One thing that bothers me a bit is that multiple rules for the same variable are allowed (for different components of the vector but still). Hence if stripped from the extension, this file would not be valid SBML document. 6.Other thing which concerns some people from our team is that using arrays one may easily create incorrect model with not matching dimensions (e.g. of species and compartments, or reactants and rections) but this is not a problem of language, I think. Also do you have already or plan to create tests for arrays? Best regards, Ilya. |
|
From: Leandro W. <lea...@gm...> - 2015-04-29 22:20:25
|
Makes sense, I agree that it is a matter of being able to flatten or not. It would be fine for me to have one of those names. But it seems to me that it is a matter of enforcing the current validation rules or not. The current validation rules were written with the goal of being able to flatten any model. The applications listed by Lucian would be invalid SBML because they break these rules: All mathematical operations must be performed on scalar values rather than vectors. (Reference: SBML Level 3 Package Specification for Arrays, Version 1, Section 3.5 on page 11.) No SBase is allowed to have value of type vector. (Reference: SBML Level 3 Package Specification for Arrays, Version 1, Section 3.5 on page 11.) The value of the arrays:size attribute on a given Dimension object, must be a valid SIdRef to an object of type Parameter. (Reference: SBML Level 3 Package Specification for Arrays, Version 1, Section 3.3 on page 6.) 24 The value of the Parameter referenced by the arrays:size attribute must be a non-negative scalar constant integer. (Reference: SBML Level 3 Package Specification for Arrays, Version 1, Section 3.3 on page 6.) Strict would make sense because it would indicate whether you are enforcing the current validation rules or not. Something that means the same thing as strict would be good in my opinion since it is currently used in another context. Leandro On Wed, Apr 29, 2015 at 3:18 PM, Lucian Smith <luc...@gm...> wrote: > I don't want to make a completely separate flag for distrib-multivariate; > I think there are other situations where an arrays model might be used > which would also mean that it couldn't be flattened. For example, if > someone is doing actual vector and matrix algebra using the proposed > 'linear algebra' MathML package, the math in those models probably can't be > flattened, either. > > I also don't think 'dynamic' is the best term, since it must also include > the 'underdefined' validation rule, for when an array has a size of an > undisclosed length. There's nothing dynamic about that; you just can't > flatten the model. > > Everything seems to me to come back to flattening, so I think the flag > should say 'flatten' in it somewhere. 'flattenable', 'canFlatten' > 'isFlattenable', 'hasFlatEquivalent', etc. I think I still like > 'flattenable' the best from that list, though. > > -Lucian > > On Wed, Apr 29, 2015 at 2:02 PM, Chris J. Myers <my...@ec...> > wrote: > >> I would be okay with this if we decouple it from the flatten issue with >> distrib-multivariate. >> >> Chris >> >> > On Apr 29, 2015, at 2:58 PM, Andreas Dräger <and...@en...> >> wrote: >> > >> > Hi guys, >> > >> > To me the terms "strict" or "static" are already used in other contexts >> that don't really fit here. The term "flattenable" sounds a bit complicated >> to me. How about simply calling it "dynamic", i.e., arrays:dynamic=false >> means that it is flattenable, whereas arrays:dynamic=true allows you to >> have arrays with dynamically allocated and changable size etc. >> > >> > Cheers >> > >> > Andreas Dräger >> > 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 >> > >> ------------------------------------------------------------------------------ >> > One dashboard for servers and applications across Physical-Virtual-Cloud >> > Widest out-of-the-box monitoring support with 50+ applications >> > Performance metrics, stats and reports that give you Actionable Insights >> > Deep dive visibility with transaction tracing using APM Insight. >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> > _______________________________________________ >> > sbml-arrays mailing list >> > sbm...@li... >> > https://lists.sourceforge.net/lists/listinfo/sbml-arrays >> >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays >> > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > |
|
From: Lucian S. <luc...@gm...> - 2015-04-29 21:18:45
|
I don't want to make a completely separate flag for distrib-multivariate; I think there are other situations where an arrays model might be used which would also mean that it couldn't be flattened. For example, if someone is doing actual vector and matrix algebra using the proposed 'linear algebra' MathML package, the math in those models probably can't be flattened, either. I also don't think 'dynamic' is the best term, since it must also include the 'underdefined' validation rule, for when an array has a size of an undisclosed length. There's nothing dynamic about that; you just can't flatten the model. Everything seems to me to come back to flattening, so I think the flag should say 'flatten' in it somewhere. 'flattenable', 'canFlatten' 'isFlattenable', 'hasFlatEquivalent', etc. I think I still like 'flattenable' the best from that list, though. -Lucian On Wed, Apr 29, 2015 at 2:02 PM, Chris J. Myers <my...@ec...> wrote: > I would be okay with this if we decouple it from the flatten issue with > distrib-multivariate. > > Chris > > > On Apr 29, 2015, at 2:58 PM, Andreas Dräger <and...@en...> > wrote: > > > > Hi guys, > > > > To me the terms "strict" or "static" are already used in other contexts > that don't really fit here. The term "flattenable" sounds a bit complicated > to me. How about simply calling it "dynamic", i.e., arrays:dynamic=false > means that it is flattenable, whereas arrays:dynamic=true allows you to > have arrays with dynamically allocated and changable size etc. > > > > Cheers > > > > Andreas Dräger > > 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 > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > _______________________________________________ > > sbml-arrays mailing list > > sbm...@li... > > https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays > |
|
From: Chris J. M. <my...@ec...> - 2015-04-29 21:02:48
|
I would be okay with this if we decouple it from the flatten issue with distrib-multivariate. Chris > On Apr 29, 2015, at 2:58 PM, Andreas Dräger <and...@en...> wrote: > > Hi guys, > > To me the terms "strict" or "static" are already used in other contexts that don't really fit here. The term "flattenable" sounds a bit complicated to me. How about simply calling it "dynamic", i.e., arrays:dynamic=false means that it is flattenable, whereas arrays:dynamic=true allows you to have arrays with dynamically allocated and changable size etc. > > Cheers > > Andreas Dräger > 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 > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Andreas D. <and...@en...> - 2015-04-29 20:59:09
|
Hi guys, To me the terms "strict" or "static" are already used in other contexts that don't really fit here. The term "flattenable" sounds a bit complicated to me. How about simply calling it "dynamic", i.e., arrays:dynamic=false means that it is flattenable, whereas arrays:dynamic=true allows you to have arrays with dynamically allocated and changable size etc. Cheers Andreas Dräger 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...> - 2015-04-29 19:10:44
|
I’m a little tempted to have two flags. One for your first two use cases and another that the multivariate distrib package adds. It is possible, for example, to have constant size arrays and multivariate distributions. This would mean you could still do validation but not falttening. Just a thought. I’m okay with one flag for now, and revisit when distrib multivariate comes along. Chris > On Apr 29, 2015, at 12:49 PM, Lucian Smith <luc...@gm...> wrote: > > If I'm remembering correctly, the three rules that would be strict in one version, but relaxed in the other are: > > * An array length could be undefined > * An array length could change > * A distrib-extended function definition could return an array in one call that would be different in a second call, making flattening impossible. > > (Man, that last is highly specific.) > > 'Static' isn't really part of the definition of the last, so that leaves 'strict' or 'flattenable'. Of the two, I think I prefer 'flattenable', since it's both easy to define, and clear to a modeler how they might use it. All you have to say in the spec is, "If the model is declared 'flattenable=false', don't try to flatten the model." The modeler may have any number of reasons they want to say that (variable array length; using multivariate 'distrib'; using actual vector arithmetic with a different MathML package), but in all cases, the spec can simply be clear and say 'the modeler said not to flatten this model'. > > I might go with 'strict' if there was some *other* restriction people wanted to relax with this flag, but I haven't heard of one thus far. > > -Lucian > > > > On Wed, Apr 29, 2015 at 11:16 AM, Leandro Watanabe <lea...@gm... <mailto:lea...@gm...>> wrote: > Hi, > > At Harmony, we talked about the arrays package and its limitation to constant sized arrays. > Because some people might want arrays that can dynamically change in size, we decided to add a flag to loosen some restrictions of arrays. > This flag would allow sizes to be non-constant parameters or not specified. > Possible names for the flag are: > > - strict > - flattenable > - static > > Does anyone have any preference? > > One of the reasons it was decided to make arrays size constants is the fact that arrayed models can be flattened. Flattening would be lost with this flag. In addition, constant sized arrays allow us to validate things that otherwise would only be possible at runtime such as arrays out-of-bounds. Thus, this flag would also change how validation is done. > > On a side note, the distrib package is currently using arrays. It looks like multivariate distributions need arrays for input/output but the arrays package does not allow that. The flag could be used allow this. Flattening is not possible in this case. > > Any suggestions or comments? > > Leandro > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y <http://ad.doubleclick.net/ddm/clk/290420510;117567292;y> > _______________________________________________ > sbml-arrays mailing list > sbm...@li... <mailto:sbm...@li...> > https://lists.sourceforge.net/lists/listinfo/sbml-arrays <https://lists.sourceforge.net/lists/listinfo/sbml-arrays> > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Lucian S. <luc...@gm...> - 2015-04-29 18:49:52
|
If I'm remembering correctly, the three rules that would be strict in one version, but relaxed in the other are: * An array length could be undefined * An array length could change * A distrib-extended function definition could return an array in one call that would be different in a second call, making flattening impossible. (Man, that last is highly specific.) 'Static' isn't really part of the definition of the last, so that leaves 'strict' or 'flattenable'. Of the two, I think I prefer 'flattenable', since it's both easy to define, and clear to a modeler how they might use it. All you have to say in the spec is, "If the model is declared 'flattenable=false', don't try to flatten the model." The modeler may have any number of reasons they want to say that (variable array length; using multivariate 'distrib'; using actual vector arithmetic with a different MathML package), but in all cases, the spec can simply be clear and say 'the modeler said not to flatten this model'. I might go with 'strict' if there was some *other* restriction people wanted to relax with this flag, but I haven't heard of one thus far. -Lucian On Wed, Apr 29, 2015 at 11:16 AM, Leandro Watanabe <lea...@gm...> wrote: > Hi, > > At Harmony, we talked about the arrays package and its limitation to > constant sized arrays. > Because some people might want arrays that can dynamically change in size, > we decided to add a flag to loosen some restrictions of arrays. > This flag would allow sizes to be non-constant parameters or not specified. > Possible names for the flag are: > > - strict > - flattenable > - static > > Does anyone have any preference? > > One of the reasons it was decided to make arrays size constants is the > fact that arrayed models can be flattened. Flattening would be lost with > this flag. In addition, constant sized arrays allow us to validate things > that otherwise would only be possible at runtime such as arrays > out-of-bounds. Thus, this flag would also change how validation is done. > > On a side note, the distrib package is currently using arrays. It looks > like multivariate distributions need arrays for input/output but the arrays > package does not allow that. The flag could be used allow this. Flattening > is not possible in this case. > > Any suggestions or comments? > > Leandro > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > |
|
From: Leandro W. <lea...@gm...> - 2015-04-29 18:16:20
|
Hi, At Harmony, we talked about the arrays package and its limitation to constant sized arrays. Because some people might want arrays that can dynamically change in size, we decided to add a flag to loosen some restrictions of arrays. This flag would allow sizes to be non-constant parameters or not specified. Possible names for the flag are: - strict - flattenable - static Does anyone have any preference? One of the reasons it was decided to make arrays size constants is the fact that arrayed models can be flattened. Flattening would be lost with this flag. In addition, constant sized arrays allow us to validate things that otherwise would only be possible at runtime such as arrays out-of-bounds. Thus, this flag would also change how validation is done. On a side note, the distrib package is currently using arrays. It looks like multivariate distributions need arrays for input/output but the arrays package does not allow that. The flag could be used allow this. Flattening is not possible in this case. Any suggestions or comments? Leandro |
|
From: Chris J. M. <my...@ec...> - 2015-04-17 04:05:10
|
Hi Lucian, We actually thought about this one a lot. We went back and forth about it several times. We initially even began considering defining all the mathML operators over these vectors. The validation rules, however, became very nasty. We then realized that by restricting all operations to scalars that the validation became much simpler, and we don’t believe that we lost any power. It may as you point out require a little more XML code to describe, we do not believe we are losing any expressiveness. One thing to keep in mind is that we abandoned long ago the idea that this was a linear algebra package but just an arrays package. Therefore, we were defining all operators to be elementwise. Namely, A*B is not the multiplication of two matrices but rather just multiplication of the elements. So, in this case, these two things are equivalent: Parameters n:=3 A[n] B[n] C[n] Rule R: C:=A*B is equivalent to Rule R[n]: <— where d0 is the dimension id for this rule C[d0]:=A[d0]*B[d0] This also made flattening much easier. You can always determine how many rules you need to generate without looking at the operand sizes. Assuming the expressiveness is the same, one can always build a GUI that converts from the simpler form to the other form. Indeed, we are doing this in at least one case (initial assignments) where we add the dimension by copying it from the target of the initial assignment. Unless, we see a useful example that cannot be converted, I would be strongly inclined towards keeping things as they are. Chris > On Apr 16, 2015, at 3:29 PM, Lucian Smith <luc...@gm...> wrote: > > First of all, I want to say thanks to Chris and his lab for putting so much effort into the arrays package, and for resurrecting it in the first place. It's looking pretty good, and I think it could be useful. > > I've gone over the latest spec and have run a few updates and clarifications by Chris, resulting in the version I'm attaching to this email. Most of the changes are non-controversial, and I've discussed the changes with Chris on another list. > > However, I do have a couple bigger question, that are probably worth discussing here. One is that I'm wondering if the position that 'all math is done on the scalar level' is going to hurt adaptation of the package by modelers that use arrays. It seems to me (from mostly-outsider's position) that the great advantage of using arrays and matrices is that vector arithmetic is much much more efficient than scalar arithmetic--in fact, it's what MATLAB in particular optimizes like crazy. Given that so much modeling takes place in MATLAB anyway, it would make sense to me to optimize things ourselves in this direction. > > As a very simple example, here's some SBML from the spec that uses an initial assignment to create a vector X = [1,2,3]: > > <listOfParameters> > <parameter id="n" constant="true" value="3"/> > <parameter id="X" constant="false" value="0"> > <arrays:listOfDimensions xmlns:arrays="http://www.sbml.org/sbml/level3/version1/arrays/version1 <http://www.sbml.org/sbml/level3/version1/arrays/version1>"> > <arrays:dimension arrays:id="d0" arrays:size="n" arrays:arrayDimension="0"/> > </arrays:listOfDimensions> > </parameter> > </listOfParameters> > <listOfInitialAssignments> > <initialAssignment symbol="X"> > <arrays:listOfDimensions xmlns:arrays="http://www.sbml.org/sbml/level3/version1/arrays/version1 <http://www.sbml.org/sbml/level3/version1/arrays/version1>"> > <arrays:dimension arrays:id="d0" arrays:size="n" arrays:arrayDimension="0"/> > </arrays:listOfDimensions> > <arrays:listOfIndices xmlns:arrays="http://www.sbml.org/sbml/level3/version1/arrays/version1 <http://www.sbml.org/sbml/level3/version1/arrays/version1>"> > <arrays:index arrays:referencedAttribute="symbol" arrays:arrayDimension="0"> > <math xmlns="http://www.w3.org/1998/Math/MathML <http://www.w3.org/1998/Math/MathML>"> > <ci> d0 </ci> > </math> > </arrays:index> > </arrays:listOfIndices> > <math xmlns="http://www.w3.org/1998/Math/MathML <http://www.w3.org/1998/Math/MathML>"> > <apply> > <selector/> > <vector> > <cn type="integer"> 3 </cn> > <cn type="integer"> 2 </cn> > <cn type="integer"> 1 </cn> > </vector> > <ci> d0 </ci> > </apply> > </math> > </initialAssignment> > </listOfInitialAssignments> > > The setup of the parameters themselves are fine, and are about as efficient as I could imagine them. But the setup of the initial assignment, following the 'all math must be scalar' principle, ends up being, I believe, much more complicated than it needs to be. First, the initial assignment itself is set up as a vector, with 'd0' being its dimension. The 'listOfIndices' then uses d0 say 'The d0th assignment rule corresponds to the d0th X". Then the vector/selector MathML is used to say "The d0th element of this vector is used in the d0th assignment rule" > > This is a very powerful system, and allows any number of really tricky assignments to be created, but I can't help but believe that the following would be not only simpler to read, but simpler to implement, and more in line with how people think about vector math: > > <listOfParameters> > <parameter id="n" constant="true" value="3"/> > <parameter id="X" constant="false" value="0"> > <arrays:listOfDimensions xmlns:arrays="http://www.sbml.org/sbml/level3/version1/arrays/version1 <http://www.sbml.org/sbml/level3/version1/arrays/version1>"> > <arrays:dimension arrays:id="d0" arrays:size="n" arrays:arrayDimension="0"/> > </arrays:listOfDimensions> > </parameter> > </listOfParameters> > <listOfInitialAssignments> > <initialAssignment symbol="X"> > <math xmlns="http://www.w3.org/1998/Math/MathML <http://www.w3.org/1998/Math/MathML>"> > <vector> > <cn type="integer"> 3 </cn> > <cn type="integer"> 2 </cn> > <cn type="integer"> 1 </cn> > </vector> > </math> > </initialAssignment> > </listOfInitialAssignments> > > Here, we just have a single initial assignment, which takes a vector and assigns it to 'X'. Obviously, the dimensions would have to match, but the intent is very straightforward. > > I'm not saying that we should remove the system described in the spec, because it's obviously working for Chris's lab, and may well be the only option for certain types of assignment and other variable manipulation. But I think if we allowed SBML array variable IDs to be treated as arrays directly, it would be both simpler and more useful in a potentially wide range of situations, such as the above. > > What do the rest of you think? > > -Lucian > <sbml-arrays-r0.2a.pdf>------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF_______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Lucian S. <luc...@gm...> - 2015-04-16 21:29:19
|
First of all, I want to say thanks to Chris and his lab for putting so much
effort into the arrays package, and for resurrecting it in the first
place. It's looking pretty good, and I think it could be useful.
I've gone over the latest spec and have run a few updates and
clarifications by Chris, resulting in the version I'm attaching to this
email. Most of the changes are non-controversial, and I've discussed the
changes with Chris on another list.
However, I do have a couple bigger question, that are probably worth
discussing here. One is that I'm wondering if the position that 'all math
is done on the scalar level' is going to hurt adaptation of the package by
modelers that use arrays. It seems to me (from mostly-outsider's position)
that the great advantage of using arrays and matrices is that vector
arithmetic is much much more efficient than scalar arithmetic--in fact,
it's what MATLAB in particular optimizes like crazy. Given that so much
modeling takes place in MATLAB anyway, it would make sense to me to
optimize things ourselves in this direction.
As a very simple example, here's some SBML from the spec that uses an
initial assignment to create a vector X = [1,2,3]:
<listOfParameters>
<parameter id="n" constant="true" value="3"/>
<parameter id="X" constant="false" value="0">
<arrays:listOfDimensions xmlns:arrays="
http://www.sbml.org/sbml/level3/version1/arrays/version1">
<arrays:dimension arrays:id="d0" arrays:size="n"
arrays:arrayDimension="0"/>
</arrays:listOfDimensions>
</parameter>
</listOfParameters>
<listOfInitialAssignments>
<initialAssignment symbol="X">
<arrays:listOfDimensions xmlns:arrays="
http://www.sbml.org/sbml/level3/version1/arrays/version1">
<arrays:dimension arrays:id="d0" arrays:size="n"
arrays:arrayDimension="0"/>
</arrays:listOfDimensions>
<arrays:listOfIndices xmlns:arrays="
http://www.sbml.org/sbml/level3/version1/arrays/version1">
<arrays:index arrays:referencedAttribute="symbol"
arrays:arrayDimension="0">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<ci> d0 </ci>
</math>
</arrays:index>
</arrays:listOfIndices>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<apply>
<selector/>
<vector>
<cn type="integer"> 3 </cn>
<cn type="integer"> 2 </cn>
<cn type="integer"> 1 </cn>
</vector>
<ci> d0 </ci>
</apply>
</math>
</initialAssignment>
</listOfInitialAssignments>
The setup of the parameters themselves are fine, and are about as efficient
as I could imagine them. But the setup of the initial assignment,
following the 'all math must be scalar' principle, ends up being, I
believe, much more complicated than it needs to be. First, the initial
assignment itself is set up as a vector, with 'd0' being its dimension.
The 'listOfIndices' then uses d0 say 'The d0th assignment rule corresponds
to the d0th X". Then the vector/selector MathML is used to say "The d0th
element of this vector is used in the d0th assignment rule"
This is a very powerful system, and allows any number of really tricky
assignments to be created, but I can't help but believe that the following
would be not only simpler to read, but simpler to implement, and more in
line with how people think about vector math:
<listOfParameters>
<parameter id="n" constant="true" value="3"/>
<parameter id="X" constant="false" value="0">
<arrays:listOfDimensions xmlns:arrays="
http://www.sbml.org/sbml/level3/version1/arrays/version1">
<arrays:dimension arrays:id="d0" arrays:size="n"
arrays:arrayDimension="0"/>
</arrays:listOfDimensions>
</parameter>
</listOfParameters>
<listOfInitialAssignments>
<initialAssignment symbol="X">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<vector>
<cn type="integer"> 3 </cn>
<cn type="integer"> 2 </cn>
<cn type="integer"> 1 </cn>
</vector>
</math>
</initialAssignment>
</listOfInitialAssignments>
Here, we just have a single initial assignment, which takes a vector and
assigns it to 'X'. Obviously, the dimensions would have to match, but the
intent is very straightforward.
I'm not saying that we should remove the system described in the spec,
because it's obviously working for Chris's lab, and may well be the only
option for certain types of assignment and other variable manipulation.
But I think if we allowed SBML array variable IDs to be treated as arrays
directly, it would be both simpler and more useful in a potentially wide
range of situations, such as the above.
What do the rest of you think?
-Lucian
|
|
From: Chris J. M. <my...@ec...> - 2014-10-02 16:49:10
|
Hi,
Leandro and I have been discussing validation rules for array math, and we have discovered a couple of things that I thought would be good to discuss.
1) Originally, we had planned on defining all mathML functions applied to arrays to be done in element-wise. For example, if A and B are arrays with same number of dimensions and sizes, then A+B yields a new array where each entry has been added together element-wise. However, it does not appear that this behavior is needed or desirable. The reason is that we are not allow any implicit arrays. All array accesses must be explicit. For example, let us assume that you have an array X and you want to assign it A+B in an assignment rule. This would be constructed as follows:
Parameter
n:=10
A[n]
B[n]
X[n]
Rule: R[n] <--- a rule with dimension n
X[d0] := A[d0] + B[d0] where d0 is the id for the rule dimension
Now, you could write this like this:
X[d0] := (A+B)[d0]
This is bad though because for each of the 10 calculations, it would do array math to compute A+B then use exactly one entry in this array to assign to X[d0]. Very costly computationally.
Therefore, we are wondering if perhaps we should just keep all operators defined only on scalar values, as it can always be rewritten in this form and executed much more efficiently.
2) Another thing we originally considered was disallowing ragged vectors. However, while not particularly useful, they are not in themselves bad. For example,
Parameter
n:=3
X[n]
Rule R[n]
X[d0] := { { 1, 2, 3, 4 }, {5, 6, 7} }[1][d0]
This is okay since the index always indexes into a valid value which is the important thing to check. The raggedness of the vector does no harm, though it also has no use. The question is should there be a validation rule to disallow this since it is not useful, or should we just have the validation rule for making sure that indices find valid values is good enough. I have no strong opinion either way.
Look forward to your input.
Chris
|
|
From: Chris J. M. <my...@ec...> - 2014-09-05 18:06:37
|
With arrays, this could be done as follows assuming a sample time of 1 second. Parameter S1_history[n]=0 Result=0 Update=0 Count=0 Rule Result = Sum(S1_history,0,n-1) Event Trigger: Update==0 (initialValue=false to make it fire immediately EventAssignment: Update=1 Trigger: Update==1 Delay: 1 EventAssignment: S1_history[Count]=S1 Count=piecewise(Count + 1, Count < n-1, 0) Update=0 Cheers, Chris On Sep 5, 2014, at 9:36 AM, Andy Somogyi <and...@gm...> wrote: > Its possible to do it today without events, its just ugly. > > Basically, what one could do is unroll the loop when generating the sbml, something like: > > # probability of firing, assuming it is a function of some > # state variable S1 > def p(time): > return delay(S1, time-0) + delay(S1, time-0.1) + delay(S1, time-0.2) + ... + delay(S1, time-0.n) > > What I was trying to say is that it would be cleaner if the delay of a symbol could be treated as an array. > > I could see this working if the 'delay' function acting on a symbol was defined that it returned an array type. > > > > > > > > > > On Sep 4, 2014, at 5:26 AM, Nicolas Rodriguez wrote: > >> >> it might be possible to do that with events. >> >> You can create a parameter named 'history' which is an array of size n >> >> Then you have two events that need to be fired, one after the other every second. >> >> The first event switch the values down in the array, history[0] is dropped and then history[i-1] = history[i] >> >> The second event assign the current value of the state variable 'X' to history[n - 1] >> >> Like this you should get the value of 'X' at each second for the last 20 second in the 'history' array. >> >> Then you can use this array to calculate if the vesicle is released or not. >> >> Not sure if it would work for Andy but I think something along those lines should be possible. >> >> Nico >> >> >> On 09/04/2014 12:18 AM, Chris J. Myers wrote: >>> Guess I'm still missing it. Just to be clear. Arrays are not equal to matrices. All math is done element-wise. This was a decision we made to keep the first version simple. If this is okay, can you make the example more concrete with some very simple idea of what the model would look like? >>> >>> Chris >>> >>> >>> On Sep 3, 2014, at 4:55 PM, Andy Somogyi <and...@gm...> wrote: >>> >>>> The application I have mind is would be a synapse model. Here the probability of a vesicle release would be calculated as a convolution of a set of state variables historical values for a finite window of time. >>>> >>>> In effect you can think of it as a sliding window moving average. >>>> >>>> So, here this value actually determines the models dynamics so it would be part of the model and not analysis. >>>> >>>> It would be possible to get this kind of behavior today by explicitly writing out the convolution when writing the model. But I think the array package would be ideal for this as you could write these in a very concise and general and flexible way. >>>> >>>> On Wednesday, September 3, 2014, Chris J. Myers <my...@ec...> wrote: >>>> Sounds like an interesting application. You can certainly create a parameter which is an array to store data. However, the question would be can you express the storing of the historical data you want using events or rules. I think you may be able to as these are pretty powerful, but I'm not sure I understand your application well enough to tell you how to do it. The question I have though is if what you are proposing is part of the model or part of its analysis. I agree the line can blur at times, but it should be considered. >>>> >>>> Cheers, >>>> >>>> Chris >>>> >>>> On Sep 3, 2014, at 10:01 AM, Andy Somogyi <and...@gm...> wrote: >>>> >>>> > Hello, >>>> > >>>> > Frequently, one needs to perform an array like operation on historical data, such as convolution of history with an array. Or some other array operation, such as summing or integrating historical data. >>>> > >>>> > What would be very useful is if specification allowed historical time series when a delay equation is specified to be use as an array in conjunction with various array functions specified in the arrays package. >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ >>>> > Slashdot TV. >>>> > Video for Nerds. Stuff that matters. >>>> > http://tv.slashdot.org/ >>>> > _______________________________________________ >>>> > sbml-arrays mailing list >>>> > sbm...@li... >>>> > https://lists.sourceforge.net/lists/listinfo/sbml-arrays >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Slashdot TV. >>>> Video for Nerds. Stuff that matters. >>>> http://tv.slashdot.org/ >>>> _______________________________________________ >>>> sbml-arrays mailing list >>>> sbm...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sbml-arrays >>>> ------------------------------------------------------------------------------ >>>> Slashdot TV. >>>> Video for Nerds. Stuff that matters. >>>> http://tv.slashdot.org/_______________________________________________ >>>> sbml-arrays mailing list >>>> sbm...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sbml-arrays >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Slashdot TV. >>> Video for Nerds. Stuff that matters. >>> http://tv.slashdot.org/ >>> >>> >>> _______________________________________________ >>> sbml-arrays mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-arrays >> >> ------------------------------------------------------------------------------ >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/_______________________________________________ >> sbml-arrays mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/_______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Andy S. <and...@gm...> - 2014-09-05 15:36:47
|
Its possible to do it today without events, its just ugly. Basically, what one could do is unroll the loop when generating the sbml, something like: # probability of firing, assuming it is a function of some # state variable S1 def p(time): return delay(S1, time-0) + delay(S1, time-0.1) + delay(S1, time-0.2) + ... + delay(S1, time-0.n) What I was trying to say is that it would be cleaner if the delay of a symbol could be treated as an array. I could see this working if the 'delay' function acting on a symbol was defined that it returned an array type. On Sep 4, 2014, at 5:26 AM, Nicolas Rodriguez wrote: > > it might be possible to do that with events. > > You can create a parameter named 'history' which is an array of size n > > Then you have two events that need to be fired, one after the other every second. > > The first event switch the values down in the array, history[0] is dropped and then history[i-1] = history[i] > > The second event assign the current value of the state variable 'X' to history[n - 1] > > Like this you should get the value of 'X' at each second for the last 20 second in the 'history' array. > > Then you can use this array to calculate if the vesicle is released or not. > > Not sure if it would work for Andy but I think something along those lines should be possible. > > Nico > > > On 09/04/2014 12:18 AM, Chris J. Myers wrote: >> Guess I'm still missing it. Just to be clear. Arrays are not equal to matrices. All math is done element-wise. This was a decision we made to keep the first version simple. If this is okay, can you make the example more concrete with some very simple idea of what the model would look like? >> >> Chris >> >> >> On Sep 3, 2014, at 4:55 PM, Andy Somogyi <and...@gm...> wrote: >> >>> The application I have mind is would be a synapse model. Here the probability of a vesicle release would be calculated as a convolution of a set of state variables historical values for a finite window of time. >>> >>> In effect you can think of it as a sliding window moving average. >>> >>> So, here this value actually determines the models dynamics so it would be part of the model and not analysis. >>> >>> It would be possible to get this kind of behavior today by explicitly writing out the convolution when writing the model. But I think the array package would be ideal for this as you could write these in a very concise and general and flexible way. >>> >>> On Wednesday, September 3, 2014, Chris J. Myers <my...@ec...> wrote: >>> Sounds like an interesting application. You can certainly create a parameter which is an array to store data. However, the question would be can you express the storing of the historical data you want using events or rules. I think you may be able to as these are pretty powerful, but I'm not sure I understand your application well enough to tell you how to do it. The question I have though is if what you are proposing is part of the model or part of its analysis. I agree the line can blur at times, but it should be considered. >>> >>> Cheers, >>> >>> Chris >>> >>> On Sep 3, 2014, at 10:01 AM, Andy Somogyi <and...@gm...> wrote: >>> >>> > Hello, >>> > >>> > Frequently, one needs to perform an array like operation on historical data, such as convolution of history with an array. Or some other array operation, such as summing or integrating historical data. >>> > >>> > What would be very useful is if specification allowed historical time series when a delay equation is specified to be use as an array in conjunction with various array functions specified in the arrays package. >>> > >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > Slashdot TV. >>> > Video for Nerds. Stuff that matters. >>> > http://tv.slashdot.org/ >>> > _______________________________________________ >>> > sbml-arrays mailing list >>> > sbm...@li... >>> > https://lists.sourceforge.net/lists/listinfo/sbml-arrays >>> >>> >>> ------------------------------------------------------------------------------ >>> Slashdot TV. >>> Video for Nerds. Stuff that matters. >>> http://tv.slashdot.org/ >>> _______________________________________________ >>> sbml-arrays mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-arrays >>> ------------------------------------------------------------------------------ >>> Slashdot TV. >>> Video for Nerds. Stuff that matters. >>> http://tv.slashdot.org/_______________________________________________ >>> sbml-arrays mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-arrays >> >> >> >> ------------------------------------------------------------------------------ >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> >> >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/_______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Nicolas R. <rod...@eb...> - 2014-09-04 09:27:04
|
it might be possible to do that with events. You can create a parameter named 'history' which is an array of size n Then you have two events that need to be fired, one after the other every second. The first event switch the values down in the array, history[0] is dropped and then history[i-1] = history[i] The second event assign the current value of the state variable 'X' to history[n - 1] Like this you should get the value of 'X' at each second for the last 20 second in the 'history' array. Then you can use this array to calculate if the vesicle is released or not. Not sure if it would work for Andy but I think something along those lines should be possible. Nico On 09/04/2014 12:18 AM, Chris J. Myers wrote: > Guess I'm still missing it. Just to be clear. Arrays are not equal > to matrices. All math is done element-wise. This was a decision we > made to keep the first version simple. If this is okay, can you make > the example more concrete with some very simple idea of what the model > would look like? > > Chris > > > On Sep 3, 2014, at 4:55 PM, Andy Somogyi <and...@gm... > <mailto:and...@gm...>> wrote: > >> The application I have mind is would be a synapse model. Here the >> probability of a vesicle release would be calculated as a convolution >> of a set of state variables historical values for a finite window of >> time. >> >> In effect you can think of it as a sliding window moving average. >> >> So, here this value actually determines the models dynamics so it >> would be part of the model and not analysis. >> >> It would be possible to get this kind of behavior today by explicitly >> writing out the convolution when writing the model. But I think the >> array package would be ideal for this as you could write these in a >> very concise and general and flexible way. >> >> On Wednesday, September 3, 2014, Chris J. Myers <my...@ec... >> <mailto:my...@ec...>> wrote: >> >> Sounds like an interesting application. You can certainly create >> a parameter which is an array to store data. However, the >> question would be can you express the storing of the historical >> data you want using events or rules. I think you may be able to >> as these are pretty powerful, but I'm not sure I understand your >> application well enough to tell you how to do it. The question I >> have though is if what you are proposing is part of the model or >> part of its analysis. I agree the line can blur at times, but it >> should be considered. >> >> Cheers, >> >> Chris >> >> On Sep 3, 2014, at 10:01 AM, Andy Somogyi <and...@gm... >> <javascript:;>> wrote: >> >> > Hello, >> > >> > Frequently, one needs to perform an array like operation on >> historical data, such as convolution of history with an array. Or >> some other array operation, such as summing or integrating >> historical data. >> > >> > What would be very useful is if specification allowed >> historical time series when a delay equation is specified to be >> use as an array in conjunction with various array functions >> specified in the arrays package. >> > >> > >> > >> > >> ------------------------------------------------------------------------------ >> > Slashdot TV. >> > Video for Nerds. Stuff that matters. >> > http://tv.slashdot.org/ >> > _______________________________________________ >> > sbml-arrays mailing list >> > sbm...@li... <javascript:;> >> > https://lists.sourceforge.net/lists/listinfo/sbml-arrays >> >> >> ------------------------------------------------------------------------------ >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> _______________________________________________ >> sbml-arrays mailing list >> sbm...@li... <javascript:;> >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays >> >> ------------------------------------------------------------------------------ >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/_______________________________________________ >> sbml-arrays mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-arrays > > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > > > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
