[anematode]

Agreed, correctly rounded libm functions are great, as long as they don't have miserable worse case behavior (as was famously the case with glibc's pow at one point).

One thing I was thinking of doing is manually SLP-vectorizing the high-precision fallbacks that they use when they're close to a rounding boundary, so that you can get better worst-case behavior – but obviously it's good enough already for most purposes.

I'm honestly surprised though that JS engines don't just keep using fdlibm though. The ECMAScript spec explicitly encourages it iirc. And if Math.tanh is on your hot path in JavaScript then you're doing something quite bizarre...

[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.

[odo1242]

> And if Math.tanh is on your hot path in JavaScript then you're doing something quite bizarre...

Machine learning? (on a machine with no WebGL/WebGPU, I guess)

[anematode]

Sure, but you'd use a low-precision approximation for that; you don't need full double precision