Re: [WIP] Fixing ulp near zero.

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 25 Apr 2013, Carlos O'Donell wrote:

> I plan on fixing the cpow result per your recommendations
> from the cos and sincos changes such that the ulp error is
> at least smaller.

That makes logical sense, since this is a case of an approximate input 
value having a significant effect on the exact expected results (actually, 
both the approximation to e and the approximation to pi may have 
significant effects here).

But I'm not sure it will work well, since the value cpow computes as the 
approximate product of (approximation to 2pi, approximation to log of 
approximation to e) may be slightly different from the exact product of 
(approximation to 2pi, exact log of approximation to e), which itself may 
have a significant effect on the result.  That is, the computed result may 
differ significantly not just from the result if the inputs were exact, 
but also from the ideal exact result for the given floating-point inputs.  
So maybe the test will still need disabling with a comment referring to 
bug 14473, until cpow is made more accurate in general.

> +/* Verify that our ulp () implementation is behaving as expected
> +   or abort.  */

I don't really see this check as being useful.  (The version using 
nextafter that you removed is closer to being independent of the main 
version of the logic to calculate ulps, but would probably fail for IBM 
long double, where the main logic works as-if the mantissa were fixed 
precision rather than allowing for discontiguous mantissa bits.)

-- 
Joseph S. Myers
joseph@codesourcery.com