sbml-arrays — The SBML L3 Arrays and Sets package discussion list

Re: [sbml-arrays] Updated specification

[Chris J. M. <my...@ec...>]

On Jun 19, 2014, at 3:56 AM, Sarah Keating <ske...@ca...> wrote:

> 
>> The compartment reference for S[n][m] assuming "i" and "j" are the dimensions id's could be:
>> 
>> C0, C1[i], C2[i], C2[j], or C3[i][j]
>> 
>> It cannot be though:
>> 
>> C0[i] because C0 is scaler.
>> C1[j] since the range of j is 0 to 20 while C1 has size 10.
>> C1[i][j] and C2[i][j] because they each only have one dimension.
>> C3[j][i] since the range of j is 0 to 20 while the first dimension only has size 10.
>> 
>> Now, that I think about it, I think this validation rule is actually covered by the one which states that the index must not go out-of-bounds.  As well as, the rule which states you should not index a dimension for an object that does not have that dimension.
> 
> I cannot see those rules - which numbers do you mean ??
> 
Oops, they were missing.  I've added text to both the syntax and validation rules for array out-of-bounds checking.  Please have a look.

These are rules are 10210 for selector and 20308 for index.  Previously, the rules before them said the math must evaluate to non-negative integer and be statically computable.  However, it does not say how to evaluate the math.  So, I split this into two rules each.  The first says it must be statically computable while the second states that it must evaluate for all values of dimension ids in the math to values which are non-negative and less than the size of the dimension of the object being index.  These rules coupled with 10208 and 20305 which ensure that the dimension being referred to exists, I believe solves all the problems you are concerned with.  Please check.

> And also I don't think a generic 'index must not go out of bounds' rule 
> is sufficient. The biggest request we get re validation is to be as 
> explicit as possible about what is wrong. There is no harm in listing 
> several rules that could be collapsed into one if you were being laconic 
> - but in fact with validation rules more is better :-)
> 
I cannot think of a case which is not solved by the rules I just added.  Could you give me an example?  I'm trying to write the validation rules in such a way that they do not refer to particular objects in core, so that arrays will work with packages without any additional effort by the other package developers.  So, far, I've been fairly successful.  I've rewritten the restriction on index to simply be that the referencedAttribute must be of type SIdRef, and made the Dimension restriction simply be what must not have a dimension.  In this second case, there is really no harm in allowing everything to have a dimension.  It is just in some cases, they are meaningless.  Therefore, all objects in packages will be allowed dimensions by default and the package developers only need to restrict them away if they decide they are not useful.  I hope to do the same with the types of issues you brought up, and I think the rules I just added achieve that.  However, if you can think of a case I missed, please do let me know.

Thanks,

Chris

Re: [sbml-arrays] Updated specification

[Sarah K. <ske...@ca...>]

> The compartment reference for S[n][m] assuming "i" and "j" are the dimensions id's could be:
>
> C0, C1[i], C2[i], C2[j], or C3[i][j]
>
> It cannot be though:
>
> C0[i] because C0 is scaler.
> C1[j] since the range of j is 0 to 20 while C1 has size 10.
> C1[i][j] and C2[i][j] because they each only have one dimension.
> C3[j][i] since the range of j is 0 to 20 while the first dimension only has size 10.
>
> Now, that I think about it, I think this validation rule is actually covered by the one which states that the index must not go out-of-bounds.  As well as, the rule which states you should not index a dimension for an object that does not have that dimension.

I cannot see those rules - which numbers do you mean ??

And also I don't think a generic 'index must not go out of bounds' rule 
is sufficient. The biggest request we get re validation is to be as 
explicit as possible about what is wrong. There is no harm in listing 
several rules that could be collapsed into one if you were being laconic 
- but in fact with validation rules more is better :-)

Sarah

Re: [sbml-arrays] Updated specification

[Chris J. M. <my...@ec...>]

Hi,

I've added some examples to the mathematical formulas section to help explain the requirements for vector and selector.  Let me know what you think.  I've also updated the examples (4.2 and 4.4) as requested.  Finally, I've updated 4.3 to use piecewise as it could be simplified even though it was not technically invalid.  

The changes are checked in and attached.

Chris

Re: [sbml-arrays] Updated specification

[Leandro W. <lea...@gm...>]

Thanks for the feedback Sarah and Chris.

The rule arrays-10206 was indeed something I wasn’t quite sure how to word. The idea is to not allow ragged vectors.

>> Hi Leandro
>> 
>> The validation rules look great :-)
>> 
>> I have two points:
>> 
>> 
>> POINT 1.
>> ========
>> 
>> This struck me as perhaps needing a little more clarification:
>> 
>> arrays-10206 The arguments of a MathML vector must all have the same 
>> number of dimensions and agree in their size.
>> 
>> I think what you are talking about if you are creating a vector of 
>> vectors they should be regular so
>> 
>> V = [ [1, 2, 3], [a, b, c]] is fine
>> 
>> but
>> 
>> V' = [[1,2], [a,b,c]] is not.
>> 
>> but that could do with slightly more elaboration.
>> 
>> And if that is not what it means it definitely needs clarifying :-)
> 
> This is indeed what was meant.  We will try to clarify this in the specification.  We tried to make sure all the validation rules were also described in the specification, but we may have missed some.  This is one, let us know if you find others.
>> 
>> POINT 2.
>> =======
>> 
>> I think there need to be validation rules explicitly stating that the 
>> size of arrays of different constructs must match when things involve 
>> interactions between elements. What I mean is
>> 
>> consider Example 1 in the spec that puts 100 species A, 100 species B 
>> and 100 species C into 100 compartment cell and then defines 100 reactions
>> 
>> A + B -> C
>> 
>> Now in terms of the reaction - if it is has dimensions then the all the 
>> species referred to must have the same dimensions. What if the reaction 
>> had dimensions 200 ? or just 50 ? or if species A had dimensions 100 but 
>> species B had only 50 ?
>> 
>> If you are going to put an array of species into an array of 
>> compartments - these must match; although you could potentially put an 
>> array of species into a single compartment :-)
>> 
>> Similarly with assignments 
>> (initialAssignment/assignmentRule/rateRule/eventAssignment) they must 
>> have the same dimensions as the dimensions of whatever is referenced by 
>> the variable/symbol.
>> 
> You do raise an important issue, but I think these cases may actually be a bit trickier than you imagine.  Consider the case of putting species into compartments.  Consider the following:
> 
> Parameters: n = 10, m = 20
> Compartments: C0, C1[n], C2[m], C3[n][m]
> Species: S[n][m]
> 
> The compartment reference for S[n][m] assuming "i" and "j" are the dimensions id's could be:
> 
> C0, C1[i], C2[i], C2[j], or C3[i][j]
> 
> It cannot be though:
> 
> C0[i] because C0 is scaler.
> C1[j] since the range of j is 0 to 20 while C1 has size 10.
> C1[i][j] and C2[i][j] because they each only have one dimension.
> C3[j][i] since the range of j is 0 to 20 while the first dimension only has size 10.
> 
> Now, that I think about it, I think this validation rule is actually covered by the one which states that the index must not go out-of-bounds.  As well as, the rule which states you should not index a dimension for an object that does not have that dimension.
> 
arrays-10208 says that the index math should evaluate to a non-negative integer and must be statically computable. I didn’t explicitly say you cannot go out-of-bounds for selector. Same thing for index. Also, regarding indexing a dimension for an object that does not have that dimension, maybe the confusion is that the rule says you need to reference a valid SIdRef, but I don’t say what is valid or not.

>> A couple of the examples in the specification (4.2/4.4) are invalid 
>> because they violate the SBML core rule that says you can only have one 
>> assignment to a particular variable and they would also violate the 
>> rules I suggest above.
>> 
>> Discussion about this situation agreed that if you wanted the math to do 
>> different things with different parts of an array you either used 
>> piecewise within the math OR you created two different arrays. So these 
>> examples need to be corrected.
>> 
> Agreed, these examples must be fixed.  
> 
> Thanks,
> 
> Chris
> 
Thanks,
Leandro

Re: [sbml-arrays] Updated specification

[Chris J. M. <my...@ec...>]

On Jun 17, 2014, at 2:23 AM, Sarah Keating <ske...@ca...> wrote:

> Hi Leandro
> 
> The validation rules look great :-)
> 
> I have two points:
> 
> 
> POINT 1.
> ========
> 
> This struck me as perhaps needing a little more clarification:
> 
> arrays-10206 The arguments of a MathML vector must all have the same 
> number of dimensions and agree in their size.
> 
> I think what you are talking about if you are creating a vector of 
> vectors they should be regular so
> 
> V = [ [1, 2, 3], [a, b, c]] is fine
> 
> but
> 
> V' = [[1,2], [a,b,c]] is not.
> 
> but that could do with slightly more elaboration.
> 
> And if that is not what it means it definitely needs clarifying :-)

This is indeed what was meant.  We will try to clarify this in the specification.  We tried to make sure all the validation rules were also described in the specification, but we may have missed some.  This is one, let us know if you find others.
> 
> POINT 2.
> =======
> 
>  I think there need to be validation rules explicitly stating that the 
> size of arrays of different constructs must match when things involve 
> interactions between elements. What I mean is
> 
> consider Example 1 in the spec that puts 100 species A, 100 species B 
> and 100 species C into 100 compartment cell and then defines 100 reactions
> 
> A + B -> C
> 
> Now in terms of the reaction - if it is has dimensions then the all the 
> species referred to must have the same dimensions. What if the reaction 
> had dimensions 200 ? or just 50 ? or if species A had dimensions 100 but 
> species B had only 50 ?
> 
> If you are going to put an array of species into an array of 
> compartments - these must match; although you could potentially put an 
> array of species into a single compartment :-)
> 
> Similarly with assignments 
> (initialAssignment/assignmentRule/rateRule/eventAssignment) they must 
> have the same dimensions as the dimensions of whatever is referenced by 
> the variable/symbol.
> 
You do raise an important issue, but I think these cases may actually be a bit trickier than you imagine.  Consider the case of putting species into compartments.  Consider the following:

Parameters: n = 10, m = 20
Compartments: C0, C1[n], C2[m], C3[n][m]
Species: S[n][m]

The compartment reference for S[n][m] assuming "i" and "j" are the dimensions id's could be:

C0, C1[i], C2[i], C2[j], or C3[i][j]

It cannot be though:

C0[i] because C0 is scaler.
C1[j] since the range of j is 0 to 20 while C1 has size 10.
C1[i][j] and C2[i][j] because they each only have one dimension.
C3[j][i] since the range of j is 0 to 20 while the first dimension only has size 10.

