Re: [WIP] Fixing ulp near zero.

["Carlos O'Donell" <carlos at redhat dot com>]

On 04/25/2013 11:02 AM, Joseph S. Myers wrote:
> 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.

Is it just policy that we disable tests for inaccurate functions?

I'm having a similar discussion with Andreas in BZ#15359.

>> +/* 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.)

I think I'd like to go back to the nextafter() implementation and just
disable the check for IBM long double.

Is it a bug that nextafter behaves as-if the mantissa were fixed
precision on IBM long double?

Cheers,
Carlos.