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

[sbml-arrays] Vector and matrix constructors

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

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

Re: [sbml-arrays] Extending the mathML subset

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

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 ;-)

Can I assume that when you talk about implementation you are referring 
to the infix-MathML-infix functionality ?

Sarah

Re: [sbml-arrays] Extending the mathML subset

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

I was not trying to "cop out".  I was trying to be flexible.  I know perhaps it is rare for me :-).

I'm fine with implicit as I actually thought that was what it always done.  I did not know that ci terms could have types.  My point was that if you felt it was better to be explicit, I would be okay with that too as long as you and Nico implemented it in the same way.

Sorry for the confusion.

Chris

On Jan 21, 2014, at 9:16 AM, Nicolas Rodriguez <rod...@eb...> wrote:

> On 01/21/2014 04:06 PM, Sarah Keating wrote:
>> On 21/01/2014 14:46, Chris J. Myers wrote:
>>> I honestly did not think of this one, so I guess that means I meant for the type to be implicit.  I don't have a strong feeling about this as long as libsbml and JSBML agree on what they do with it.
>> But it does need to be solved.
>> 
>> It is a bit of a cop out to say it doesn't matter so long as libSBML and
>> JSBML do the same thing (which since neither actually does anything
>> mathematical is irrelevant.)  The specification needs to make it clear
>> to anyone developing support for the package - whether they use
>> libsbml/jsbml or something else.
>> 
>> If arrays is going to use selector/transpose etc in a slightly different
>> fashion to their definition in MathML then the arrays specification
>> needs to detail this.
> 
> I agree that the specs should be clear about the interpretation of the 
> math, in particular, in case where
> they are differences from standard mathML.
> 
>> 
>> Sorry not meaning to be blunt or denigrate the effort Chris has put into
>> arrays so far :-) It was just having got to the point of implementing
>> support for this - I hit a wall with not really knowing what I should be
>> implementing.
>> 
>> I can go with "it is implicit" :-)
> 
> I am fine as well with the type attribute being implicit.
> 
> Thanks,
> Nico
> 
> 
> ------------------------------------------------------------------------------
> 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

Re: [sbml-arrays] Extending the mathML subset

[Nicolas R. <rod...@eb...>]

On 01/21/2014 04:06 PM, Sarah Keating wrote:
> On 21/01/2014 14:46, Chris J. Myers wrote:
>> I honestly did not think of this one, so I guess that means I meant for the type to be implicit.  I don't have a strong feeling about this as long as libsbml and JSBML agree on what they do with it.
> But it does need to be solved.
>
> It is a bit of a cop out to say it doesn't matter so long as libSBML and
> JSBML do the same thing (which since neither actually does anything
> mathematical is irrelevant.)  The specification needs to make it clear
> to anyone developing support for the package - whether they use
> libsbml/jsbml or something else.
>
> If arrays is going to use selector/transpose etc in a slightly different
> fashion to their definition in MathML then the arrays specification
> needs to detail this.

I agree that the specs should be clear about the interpretation of the 
math, in particular, in case where
they are differences from standard mathML.

>
> Sorry not meaning to be blunt or denigrate the effort Chris has put into
> arrays so far :-) It was just having got to the point of implementing
> support for this - I hit a wall with not really knowing what I should be
> implementing.
>
> I can go with "it is implicit" :-)

I am fine as well with the type attribute being implicit.

Thanks,
Nico

Re: [sbml-arrays] Extending the mathML subset

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

On 21/01/2014 14:46, Chris J. Myers wrote:
> I honestly did not think of this one, so I guess that means I meant for the type to be implicit.  I don't have a strong feeling about this as long as libsbml and JSBML agree on what they do with it.

But it does need to be solved.

It is a bit of a cop out to say it doesn't matter so long as libSBML and 
JSBML do the same thing (which since neither actually does anything 
mathematical is irrelevant.)  The specification needs to make it clear 
to anyone developing support for the package - whether they use 
libsbml/jsbml or something else.

If arrays is going to use selector/transpose etc in a slightly different 
fashion to their definition in MathML then the arrays specification 
needs to detail this.

Sorry not meaning to be blunt or denigrate the effort Chris has put into 
arrays so far :-) It was just having got to the point of implementing 
support for this - I hit a wall with not really knowing what I should be 
implementing.

I can go with "it is implicit" :-)