Now, that I think about it, I think this validation rule is actually covered by the one which states that the index must not go out-of-bounds.  As well as, the rule which states you should not index a dimension for an object that does not have that dimension.

> A couple of the examples in the specification (4.2/4.4) are invalid 
> because they violate the SBML core rule that says you can only have one 
> assignment to a particular variable and they would also violate the 
> rules I suggest above.
> 
> Discussion about this situation agreed that if you wanted the math to do 
> different things with different parts of an array you either used 
> piecewise within the math OR you created two different arrays. So these 
> examples need to be corrected.
> 
Agreed, these examples must be fixed.  

Thanks,

Chris

Re: [sbml-arrays] Updated specification

[Sarah K. <ske...@ca...>]

Hi Leandro

The validation rules look great :-)

I have two points:


POINT 1.
========

This struck me as perhaps needing a little more clarification:

arrays-10206 The arguments of a MathML vector must all have the same 
number of dimensions and agree in their size.

I think what you are talking about if you are creating a vector of 
vectors they should be regular so

V = [ [1, 2, 3], [a, b, c]] is fine

but

V' = [[1,2], [a,b,c]] is not.

but that could do with slightly more elaboration.

And if that is not what it means it definitely needs clarifying :-)

POINT 2.
=======

  I think there need to be validation rules explicitly stating that the 
size of arrays of different constructs must match when things involve 
interactions between elements. What I mean is

consider Example 1 in the spec that puts 100 species A, 100 species B 
and 100 species C into 100 compartment cell and then defines 100 reactions

A + B -> C

Now in terms of the reaction - if it is has dimensions then the all the 
species referred to must have the same dimensions. What if the reaction 
had dimensions 200 ? or just 50 ? or if species A had dimensions 100 but 
species B had only 50 ?

If you are going to put an array of species into an array of 
compartments - these must match; although you could potentially put an 
array of species into a single compartment :-)

Similarly with assignments 
(initialAssignment/assignmentRule/rateRule/eventAssignment) they must 
have the same dimensions as the dimensions of whatever is referenced by 
the variable/symbol.

A couple of the examples in the specification (4.2/4.4) are invalid 
because they violate the SBML core rule that says you can only have one 
assignment to a particular variable and they would also violate the 
rules I suggest above.

Discussion about this situation agreed that if you wanted the math to do 
different things with different parts of an array you either used 
piecewise within the math OR you created two different arrays. So these 
examples need to be corrected.

Sarah

[sbml-arrays] Updated specification

[Leandro W. <lea...@gm...>]

Hi,

I am working on the implementation of the arrays package for JSBML as part of my project for Google Summer of Code (GSoC). 
Currently, I am focusing on the validation for the arrays package.  I’ve updated the arrays specifications to include
a list of validation rules and the changes are checked in. I got really great feedback from Chris, Nico, and Sarah in our weekly GSoC meeting but feedback is always appreciated.

Thanks,
Leandro

[sbml-arrays] Updated specification

[Chris J. M. <my...@ec...>]

Hi,

I've updated the arrays specification to reflect the decisions made at HARMONY 2014.  The most significant decision was to focus on arrays rather than vectors and matrices.  In other words, this is an arrays package and not a linear algebra package.  Other changes include allowing 3-dimensional arrays and changing some of the element names.  Feedback as always is very appreciated.

These updates have been checked into the SVN repository.

Cheers,

Chris

Re: [sbml-arrays] Slides for Harmony

[Nicolas Le N. <n.l...@gm...>]

Yeah!

On 22/04/14 21:04, Chris J. Myers wrote:
> We decided today to allow 3d arrays.  There is still a bit of a question about whether it is okay to limit to 3d or allow arbitrary number of dimensions.  I would like to stick to 3d limit though if there is no compelling use case for more dimensions, at least initially.
>
> Chris
>
> On Apr 22, 2014, at 2:43 AM, Markus Owen <Mar...@no...> wrote:
>
>> Hi,
>> Sorry I've been rather absent from this discussion due to long-term illness - but I have been following at a distance. A discussion point raised in the slides is whether 2d is sufficient. I would say no, and 3d at least should be incorporated - or at least an outline or plan of how 2d could be extended. It is inevitable that users will want (need?) to be able to share models with 3d lattices. I do understand that it may be sensible to get 2d implemented first.
>> Best wishes,
>> Markus
>>
>> * Professor Markus Owen
>> * University of Nottingham
>> * https://www.maths.nottingham.ac.uk/personal/mro/
>>
>>> On 20 Apr 2014, at 23:54, "Chris J. Myers" <my...@ec...> wrote:
>>>
>>> Hi,
>>>
>>> Attached are the slides I plan to use to create discussion in the arrays session.  I plan to present just slides 2 and 3 in the update session.  Please let me know if there are any discussion items that I'm missing.
>>>
>>> Thanks,
>>>
>>> Chris
>>> <array.pdf>
>>> ------------------------------------------------------------------------------
>>> 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/NeoTech
>>> _______________________________________________
>>> sbml-arrays mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-arrays
>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an attachment
>> may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> _______________________________________________
>> sbml-arrays mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-arrays
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays
>


