Re: floating point inconsistency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andrew Haley <aph@xxxxxxxxxx> writes:

>> If I take the second (-O1) binary and execute it on an Opteron it
>> produces the _first_ result.  Thus, the same static binary produces
>> different results on different processors!
>
> That is strange.  A bit of debugging would be required to understand
> why that happens.

It boils down to sincos giving different results on core2 and opteron,
as demonstrated by the following program (compiled with "g++ test.cc").

################################################################
#include <iostream>
#include <cmath>

using namespace std;

double angle = 0.60066412215710574;

int main()
{
    double sinval, cosval;
    sincos(angle, &sinval, &cosval);
    cout << cosval - cos(angle) << '\n';
}
################################################################

which produces

1.11022e-16

on a core2 and

0

on Opteron.

>> I observe this problem also with g++ 4.4.2.  It seems only a tiny
>> difference, but this inconsistency makes my Montecarlo simulation
>> produce different results on different machines.
>>
>> Any help with this would be greatly appreciated.
>
> gcc applies an optimization to code where the same angle is passed to
> sin and cos.  This is turned into a single call to sincos() aka
> __builtin_cexpi().  Clearly the lsb is different in the optimized
> case.

Thanks, that clarified it.  I can avoid this inconsistency while staying
portable by computing cos(x) as sqrt(1 - sin(x)^2).

Christoph


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux