
Boost : 
Subject: Re: [boost] [Math] Rationale Behind Epsilon Values
From: Axel Ismirlian (aismirl_at_[hidden])
Date: 20140527 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" <boostbounces_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.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.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk