standards/83845: [ patch ] add log2() and log2f() support for libm

[Roman Bogorodskiy]

The following reply was made to PR standards/83845; it has been noted by GNATS.

From: Roman Bogorodskiy <bogorodskiy at gmail.com>
To: David Schultz <das at FreeBSD.ORG>
Cc: FreeBSD-gnats-submit at FreeBSD.ORG
Subject: Re: standards/83845: [ patch ] add log2() and log2f() support for libm
Date: Thu, 21 Jul 2005 22:51:31 +0400

  David wrote:
 
 > Though this seems like a reasonable approach, it leads to
 > significant rounding errors since it requires dividing an inexact
 > result (ln(x) rounded to 52 bits) by another inexact quantity
 > (ln(2) rounded to 52 bits).  For instance, I suspect that if you
 > computed log2(2), log2(4), log2(8), log2(16), ... using your
 > implementation, the results would not always be exact.
 > Technically speaking I don't think they are required to be exact,
 > but common sense suggests that they ought to be.
 
 Is not it exact?
 
 $> ./a.out=20
 log2(2) =3D 1.0000000000000000000000
 log2(4) =3D 2.0000000000000000000000
 log2(8) =3D 3.0000000000000000000000
 log2(16) =3D 4.0000000000000000000000
 $>=20
 
 It's exact enough for me.
 
 > A more minor objection is that log2() can be computed more quickly
 > than log(), but this impelementation does it less quickly.  This
 > isn't such a big deal, though; I'm more concerned about the
 > problem that accuracy guarantees will be significantly weaker than
 > for other routines in libm.
 
 Ok. You know, log2() confirms to C99 and some apps become to use it now. Su=
 re,=20
 it's not problem for me to add hacks like #define log2(x) log(x)/log(2) whi=
 le=20
 you're looking for the ideal solution.
 
 Roman Bogorodskiy