Re: More Load/Save stuff

[David Bateman]

Updated my load/save patch to include load/saving of N-D real, complex
and boolean arrays in HDF5 and ascii files. Not sure of a clean way to
treat N-D string arrays, so haven't implemented it. This required some
additional functions in liboctave as well that seemed to be missing for
N-D arrays. Perhaps these wern't implemented for a reason, so check them..

There was also a bug in ov-typeinfo.cc for the lookup_type function needed
by my load/save patch. The returned octave_value wasn't made unique and 
so it was only possible to reload a single variable of each type....

Regards
David

According to David Bateman <address@hidden> (on 12/01/03):
> 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

> sh: octet-filter: command not found


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