Re: The state of glibc libm

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

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)