Re: diagonal matrices specializations

[Jaroslav Hajek]

On Thu, Dec 11, 2008 at 9:42 PM,  <address@hidden> wrote:
> 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.
>

Unfortunately I don't understand the hdf5 format, so I'm not even sure
how the "analogous way" you refer to in point 1 should look like. So
for the time being I've committed a simplistic FIXME'd hack that
simply detects the special matrices in add_hdf5_data and densifies
them, so that this issue doesn't block the progress for 3.2.
This will be easy to revert if something more proper is to be implemented.

cheers

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