The issue is this:
Our tests, and some of the code in the headers as well assume that:
x + x * eps != x for all x.
It's kind of a fundamental requirement for sensibly reasoning about the
bahaviour of floating point types.
But on platforms that use gcc's weird "double double" type as a long
double, then numeric_limits<long double>::epsilon() is the rather insane
value of 4.9406564584124654e-324. Technically this is correct, since
adding 1.0L to this value does indeed yield a distinct value, but the
broarder condition we rely on above holds only for x = 1, not all x.
The workaround is to use 2^(1-D) for epsilon, where D is the number of bits
precision in the type: in this case 106 as opposed to 64 on x86, or 113 for
a "true" 128-bit floating point type. Note that for any "normal" binary
floating point type F, then, numeric_limits<F>::epsilon and ldexp(F(1),
1-numeric_limits<F>::digits) yield the same value. It's just these problem
"double double" types that fail this test.
HTH, John.
On 27 May 2014 17:19, Axel Ismirlian
Hello, I am new to this mailing list, so its possible the format of my question may be off by a little. My team has been working on getting boost to run on PPC 64-LE. There are many tests in boost that rely on the machine epsilon value. Why was this value chosen to determine success or failure of a particular test knowing that it is hardware specific? More specifically, the Long Double type is very different on both platforms.
However, by forcing the x86 Long Double epsilon value on the PPC machine we were able to get many of the previously failing tests to pass. This change was inspired by the fact that a similar fix was already in the code for Darwin platform, but the value that it returns for the Darwin platform is not the x86 value. Also the LDBL_MANT_DIG on both the Darwin platform and our platform (PPC 64-LE) are the same, and are equal to 106. How was the Long Double value on the Darwin platform determined? For reference, the actual code lies in boost/math/tools/precision.hpp. We were also wondering whether or not this was a valid solution to fixing the problem? Part of us feel this doesn't address the underlaying problem. Sincerely. -Axel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost