fix precision issue in Float64^Float64.

[oscardssmith]

Closes #44525
this only costs 1 fma more, so the performance impact is minimal.

[oscardssmith]

I've done local testing on 2^22 random inputs to confirm correctness. For uniform x,y (x in -0:2000, y in -100:100), mean error is now .257 ULP, maximum error found is 1.36 ULP, and only 1e-5 results have error greater than 1 ULP.

For comparison, 1.7 has slightly worse average error (.262), but better maximum error (.85 ULP)

[KristofferC]

How about 10.0^-3 with this?

[oscardssmith]

Unchanged, but that is actually a bugfix. In 1.7, 10^-3 returned a different result than 10.0^-3 due to literal pow stuff.

[oscardssmith]

Also, what do you want in terms of tests for this? It's much harder to exhaustively test this than single argument functions because there are way more possibilities.

[ViralBShah]

Would be nice to have a slightly more descriptive issue title.

[giordano]

10^-3 returned a different result than 10.0^-3 due to literal pow stuff.

But now it returns a different result than BigFloat(10.0) ^ -3

julia> Float64(BigFloat(10.0) ^ -3)
0.001

[oscardssmith]

Yeah. The 2 options are to make x^-3 3x slower and always within .51 ULP, or leave as is. I'd be fine going either way.

[KristofferC]

returned a different result than 10.0^-3 due to literal pow stuff.

It kind of feels "embarrassing" to not be able to compute something like 10.0^-3 accurately anymore (this goes for both the literal pow and the floating point version). Any idea what other programming languages do here? Are we the odd one out or is this common?

[oscardssmith]

I've created https://discourse.julialang.org/t/poll-speed-vs-performance-for-float64-float64/77619 to gauge community opinion here. I'm happy to go either way.

[oscardssmith]

I've now fixed x^-3 to be more accurate after some democracy, and more careful analysis (I hadn't realized that the fast version's error could get above 2 ULPs). @KristofferC or anyone else that wants to this is ready to review.

[KristofferC]

Still need to add tests for all the cases this changed I think?

[oscardssmith]

tests added. (note that I've run the tests locally with higher parameters, but I've reduced the number a bit to keep CI running faster).

[oscardssmith]

The tests also caught a minor precision bug for Float32^-Integer so that is now fixed.

[KristofferC]

Seems to still fail CI.

[giordano]

You may have to rebase on master

[KristofferC]

Seems like some other test started failing now.

[oscardssmith]

this is surprisingly fiddly to get 100% correct.

[oscardssmith]

This appears to finally be correct. Thanks for catching it before release @KristofferC.