Re: [WIP] Fixing ulp near zero.

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

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

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

It's de factor policy to keep clean test results: to use Bugzilla, not 
"expected" test failures, to track known defects.  That means that if a 
checked-in test is failing but believed to be correct, it should be 
appropriately disabled with a comment referring to the relevant bug in 
Bugzilla.  There are several existing such instances in libm-test.inc of 
tests either disabled completely, or with _EXCEPTION_OK where the 
exceptions generated are incorrect.

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

It's the other way round.  nextafter *should* handle variable precision 
(although it doesn't look like it does), whereas libm-test.inc can't 
sensibly treat IBM long double other than as fixed-precision for the 
purpose of computing ulps.  Anyway, ulps are poorly enough defined for IBM 
long double that you shouldn't expect two methods of computation to agree 
reliably.

-- 
Joseph S. Myers
joseph@codesourcery.com