This is the mail archive of the 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]

Re: The state of glibc libm

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 
> <>.  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

Vincent Lefèvre <> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]