This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [WIP] Fixing ulp near zero.

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

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]