Re: The state of glibc libm

[Vincent Lefevre <vincent+gcc at vinc17 dot org>]

On 2012-03-14 14:40:06 +0000, Joseph S. Myers wrote:
> On Wed, 14 Mar 2012, Vincent Lefevre wrote:
> 
> > For double-double (IBM long double), I don't think the notion of
> > correct rounding makes much sense anyway. Actually the double-double
> > arithmetic is mainly useful for the basic operations in order to be
> > able to implement elementary functions accurately (first step in
> > Ziv's strategy, possibly a second step as well). IMHO, on such a
> > platform, if expl() (for instance) just calls exp(), this is OK.
> 
> expl just calling exp - losing 53 bits of precision - seems rather 
> extreme.  But I'd think it would be fine to say: when asked to compute 
> f(x), take x' within 10ulp of x, and return a number within 10ulp of 
> f(x'), where ulp is interpreted as if the mantissa were a fixed 106 bits 
> (fewer bits for subnormals, of course).  (And as a consequence, accurate 
> range reduction for large arguments would be considered not to matter for 
> IBM long double; sin and cos could return any value in the range [-1, 1] 
> for sufficiently large arguments.)

After thinking about this, you could assume that you have a 106-bit
floating-point system (BTW, LDBL_MANT_DIG = 106) and use the same
method to generate code that provides an accurate implementation
(if the code generator doesn't assume an IEEE 754 compatible FP
system). Concerning sin and cos, I think there should be a minimum
of specification and some consistency (such as sin(x)² + cos(x)²
being close to 1).

> Various bugs do complain about particular cases being slow (as well as 
> about such things as sinf being slower than sin - there, if you 
> automatically generate functions based not just on the type for the 
> function being generated but also on what wider types are available and 
> efficient in hardware, you could generate a version of sinf that uses 
> double or long double computations internally to speed things up).

sinf being slower than sin is surprising (but I know that sinl
could be faster than sin on x86_64 because sin uses the accurate
IBM implementation, while sinl uses the hardware instruction).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)