More Load/Save stuff

[David Bateman]

Dear All,

Ok, I've bitten the bullet and have been working of distributing the
HDF5 code into the classes so that they can also be used with user
defined types. The idea being that the HDF5 format would become the
default octave binary format.

The attached patch, against 2.1.52, is where I'm upto, and includes
all of the things from my previous e-mail, plus the changes for the
HDF5 class and code for load/save of structures and lists in ascii
format and cells in HDF5 which weren't present in the previous code.

I had to make a major change to the HDF5 format. The problem is that
in the current scheme the type of the variable is derived from the
type of the saved variable in the HDF5 file. This is very limiting in
that another user type might very well use the same format. Thus there
needed to be a means of including the octave type in the HDF5 file.

The way I attacked this is that can be seen in the following example.
Consider saving a scalar value "a=1" with "save -hdf5 hdf5.mat a".
An "h5ls -r -d" on the file will show that the original file has
the format. 

/hdf5.mat/a              Dataset {SCALAR}
    Data:
        (0) 1

I propose to change this to be

/hdf5.mat/a              Group
/hdf5.mat/a/type         Dataset {SCALAR}
    Data:
        (0) "scalar"
/hdf5.mat/a/value        Dataset {SCALAR}
    Data:
        (0) 1

Where the variable "a" in the HDF5 is now a group containing
explicitly the octave type in the sub-variable "type" and its value in
the sub-variable "value". This makes the probing code of the type much
cleaner and makes it easy to include new types.

However, there is a downside. Firstly, the proposed file format is
incompatiable with the previous format. Secondly an advantage of the
previous format was that HDF5 files generated by other software could
be easily imported into octave. Without changes in these other packages
this might no longer be the case.

What I therefore propose it that we create two new oct-files "import"
and "export" that are basically based on the existing load-save code.
This then has the dual function of allowing forward/backward
compatiability, as well as allowing the importation of foriegn HDF5
files. I'd also suggest moving the matlab file formats to these
oct-files, leaving the core load-save functions much cleaner.

Basically, the suplied patch is about three quarters of the work 
needed to arrive at the above. However, I've now come a long way on
this code without any feedback, or indication whether this code is
likely to be accepted. As I have no desire to see my work wasted,
until there is at least some indication of whether this code will be
accepted, or what needs to be changed to have it accepted, I won't
work on it any further....

Cheers
D.

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

patch.gz
Description: Binary data