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

["vincent-srcware at vinc17 dot net" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=13932

--- Comment #17 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
(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)?

-- 
You are receiving this mail because:
You are on the CC list for the bug.