
Boost : 
Subject: Re: [boost] [Math] Rationale Behind Epsilon Values
From: JOHN MADDOCK (boost.regex_at_[hidden])
Date: 20140527 14:44:41
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.9406564584124654e324. 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^(1D) 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" 128bit floating point type. Note that for any "normal" binary
floating point type F, then, numeric_limits<F>::epsilon and ldexp(F(1),
1numeric_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 <aismirl_at_[hidden]> wrote:
>
>
> 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 64LE. 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 64LE) 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
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk