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
From: JOHN MADDOCK
"double double" types that fail this test.
HTH, John.
How do you suggest implementing this particular workaround? We had tried adding a special case for the epsilon function for the PPC in precision.hpp much like the special case found for the Darwin platform in the same file. Or should we implement a solution that uses the workaround you mentioned? Sincerely, -Axel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
