This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [WIP] Fixing ulp near zero.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Andreas Schwab <schwab at suse dot de>
- Date: Thu, 25 Apr 2013 19:20:34 +0000
- Subject: Re: [WIP] Fixing ulp near zero.
- References: <5178AC1D dot 90001 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1304251455170 dot 8948 at digraph dot polyomino dot org dot uk> <517962E0 dot 4030108 at redhat 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