bugGNU Octave - Bugs: bug #30289, save/load does not restore a...

 
 

bug #30289: save/load does not restore a variable created with ones()

Submitted by:  Olaf Till <i7tiol>
Submitted on:  Tue 29 Jun 2010 08:07:35 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Other
Status: ConfirmedAssigned to: Jaroslav Hajek <highegg>
Originator Name: Open/Closed: Closed
Release: 3.3.51Operating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 30 Jun 2010 01:53:53 PM UTC, comment #4:

A fix is online:
http://hg.savannah.gnu.org/hgweb/octave/rev/d899b2ee6a37

The solution is to simply store length in place of limit when increment is zero, and handle it when loading. This will ensure backward load compatibility, and non-const ranges will also be saved in a compatible manner.

I think this patch could apply to 3.2.4, though I haven't tried.
A workaround is to convert the ranges to regular arrays prior to saving.

Jaroslav Hajek <highegg>In charge of this item.
Wed 30 Jun 2010 01:03:40 PM UTC, comment #3:

An accurate analysis, Olaf. This optimization is vital for certain array indexing operations (repmat), so we want to keep it.

Generally, we do not ensure backward compatibility of save, i.e. files saved in newer versions may not be correctly loadable in older versions. (Sometimes that's not even reasonably possible).

But we surely want backward compatibility of load, i.e. we want to keep datafiles saved by old versions loadable.

The solution certainly is to somehow store the length for constant ranges, but it needs to be done in a load-compatible manner.

Jaroslav Hajek <highegg>In charge of this item.
Wed 30 Jun 2010 11:36:05 AM UTC, comment #2:

According to src/data.cc:

case oct_data_conv::dt_double:
{
if (val == 1 && dims.length () == 2 && dims (0) == 1)
retval = Range (1.0, 0.0, dims (1)); // packed form
else
retval = NDArray (dims, val);
}
break;

it is intentional --- only saving is not yet handled. If this optimization is kept and saving is changed accordingly, it will probably break backwards compatibility of save-ed data, since the current format of saved data does not seem to allow zero-increment ranges. Maybe there should be an "-oct3.2" switch of the "save" command, leading to expansion of such ranges, for backwards compatibility...

Olaf Till <i7tiol>
Project Member
Tue 29 Jun 2010 04:12:20 PM UTC, comment #1:

This bug is confirmed with a recent tip on a GNU/Linux system.

The problem seems to be the mischaracterization of a row vector of ones as being a range. As Olaf noted, the saved file indicates that the variable being saved is a range, rather than a matrix.

Other interesting tests and their results:
ones (2,2) : works : saved as type matrix
ones (1,1) : works : saved as type scalar
a' : works : saved as type matrix
logical (a) : works : saved as type bool matrix
ones (1,3,'single') : works : saved as type float matrix
zeros (1,2) : works : saved as type matrix
e (1,2) : works : saved as type matrix

This brief testing seems to confine the problem exclusively to row vectors created by ones since other orientations (column vectors, 2x2 matrices, scalars), other types (logical, single), and other values (zero, e) all work.

Rik <rik5>
Project Administrator
Tue 29 Jun 2010 08:07:35 AM UTC, original submission:

repeat by:

octave:1> a = ones (1, 2)
a =

1 1

octave:2> save ("test1", "a")
octave:3> save ("-binary", "test2", "a")
octave:4> clear a
octave:5> load test1
octave:6> a
a =
octave:7> load test2
octave:8> a
a =
octave:9>

The file "test1" contains:

# Created by Octave 3.3.51, Tue Jun 29 10:02:15 2010 MEST <olaf@olaf>
# name: a
# type: range
# base, limit, increment
1 1 0

Octave-3.2.4 behaves the same way. Is there a fix or work-around for Octave-3.2.4?

Olaf Till <i7tiol>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by highegg (Updated the item)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by i7tiol (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 30 Jun 2010 01:54:04 PM UTChigheggOpen/ClosedOpen=>Closed
    Wed 30 Jun 2010 12:51:03 PM UTChigheggAssigned toNone=>highegg
    Tue 29 Jun 2010 04:12:20 PM UTCrik5StatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup1