Re: deprecating support for HDF5 files in load/save

[Jaroslav Hajek]

On Thu, Mar 5, 2009 at 9:35 AM, John W. Eaton <address@hidden> wrote:
> I'd like for us to consider deprecating support for HDF5 files in the
> load and save functions, at least as it is currently implemented.
> Some reasons for this are
>
>  * Saving in the HDF5 format does not currently work for diagonal or
>    permutation matrices.
>

They're converted to full matrices when saved.

>
>  * As I recall, David has said that he doesn't think the structure of
>    the HDF5 files that we generate is as good as it could be, but
>    there is little hope of fixing this and keeping backward
>    compatibility.
>
>  * Some users seem to think that the load function should be able to
>    intelligently handle any HDF5 file, but most likely it will only
>    only work properly for HDF5 files that were generated with
>    Octave's save command using the "-hdf5" option.
>
> Instead of having specialized and limited support for HDF5 files
> hardwired into the save and load commands, I'd prefer to have a
> lower-level wrapper for important functions from the HDF5 library
> interface.  Using those, I would expect that you could read or write
> most HDF5 files with Octave, and we could also use them to create
> Matlab-compatible hdf5info, hdf5read, and hdf5write functions.  It
> might also be useful to organize the low-level functions in a
> compatible class hierarchy.
>
> But even if we don't have these functions now, I think we should
> deprecate the HDF5 capability of the load and save functions because
> they are broken and it seems unlikely that they will be fixed any time
> soon.  I also think it requires too much effort to have to deal with
> text, binary, and hdf5 formats in load and save.
>
> Note that I'm not volunteering to write these functions.  This work
> should be done by someone with some knowledge and interest in the HDF5
> format (I currently have neither).  However, I could provide some help
> with the design and perhaps parts of the implementation.
>
> Comments?
>
> jwe
>

I agree.
I think there is little reason to use per-class saving/loading
mechanism for hdf5 files, if they are to be shared with external
programs, because we can hardly expect these programs to be able to
work with the same set of value classes as Octave does (diagonal &
permutation matrices are an example).
If hdf5 only handles Octave -> Octave transfers, then it's just pointless.

cheers

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