This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [WIP] Fixing ulp near zero.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Andreas Schwab <schwab at suse dot de>
- Date: Thu, 25 Apr 2013 13:07:44 -0400
- 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>
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.