sbml-spatial Mailing List for Systems Biology Markup Language (SBML)

Basically that part of my mail was just asking for a congrete example, as currently I would not know how the new way of addressing  is to be used. Since the spec currently does not make that clear, I just don’t know what is right. 

Frank

> On Jan 8, 2015, at 5:17 PM, Devin Sullivan <de...@cm...> wrote:
> 
> Hey Frank,
> 
> Can you explain that last bit a little more? I'm confused where you're expanding [0,3,6] to those three point (0,1,2),(3,4,5),and (6,7,8). I think that's right assuming you have a list of points like this: 
> [1,2,3;2,3,4;3,4,5;4,5,6;6,7,8;...etc] (commas and semicolons just for your readability) 
> but the point list doesn't necessarily have to be sequential like that, the triangle [0,3,6] should refer to connecting the vertices at positions 0, 3, and 6 in the vertices list respectively correct? 
> 
> Happy new years to all, 
> -Devin 
> 
> On Thu, Jan 8, 2015 at 10:56 AM, Frank Bergmann <fbe...@ca...> wrote:
> A happy new year to all!,
> 
> thanks for the update, Lucian here some comments that i came across while trying to update libsbml to v89:
> 
> - figure 9: should be domain UML, but is again domaintype UML.
> 
> - arrayData data, reads strange ... maybe we can find another header for those paragraphs (also only in the 'sampledField' it is not 'arrayData data' but 'arrayData'. I much prefer the old way as in v88, where we had an array called 'samples' and thus 'samplesLenght'.
> 
> - samplesLength: in the spec you again iterate that you don't see the need for the samplesLength attribute. It really is just there to make the array easier to read for developers, as they then can pre-allocate the arrays. It will also be useful for validation. (and no, the dimensions cannot be used for it, as compressed samples will take considerably less space than the uncompressed ones).
> 
> As for the name. In the sampledFieldGeometry, we had an array called 'samples', thus the length attribute was called samplesLength. Unfortunately, neither for the SpatialPoints class, nor the ParametricObject class you mentioned, what you wish that array to be called. For now I made the Spatial Points array 'arrayData' and thus the length field 'arrayDataLength', and for ParametricObject i left it with 'pointIndex' and 'pointIndexLength' as in v88 for the PolygonObject, but feel free to rename as needed. I just would think it helpful if we could call the array something.
> 
> - base64: in the spec you mention that the compression will be abandoned soon for base64. as base64 is only an encoding and not a compression measure. I would prefer for that paragraph to go up until a moment in time where this change is made (and even then it seems odd to force such a change, when there are already software applications that are happily using the current encoding scheme). I still maintain that it will introduce much of an overhead (as apart from compressing the data, and writing them you, you will also change the encoding).
> 
> ---
> 
> I really could do with some examples for the new classes, as I'm afraid I'm not yet sure how exactly it will be used. API wise i still prefer the old api over the new encoding. Only a couple issues for now:
> 
> - SpatialPoints datatype: should the point data not always be double?  Only then it would be comparable to the original listOfSpatialPoints (even though now developers will have to search for the points from the array) Since there are no examples: I suppose each point will always be specified by three subsequent numbers? Otherwise we might need an attribute that tells us that.
> 
> - PrametricObject dataType: here the datatype should always be a uint, as it will be an index into the SpatialPoints array, where a developer has then to take the elements from the point list.
> 
> - I'm not sure that the parametric object would need the compression in the first place.
> 
> - a basic example for a prametericObject would be a triangle, so if we have one with indices 0, 3, 6 then that would mean for a developer to take points  (0, 1, 2), (3,4,5) and (6,7,8) from the spatial points array, right?
> 
> 
> Cheers
> Frank
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net_______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial

Hey Frank,

Can you explain that last bit a little more? I'm confused where you're
expanding [0,3,6] to those three point (0,1,2),(3,4,5),and (6,7,8). I think
that's right assuming you have a list of points like this:
[1,2,3;2,3,4;3,4,5;4,5,6;6,7,8;...etc] (commas and semicolons just for your
readability)
but the point list doesn't necessarily have to be sequential like that, the
triangle [0,3,6] should refer to connecting the vertices at positions 0, 3,
and 6 in the vertices list respectively correct?

Happy new years to all,
-Devin

On Thu, Jan 8, 2015 at 10:56 AM, Frank Bergmann <fbe...@ca...>
wrote:

> A happy new year to all!,
>
> thanks for the update, Lucian here some comments that i came across while
> trying to update libsbml to v89:
>
> - figure 9: should be domain UML, but is again domaintype UML.
>
> - arrayData data, reads strange ... maybe we can find another header for
> those paragraphs (also only in the 'sampledField' it is not 'arrayData
> data' but 'arrayData'. I much prefer the old way as in v88, where we had an
> array called 'samples' and thus 'samplesLenght'.
>
> - samplesLength: in the spec you again iterate that you don't see the need
> for the samplesLength attribute. It really is just there to make the array
> easier to read for developers, as they then can pre-allocate the arrays. It
> will also be useful for validation. (and no, the dimensions cannot be used
> for it, as compressed samples will take considerably less space than the
> uncompressed ones).
>
> As for the name. In the sampledFieldGeometry, we had an array called
> 'samples', thus the length attribute was called samplesLength.
> Unfortunately, neither for the SpatialPoints class, nor the
> ParametricObject class you mentioned, what you wish that array to be
> called. For now I made the Spatial Points array 'arrayData' and thus the
> length field 'arrayDataLength', and for ParametricObject i left it with
> 'pointIndex' and 'pointIndexLength' as in v88 for the PolygonObject, but
> feel free to rename as needed. I just would think it helpful if we could
> call the array something.
>
> - base64: in the spec you mention that the compression will be abandoned
> soon for base64. as base64 is only an encoding and not a compression
> measure. I would prefer for that paragraph to go up until a moment in time
> where this change is made (and even then it seems odd to force such a
> change, when there are already software applications that are happily using
> the current encoding scheme). I still maintain that it will introduce much
> of an overhead (as apart from compressing the data, and writing them you,
> you will also change the encoding).
>
> ---
>
> I really could do with some examples for the new classes, as I'm afraid
> I'm not yet sure how exactly it will be used. API wise i still prefer the
> old api over the new encoding. Only a couple issues for now:
>
> - SpatialPoints datatype: should the point data not always be double?
> Only then it would be comparable to the original listOfSpatialPoints (even
> though now developers will have to search for the points from the array)
> Since there are no examples: I suppose each point will always be specified
> by three subsequent numbers? Otherwise we might need an attribute that
> tells us that.
>
> - PrametricObject dataType: here the datatype should always be a uint, as
> it will be an index into the SpatialPoints array, where a developer has
> then to take the elements from the point list.
>
> - I'm not sure that the parametric object would need the compression in
> the first place.
>
> - a basic example for a prametericObject would be a triangle, so if we
> have one with indices 0, 3, 6 then that would mean for a developer to take
> points  (0, 1, 2), (3,4,5) and (6,7,8) from the spatial points array, right?
>
>
> Cheers
> Frank
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
>

A happy new year to all!, 

thanks for the update, Lucian here some comments that i came across while trying to update libsbml to v89: 

- figure 9: should be domain UML, but is again domaintype UML.

- arrayData data, reads strange ... maybe we can find another header for those paragraphs (also only in the 'sampledField' it is not 'arrayData data' but 'arrayData'. I much prefer the old way as in v88, where we had an array called 'samples' and thus 'samplesLenght'. 

- samplesLength: in the spec you again iterate that you don't see the need for the samplesLength attribute. It really is just there to make the array easier to read for developers, as they then can pre-allocate the arrays. It will also be useful for validation. (and no, the dimensions cannot be used for it, as compressed samples will take considerably less space than the uncompressed ones). 

As for the name. In the sampledFieldGeometry, we had an array called 'samples', thus the length attribute was called samplesLength. Unfortunately, neither for the SpatialPoints class, nor the ParametricObject class you mentioned, what you wish that array to be called. For now I made the Spatial Points array 'arrayData' and thus the length field 'arrayDataLength', and for ParametricObject i left it with 'pointIndex' and 'pointIndexLength' as in v88 for the PolygonObject, but feel free to rename as needed. I just would think it helpful if we could call the array something. 

- base64: in the spec you mention that the compression will be abandoned soon for base64. as base64 is only an encoding and not a compression measure. I would prefer for that paragraph to go up until a moment in time where this change is made (and even then it seems odd to force such a change, when there are already software applications that are happily using the current encoding scheme). I still maintain that it will introduce much of an overhead (as apart from compressing the data, and writing them you, you will also change the encoding). 

--- 

I really could do with some examples for the new classes, as I'm afraid I'm not yet sure how exactly it will be used. API wise i still prefer the old api over the new encoding. Only a couple issues for now: 

- SpatialPoints datatype: should the point data not always be double?  Only then it would be comparable to the original listOfSpatialPoints (even though now developers will have to search for the points from the array) Since there are no examples: I suppose each point will always be specified by three subsequent numbers? Otherwise we might need an attribute that tells us that.

- PrametricObject dataType: here the datatype should always be a uint, as it will be an index into the SpatialPoints array, where a developer has then to take the elements from the point list. 

- I'm not sure that the parametric object would need the compression in the first place. 

- a basic example for a prametericObject would be a triangle, so if we have one with indices 0, 3, 6 then that would mean for a developer to take points  (0, 1, 2), (3,4,5) and (6,7,8) from the spatial points array, right? 


Cheers
Frank