-- 
Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
Tel: +441223496433   Mob:+447833147074   n.l...@gm...
orcid.org//0000-0002-6309-7327  http://lenoverelab.org/perso/lenov/
Skype:n.lenovere  twitter:@lenovere  http://nlenov.wordpress.com/

Re: [sbml-arrays] Slides for Harmony

[Chris J. M. <my...@ec...>]

We decided today to allow 3d arrays.  There is still a bit of a question about whether it is okay to limit to 3d or allow arbitrary number of dimensions.  I would like to stick to 3d limit though if there is no compelling use case for more dimensions, at least initially.

Chris

On Apr 22, 2014, at 2:43 AM, Markus Owen <Mar...@no...> wrote:

> Hi,
> Sorry I've been rather absent from this discussion due to long-term illness - but I have been following at a distance. A discussion point raised in the slides is whether 2d is sufficient. I would say no, and 3d at least should be incorporated - or at least an outline or plan of how 2d could be extended. It is inevitable that users will want (need?) to be able to share models with 3d lattices. I do understand that it may be sensible to get 2d implemented first. 
> Best wishes,
> Markus
> 
> * Professor Markus Owen
> * University of Nottingham
> * https://www.maths.nottingham.ac.uk/personal/mro/
> 
>> On 20 Apr 2014, at 23:54, "Chris J. Myers" <my...@ec...> wrote:
>> 
>> Hi,
>> 
>> Attached are the slides I plan to use to create discussion in the arrays session.  I plan to present just slides 2 and 3 in the update session.  Please let me know if there are any discussion items that I'm missing.
>> 
>> Thanks,
>> 
>> Chris
>> <array.pdf>
>> ------------------------------------------------------------------------------
>> 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/NeoTech
>> _______________________________________________
>> sbml-arrays mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-arrays
> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.
> 
> This message has been checked for viruses but the contents of an attachment
> may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays

Re: [sbml-arrays] Slides for Harmony

[Markus O. <Mar...@no...>]

Hi,
Sorry I've been rather absent from this discussion due to long-term illness - but I have been following at a distance. A discussion point raised in the slides is whether 2d is sufficient. I would say no, and 3d at least should be incorporated - or at least an outline or plan of how 2d could be extended. It is inevitable that users will want (need?) to be able to share models with 3d lattices. I do understand that it may be sensible to get 2d implemented first. 
Best wishes,
Markus

* Professor Markus Owen
* University of Nottingham
* https://www.maths.nottingham.ac.uk/personal/mro/

> On 20 Apr 2014, at 23:54, "Chris J. Myers" <my...@ec...> wrote:
> 
> Hi,
> 
> Attached are the slides I plan to use to create discussion in the arrays session.  I plan to present just slides 2 and 3 in the update session.  Please let me know if there are any discussion items that I'm missing.
> 
> Thanks,
> 
> Chris
> <array.pdf>
> ------------------------------------------------------------------------------
> 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/NeoTech
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays
This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

[sbml-arrays] Slides for Harmony

[Chris J. M. <my...@ec...>]

Hi,

Attached are the slides I plan to use to create discussion in the arrays session.  I plan to present just slides 2 and 3 in the update session.  Please let me know if there are any discussion items that I'm missing.

Thanks,

Chris

Re: [sbml-arrays] Small update on spec

[Chris J. M. <my...@ec...>]

Hi Sarah,

Thanks for seeding the discussion, and we can certainly discuss more next week.  When do you arrive, by the way?  I arrive 11am on Monday to Manchester airport.
> 
> Have been trying to get to this :-)
> 
> I did some time ago say that I was not convinced by the names of some of 
> the attributes so I am putting my money where my mouth is and suggesting 
> alternatives. Then these are on the table for discussion at HARMONY.
> 
> 1. The Dimension attribute 'dim'
> 
> I can see why you used dim but usage of 'dim' is not consistent with 
> what you mean here. dim(A) is interpreted as 'how many dimensions does A 
> have'. Here we want to state the actual dimension value - so 'order or 
> cardinality of the dimension' but I also think order/cardinality is not 
> quite right either :-(
> 
> I'm stumped for the right name here - we need something which captures 
> 'which dimension is this'.
> 
> Would 'value' do it ?
> 
> So
> <dimension value="0"> is the 0th dimension
> <dimension value="1"> is the first dimension
> 
> etc
> 
> ??
> 
We have been using the term "Array Dimension" in the GUI.  It is a bit wordy, but could be an option.

> 2. The Index attribute 'dim'
> 
> Here I actually think this attribute should be named 'dimension' and be 
> an SIdRef to the Dimension it refers to. This would eliminate potential 
> errors with which dimension the index is referring to.
> 
It cannot be an SiDRef to Dimension.  You actually have fallen into the same trap that we did :-).  You do not need to have a dimension to have an index.  You could, for example, have a rule of the form:

X[2,3] = 5

The rule does not have dimensions, but it does have two indices.  The index refers to the SiDRef in an SBML element NOT the SBML element itself.  Therefore, the above is complied to:

<assignmentRule variable="X">
<arrays:listOfIndices>
	<arrays:index attribute="variable" dim="0">
	<math>
		<cn>2</cn>
	</math>
	<arrays:index attribute="variable" dim="1">
	<math>
		<cn>3</cn>
	</math>
</arrays:listOfIndices>
<math>
	<cn>5</cn>
</math>
</assignmentRule>

We could also call this one "arrayDimension".

> 3. The Index attribute 'attribute'
> 
> I think an attribute named attribute may cause confusion - it could even 
> cause confusion when talking about it. You have to say 'the attribute 
> named attribute' just to be completely sure which attribute you are 
> talking about.
> 
> I suggest this should be 'referencedAttribute' since the value is the 
> name of the attribute that is being referenced by the Index.
> 
Sounds good to me.

Chris

Re: [sbml-arrays] Small update on spec

[Sarah K. <ske...@ca...>]

Hi Chris

Have been trying to get to this :-)

I did some time ago say that I was not convinced by the names of some of 
the attributes so I am putting my money where my mouth is and suggesting 
alternatives. Then these are on the table for discussion at HARMONY.

1. The Dimension attribute 'dim'

I can see why you used dim but usage of 'dim' is not consistent with 
what you mean here. dim(A) is interpreted as 'how many dimensions does A 
have'. Here we want to state the actual dimension value - so 'order or 
cardinality of the dimension' but I also think order/cardinality is not 
quite right either :-(

I'm stumped for the right name here - we need something which captures 
'which dimension is this'.

Would 'value' do it ?

So
<dimension value="0"> is the 0th dimension
<dimension value="1"> is the first dimension

etc

??

2. The Index attribute 'dim'

Here I actually think this attribute should be named 'dimension' and be 
an SIdRef to the Dimension it refers to. This would eliminate potential 
errors with which dimension the index is referring to.

3. The Index attribute 'attribute'

I think an attribute named attribute may cause confusion - it could even 
cause confusion when talking about it. You have to say 'the attribute 
named attribute' just to be completely sure which attribute you are 
talking about.

I suggest this should be 'referencedAttribute' since the value is the 
name of the attribute that is being referenced by the Index.


Sarah

[sbml-arrays] Special HARMONY release of libSBML

[Sarah K. <ske...@ca...>]

               Special HARMONY release of libSBML

Available from https://www.dropbox.com/sh/wdq771dtdbdfq8l/OFKQ5DSvki

The facility to parse the additional MathML included by the 'arrays'
package to and from infix notation was not sufficiently well tested
to be included in the latest libSBML release (libSBML-5.10.0).

In order to provide this functionality to developers at HARMONY we
have created an archive and a number of binaries that do include
this functionality. Note these files have a version number of 5.10.1
as they reflect the current libSBML svn status from the branch
https://svn.code.sf.net/p/sbml/code/branches/libsbml-ast-infix.


NOTE: The ONLY difference between these files and those of libSBML-5.10.0
is that the SBML_parseL3Formula and SBML_formulaToL3String functions
will deal with MathML from the arrays proposal that is currently available
at http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/Arrays_
and_Sets_%28arrays%29 in a manner as discussed on the arrays list. If
you do not need this functionality then please use the official release
available from:
https://sourceforge.net/projects/sbml/files/libsbml/5.10.0/


If there are any binaries you desperately require that we have not
provided please ask either Frank Bergmann or Sarah Keating who will
both be present at HARMONY.

Thanks

The LibSBML Team

Re: [sbml-arrays] Infix syntax for arrays

[Chris J. M. <my...@ec...>]

Cool.  Something we should discuss next Tuesday.

Chris

Sent from my iPhone

On Apr 15, 2014, at 2:25 PM, Lucian Smith <luc...@gm...> wrote:

> OK, the 'libsbml-ast-infix' branch of SVN now doesn't try to do anything tricky and convert things like "A[x, y, z, p, d]" to "A[x][y][z][p][d]"; instead, it just parses it as a selector with too many arguments, and returns an error.  Similarly, "A[x, y]" roundtrips as "A[x, y]", and can only be used for matrices (not vectors of vectors), exactly like the underlying MathML.
> 
> At this point, I can say that at least on the ASTNode side of things, libsbml is ready to support multi-dimensional arrays, if you decide that you do indeed want to handle 3D or higher arrays in the rest of the spec.
> 
> -Lucian
> 
> 
> On Tue, Apr 8, 2014 at 7:34 AM, Chris J. Myers <my...@ec...> wrote:
>> Seems a reasonable point to me.  I was not keen on allowing A[i,j] as well as A[i][j], but assuming we do, it does seem like it would be nice to get that back when you parse as well.  I always found it a bit odd when you have aliases for things because you don't get back what you typed in.
>> 
>> Chris
>> 
>> On Apr 8, 2014, at 1:23 AM, Sarah Keating <ske...@ca...> wrote:
>> 
>> >
>> >>> I would be okay if:
>> >>>
>> >>> A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to selector(A,i,j).
>> >>>
>> >>> However, if we make that change, then I would prefer that A[i,j,k] is illegal.  Instead, you must either do:
>> >>>
>> >>> A[i][j][k] OR A[i,j][k] OR A[i][j,k]
>> >
>> > I agree.
>> >
>> > My point was really not to do with creating invalid (or indeed ambiguous
>> > stuff) but was focussed on the point that one of the thinks the new
>> > parser allowed (which was a good beneficial thing) was for the user to
>> > get what they put in rather than a libsbml imposed version of what they
>> > entered.
>> >
>> > It just seemed to me that by saying that A[i,j] would become a nested
>> > selector equivalent to A[i][j] we were going back on this principle :-)
>> >
>> > Sarah
>> >
>> > ------------------------------------------------------------------------------
>> > Put Bad Developers to Shame
>> > Dominate Development with Jenkins Continuous Integration
>> > Continuously Automate Build, Test & Deployment
>> > Start a new project now. Try Jenkins in the cloud.
>> > http://p.sf.net/sfu/13600_Cloudbees
>> > _______________________________________________
>> > sbml-arrays mailing list
>> > sbm...@li...
>> > https://lists.sourceforge.net/lists/listinfo/sbml-arrays
>> 
>> 
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> sbml-arrays mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-arrays
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays

Re: [sbml-arrays] Infix syntax for arrays

[Lucian S. <luc...@gm...>]

OK, the 'libsbml-ast-infix' branch of SVN now doesn't try to do anything
tricky and convert things like "A[x, y, z, p, d]" to "A[x][y][z][p][d]";
instead, it just parses it as a selector with too many arguments, and
returns an error.  Similarly, "A[x, y]" roundtrips as "A[x, y]", and can
only be used for matrices (not vectors of vectors), exactly like the
underlying MathML.

At this point, I can say that at least on the ASTNode side of things,
libsbml is ready to support multi-dimensional arrays, if you decide that
you do indeed want to handle 3D or higher arrays in the rest of the spec.

-Lucian


On Tue, Apr 8, 2014 at 7:34 AM, Chris J. Myers <my...@ec...> wrote:

> Seems a reasonable point to me.  I was not keen on allowing A[i,j] as well
> as A[i][j], but assuming we do, it does seem like it would be nice to get
> that back when you parse as well.  I always found it a bit odd when you
> have aliases for things because you don't get back what you typed in.
>
> Chris
>
> On Apr 8, 2014, at 1:23 AM, Sarah Keating <ske...@ca...> wrote:
>
> >
> >>> I would be okay if:
> >>>
> >>> A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to
> selector(A,i,j).
> >>>
> >>> However, if we make that change, then I would prefer that A[i,j,k] is
> illegal.  Instead, you must either do:
> >>>
> >>> A[i][j][k] OR A[i,j][k] OR A[i][j,k]
> >
> > I agree.
> >
> > My point was really not to do with creating invalid (or indeed ambiguous
> > stuff) but was focussed on the point that one of the thinks the new
> > parser allowed (which was a good beneficial thing) was for the user to
> > get what they put in rather than a libsbml imposed version of what they
> > entered.
> >
> > It just seemed to me that by saying that A[i,j] would become a nested
> > selector equivalent to A[i][j] we were going back on this principle :-)
> >
> > Sarah
> >
> >
> ------------------------------------------------------------------------------
> > Put Bad Developers to Shame
> > Dominate Development with Jenkins Continuous Integration
> > Continuously Automate Build, Test & Deployment
> > Start a new project now. Try Jenkins in the cloud.
> > http://p.sf.net/sfu/13600_Cloudbees
> > _______________________________________________
> > sbml-arrays mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbml-arrays
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays
>

[sbml-arrays] Small update on spec

[Chris J. M. <my...@ec...>]

Hi,

I just realized that we forgot to include compartment on reaction as an item which needs an index.  I've added that to the list.

I've also removed "bvar" from the mathML subset because it is already in L3V1.  I also removed "interval" based on recent discussion (on another list) which made it clear that it was not needed for arrays.  I've left in lowlimit, uplimit, condition, sum, and product for now as they are not in L3V1 though they may be in L3V2, so may be removed in the future.

Hope to start adding some validation rules to the document soon.  All changes are in SVN.  Feedback is always appreciated.

Cheers,

Chris

Re: [sbml-arrays] Infix syntax for arrays

[Chris J. M. <my...@ec...>]

Seems a reasonable point to me.  I was not keen on allowing A[i,j] as well as A[i][j], but assuming we do, it does seem like it would be nice to get that back when you parse as well.  I always found it a bit odd when you have aliases for things because you don't get back what you typed in.

Chris

On Apr 8, 2014, at 1:23 AM, Sarah Keating <ske...@ca...> wrote:

> 
>>> I would be okay if:
>>> 
>>> A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to selector(A,i,j).
>>> 
>>> However, if we make that change, then I would prefer that A[i,j,k] is illegal.  Instead, you must either do:
>>> 
>>> A[i][j][k] OR A[i,j][k] OR A[i][j,k]
> 
> I agree.
> 
> My point was really not to do with creating invalid (or indeed ambiguous 
> stuff) but was focussed on the point that one of the thinks the new 
> parser allowed (which was a good beneficial thing) was for the user to 
> get what they put in rather than a libsbml imposed version of what they 
> entered.
> 
> It just seemed to me that by saying that A[i,j] would become a nested 
> selector equivalent to A[i][j] we were going back on this principle :-)
> 
> Sarah
> 
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment 
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays

Re: [sbml-arrays] Infix syntax for arrays

[Sarah K. <ske...@ca...>]

>> I would be okay if:
>>
>> A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to selector(A,i,j).
>>
>> However, if we make that change, then I would prefer that A[i,j,k] is illegal.  Instead, you must either do:
>>
>> A[i][j][k] OR A[i,j][k] OR A[i][j,k]

I agree.

My point was really not to do with creating invalid (or indeed ambiguous 
stuff) but was focussed on the point that one of the thinks the new 
parser allowed (which was a good beneficial thing) was for the user to 
get what they put in rather than a libsbml imposed version of what they 
entered.

