RE: save and load bug.

[GARY FORBIS]

I reloaded Octave again from http://sourceforge.net/project/showfiles.php?group_id=2888&package_id=40078
version 3.0.3.  Since Ben Abbott said the indicated program worked fine on his system I did a bit more testing.
 
a=-0.03597396637549816
b=[]
for x=1:383
b=[b,a]
end
save stest b
load stest  # this load works.
b=[b,a]
save stest b
load stest # this load fails.

The second load works find when I use the cygwin setup to install Octave but it's version 3.0.2.
Either the problem is the installer for 3.0.3 or version  3.0.3 itself.
Since the load function should be quite stable the issue is likely related to a called routine.
 
Digging into the code is a bit over my head right now.  I'll give it a try but I'm not looking forward to it.
 

---

From: address@hidden
To: address@hidden
Subject: save and load bug.
Date: Thu, 25 Dec 2008 04:55:55 +0000

OK, it's been awhile since I've tried GNU Octave.  I'm running vista with octave-3.0.3.
It's much better than 3.0.1.  I'm back to learning the language by running an existing program.
It did a save in several places then loaded the files back in later.  Unfortunately they didn't load.
 
I used this unix command to help me track down the problem:
 
$ head -n 6 mnistvhclassify| cut -d\  -f-1000 >garytest2;tail -n 1 garytest2 | wc
      1     500   10420
 
and modified the number of rows and columns until it quit failing.
 
This one worked:
$ head -n 6 garytest2| cut -d\  -f-190 >garytest1;tail -n 1 garytest1 | wc
      1     189    3943
 
This one failed:
$ head -n 6 garytest2| cut -d\  -f-191 >garytest1;tail -n 1 garytest1 | wc
      1     190    3964
 
There's nothing interesting about the number of characters near these numbers so I wrotethis:
 
 a=0.0877672686001518
 b=[]
 for x=1:500
 b=[b,a]
 save stest b
 load stest
 end
 
and it worked all the way thru.
 
$ tail -n 1 stest | wc
      1     500    9502
 
so I took the last value in the file that failed, -0.03597396637549816, and reran the program and it fail with this size:

$ tail -n 1 stest | wc
      1     384    8066
 
The problem appears to have nothing to do with the number of characters in the row.
Then I counted the number of negative number:
 
$ tail -n 1 garytest1 | sed 's/[^-]//g' | wc
      1       1     191
 
but that's only half of the place where the simple program failed.
I don't get it.
 
Any ideas?
 
Thanks.