[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Save-load problem
From: |
Henry F. Mollet |
Subject: |
Re: Save-load problem |
Date: |
Tue, 29 Apr 2003 14:50:19 -0700 |
User-agent: |
Microsoft-Entourage/10.1.1.2418 |
>From a beginners point of view, I had to scratch my head if saving and
re-loading does not produce the same results. Obviously, I was not aware
that Octave was saving a range rather than the 1x129 matrix I anticipated. I
presume that's what MATLAB does as I was merely trying an example in the
introduction of a MATLAB text and combined it with save/load on the previous
page. I thought that the "range" statement (A=0:pi/16:8*pi;) was a quick way
to produce the matrix.
Four work-around solutions were provided:
1) save -float-binary session3.mat
2) Add default_save_format="ascii"; to ~/.octaverc
3) a(1)=a(1) <- the trick
4) save_precision = 16
I do not doubt JWE's response that there are good reasons to save as a range
but should this be the default for beginners to trip over? None of
work-around solutions were obvious to me. Some of them also have potential
problems according to John's reply. Perhaps then default save should mean
save -matrix, and one would use save -range for saving the range?
Henry
on 4/29/03 11:33 AM, John W. Eaton at address@hidden wrote:
> On 29-Apr-2003, Henry F. Mollet <address@hidden> wrote:
>
> | But I still don't understand. If it were a matter of loosing precision,
> | would not the elements of vector A be a little different.
>
> The problem is that for a range, the base, limit, and increment of the
> range are stored instead of all the individual elements. Then when
> you load the file with this information and recompute the size, Octave
> has to recompute the size given the numbers read from the file. If
> they are off slightly, you can generate a different number of
> elements.
>
> The following worked for me:
>
> save_precision = 16
> A = 0:pi/16:8*pi;
> save foo.dat A
> clear
> load foo.dat
> size (A) ==> 1, 129.
>
> but this is not a very good solution (you might also be able to get
> bad results if you use a value for save_precision that is too large).
>
> At this point, probably it would be best for Octave to default to a
> binary format. I don't think it makes sense to save all elements of
> the range, but if that's what you want, I think you will have to
> either modify Octave or use the Matlab binary format which I don't
> think supports ranges as a special case.
>
> I like the space savings that are possible by representing ranges
> using the base, limit, and increment, and it would be nice to preserve
> that when saving and loading files, but perhaps when saving in ASCII,
> it would be best to convert to matrices.
>
> Comments?
>
> jwe
-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.org
How to fund new projects: http://www.octave.org/funding.html
Subscription information: http://www.octave.org/archive.html
-------------------------------------------------------------
- Save-load problem, Henry F. Mollet, 2003/04/29
- Re: Save-load problem, Pablo Barrera González, 2003/04/29
- Re: Save-load problem, Iago Mosqueira, 2003/04/29
- Re: Save-load problem, Henry F. Mollet, 2003/04/29
- Re: Save-load problem, John W. Eaton, 2003/04/29
- Re: Save-load problem, Przemek Klosowski, 2003/04/29
- Re: Save-load problem,
Henry F. Mollet <=
- Re: Save-load problem, Francesco Potorti`, 2003/04/30
- Re: Save-load problem, Paul Kienzle, 2003/04/30
- Re: Save-load problem, Mike Miller, 2003/04/30