[Bug math/28472] pow(10, i) accuracy

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

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

--- Comment #18 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
(In reply to Wilco from comment #17)
> (In reply to Vincent Lefèvre from comment #16)
> > (In reply to Wilco from comment #15)
> > > GLIBC double precision pow is the most accurate of all libraries tested at
> > > 0.523 ULP [1].
> > 
> > What you forget is that this is the accuracy *tested* on arbitrary values.
> > The actual accuracy may be worse. And this is the case here, with an
> > accuracy larger than 1 ulp, according to the results in Comment #6!
> 
> Please see the implementation - it documents the accuracy across the full
> input ranges. The worst-case reported by random testing is slightly lower
> due to not being able to test all input values.

OK, this is something that is new to me. So perhaps [1] should also document
the proved error bounds.

> And comment #6 discusses exp10, which had a known ULP of 2.01 in previous
> GLIBCs.

Sorry, I got confused by a recent mail (2024-03-02) giving these values and
saying that this was the corresponding bug report, but this bug is really about
pow() according to its title.

> Ie. if we have an algorithm that does < 0.55ULP before rounding, we can't ever > get a 2 ULP error.

OK, but in addition to the source, such proved error bounds (assuming no
mistakes in the analysis) should be given in the glibc manual.

Also, note that an error < 0.55 ULP before rounding does not guarantee that
pow(2,i) will be correct for the integers i. So, perhaps more should be said.

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