[lifthrasiir]

> as was famously the case with glibc's pow at one point

Pow is famously hard anyway because it's bivariate and there is no currently known way to work around the table-maker's dilemma (TMD). CORE-MATH even crashes upon a new required precision record, because it intentionally avoids Ziv's rounding.

[mananaysiempre]

I was a bit puzzled by your second sentence, so I searched around a bit and... do I have this right?

- There’s a well-known way (“Ziv’s rounding”) to get (among other things) a correctly rounded double-precision pow(), but in bad cases it can get slow, meaning really quite slow in practice and we’ve got no idea how slow in the worst case (nobody knows what the worst case is).

- There’s a recent, guaranteed-correct way[1] to get (specifically) a correctly rounded double-precision pow(), but the last step requires “enough” precision and we’ve got no idea how much that actually is, so CORE-MATH uses 256 bits of mantissa and crashes if that turns out not to be enough (no such cases are currently known).

- (Bonus) For most special functions [not just the bivariate ugly duckling of pow()], there’s essentially no hope of getting a correctly rounded quad-precision version anytime soon.

[1] https://inria.hal.science/hal-04159652v2

[lifthrasiir]

You are right. (Ziv's rounding is essentially a method that keeps error bounds and increases the precision on the inconclusive result.) I think atan2 suffers from the same problem as well, but haven't actually looked up.

[nish__]

At what point are we going to realize that computers will never work for floating point math. If your numbers are not exact there will always be a better solution for what you are doing that does not involve a computer.

[pix128]

Representations other than the standard IEEE-754 can store floats in arbitrary precision.