This is the mail archive of the glibc-bugs@sourceware.org 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]

[Bug math/13932] dbl-64 pow unexpectedly slow for some inputs


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]