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>
- Date: Thu, 25 Apr 2013 15:02:23 +0000
- Subject: Re: [WIP] Fixing ulp near zero.
- References: <5178AC1D dot 90001 at redhat dot com>
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.
> +/* 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.)
--
Joseph S. Myers
joseph@codesourcery.com