Sarah

Re: [sbml-arrays] Extending the mathML subset

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

I honestly did not think of this one, so I guess that means I meant for the type to be implicit.  I don't have a strong feeling about this as long as libsbml and JSBML agree on what they do with it.

Thanks,

Chris

On Jan 21, 2014, at 4:25 AM, Sarah Keating <ske...@ca...> wrote:

>> SBML would use muti-dimensional arrays.
> 
> Well at the moment the arrays proposal is limiting itself to 2 
> dimensions :-)
> 
> My issue is that the proposal does not make mention of introducing the 
> 'vector' or 'matrix' type attribute on the ci element. And indeed I 
> agree with Nicolas that for SBML purposes it is not necessary - the type 
> of the ci element is implicit in the fact that SBML has defined whatever 
> the id points to as an array.
> 
> My query really arises from the point of view of someone using a mathML 
> parser that is independent of the SBML parser - without the attribute 
> and without knowing that the id referenced is an SBML array it is 
> unclear what the result of the selection should be.
> 
> So do we need to introduce the type attribute OR are we assuming an 
> implicit type based on the SBML listOfDimensions and that developers 
> will cope with the MathML anomaly.
> 
> Sarah
> 
> PS Are we envisioning that ultimately with multidimensional arrays we 
> would corrupt the selector function to allow as many index arguments as 
> are necessary ?
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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

Re: [sbml-arrays] Extending the mathML subset

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

On 21/01/14 11:25, Sarah Keating wrote:

> PS Are we envisioning that ultimately with multidimensional arrays we
> would corrupt the selector function to allow as many index arguments as
> are necessary ?

I very much hope so. And I dream of a world where we would thus address directly cells of a NuML dataset :-)


-- 
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] Extending the mathML subset

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

> SBML would use muti-dimensional arrays.

Well at the moment the arrays proposal is limiting itself to 2 
dimensions :-)

My issue is that the proposal does not make mention of introducing the 
'vector' or 'matrix' type attribute on the ci element. And indeed I 
agree with Nicolas that for SBML purposes it is not necessary - the type 
of the ci element is implicit in the fact that SBML has defined whatever 
the id points to as an array.

My query really arises from the point of view of someone using a mathML 
parser that is independent of the SBML parser - without the attribute 
and without knowing that the id referenced is an SBML array it is 
unclear what the result of the selection should be.

So do we need to introduce the type attribute OR are we assuming an 
implicit type based on the SBML listOfDimensions and that developers 
will cope with the MathML anomaly.

Sarah

PS Are we envisioning that ultimately with multidimensional arrays we 
would corrupt the selector function to allow as many index arguments as 
are necessary ?

Re: [sbml-arrays] Extending the mathML subset

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

IMHO, this is attribute is meaningless for SBML. It is used in MathML to decide how many arguments you need to read afterwards. But it can be only 1 (vector) or 2 (matrix), because MathML is not a language to manipulate mathematics but to represent mathematics. Therefore, when there are more than 2 dimensions, MathML nest them.

SBML would use muti-dimensional arrays. The only thing an expression needs to know is that something is an array. It is up to the software writing the expression to make sure that the number of indices correspond to what we want to select in a given context.


On 21/01/14 10:43, Nicolas Rodriguez wrote:
> On 01/21/2014 10:16 AM, Sarah Keating wrote:
>> Hi Chris
>>
>> So the MathML definition of selector specifically states that it expects
>> the first argument to be of type vector or matrix (or list - which is
>> not relevant here)
>>
>> So an example using selector would be
>>
>> <apply>
>>      <selector/>
>>      <ci type="matrix"> A </ci>
>>      <cn> 3 </cn>
>>      <cn> 2 </cn>
>> </apply>
>>
>> http://www.w3.org/TR/2002/WD-MathML2-20021219/chapter4.html#contm.selector
>>
>> Now I can see that in the arrays proposal the type of the ci element is
>> implicit in the sense that it is an SBML element with a listOfDimensions
>> that will tell a reader whether A should be considered a vector or a matrix.
>>
>> Similarly if using an vector/matrix constructor with a assignment math
>> of some sort. The target of the assignment is implicitly a vector/matrix.
>>
>> Is this implicit "type" what you were thinking ?
>
> Are you asking to have the attribute 'type' set correctly to matrix,
> vector or double in the mathml ??
> Or if we want to let it undefined ?
>
> Nico
>
>
> ------------------------------------------------------------------------------
> 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
>


-- 
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] Extending the mathML subset

[Nicolas R. <rod...@eb...>]

On 01/21/2014 10:16 AM, Sarah Keating wrote:
> Hi Chris
>
> So the MathML definition of selector specifically states that it expects
> the first argument to be of type vector or matrix (or list - which is
> not relevant here)
>
> So an example using selector would be
>
> <apply>
>     <selector/>
>     <ci type="matrix"> A </ci>
>     <cn> 3 </cn>
>     <cn> 2 </cn>
> </apply>
>
> http://www.w3.org/TR/2002/WD-MathML2-20021219/chapter4.html#contm.selector
>
> Now I can see that in the arrays proposal the type of the ci element is
> implicit in the sense that it is an SBML element with a listOfDimensions
> that will tell a reader whether A should be considered a vector or a matrix.
>
> Similarly if using an vector/matrix constructor with a assignment math
> of some sort. The target of the assignment is implicitly a vector/matrix.
>
> Is this implicit "type" what you were thinking ?

Are you asking to have the attribute 'type' set correctly to matrix, 
vector or double in the mathml ??
Or if we want to let it undefined ?

Nico

Re: [sbml-arrays] Extending the mathML subset

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

Hi Chris

So the MathML definition of selector specifically states that it expects 
the first argument to be of type vector or matrix (or list - which is 
not relevant here)

So an example using selector would be

<apply>
   <selector/>
   <ci type="matrix"> A </ci>
   <cn> 3 </cn>
   <cn> 2 </cn>
</apply>

http://www.w3.org/TR/2002/WD-MathML2-20021219/chapter4.html#contm.selector

Now I can see that in the arrays proposal the type of the ci element is 
implicit in the sense that it is an SBML element with a listOfDimensions 
that will tell a reader whether A should be considered a vector or a matrix.

Similarly if using an vector/matrix constructor with a assignment math 
of some sort. The target of the assignment is implicitly a vector/matrix.

Is this implicit "type" what you were thinking ?

Sarah

Re: [sbml-arrays] Extending the mathML subset

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

Hi Sarah,

Could you perhaps give an example of what you think the proper mathML would look like?  When I drafted the proposal, I was not aware of the issues you have raised.  I was simply trying to make as few changes to mathML as possible to make it work for arrays.  However, I certainly would prefer to do it in the proper way, if possible.  

Thanks,

Chris

On Jan 20, 2014, at 7:24 AM, Sarah Keating <ske...@ca...> wrote:

> Hi
> 
> So I am actually looking at this specifically (as opposed to generically 
> making libsbml math extendible!) and now I have more questions:
> 
> So as it stands SBML will declare an array of objects of the same type 
> which can be 1 or 2 dimensional. Numeric values associated with objects 
> in such an array are on a "per object" basis.
> 
> With respect to the operators that the proposal suggests we add to 
> MathML (selector/determinant/etc.) - these are operators that in true 
> MathML would expect to have arguments that were of type vector/matrix(or 
> indeed list in some cases). But we are not introducing the type 'vector' 
> and 'matrix' to our ci element. We are allowing the argument to be a ci 
> element that references an SBML object that has a listOfDimensions.
> 
> Also the proposal suggests we add constructors for vectors/matrices that 
> would allow numerical values to be assigned to each object in the SBML 
> array using these constructs. Although technically we are not assigning 
> values to a vector or matrix.
> 
> Now I get it - I have been through the proposal a million times (!) - 
> but if we do this we are heavily bastardising the use of MathML. This 
> worries me from the point of view of developers who may use off the 
> shelf or their own mathML parsers.
> 
> Thoughts ??
> 
> 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

[sbml-arrays] Extending the mathML subset

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

Hi

So I am actually looking at this specifically (as opposed to generically 
making libsbml math extendible!) and now I have more questions:

So as it stands SBML will declare an array of objects of the same type 
which can be 1 or 2 dimensional. Numeric values associated with objects 
in such an array are on a "per object" basis.

With respect to the operators that the proposal suggests we add to 
MathML (selector/determinant/etc.) - these are operators that in true 
MathML would expect to have arguments that were of type vector/matrix(or 
indeed list in some cases). But we are not introducing the type 'vector' 
and 'matrix' to our ci element. We are allowing the argument to be a ci 
element that references an SBML object that has a listOfDimensions.

