[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 #20 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
(In reply to Wilco from comment #19)
> (In reply to Vincent Lefèvre from comment #18)
> > OK, this is something that is new to me. So perhaps [1] should also document
> > the proved error bounds.
> 
> That might be too much work to figure out for every math library (AFAIK only
> GLIBC documents these error bounds in the implementations). Note the final
> result vary depending on FMA support, evaluation order etc.

Well, I meant only when the bound is known.

> As it happens, it does work out perfectly for pow(2, i) and exp2(i). Only
> exp10 and pow(10, i) have a few cases that are not:
> 
> exp10(126): 0x1.7a2ecc414a04p+418 0x1.7a2ecc414a03f7ff6ca1cb527788p+418

I meant only for the exact cases (pow(2,i) is always exact for integer i,
except in case of overflow/underflow, of course).

exp10(i) is exact for integers i up to 22 (5^22 < 2^53 < 5^23), but these are
not powers of 2. You need to be careful with powers of 2, because this is where
the value of the ulp changes (I've seen errors in several proofs because of
that); such cases may need a separate check.

> Note GLIBC previously had some correctly rounded math functions, but they
> were a total nightmare. Whenever you got close to a halfway point,
> performance dropped by a factor of a million times, even for cases that were
> relatively easy.

The implementation was much too pessimistic about the probability of failure
for the slow path, which used a precision of 768 bits (much more than what is
assumed for cryptographic hashes, for instance). Moreover, some slow cases (for
pow) were inputs that could easily be found in practice. CORE-MATH should be a
huge improvement.

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