|
From: | GARY FORBIS |
Subject: | RE: save and load bug. |
Date: | Sun, 28 Dec 2008 08:26:26 +0000 |
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. |
[Prev in Thread] | Current Thread | [Next in Thread] |