This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/13932] dbl-64 pow unexpectedly slow for some inputs
- From: "wdijkstr at arm dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 12 Feb 2018 13:10:23 +0000
- Subject: [Bug math/13932] dbl-64 pow unexpectedly slow for some inputs
- Auto-submitted: auto-generated
- References: <bug-13932-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=13932
--- Comment #18 from Wilco <wdijkstr at arm dot com> ---
(In reply to Vincent Lefèvre from comment #17)
> (In reply to Vincent Lefèvre from comment #16)
> > > (In reply to Vincent Lefèvre from comment #13)
> > > > For the example of slow case pow(0.562500, 1.5), the exact result is
> > > > 0.421875 = 27/64, so that cor should be much smaller than ulp(res) and a
> > > > positive value should be returned, which doesn't explain the behavior.
> > >
> > > Whenever you're close to 0.5 ULP,
> >
> > It is not close to 0.5 ulp. This is an *exact* case (27/64), so that the
> > correction term should be very small, much smaller than 0.5 ulp.
>
> If it were close to 0.5 ulp, it would mean that there would be around 53
> bits of accuracy, which does not match your error analysis: "Maximum
> relative error before rounding is 8.8e-22 (69.9 bits)."
>
> So how can you explain the switch to the slow path with the previous code on
> this exact case with the 69.9 bits of accuracy for (al,rem)?
I don't think pow(0.562500, 1.5) was ever slow. The case I tested as slow was
pow(0.999999999999999889, 1.5).
Either way the calculation of the error term was incorrect, for example in
pow.c there was:
error = error * fabs (y);
t = __exp1 (a1, a2, 1.9e16 * error); /* return -10 or 0 if wasn't
computed exactly */
The error for pow scales with log(x) * y which is bounded by 710.
--
You are receiving this mail because:
You are on the CC list for the bug.