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: Michael H. <mh...@ca...> - 2014-03-25 20:46:43
|
On Tue, 25 Mar 2014 08:38:39 -0700, Lucian Smith wrote: > On Tue, Mar 25, 2014 at 01:42:22PM +0100, Frank T. Bergmann wrote: >> I'm not sure we ought to standardize an infix syntax as well. (Just >> consider >> again the C / Java syntax here ... if you actually want to initialize an >> array with values, you would use curly brackets). >> >> Just saying :) > > Wait, I don't know what you mean. Using curly brackets was explicitly > mentioned in the document already. And what do you mean by 'as well'? > Standardizing the infix syntax is explicitly and solely what we are > proposing, so I can't tell what you're talking about. Lucian stated it more brusquely than I would have, but actually, Frank, I had the same confusion when I read your reply. Can you clarify what you meant? MH |
|
From: Lucian S. <lp...@uw...> - 2014-03-25 15:38:47
|
On Tue, Mar 25, 2014 at 01:42:22PM +0100, Frank T. Bergmann wrote: > > > I think we should consistently use C/Java syntax for arrays related > math. > > > > Same for me. > > > > I'm not sure we ought to standardize an infix syntax as well. (Just consider > again the C / Java syntax here ... if you actually want to initialize an > array with values, you would use curly brackets). > > Just saying :) Wait, I don't know what you mean. Using curly brackets was explicitly mentioned in the document already. And what do you mean by 'as well'? Standardizing the infix syntax is explicitly and solely what we are proposing, so I can't tell what you're talking about. -Lucian |
|
From: Chris J. M. <my...@ec...> - 2014-03-25 13:30:35
|
Well, it is not part of the standard, it is just an agreement between libsbml and jsbml for a helper parser for math strings. I think since there is general agreement on C/Java syntax, then that is what the parser should use. I have no problems with curly braces :-). Chris On Mar 25, 2014, at 6:42 AM, "Frank T. Bergmann" <fbe...@ca...> wrote: >>> I think we should consistently use C/Java syntax for arrays related > math. >> >> Same for me. >> > > I'm not sure we ought to standardize an infix syntax as well. (Just consider > again the C / Java syntax here ... if you actually want to initialize an > array with values, you would use curly brackets). > > Just saying :) > > Cheers > Frank > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Frank T. B. <fbe...@ca...> - 2014-03-25 13:19:45
|
> > I think we should consistently use C/Java syntax for arrays related math. > > Same for me. > I'm not sure we ought to standardize an infix syntax as well. (Just consider again the C / Java syntax here ... if you actually want to initialize an array with values, you would use curly brackets). Just saying :) Cheers Frank |
|
From: Nicolas R. <rod...@eb...> - 2014-03-25 12:36:10
|
On 25/03/2014 11:42, Sarah Keating wrote: >> I vote for using the C/Java syntax > I agree. > > I think we should consistently use C/Java syntax for arrays related math. Same for me. Nico |
|
From: Sarah K. <ske...@ca...> - 2014-03-25 11:41:52
|
> I vote for using the C/Java syntax I agree. I think we should consistently use C/Java syntax for arrays related math. Sarah |
|
From: Chris J. M. <my...@ec...> - 2014-03-24 18:13:54
|
Oh, that makes more sense. I agree that it would be nice to have the validity of the mathML reflect which namespaces are included. Chris On Mar 24, 2014, at 11:17 AM, Sarah Keating <ske...@ca...> wrote: > On 24/03/2014 16:35, Chris J. Myers wrote: >> My memory of this matches Lucian's. Keep the namespace issue simple and just keep all in mathML. We really wanted to avoid having packages defining the constructs differently. > > No no no, I did not mean that the new MathML elements would be in an > SBML namespace - that would be bad :-) > > I am talking about the fact that in order to be allowable in the MathML > a particular element will depend on the presence of an SBML ns. > > So > > <math> > <vector> > etc... > > is only valid for SBML when part of an SBMLDocument that has the arrays ns. > > Sarah > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Sarah K. <ske...@ca...> - 2014-03-24 17:16:34
|
On 24/03/2014 16:35, Chris J. Myers wrote: > My memory of this matches Lucian's. Keep the namespace issue simple and just keep all in mathML. We really wanted to avoid having packages defining the constructs differently. No no no, I did not mean that the new MathML elements would be in an SBML namespace - that would be bad :-) I am talking about the fact that in order to be allowable in the MathML a particular element will depend on the presence of an SBML ns. So <math> <vector> etc... is only valid for SBML when part of an SBMLDocument that has the arrays ns. Sarah |
|
From: Chris J. M. <my...@ec...> - 2014-03-24 16:35:02
|
My memory of this matches Lucian's. Keep the namespace issue simple and just keep all in mathML. We really wanted to avoid having packages defining the constructs differently. I forget the discussion you mention Sarah. When was that? I'm curious. Chris On Mar 24, 2014, at 10:30 AM, Sarah Keating <ske...@ca...> wrote: > >> I remember discussing this, and agreeing that multiple packages could >> allow the same MathML elements, > > Ah - well my memory is different :-) > > I thought it had not been definitely decided - and indeed when I tried > to get some sort of definitive answer from the editors ( on the all > editors list) I did not get a clear answer (the discussion got side > tracked - what a surprise!) > > > Sarah > > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Sarah K. <ske...@ca...> - 2014-03-24 16:30:14
|
> I remember discussing this, and agreeing that multiple packages could > allow the same MathML elements, Ah - well my memory is different :-) I thought it had not been definitely decided - and indeed when I tried to get some sort of definitive answer from the editors ( on the all editors list) I did not get a clear answer (the discussion got side tracked - what a surprise!) Sarah |
|
From: Lucian S. <lp...@uw...> - 2014-03-24 16:22:32
|
On Mon, Mar 24, 2014 at 03:13:49PM +0000, Sarah Keating wrote: > > > When you says that, it means it will cause issues for the libSBML > > implementation I suppose ? > > It will, but also for any parser - as there are the issues of > namespaces that allow a particular component. What? No; the namespace of the 'sum' and other MathML constructs would still be the MathML namespace, not the sbml namespace nor the namespace of any SBML package. At lest, that's how I've always interpreted it! > The SBML Editors have already discussed the issues of different packages > adding the same math elements and they are not just libsbml issues (in > fact the libsbml issues have never been discussed !). I remember discussing this, and agreeing that multiple packages could allow the same MathML elements, which meant that it was particularly important that all packages went with the MathML definition of the elements, not their own interpretation thereof. -Lucian |
|
From: Nicolas R. <rod...@eb...> - 2014-03-24 16:18:10
|
On 03/24/2014 03:20 PM, Nicolas Rodriguez wrote: > On 03/24/2014 03:13 PM, Sarah Keating wrote: >>> When you says that, it means it will cause issues for the libSBML >>> implementation I suppose ? >> It will, but also for any parser - as there are the issues of >> namespaces that allow a particular component. >> >> The SBML Editors have already discussed the issues of different packages >> adding the same math elements and they are not just libsbml issues (in >> fact the libsbml issues have never been discussed !). > I don't see any issues with that. Apart, may be if they adapt the mathml > and then the interpretation could change. Note that I am not saying that there is no issues, so there is may be something I am missing so it would be nice to get more details on those issues. > > Is it assumed that the new elements will stay in the mathML namespace ? > > Nico > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Chris J. M. <my...@ec...> - 2014-03-24 15:34:06
|
> Again I apologise if I was a little blunt :-) > Accepted. > I do appreciate that as work continues the draft will change and that > you don't need to release a new pdf every time you change a comma :-) > That is the point we are at right now. It is still so rough, I really think it needs some polishing before wide release. Of course, we appreciate help with this process but this list has been quite quiet. > But it worries me (and arrays is not the only package where this worries > me) that people are thinking about and making changes to specifications > without using the lists - which essentially excludes some people. > Not intended. However, specifications are ultimately developed by a few individuals than brought to the list for wider discussion, modification, and finally approval. > Maybe I misinterpreted you but you actually called Lucian out on the > fact that he had not referred to math that is in this new specification; > which did give me the 'wrong' impression that you considered this to be > the latest document to work from. This will have made me a little grumpy > since as I'm sure you are well aware when developing software support > for something - chasing a moving target makes things impossible. > Arrays is very much a moving target still. It is getting much closer I think. Our annotation based prototype is giving us some confidence that it is stabilizing, but it still needs to be experimented with further. The added mathML are just things we realized that may be useful. We can still debate the list of mathML for arrays. Nothing is set in stone. > As an aside: The additional math has not been discussed in any way on > the list but it is actually an issue since you have added sum and > product which will probably get added by L3V2 and that WILL cause issues > if it happens :-) > How will sum and product be added for L3V2? I'm not sure how they would work unless you have arrays or sets. I'm happy to have them in core, but I was not aware of that being discussed. Perhaps that has happened since I stepped down as editor. I'm interested to hear though how they will be used in core, so please enlighten me :-). Again, we did not bring it to the list because I have not even read the updates my student put in yet. I wanted to first proofread it myself to make sure I agreed with the changes. I thought also with HARMONY coming up that would be a good spot to discuss because I believe the few vocal people on this list will be there. So, please keep in mind the version I just sent is still a very rough DRAFT, and anything and everything can still be changed as the group sees fit. However, we are indeed starting to gain some confidence that it is getting close to something real. Hopefully, we can work out many of the remaining kinks face-to-face at HARMONY. Chris |
|
From: Nicolas R. <rod...@eb...> - 2014-03-24 15:20:52
|
On 03/24/2014 03:13 PM, Sarah Keating wrote: >> When you says that, it means it will cause issues for the libSBML >> implementation I suppose ? > It will, but also for any parser - as there are the issues of > namespaces that allow a particular component. > > The SBML Editors have already discussed the issues of different packages > adding the same math elements and they are not just libsbml issues (in > fact the libsbml issues have never been discussed !). I don't see any issues with that. Apart, may be if they adapt the mathml and then the interpretation could change. Is it assumed that the new elements will stay in the mathML namespace ? Nico |
|
From: Sarah K. <ske...@ca...> - 2014-03-24 15:13:02
|
> When you says that, it means it will cause issues for the libSBML > implementation I suppose ? It will, but also for any parser - as there are the issues of namespaces that allow a particular component. The SBML Editors have already discussed the issues of different packages adding the same math elements and they are not just libsbml issues (in fact the libsbml issues have never been discussed !). Sarah |
|
From: Nicolas R. <rod...@eb...> - 2014-03-24 14:59:39
|
On 03/24/2014 02:28 PM, Sarah Keating wrote: > As an aside: The additional math has not been discussed in any way on > the list but it is actually an issue since you have added sum and > product which will probably get added by L3V2 and that WILL cause issues > if it happens :-) When you says that, it means it will cause issues for the libSBML implementation I suppose ? Hopefully, L3V2 will not be too long to come then, there will be no issues as arrays won't have to include those mathML elements any more. cheers, Nico |
|
From: Sarah K. <ske...@ca...> - 2014-03-24 14:27:32
|
Hi Chris Again I apologise if I was a little blunt :-) I do appreciate that as work continues the draft will change and that you don't need to release a new pdf every time you change a comma :-) But it worries me (and arrays is not the only package where this worries me) that people are thinking about and making changes to specifications without using the lists - which essentially excludes some people. Maybe I misinterpreted you but you actually called Lucian out on the fact that he had not referred to math that is in this new specification; which did give me the 'wrong' impression that you considered this to be the latest document to work from. This will have made me a little grumpy since as I'm sure you are well aware when developing software support for something - chasing a moving target makes things impossible. As an aside: The additional math has not been discussed in any way on the list but it is actually an issue since you have added sum and product which will probably get added by L3V2 and that WILL cause issues if it happens :-) Sarah |
|
From: Chris J. M. <my...@ec...> - 2014-03-24 14:11:25
|
Hi, My student, Leandro Watanabe, was kind enough to recently spend some time cleaning up the draft specification for the arrays package. Mostly, he just added some explanatory text and updated all of the examples to use the current data model. Note that the data model has not changed at all recently. The only potentially substantive change is that we add sum, product, forall, and exists into the extended mathML subset as well as bvar, lowlimit, uplimit, interval, and condition which are used by these. We studied mathML a bit more and came to realize that these may be useful for arrays. We welcome comments on the current mathML subset and on the draft specification in general. We intend to continue word-smithing the specification as time permits in the hope that we can get to a release specification before too long. Any help with this would, of course, be appreciated. BTW, we are well on our way to an implementation in iBioSim of an experimental version of arrays to test the specification using custom annotations. We hope to report on this at HARMONY. Cheers, Chris |
|
From: Chris J. M. <my...@ec...> - 2014-03-24 13:38:41
|
Just to be clear. You want me to send the specification to the list each time we make a change? Chris Sent from my iPhone On Mar 24, 2014, at 2:04 AM, Sarah Keating <ske...@ca...> wrote: > Hi Chris > > I'm sorry but you cannot say: > > "Please see the recently updated Arrays spec. Should be checked into SVN." > > If there is a new version of the specification the list should have been > informed and a pdf of specification put somewhere people can access it > without needing to download tex files and build it themselves. > > At this point in time libSBML will develop to the latest officially > released version of any specification - as we did whilst the distrib > spec underwent iteration. We have to develop to something that is fixed > that we can point people to - not some tex files in svn that can at any > point be changed. > > Sorry to be blunt. > > Sarah > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Chris J. M. <my...@ec...> - 2014-03-24 13:33:53
|
Sarah you misunderstand there is no released specification. It is still very rough but better than it was. Examples are updated. It needs lots and lots of work and no where near release. I guess what I should have said is we updated the working draft. Chris Sent from my iPhone On Mar 24, 2014, at 2:04 AM, Sarah Keating <ske...@ca...> wrote: > Hi Chris > > I'm sorry but you cannot say: > > "Please see the recently updated Arrays spec. Should be checked into SVN." > > If there is a new version of the specification the list should have been > informed and a pdf of specification put somewhere people can access it > without needing to download tex files and build it themselves. > > At this point in time libSBML will develop to the latest officially > released version of any specification - as we did whilst the distrib > spec underwent iteration. We have to develop to something that is fixed > that we can point people to - not some tex files in svn that can at any > point be changed. > > Sorry to be blunt. > > Sarah > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Sarah K. <ske...@ca...> - 2014-03-24 08:04:06
|
Hi Chris I'm sorry but you cannot say: "Please see the recently updated Arrays spec. Should be checked into SVN." If there is a new version of the specification the list should have been informed and a pdf of specification put somewhere people can access it without needing to download tex files and build it themselves. At this point in time libSBML will develop to the latest officially released version of any specification - as we did whilst the distrib spec underwent iteration. We have to develop to something that is fixed that we can point people to - not some tex files in svn that can at any point be changed. Sorry to be blunt. Sarah |
|
From: Chris J. M. <my...@ec...> - 2014-03-22 15:50:34
|
Hi, I vote for using the C/Java syntax exclusively for selectors. I don't like the idea of using parentheses as they can be confused with use with functions. I also prefer to use C/Java style construction with braces. We are using C/Java syntax for everything else, so why confuse things. As for functions, I'm okay with one short name and one long name for each though that is a bit unique as other functions in SBML I believe all just have one name. Are there exceptions to this? By the way, there are more functions than you listed. Please see the recently updated Arrays spec. Should be checked into SVN. I think we should restrict arithmetic to be between compatible sized objects. Namely, add and subtract should be same size objects while multiply requires number of columns of first object to match number of rows of second, if matrices. No strong feeling on transpose. However, single quote is likely problematic. I object to incorporating ANY of the odd Matlab syntax. I always found that tremendously confusing. Matlab is designed as a tool to manipulate matrices, and that is where the syntax grew out of. SBML is not, so it should still be easy to work with non-matrices. Chris On Mar 21, 2014, at 5:07 PM, Lucian Smith <luc...@gm...> wrote: > So, we've had a couple different discussions about infix syntax for arrays, but it's all been hypothetical up until now. At this point, after Sarah's heroic efforts getting extended MathML into libSBML's 'ASTNode' system, I am actually in a position to implement infix support for it! So we need to make some final decisions. > > I've written up a document of what all I think we need to decide at: > > https://docs.google.com/document/d/1z9QLbmfltAIOkPcR883g4Ml5S7B5crJULXMX68ImL6k/edit# > > Feel free to comment, edit, and whatever else! > > -Lucian > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech_______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Lucian S. <luc...@gm...> - 2014-03-21 23:08:00
|
So, we've had a couple different discussions about infix syntax for arrays, but it's all been hypothetical up until now. At this point, after Sarah's heroic efforts getting extended MathML into libSBML's 'ASTNode' system, I am actually in a position to implement infix support for it! So we need to make some final decisions. I've written up a document of what all I think we need to decide at: https://docs.google.com/document/d/1z9QLbmfltAIOkPcR883g4Ml5S7B5crJULXMX68ImL6k/edit# Feel free to comment, edit, and whatever else! -Lucian |
|
From: Chris J. M. <my...@ec...> - 2014-01-22 15:01:34
|
Yes, I believe the general functionality that you show below is fine. Do you foresee some problem allowing that? Chris On Jan 22, 2014, at 5:14 AM, Sarah Keating <ske...@ca...> wrote: > Hi Chris > > So the proposal talks about using vector and matrix constructors to > assign values. > > Technically the elements of these can be functions/numbers/ci elements etc > > <vector> > <apply><sin/><cn>1</cn></apply> > <cn> 3 </cn> > <ci> a </ci> > </vector> > > is perfectly valid. > > Were you envisioning this type of functionality ? > > Or would arrays impose some restriction on the content of vector ? > > Sarah > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |
|
From: Chris J. M. <my...@ec...> - 2014-01-22 14:50:02
|
> On 21/01/2014 16:31, Chris J. Myers wrote: >> I was not trying to "cop out". I was trying to be flexible. I know perhaps it is rare for me :-). > > Sorry if I offended you - I did not mean to sound like I was laying > blame. Indeed I was probably just surprised that you said you didn't > mind ;-) > A rarity indeed :-) > Can I assume that when you talk about implementation you are referring > to the infix-MathML-infix functionality ? > That is indeed important to have consistent though, of course, I would want libsbml and JSBML to agree on how to read and write arrays in XML as well. Speaking of the string parser, I assume the parser would accept a string of the form X[i] and convert that to a use of the selector. For two dimensional arrays, we could either do X[i][j] OR X[i,j]. I think the former is a bit more common and inline with language influence (java, C) used for other parts of the parser. Actually, now that I think about it, I think we had a discussion about the parser syntax in an earlier thread. Cheers, Chris |
