Free42 possible accuracy flaw

[Albert Chan]

(03-22-2022 05:18 PM)Thomas Okken Wrote:  The repeated squaring is not the issue by itself, you're not losing 7 digits of precision from calculati≈ng 39 multiplications unless something else is wrong. Note that if you calculate this using LN instead of LN1+X, you end up way off as well.

When we keep squaring, the errors also blows up exponentially.

x = 1e8 = 0b101 111 101 011 110 000 100 000 000
b = 1+1/x

Free42 (internally only do squarings)
b^(2^08) = 1.000002560003264002763521747927282
b^(2^13) = 1.000081923355125194292436470243333
...
b^(2^26) = 1.956365933428064586618947538663749

All terms to multiply has errors on the *same* side; losing 7 digits precision is normal.

Note that b^(2^8) only lost 1 ULP here.
If the base is worse, it might even lose log10(x) = 8 digits precision.

Quote:That logic is there for a reason, bid128_pow() is not very good when raising integers to integer powers, and the 2.0u2 revision of the library even includes a patch that does the same thing as the work-around I'm applying to 2.0u1.

Just because the new revision has the patch does not make it right.
Unless bid128_pow() loses *millions* of ULP's, we should limit exponent range.

Patch should only help, stop if it pass the break-even point.