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-03-15 10:52:05 -0500, Steven Munroe wrote:
> On Thu, 2012-03-15 at 03:07 +0100, Vincent Lefevre wrote:
> > 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.
> > > 
> Why would that be OK? If we have higher precision long double then the
> libm should deliver that higher precision.

I initially thought that the only goal of a double-double format
(instead of the standard quadruple precision) was to get an
accurate implementation of the elementary functions in double
precision (BTW, that's probably why expl() and so on didn't
exist before C99).

Now, since expl() now exists, if the user calls it, perhaps his
goal is to get more precision, so finally I agree that expl()
should really have an accuracy close to LDBL_MANT_DIG. However
this is quite useless in portable programs, where long double
can have the same precision as double (as this is the case on

For the same reason, if the user chose long double instead of
double, this may be because he wanted more precision than double.
So, in the long term, the ABI should probably be changed to have
long double = quadruple precision (binary128).

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]