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

 
 

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

Submitter:  Olaf Till <i7tiol>
Submitted:  Tue 29 Jun 2010 08:07:35 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Confirmed Assigned to:  highegg
Originator Name:  Open/Closed:  * Closed
Release:  * 3.3.51 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
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>
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>
Group 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>
Group 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>
Group Member

 

(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 highegg (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by i7tiol (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-06-30 highegg Open/ClosedOpen Closed
    2010-06-30 highegg Assigned toNone highegg
    2010-06-29 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code