RFC: removing slow paths in various dbl-64 libm functions
Carlos O'Donell
carlos@redhat.com
Fri Nov 27 03:53:00 GMT 2015
On 11/26/2015 01:09 PM, Joseph Myers wrote:
> I'd like to propose that we consider it OK to remove those slow paths, and
> thereby make the functions not correctly rounded, if this would not result
> in errors from those functions of more than 1ulp in round-to-nearest or
> 2ulp in other rounding modes (this is stronger than the limits
> libm-test.inc places on libm function errors, but might be a longer-term
> goal for general libm function accuracy). The error analysis may be done
> on the basis of the existing conditions in those functions for when to use
> the slow paths. For example, in e_asin.c:
>
> res = x+t; /* res=arcsin(x) according to Taylor series */
> cor = (x-res)+t;
> if (res == res+1.025*cor) return res;
...
> This does not affect cases where multiple-precision slow paths are needed
> simply to get results within the normal accuracy goals for libm functions,
> or where they are involved in functions that are fully defined by
> reference to IEEE 754 operations and so *are* required to be correctly
> rounded.
This seems good to me.
Cheers,
Carlos.
More information about the Libc-alpha
mailing list