[Scilab-Dev] SEP 064: HDF5 Scilab specification

[Samuel GOUGEON]

  Hello Sylvestre,

Taking some time to read completely the SEP, i would have some remarks
on some specific points of it:

* (head of page 2) *Several "types" are based on tlist or mlist. It is the case 
of rational,
state-space, hypermat and struct.They are therefor transparently saved.*
=> What about the missing /cell/ datatype ? (this one is presently also a 
predefined mlist() type,
isn't it? But there will be some changes in Scilab 6 about cells. So...a new 
full type?)

* (2 lines before 3.2)/ If the variable is primitive and without complex values 
associated, .../
By /primitive/, you are not speaking about a pointer to a primitive (function), 
are you?

* 3.2.1 Example. After the screenshot of the table, you mention /hdfview/.
Is it a new editor, distinct from /browsevar/ ? Couldn't browsevar be extended,
instead of being bypassed/duplicated?

* (the main concern) In 3.3, you describe the specific role of the # char.
Now, # in an authorized heading as well as building char in names of variables.
Couldn't this be of concern, for instance when "decoding" the nesting level of
hierarchical data with names including some #?

* 3.3.1 sparse (1 line before 3.3.2: /
#2# reference a matrix of _double_ which contains 1.0; 3.0; 2.0/
=> (i am underlying) Apparently, sparse with /complex/ numbers won't be supported.
Do you confirm that?

* 3.3.2 Boolean sparse: A typo:
/     While a sparse has 3 datasets, the// sparse has only 2 .../
=> While a sparse has 3 datasets, the boolean sparse has only 2...

That's all for me ;-)

Best regards
Samuel


----- Message d'origine -----
De : Sylvestre Ledru
Date : 25/05/2011 00:00:
> Le lundi 23 mai 2011 à 17:47 +0200, Sylvestre Ledru a écrit :
>> Hello,
>>
>> Since Scilab 5.2.0, we introduced a HDF5 storage for Scilab variables.
>> It is already widely used in the Xcos internal.
>> HDF5 is now a de-facto standard for the storage of numerical data [1].
>> In Scilab 5.4.0, we are going to update the load/save functions to use
>> this format (it is going to be the SEP 065). This for two main reasons:
>> * for the future version 6.0 of Scilab (which won't manage current .bin
>> files)
>> * allows the management of Scilab data (import/export) files by other
>> software.
>>
>> The attached document shows the current specification and implementation
>> of the Scilab / HDF5 schema.
> For information, this SEP is incomplete. It will be updated once we will
> completed the support of handlers (including uicontrol&  uimenu).
>
> Sylvestre
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20110525/91e90ef0/attachment.htm>