Re: [boost] [Math] Rationale Behind Epsilon Values

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
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.

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