Also the proposal suggests we add constructors for vectors/matrices that 
would allow numerical values to be assigned to each object in the SBML 
array using these constructs. Although technically we are not assigning 
values to a vector or matrix.

Now I get it - I have been through the proposal a million times (!) - 
but if we do this we are heavily bastardising the use of MathML. This 
worries me from the point of view of developers who may use off the 
shelf or their own mathML parsers.

Thoughts ??

Sarah

Re: [sbml-arrays] Question about the index

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

I think you are right.  We should not use selector in the index math unless, of course, you are doing something like:

x[y[i]] 

:-)

I will correct it as you suggest.  Nice catch thanks.

Chris

On Jan 8, 2014, at 8:24 AM, Sarah Keating <ske...@ca...> wrote:

> 
> An index declares which SIdRef it is related to but in all the examples 
> given (and I followed this too)  the math of the index object uses the 
> selector function with the SIdRef as the argument. But surely it cannot 
> actually be selecting from anything else and it is in fact unnecessary 
> for the math of the index to return the selected element of the array - 
> it should in fact just return the index (i.e. the integer value of the 
> index into the array of whatever the SIdRef is).
> 
> So in the reverse assign value of an array example
> 
> x and y are arrays with size n=10
> 
> <assignmentRule variable="y">
> <arrays:listOfDimensions>
>     <arrays:dimension arrays:size="n" arrays:dim="0" 
> arrays:id="i"/>
> </arrays:listOfDimensions>    <arrays:listOfIndices>
>     <arrays:index arrays:dim="0" arrays:attribute="y">
>          <math xmlns="http://www.w3.org/1998/Math/MathML">
>               <apply><minus/><cn>9</cn><ci>i</ci></apply>
>          </math>
>     </arrays:index>
> </arrays:listOfIndices>
> 
> the above is saying
> 
> for i = 0 to 9
> y[9-i] = whatever
> 
> I have to say I found the fact that index does not return an index quite 
> confusing when trying to get my head round the different semantics of 
> the use on an element with no math and the use when there is math :-(
> 
> Sarah
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays

[sbml-arrays] Question about the index

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

An index declares which SIdRef it is related to but in all the examples 
given (and I followed this too)  the math of the index object uses the 
selector function with the SIdRef as the argument. But surely it cannot 
actually be selecting from anything else and it is in fact unnecessary 
for the math of the index to return the selected element of the array - 
it should in fact just return the index (i.e. the integer value of the 
index into the array of whatever the SIdRef is).

So in the reverse assign value of an array example

x and y are arrays with size n=10

<assignmentRule variable="y">
     <arrays:listOfDimensions>
         <arrays:dimension arrays:size="n" arrays:dim="0" 
arrays:id="i"/>
     </arrays:listOfDimensions>    <arrays:listOfIndices>
         <arrays:index arrays:dim="0" arrays:attribute="y">
              <math xmlns="http://www.w3.org/1998/Math/MathML">
                   <apply><minus/><cn>9</cn><ci>i</ci></apply>
              </math>
         </arrays:index>
     </arrays:listOfIndices>

the above is saying

for i = 0 to 9
y[9-i] = whatever

I have to say I found the fact that index does not return an index quite 
confusing when trying to get my head round the different semantics of 
the use on an element with no math and the use when there is math :-(

Sarah

Re: [sbml-arrays] Possible alternative arrayAssignment

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

So if everyone is cool with using piecewise then fine but just think of 
the scenario where you had an array of 100 objects and you wanted to 
assign to them in blocks of 10. That would be one helluva piecewise 
function. Very difficult to look at (for those of us who do look at raw 
SBML !).

I can see that when an index is computed there is no way other than 
computing it to determine whether it is out of bounds ! However my 
startIndex and endIndex was an attempt to enable a first parse of a 
document to flag up to the user - Hey you haven't assigned all of the 
array Or Hey you are assigning some elements more than once. Without 
this you have no chance of telling the user this. Although if we go with 
the use of piecewise when different parts of the array do different 
things then this becomes moot since each index will encompass the whole 
array.

Personally I would say my outline had advantages in making things 
slightly cleaner and being able to provide at least a first step at 
validating index use but ...

I realise that probably the issue that was most prominent is what if you 
want to use part of an array in a one type of element and part some 
other math related element; and unfortunately, no, I did not solve that 
one. But I do think that given the way the proposal is shaping, arrays 
of things are very tightly connected and thus having to use two arrays 
when things are treated so differently is not out of step with the rest.

Sarah

Re: [sbml-arrays] Possible alternative arrayAssignment

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

>> 
>> I'm worried, however, about the 'math' child of ArrayAssignment.  It
>> seems pretty arbitrary--there are a lot more child elements in SBML
>> besides 'math', and if we have to have it for that, I can't help but
>> think it would be needed for the other.  Reactions are particularly
>> susceptible to that; wouldn't they have potentially different
>> KineticLaws and/or reactants/products?  Anyway.
> 
> 
> I do see that point. However, in Chris' proposals to date the only 
> examples he has encountered where you might want a different child for 
> different elements in the array has been assignment type elements with a 
> math child. As I said I was not trying to create a whole new thing I was 
> adapting what was there slightly so it fixed the problems I saw.
> 
I think we are okay with reactions.  You may want different index schemes for reactants and products which is why SpeciesReferences is one of the elements that can be extended.  There is no math needed there though.  As for the kineticLaw, this is the math associated with a reaction, so it would be the math that gets updated by Sarah's proposed ArrayAssignment idea.  This is the only math in a reaction, so I think we are okay assuming this.
> 
> 
>> 
>> Mike also brings up a good point that the 'i' is undefined.  This could,
>> perhaps, solve the need for separate math children.  For your initial
>> assignment example, if you introduced a way to define a symbol to mean
>> "the index of this array", you then give the InitialAssignment's normal
>> 'math' child a simple 'piecewise' function:
>> 
>> piecewise:
>>   0 <= i <= 4: 5.7
>>   5 <= i <= 9: 3.2
> 
> We do have a means of specifying the index of the array. My missing i 
> was a typo !!!
> 
> I'm sure the idea of using piecewise has already been raised - I cannot 
> remember why it might have been rejected - but I think it was  ...
> 
> 
> We could fix the problem totally by saying if you have an array of 
> things where the members of the array have any sort of different 
> behaviour then you actually need to have two (or more) arrays of that 
> element, So for the piecewise example you would have two arrays of 
> parameters each of size 5 and two arrays of initialAssignments one with 
> math assigning 5.7 and the other with math assigning 3.2.  That would be 
> the simplest :-)

I don't recall dismissing piecewise.  There is already a way to handle initial assignment which is to use a vector for a one dimensional assignment and matrix for a two dimensional assignment.  The piecewise idea also works.

The actual real problem is that you cannot have an arrayed variable that is partially determined by an initialAssignment and partially by a rule (or something similar).  We had decided the last time we discussed this to solve it as Sarah points out above which is to say anything as mixed up as that should not be collapsed into an array.  I don't think Sarah's solution solves this issue either.

Hmm, I'm afraid that I'm now less sold on your idea Sarah, sorry.  I had momentarily forgotten that the problem was already resolved for the simple case and punted for the complicated case.  Your second issue of validating if all indices are assigned is also not solved by your approach.  You subset the values of "i" with the start and end index, but because of the math used to compute the index, it is not easy to determine if the left hand side actually has assignments for every possible location of the array.

I think validation with arrays, unfortunately, is going to end up being a dynamic thing.  Just like in software, array index out-of-bounds cannot be determined by the compiler.  Since array indices (both LHS and RHS) are to be computed using math, there is no way to know if you will ever read or write an invalid location statically.  The only way to do this would be to only allow constants in the array references, but this would greatly limit the utility of arrays.

Chris

> 
> Sarah
> 
> 
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays

Re: [sbml-arrays] Possible alternative arrayAssignment

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

Actually I was trying to stick as closely as possibly to the original 
whilst solving the things I saw as issues. I changed very very little. 
You need to read this section within the last draft as a replacement of 
one section - sorry if I did not make that clear.


Yes, I extended SBase (as is done in the last draft) as if you only 
extend particular elements then you have to also extend relevant 
elements in packages (some of which may not exist yet!). So extending 
SBase (as indeed the listOfDimensions also does) and then specifying 
which elements it actually means something on allows for the flexibility 
of 'the unknown package'.


>
> I'm worried, however, about the 'math' child of ArrayAssignment.  It
> seems pretty arbitrary--there are a lot more child elements in SBML
> besides 'math', and if we have to have it for that, I can't help but
> think it would be needed for the other.  Reactions are particularly
> susceptible to that; wouldn't they have potentially different
> KineticLaws and/or reactants/products?  Anyway.


I do see that point. However, in Chris' proposals to date the only 
examples he has encountered where you might want a different child for 
different elements in the array has been assignment type elements with a 
math child. As I said I was not trying to create a whole new thing I was 
adapting what was there slightly so it fixed the problems I saw.



>
> Mike also brings up a good point that the 'i' is undefined.  This could,
> perhaps, solve the need for separate math children.  For your initial
> assignment example, if you introduced a way to define a symbol to mean
> "the index of this array", you then give the InitialAssignment's normal
> 'math' child a simple 'piecewise' function:
>
> piecewise:
>    0 <= i <= 4: 5.7
>    5 <= i <= 9: 3.2

We do have a means of specifying the index of the array. My missing i 
was a typo !!!

I'm sure the idea of using piecewise has already been raised - I cannot 
remember why it might have been rejected - but I think it was  ...


We could fix the problem totally by saying if you have an array of 
things where the members of the array have any sort of different 
behaviour then you actually need to have two (or more) arrays of that 
element, So for the piecewise example you would have two arrays of 
parameters each of size 5 and two arrays of initialAssignments one with 
math assigning 5.7 and the other with math assigning 3.2.  That would be 
the simplest :-)

