octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: diagonal matrices specializations


From: Jaroslav Hajek
Subject: Re: diagonal matrices specializations
Date: Thu, 11 Dec 2008 16:01:20 +0100

On Thu, Dec 11, 2008 at 3:24 PM, John W. Eaton <address@hidden> wrote:
> On 11-Dec-2008, Jaroslav Hajek wrote:
>
> | OK, that's right, it will fail. However, the converting is not that
> | easy, because what the HDF5 saving code does is that it asks an
> | octave_value "what type are you of?", then stores the type name, and
> | then calls the value "now save yourself".
> | Instead, the sequence needs to be changed to:
> | "are you hdf-5 saveable?"
> | if yes, then "what type are you of?", write type, "save yourself".
> | if not, then "convert yourself" (numeric_conversion), and repeat.
>
> What is preventing us from simply saving the new data types?  Isn't it
> just the type name (as usual) plus dimensions (usual) and then the
> array that makes up the diagonal (or permutation) matrix?  Why not
> just write that code so that saving and loading these data types at
> least works, and then users of 3.2 (and snapshots leading up to it)
> won't see any surprising regressions from 3.0?
>

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.

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

> jwe
>



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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]