It just seemed to me that by saying that A[i,j] would become a nested 
selector equivalent to A[i][j] we were going back on this principle :-)

Sarah

Re: [sbml-arrays] Infix syntax for arrays

[Lucian S. <lp...@uw...>]

On Mon, Apr 07, 2014 at 12:24:46PM -0600, Chris J. Myers wrote:
> I did not realize that we will also support "selector", but it makes sense and as you say gives the flexibility that Sarah desires.  I assume that it can have two or three arguments, but not more, right?

Correct.  Actually, it can also have just one argument (the 
vector/matrix itself), which as far as I can tell means 'select this 
vector' and returns that vector.  So, not very useful, but technically 
valid MathML.  But I went ahead and made 'selector' with 0 or 4+ 
arguments illegal.

> I would be okay if:
> 
> A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to selector(A,i,j).
> 
> However, if we make that change, then I would prefer that A[i,j,k] is illegal.  Instead, you must either do:
> 
> A[i][j][k] OR A[i,j][k] OR A[i][j,k]

Yeah, I agree.  All these changes are relatively trivial to make in the 
code, so whatever people want, we can give them.  Perhaps an informal 
survey at HARMONY would work?

> to make it explicit how to compile it into selectors.
> 
> I'm curious though if we see there being any actual performance difference of selector(selector(A,i)) and selector(A,i,j).

That would be implementation-dependent, one presumes.  And it seems like 
it would be relatively straightforward to convert from one to the other 
if it turned out to be a serious slowdown in someone's code.

-Lucian

Re: [sbml-arrays] Infix syntax for arrays

[Chris J. M. <my...@ec...>]

I did not realize that we will also support "selector", but it makes sense and as you say gives the flexibility that Sarah desires.  I assume that it can have two or three arguments, but not more, right?

I would be okay if:

A[i][j] compiles to selector(selector(A,i),j) and A[i,j] compiles to selector(A,i,j).

However, if we make that change, then I would prefer that A[i,j,k] is illegal.  Instead, you must either do:

A[i][j][k] OR A[i,j][k] OR A[i][j,k]

to make it explicit how to compile it into selectors.

I'm curious though if we see there being any actual performance difference of selector(selector(A,i)) and selector(A,i,j).

Chris

On Apr 7, 2014, at 9:19 AM, Lucian Smith <lp...@uw...> wrote:

> On Mon, Apr 07, 2014 at 02:16:04PM +0100, Sarah Keating wrote:
>> 
>>> Selectors:
>>>   * Accepted input syntax:  both A[x][y] and A[x, y] mean the same thing.
>>>   * Standard output syntax:  A[x][y]
>>>   * 'A' doesn't have to only be a string; it can be anything:
>>>  "transpose(A)[x, y]" works fine.
>>>   * The produced MathML always created nested selectors, and never uses
>>> the special matrix syntax with two arguments.  This lets 'A' be either a
>>> vector of vectors or a matrix, and the user doesn't need to know the
>>> difference.
>> 
>> The last point about nested selectors worries me slightly.
>> 
>> One of the main benefits of the new parser was that if you used
>> 
>> (a + b) + c
>> 
>> you got different ASTNode structure than if you wrote
>> 
>> a + b + c
>> 
>> i.e. the user was choosing to nest in the first instance and choosing 
>> not to in the second instance.
>> 
>> But you are now saying that
>> 
>> selector(A, i, j)
>> 
>> would produce a nested AST which would basically be the same as if the 
>> user put
>> 
>> selector(selector(A,i), j)
>> 
>> But the user may want the first (un-nested form).
>> 
>> It just seems that this is counter-intuitive to the first example ...
> 
> Actually, if you use 'selector', you get what you input exactly.  If you 
> input "seletor(A, i, j)", you get a single selector that only works for 
> a matrix.  It's only the '[]' syntax that combines the two:
> 
> A[i][j]
> 
> is the same as:
> 
> A[i, j]
> 
> and does the 'nested selector' thing.
> 
> I did that so that whether A is implemented as a vector of vectors or as 
> a matrix, the produced 'selector' mathML will always work.  It also 
> means that:
> 
> A[i][j][k]
> 
> is the same as:
> 
> A[i, j, k]
> 
> meaning it will work for any form of 3-d arrays.
> 
> However, this can be revisited!  If we decide it's more important to 
> preserve user intent, we can make:
> 
> A[i][j]
> 
> nested selectors, and
> 
> A[i, j]
> 
> the matrix selector.
> 
> -Lucian
> 
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment 
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays

Re: [sbml-arrays] Infix syntax for arrays

[Lucian S. <lp...@uw...>]

On Mon, Apr 07, 2014 at 02:16:04PM +0100, Sarah Keating wrote:
> 
> > Selectors:
> >    * Accepted input syntax:  both A[x][y] and A[x, y] mean the same thing.
> >    * Standard output syntax:  A[x][y]
> >    * 'A' doesn't have to only be a string; it can be anything:
> >   "transpose(A)[x, y]" works fine.
> >    * The produced MathML always created nested selectors, and never uses
> > the special matrix syntax with two arguments.  This lets 'A' be either a
> > vector of vectors or a matrix, and the user doesn't need to know the
> > difference.
> 
> The last point about nested selectors worries me slightly.
> 
> One of the main benefits of the new parser was that if you used
> 
> (a + b) + c
> 
> you got different ASTNode structure than if you wrote
> 
> a + b + c
> 
> i.e. the user was choosing to nest in the first instance and choosing 
> not to in the second instance.
> 
> But you are now saying that
> 
> selector(A, i, j)
> 
> would produce a nested AST which would basically be the same as if the 
> user put
> 
> selector(selector(A,i), j)
> 
> But the user may want the first (un-nested form).
> 
> It just seems that this is counter-intuitive to the first example ...

