Boost logo

Boost :

Subject: Re: [boost] [Math] Rationale Behind Epsilon Values
From: Axel Ismirlian (aismirl_at_[hidden])
Date: 2014-05-27 15:19:00

From: JOHN MADDOCK <boost.regex_at_[hidden]>
To: boost_at_[hidden]
Date: 05/27/2014 01:44 PM
Subject: Re: [boost] [Math] Rationale Behind Epsilon Values
Sent by: "Boost" <boost-bounces_at_[hidden]>

> 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
> precision in the type: in this case 106 as opposed to 64 on x86, or 113
> 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
> "double double" types that fail this test.
> HTH, John.

How do you suggest implementing this particular workaround? We had tried
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
a solution that uses the workaround you mentioned?


Unsubscribe & other changes:


Boost list run by bdawes at, gregod at, cpdaniel at, john at