bugGNU Octave - Bugs: bug #31471, Problem saving ranges with HDF5...

 
 

bug #31471: Problem saving ranges with HDF5 format

Submitter:  None
Submitted:  Tue 26 Oct 2010 06:03:34 PM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  dbateman
Originator Name:  Moshe Apelbaum Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.2.2
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 11 Nov 2010 08:01:11 PM UTC, comment #4: 

David, your patch seems OK to me so I'm closing this report.

John W. Eaton <jwe>
Group administrator
Tue 02 Nov 2010 03:45:23 PM UTC, comment #3: 

You'll also need this trivial change, or we won't be able to have more than 255 elements in a range.

http://hg.savannah.gnu.org/hgweb/octave/rev/30bcd1aa9f09

D.

David Bateman <dbateman>
Group Member
Tue 02 Nov 2010 03:34:13 PM UTC, comment #2: 

The problem with trying to fix this issue is that the number of elements in the range needs to be saved to the HDF5 file to ensure that range can be restored with the correct number of elements. This of course introduces forwards and backwards compatibility issues.

Conceptual the easiest way to fix this would be to add the number of elements (or replace the limit value) in the HDF5 compound value that is saved for the range. We could treat the backward compatibility issue by testing for both compound types in the range code and use the right version, however this technique can never ensure forward compatibility.

A method to ensure forward and backward compatibility would be to save the number of elements of the range as an attribute of the range. With older versions of Octave this attribute would be ignored and if it didn't exist in newer versions of Octave we can just do without it, ensuring full compatibility. However this means that one value needed to restore the range has a different treatment from the others, so it might be considered as ugly.

I applied a changeset for this in

http://hg.savannah.gnu.org/hgweb/octave/rev/2271261f088a

If you are happy with this changeset then please close this bug. Otherwise, feel free to back it out if you consider this idea too ugly.

Cheers
D.

David Bateman <dbateman>
Group Member
Tue 26 Oct 2010 06:07:20 PM UTC, comment #1: 

I can confirm this on a Debian system with the current development sources.  It looks like a precision problem.  Ranges are stored as three elements, (base, limit, increment) so when those values are reloaded and the number of elements in the range is computed, a different result is obtained compared to the original.

John W. Eaton <jwe>
Group administrator
Tue 26 Oct 2010 06:03:34 PM UTC, original submission:  

Hello, I used Octave 3.2.2 on Win Xp Sp3.
After saving a struct that contains a vector to hdf5 file I try to load the
file and I don't get the same vector.
Code Example:

struct.g=(-1.0e-007:0.02:0.3)+0.84; % vector with 16 elements
save('-hdf5', 'bug.h5'); % the bug caused because of this line - open the file
in HDF View and you will see
m=load('bug.h5');
size(m.struct.g) % should be vector with 16 elements - the bug is that it
contains 17 elements
size(struct.g) % a vector with 16 elements as it should be
% when saving in mat format - there is no problem:
save('-mat', 'noBug.mat', struct);
n=load('noBug.mat');
size(n.struct.g) % contains 16 elements as it should

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dbateman (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-11-11 jwe StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2010-11-02 dbateman StatusConfirmed Patch Submitted
        Assigned toNone dbateman
    2010-10-26 jwe StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code