Actually, if you use 'selector', you get what you input exactly.  If you 
input "seletor(A, i, j)", you get a single selector that only works for 
a matrix.  It's only the '[]' syntax that combines the two:

A[i][j]

is the same as:

A[i, j]

and does the 'nested selector' thing.

I did that so that whether A is implemented as a vector of vectors or as 
a matrix, the produced 'selector' mathML will always work.  It also 
means that:

A[i][j][k]

is the same as:

A[i, j, k]

meaning it will work for any form of 3-d arrays.

However, this can be revisited!  If we decide it's more important to 
preserve user intent, we can make:

A[i][j]

nested selectors, and

A[i, j]

the matrix selector.

-Lucian

Re: [sbml-arrays] Infix syntax for arrays

[Sarah K. <ske...@ca...>]

> Selectors:
>    * Accepted input syntax:  both A[x][y] and A[x, y] mean the same thing.
>    * Standard output syntax:  A[x][y]
>    * 'A' doesn't have to only be a string; it can be anything:
>   "transpose(A)[x, y]" works fine.
>    * The produced MathML always created nested selectors, and never uses
> the special matrix syntax with two arguments.  This lets 'A' be either a
> vector of vectors or a matrix, and the user doesn't need to know the
> difference.

The last point about nested selectors worries me slightly.

One of the main benefits of the new parser was that if you used

(a + b) + c

you got different ASTNode structure than if you wrote

a + b + c

i.e. the user was choosing to nest in the first instance and choosing 
not to in the second instance.

But you are now saying that

selector(A, i, j)

would produce a nested AST which would basically be the same as if the 
user put

selector(selector(A,i), j)

But the user may want the first (un-nested form).

It just seems that this is counter-intuitive to the first example ...

Sarah

Re: [sbml-arrays] Infix syntax for arrays

[Michael H. <mh...@ca...>]

Hi Lucian,

This is an impressive bit of work :-).  Bravo.

MH

On Tue, 1 Apr 2014 13:38:53 -0700, Lucian Smith wrote:
> OK, in a branch of libsbml, I now have roundtripping of mostly-C/Java infix
> to and from ASTNodes and MathML.  Special thanks to Sarah for getting all
> the basics set up, and all the ASTNode/MathML translations in.
> 
> Here's what I went with:
> 
> Selectors:
>   * Accepted input syntax:  both A[x][y] and A[x, y] mean the same thing.
>   * Standard output syntax:  A[x][y]
>   * 'A' doesn't have to only be a string; it can be anything:
>  "transpose(A)[x, y]" works fine.
>   * The produced MathML always created nested selectors, and never uses the
> special matrix syntax with two arguments.  This lets 'A' be either a vector
> of vectors or a matrix, and the user doesn't need to know the difference.
> 
> Vectors:
>   * Curly braces with commas:  {a, b, c}; vectors of vectors as {{a, b, c},
> {d, e, f}, {g, h, i}}  (both input and output)
> 
> Matrices:
>   * Curly braces with commas and semicolons:  {a, b, c; d, e, f; g, h, i}
> (both input and output).
> 
> Note that this means you can create 3D elements unambiguously however you
> want:
> {{{a, b}, {c, d}}, {{e, f}, {g, h}}} <--vector of vector of vectors
> {{a, b; c, d}, {e, f; g, h}} <--vector of matrices
> {{a, b}, {c, d}; {e, f}, {g, h}} <--matrix of vectors
> 
> These will all produce different MathML structures, but should otherwise be
> treated the same within the other SBML constructs.
> 
> There is no problem from the infix side to produce vectors and/or matrices
> of arbitrary dimensions; the Arrays package itself will have to decide what
> specifically is allowed.  Personally, I would advocate starting off
> allowing anything, and then pulling back before finalization of the spec if
> all the implementations were restricted in some way, but that's just a
> suggestion.
> 
> For the other arrays functions (as they were defined in the previous
> version of the spec, which Sarah used to create all the back-end things),
> we have:
> 
> * determinant, det
> * transpose, trans
> * vectorproduct, vectorProd, cross
> * scalarproduct, scalarProd, dot
> * outerproduct, outerProd, outer
> 
> with all options accepted as infix input, and the first of each line being
> produced for infix output (since this matches the MathML exactly).
> 
> Because making this work involved changes to core libsbml, this makes it
> different from what we promised would be in the 'experimental' branch, and
> therefore won't be in the next experimental release.  However, a special
> 'arrays' version of the code will be available for HARMONY, and if anyone
> wants to experiment with it before then, you can check it out from SVN
> directly from branches/libsbml-ast-infix, or you can request a bundle for
> your system, and we'll see what we can do.
> 
> Thank you!  And if anyone has any further suggestions, please don't
> hesitate to make them!
> 
> -Lucian
> ------------------------------------------------------------------------------
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays