Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Dec 2015 18:34:31 -0800
From:      NGie Cooper <yaneurabeya@gmail.com>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        Garrett Cooper <ngie@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r290605 - in head/lib/msun: . man
Message-ID:  <4E9A0C74-DC06-41E3-A27D-46FF06A98C95@gmail.com>
In-Reply-To: <20151109223117.Y2340@besplex.bde.org>
References:  <201511091040.tA9AeG0B038056@repo.freebsd.org> <20151109223117.Y2340@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Bruce!

> On Nov 9, 2015, at 04:03, Bruce Evans <brde@optusnet.com.au> wrote:
>=20
> On Mon, 9 Nov 2015, Garrett Cooper wrote:
>=20
>> Log:
>> Document powl(3)
>=20
> powl was garbage that was intentionally undocumented.  At least, I
> intentionally ignored its non-documentation together with it.

POSIX documents it and I noticed it was missing when porting the msun =
testcases from NetBSD. That=E2=80=99s the reason why I filed the bug.

> powl doesn't compute the value of .Ar x to the exponent .Ar y.  It =
computes
> the value of (double)(.Ar x) to the exponent (double)(.Ar y), =
converted to
> double.

Hmmm? The types look ok per the function signatures in lib/msun:

lib/msun/src/imprecise.c:imprecise_powl(long double x, long double y)
lib/msun/src/math.h:long double     powl(long double, long double);

=46rom exp(3):

     double
     pow(double x, double y);

     float
     powf(float x, float y);

     long double
     powl(long double x, long double y);

If the implementation is bugged/questionable, it should be documented in =
CAVEATS.

>> @@ -122,9 +126,10 @@ Otherwise the error in these functions i
>> These functions will return the appropriate computation unless an =
error
>> occurs or an argument is out of range.
>=20
> powl() almost never returns the appropriate computation.  Its bugs are
> most obvious when an argument is too large for double but not out of =
range.

These are bugs that need to be fixed then in the longterm, but in the =
short term should be documented under CAVEATS.

> I doubt that the rest of this section (about exception handling) is
> correct for powl().
>=20
> The section on errors wasn't changed since it uses generic pow().  It
> claims that the error is generally less than 1 ulp.  But for powl(),
> the error is generally more that 4096 ulps.  Much more when the
> error exponentiates.  powf() and pow() do well to avoid exponentiation
> of roundoff errors.

I think the comment above applies here too about adding some notes to =
CAVEATS.

Thank you for the input!
-NGie=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E9A0C74-DC06-41E3-A27D-46FF06A98C95>