Re: Save-load problem

[Paul Kienzle]

Francesco Potorti` wrote:
> > 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
> >   
>
> In fact, the "correct" way is what John Eaton suggested, that is, do
>   a=[0:pi/16:8*pi];
> instead of
>   a=0:pi/16:8*pi;
Would it make sense to save start/stop/n instead of
start/step/stop?  True, the values would be slightly
different, but at least the number of elements would
stay the same.

For my part, I avoid real-valued ranges and do
everything with the more reliable linspace(start,stop,n).
Or if the transformation is simple enough, using
integer ranges such as:
     a = [0:16*8]*pi/16