'save_precision' doesn't work

[Jaroslav Hajek]

On Thu, Dec 25, 2008 at 8:12 PM, Sergei Steshenko <sergstesh at yahoo.com> wrote:
>
>
>
> --- On Wed, 12/24/08, John W. Eaton <jwe at octave.org> wrote:
>
>> From: John W. Eaton <jwe at octave.org>
>> Subject: Re: 'save_precision' doesn't work
>> To: sergstesh at yahoo.com
>> Cc: "Jaroslav Hajek" <highegg at gmail.com>, bug-octave at octave.org
>> Date: Wednesday, December 24, 2008, 10:22 AM
>> On 24-Dec-2008, Sergei Steshenko wrote:
>>
>> | There is no sense in having a 'save' subroutine
>> which always truncates
>> | data, i.e. if it's not a bug in code (i.e. the code
>> works as advertised),
>> | it's a bug in spec, i.e. the code implements wrong
>> goals.
>>
>> Complain to the MathWorks about the design decision.  Since
>> the -ascii
>> option to save is clearly documented as saving 8 digits, I
>> think we
>> would also see complaints if we did something different
>> here.
>>
>> | I think that 'save_precision' should simply
>> affect all 'save' operations.
>>
>> I think save_precision should maybe be removed from Octave.
>>
>> jwe
>
> What about '-octave_ascii' which obeys 'save_precision' ?
>

You can just use -text and strip away the leading comments. But, as
John commented, save is not really intended for formatted output, and
should probably always save with full precision.
There are other export functions that should allow tuning the
precision and other stuff, e.g. dlmwrite.

> At all, probably there should be C++ code which is functionally betters
> than the one of MathWorks, and a 'save.m' file which truncates/tunes the
> C++ code to be compatible with Matlab.
>

I don't think save should be an m-file. Apart from the technical
problems (save manipulates the local context), m-file would introduce
an unnecessary overhead.

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