Re: diagonal matrices specializations

[dbateman]

On Thu, Dec 11, 2008 at 04:01:20PM +0100, Jaroslav Hajek wrote:
> Yes, that is of course possible, just I wasn't sure whether it's the
> right thing. If the
> Octave's hdf5 format is only supposed to be read by Octave, then that's OK.
> But then I don't understand its purpose as I see no advantages over
> Octave's own
> binary format.
> If, on the contrary, the saved hdf5 files are supposed to be read by
> other software
> (like R, Matlab, IDL or whatever), then maybe saving a diagonal matrix
> into them is
> a bad idea, as the other software won't understand it.

Things that can read general HDF5 files can read the Octave HDF5 file 
format and then decide what to do with it. That doesn't mean that Octave 
can't have its own structure for the HDF5 files. 

My mistake when implementing this has to create a group for each 
variable with two sub values. One with a string for the type of the 
variable. The right way to do it would have been to save the value 
directly and make the type an attribute of the value, much as matlab 
does. In this way thing that can load HDF5 files but don't understand a 
uint16 can still load it as a double array, and other such things. 

As the attribute is added after the value is saved the seting of the 
type attribute would be moved to the save_hdf5 method and your 
is_hdf5_saveable method becomes redundant.


> If you say that we're in the first situation where Octave's hdf5
> format is just for Octave,
> I can readily implement the solution just described. But, as David
> said, that was not
> his intention when implementing hdf5 format. I guess it all comes down
> to the question
> of whether David is going to do something with the hdf5 format in the
> near future
> (before 3.2.0 is out). If not, I'll implement hdf5 saving/loading
> analogically to what I did
> with ASCII/binary format, because crashing is not acceptable.
> David, can you comment...?

I'd hope the octave HDF5 format was useful elsewhere than Octave, but 
suspect its not used much. I'd say what should be done is

* Implement the save/load hdf5 methods for diagonal matrices in an 
analogous way to the othe hdf5 load/save methods.
* In the long term (after 3.2), modify the HDF5 code such that the 
format is matlab compatiable for the v7.3 file format and dump the 
current HDF5 format... 
* Write a simple conversion function for the deprecated octave hdf5 file 
to the new format.

Frankly, I'm not sure I have the energy to consider this as a personal 
project.

Regards
David




> 
> > jwe
> >
> 
> 
> 
> -- 
> RNDr. Jaroslav Hajek
> computing expert
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz