This is the mail archive of the
`libc-alpha@sourceware.org`
mailing list for the glibc project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Vincent Lefevre <vincent+gcc at vinc17 dot org>*To*: "Joseph S. Myers" <joseph at codesourcery dot com>*Cc*: libc-alpha at sourceware dot org, gcc at gcc dot gnu dot org,Geert Bosch <bosch at adacore dot com>,Christoph Lauter <christoph dot lauter at lip6 dot fr>*Date*: Thu, 15 Mar 2012 03:07:43 +0100*Subject*: Re: The state of glibc libm*References*: <Pine.LNX.4.64.1202291655580.7156@digraph.polyomino.org.uk><20120314143045.GG3804@xvii.vinc17.org><Pine.LNX.4.64.1203141432400.22094@digraph.polyomino.org.uk>

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)

**Follow-Ups**:**Re: The state of glibc libm***From:*James Cloos

**Re: The state of glibc libm***From:*Steven Munroe

**References**:**Re: The state of glibc libm***From:*Vincent Lefevre

**Re: The state of glibc libm***From:*Joseph S. Myers

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |