Re: save and load bug.

[Jaroslav Hajek]

On Sun, Dec 28, 2008 at 11:59 PM, GARY FORBIS <address@hidden> wrote:
>
>> Date: Sun, 28 Dec 2008 18:55:56 +0100
>> From: address@hidden
>> To: address@hidden
>> Subject: Re: save and load bug.
>> CC: address@hidden; address@hidden; address@hidden
>>
>> On Sun, Dec 28, 2008 at 6:09 PM, GARY FORBIS <address@hidden> wrote:
>> > Thanks all. Eliminating one issue lets me focus better.
>> >
>> > I'm still looking. I'm very new to Octave even though I tried
>> > loading it in the spring of 2008. I didn't get as far as I've gotten now
>> > when
>> > trying to run the software I was using to learn more about ANNs and
>> > MathLab
>> > at the same time. I gave up quickly.
>> >
>> > I don't understand the structure of the files on sourceforge.
>> > I'm having a bit of trouble getting started. It's one more thing to
>> > learn.
>> > I saved octave-forge-bundle-20080831.tar.gz to my cygwin home directory,
>> > unzipped,
>> > and untarred it. It looks like the various pieces are tarred and zipped
>> > inside the package.
>> >
>> > I guess I can just recursively unzip an untar the files. Is there some
>> > documentation about
>> > where things are in the source files?
>> >
>>
>> I'm confused; maybe we both are. What are you trying to do?
>
> I'm trying to run a program written in mathlab that won't run on
> my computer under Octave.  I tracked down the problem to load not
> working with a file produced by a save.  I discovered that Octave
> uses an ascii file to do the save and I tracked down the minimum
> file that would fail.  I found the scalar that was in the last position
> in the matrix that failed.  I wrote a simple program that kept adding
> instances of that scalar to an array until the load of the array failed.
> I created another program that only did two saves and two load to
> demonstrate that on my machine Octave 3.0.3 loaded with the windows
> installer failed predictably.  I can find other numbers that will fail
> predictable
> after different occurrances and as far as I can tell there's nothing
> remarkable
> about the numbers or the number of occurrances of any of the characters
> or digits in the record.
>

Still you could go one step further in your experiments and inspect
the saved file prior to the unsuccessful load. That way you would find
out whether load failed on its own or because the previous save did
something wrong.


>> You can
>> get the latest stable Octave sources from
>> ftp://ftp.gnu.org/pub/gnu/octave/ or one of the GNU mirrors.
>> ftp.octave.org should also still work. I guess that building them on
>> Cygwin should be as simple as unpacking and doing configure&make,
>> provided you have the prerequisities.
>> If you have problems with compiling OctaveForge packages, you should
>> probably report the issue on the OctaveForge mailing list.
>
> I don't particularly want to compile Octave.  I want to track down
> the  problem
> and propose a solution.  Since other installations do not produce this
> problem,
> it looks like I'll have to dig deep enough into the code to see what limits
> exist.

Obviously, there should be no such limits. Of course it's up to you to
use any workaround you want. I was just assuming you'd like to help
discover a potential source of the problem - maybe a bug. Compiling
Octave yourself could help with that.

>
> I found dmlread earlier.  I'm assuming load uses a similar algorithm.

Not really. Octave's native text format (used by default by load/save)
decorates the file with blocks containing type and dimension info.

> I was
> right
> about reading a records at a time:
>
>       while (getline (file, line))
>
> While this sets an upper limit on the size of a record in characters it's
> much
> bigger than where I am encountering a problem.


What upper limit?
This should only be limited by your available memory, or, if your
Octave is compiled without 64-bit indexing, possibly by the limit of
2GB addressable by Octave.

>
>> > My first guess was that the file was read a record at a time then parsed
>> > and
>> > I had hit a
>> > 16 bit limit. This didn't make much sense to me so I tried positive
>> > numbers
>> > and I was able
>> > to write records with many more numbers in them and load them back in.
>> > Negative number
>> > with few significant digits had less poblems as well.
>> >
>>
>> It's hard to tell what can cause your problem, especially as nobody
>> seems to be able to reproduce it. So, if you wish it to be
>> investigated further, you need to carry out more experiments and tell
>> us the results.
>
> Well, as I said the small program works find on the cygwin octave
> version 3.0.2 so the problem is specific to the windows version 3.0.3
> dated  (2008-11-22 11:55)
>
> It isn't a problem with 3.1.50 either so I'll just us that until I find some
> other problem
> I have to deal with.
>

OK. good luck

regards

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz