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*: Wed, 14 Mar 2012 15:30:45 +0100*Subject*: Re: The state of glibc libm*References*: <Pine.LNX.4.64.1202291655580.7156@digraph.polyomino.org.uk>

On 2012-02-29 17:17:17 +0000, Joseph S. Myers wrote: > (a) Most libm functions are not correctly rounded - and do not make an > attempt at being correctly rounded. > > A full fix would likely require new (automatically generated and tuned) > implementations such as proposed at > <http://gcc.gnu.org/ml/gcc/2012-02/msg00298.html>. As I understand it, > correct rounding (proved correct) is generally feasible for functions of > one binary32, binary64 or x86 extended argument. For functions of two > arguments, or one binary128 argument, it may not be feasible to search for > worst cases for correct rounding, although it may be possible to produce > implementations that are "probably" correctly rounding. For functions of > complex arguments or IBM long double, correct rounding may be less > feasible (even complex multiplication and division, and all of +-*/ on IBM > long double, are not correctly rounding, and correct rounding isn't so > well-defined for IBM long double with its possibility of discontiguous > mantissa bits). 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. > (b) Where functions do make attempts at being correctly rounded > (especially the IBM Accurate Mathematical Library functions), they tend to > be sufficiently slow that the slowness attracts bug reports. Again, this > would likely be addressed by new implementations that use careful error > bounds and information about worst cases to reduce the cost of being > correctly rounding. I'm not sure that the complaints are about worst cases. More probably software implementation vs hardware implementation in the average case. But a new software implementation (better in average) could help. -- 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:*Joseph S. Myers

**Re: The state of glibc libm***From:*Jeff Law

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

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