Sarah

Re: [sbml-arrays] Possible alternative arrayAssignment

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

On 06/01/2014 22:41, Michael Hucka wrote:
> This looks reasonable.  One thing, though: in the first XML example on p.4, in the MathML using <selector>, it uses a <ci> named "i".  Is it undefined in that example, or do I misunderstand how it all works?

Sorry :-)

The dimension element should have an id that is 'i'.

<arrays:dimension arrays:size="p" arrays:dim="0" arrays:id="i"/>

Sarah

Re: [sbml-arrays] Possible alternative arrayAssignment

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

This looks interesting--I couldn't initially figure out why you were
extending SBase and what all the moving pieces were doing, but I think I
figured it out in the end--tell me if my summary is correct.

Basically, you're extending SBase because you want to be able to extend any
SBase element that has an SIdRef attribute, and there's no base class for
that (you list all such core elements on page 3).  Similarly, some elements
have multiple such attributes (such as Species) and thus need multiple
ArrayAssignments.

I'm worried, however, about the 'math' child of ArrayAssignment.  It seems
pretty arbitrary--there are a lot more child elements in SBML besides
'math', and if we have to have it for that, I can't help but think it would
be needed for the other.  Reactions are particularly susceptible to that;
wouldn't they have potentially different KineticLaws and/or
reactants/products?  Anyway.

Mike also brings up a good point that the 'i' is undefined.  This could,
perhaps, solve the need for separate math children.  For your initial
assignment example, if you introduced a way to define a symbol to mean "the
index of this array", you then give the InitialAssignment's normal 'math'
child a simple 'piecewise' function:

piecewise:
  0 <= i <= 4: 5.7
  5 <= i <= 9: 3.2

(only in MathML, of course).

-Lucian


On Mon, Jan 6, 2014 at 5:27 AM, Sarah Keating <ske...@ca...> wrote:

> Hi Guys
>
> So having been looking at the current draft of the spec and thinking about
> implementation - particularly of validation - I had two concerns.
>
> 1. We still had not solved the issue of having multiple assignments
> (initialAssignment/assignmentRule etc) with the same variable. Something
> that is illegal in L3 core and I am very much against saying that packages
> can say that certain rules no longer apply.
>
> 2. In order to establish whether all elements of an array had been
> assigned once and only once it was necessary to parse the math expression
> of the index.
>
> So, having thought about it I came up with a possible solution. Attached
> is a revised Section 3.4 of the latest spec draft that outlines my
> suggestion.
>
> Sarah
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays
>
>

Re: [sbml-arrays] Possible alternative arrayAssignment

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

This looks promising.  One can still not have a single arrayed variable in say both assignment rules and rate rules, but I think we can safely argue that if you want to do that then don't put them together in an array.

I would lean towards indices being constant parameters to be consistent with size.   I think I would also lean towards allowing the math element in the object to be used when not provided in the array assignment.  Likely in these cases the startIndex and endIndex are omitted which reverts it to being essentially the same as the original proposal for those cases.

Cheers,

Chris

On Jan 6, 2014, at 6:27 AM, Sarah Keating <ske...@ca...> wrote:

> Hi Guys
> 
> So having been looking at the current draft of the spec and thinking about implementation - particularly of validation - I had two concerns.
> 
> 1. We still had not solved the issue of having multiple assignments (initialAssignment/assignmentRule etc) with the same variable. Something that is illegal in L3 core and I am very much against saying that packages can say that certain rules no longer apply.
> 
> 2. In order to establish whether all elements of an array had been assigned once and only once it was necessary to parse the math expression of the index.
> 
> So, having thought about it I came up with a possible solution. Attached is a revised Section 3.4 of the latest spec draft that outlines my suggestion.
> 
> Sarah
> <alternativeArrayAssignments.pdf>------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays

Re: [sbml-arrays] Possible alternative arrayAssignment

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

This looks reasonable.  One thing, though: in the first XML example on p.4, in the MathML using <selector>, it uses a <ci> named "i".  Is it undefined in that example, or do I misunderstand how it all works?

MH

[sbml-arrays] Possible alternative arrayAssignment

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

Hi Guys

So having been looking at the current draft of the spec and thinking 
about implementation - particularly of validation - I had two concerns.

1. We still had not solved the issue of having multiple assignments 
(initialAssignment/assignmentRule etc) with the same variable. Something 
that is illegal in L3 core and I am very much against saying that 
packages can say that certain rules no longer apply.

2. In order to establish whether all elements of an array had been 
assigned once and only once it was necessary to parse the math 
expression of the index.

So, having thought about it I came up with a possible solution. Attached 
is a revised Section 3.4 of the latest spec draft that outlines my 
suggestion.

Sarah

Re: [sbml-arrays] Index usage

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

Hi Sarah,

In your example, I would include an id for the dimension.  Let's call it "i".  I would then include in the math:

<apply>
<selector/>
<ci>c</ci>
<ci>i</ci>
</apply>

This would place each species in a compartment.  Namely, s(0) into c(0), etc.  You could use the math to place them in reverse if you like, c(0) into c(p-1), or any other thing you want to come up with.  We are going to use this perhaps to place a one dimensional species array into a 2-dimensional compartment array for grid models.

Chris

On Dec 14, 2013, at 4:44 AM, Sarah Keating <ske...@ca...> wrote:

> Hi Chris
> 
> This one is a query :-)
> 
> Spec states that only objects that have attributes of type SIdRef can 
> have a listOfIndices but what does an index mean when used with an 
> object that does not normally have a math element.
> 
> I'm clear on using the construct for 
> Rules/InitialAssigments/EventAssignments where you use the index to then 
> apply the math element to that instance of the variable but I am not 
> clear on the others.
> 
> For example:
> 
> Assume compartment c also has dimension 0 of size p
> 
> What would you expect to put in the math element of a species
> 
>        <species id="s" compartment="c" >
>          <arrays:listOfDimensions>
>            <arrays:dimension arrays:size="p" arrays:dim="0"/>
>          </arrays:listOfDimensions>
>          <arrays:listOfIndices>
>            <arrays:index arrays:dim="0" arrays:attribute="compartment">
>              <math xmlns="http://www.w3.org/1998/Math/MathML">
> 
>              </math>
>            </arrays:index>
>          </arrays:listOfIndices>
>        </species>
> 
> and what would it mean ???
> 
> 
> 
> Thanks
> 
> Sarah
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays

Re: [sbml-arrays] Example in Section 3.4.1 of latest doc

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

Yep.  Good catches.  Leftovers from when I thought we would be 1-index.

Thanks,

Chris

On Dec 14, 2013, at 4:43 AM, Sarah Keating <ske...@ca...> wrote:

> Hi Chris
> 
> I'm guessing these are typos but just making sure.
> 
> 1. The for statement should read
> for (i=0; i < n; i++)
> 
> since arrays are indexed from 0
> 
> 2. The array in the example has size n = 10 so the number used for 
> allocating the index in reverse should be 9 not 11.
> y[9-i] = x[i]
> and again in the actual math 11 should be 9
> 
> Thanks
> 
> Sarah
> 
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-arrays mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-arrays