Re: Possible loss of accuracy

[Marco Caliari]

Thanks Jordi,

but the flag -ffloat-store does not affect my fortran test. I discovered 
that -O (instead of -O2) is enough. On another machine, with a newer gcc,
the result is always precise, even without the optimization flag, so it 
could be a fault of older versions of gcc.
On the other hand, gcc 4.3.3 with -O2 gives the desired precision and 
Octave was compiled with -O2, but Octave does not give the desired precision.

Marco

On Wed, 15 May 2013, Jordi Gutiérrez Hermoso wrote:

> On 15 May 2013 05:27, Marco Caliari <address@hidden> wrote:
> > if I compute
> >
> > t=50
> > (1-2^(-t))^(2^t)
> >
> > I get (different versions, machines, ...)
> >
> > ans =  3.67879441128629e-01
> >
> > which is correct to the 10th digit (compared with www.wolframalpha.com). I
> > can stay with it, but Matlab is correct to the 15th digit. While trying to
> > understand,
> [snip]
> > So, I understand that compiler optimizations are involved. On the other
> > hand, I compiled Octave with -O2 (and other flags).
> >
> > Can anyone point me to the right direction?
>
> I believe this may give some indication:
>
>    https://bbs.archlinux.org/viewtopic.php?id=99634
>
> Floats may sometimes be stored in CPU registers instead of memory,
> which usually only gives you more precision. In some calculations,
> this extra precision actually results in error overall, when combined
> with other computations that have less memory. With -ffloat-store, you
> inhibit using registers for floats.
>
> I believed older versions of gcc turned on or off -ffloat-store at
> some optimisation levels, but I don't think newer versions affect
> -ffloat-store anymore.
>
> HTH,
> - Jordi G. H.