Re: RFC: removing slow paths in various dbl-64 libm functions

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 30 Nov 2015, Carlos O'Donell wrote:

> Those higher precision fallback paths are often required just to get
> a moderately precise answer. So while this fix might remove some cases where
> we were being overly accurate and outside the stated goals, it doesn't
> remove cases where we need the accuracy to meet even the minimum goals.
> I expect that computations near sharp cuts still require MP solutions to
> attain reasonably accurate answers. What users don't like is that the

Range reduction requires a high-precision value of 2/pi, but only a 
limited number of bits of that value are needed in any particular case 
(it's easy to bound how close floating-point values can get to multiples 
of pi/2 using the classical theory of rational approximation by continued 
fractions).

It's true that the slow-path conditionals in sin, cos and tan have the 
effect of using the slow path (MP computation) when the argument is very 
close to a problematic multiple of pi/2 (in the case of tan through 
explicitly checking for a reduced argument with absolute value below 1e-7, 
in the case of sin and cos through including a multiple of the original 
unreduced value when checking for correct rounding).  It's also true that 
sin and cos use the slow path for all very large arguments.  It's 
certainly OK in such cases to use the slower (but still non-MP) version of 
range reduction in such cases and then the faster sin / cos / tan 
computation; it's possible that in some cases even the original range 
reduction is precise enough, but that would require more detailed 
analysis.

> time taken to compute an answer is not constant, and that might even
> constitute a timing oracle in some cases. Either way I think the community

I don't think timing oracle avoidance is a goal for libm functions (or for 
glibc functions in general, e.g. memcmp).

-- 
Joseph S. Myers
joseph@codesourcery.com