4 ms·

I guess that's one more good reason to push for correctly rounded transcendental functions. I recently learned that they're basically solved now. [1] [1] https

by sjrd 3mo ago

I guess that's one more good reason to push for correctly rounded transcendental functions. I recently learned that they're basically solved now. [1] [1] https://arith2026.org/program.html https://arith2026.org/program.html (2nd keynote)

Retr0id 3mo ago
Tangential, but wow do they really register a new domain for each year and renew it in perpetuity?
- yzydserd 3mo ago
  arith2027.org taken, arith2028.org available.
  - Retr0id 3mo ago
    Well, there's an arbitrage opportunity if I ever saw one
    - voxl 3mo ago
      They would just choose a different domain name, it's not that important and the previous years tend to forward link anyway.
    - pclmulqdq 3mo ago
      I go to the conference frequently and know the organizing committee. It depends on the year (2025 and 2026 did it, but not 2024). And if someone decides to register arith20xx.org, I doubt the conference would buy it.
torginus 3mo ago
I never understood why fixed precision, and integer math isn't more popular. In engineering, we used fixed point all the time, it ran on much simpler hardware and the error is mathematically easy to model. IEEE 754 floats are not only suspect when it comes to theory, but are often outperformed with integers smaller than the mantissa (so less than 24 bits of int can beat a 32 bit float), when it comes to things like loss of precision.
- AlotOfReading 3mo ago
  I recommend pretty much everyone avoid fixed point and other float alternatives, barring exceptional cases after you've done your own numerical analysis, or you lack floating point hardware (rare these days). Yes, fixed point can use simpler hardware. That's also a completely irrelevant consideration for software. The vast majority of processors are optimized for floats now and some operations (e.g. division) are actually faster. The precision argument also falls apart. Any float with mantissa >= X+Y can get exactly the same results as a QX.Y fixed point. The float will actually perform better across the same range because you have to round it to perform like the fixed point. That means more precision, lower error, automatic normalization, better overflow behavior, a larger working range, etc. And it'll probably be just as fast, unless you're bottlenecked on memory bandwidth of inputs (unlikely). When you inevitably want an exp() or another special function, it's a heck of a lot easier to call libm than implement your own and it will perform better. Floats are also much easier to get right for your coworkers that aren't numerical analysts.
  - hilariously 3mo ago
    fixed-point provides uniform precision, exact integer-scaled arithmetic, is deterministic whereas floating point is more convenient but its not a panacea
    - AlotOfReading 3mo ago
      As I said, floats can provide results that are no worse than a specified fixed point type. So if you want uniform absolute precision, just round down to the required precision. Floating point is generally deterministic in practice with a fairly minor amount of effort, the major remaining issue being library rounding. I actually wrote a library that guarantees this for arbitrary code, with some small, obvious caveats like standard library precision. And the conference talks linked above note, the standard library issues are an increasingly solved problem for modern toolchains. The remaining cases are mostly things you won't do in fixed point. Let me know if you're aware of anyone computing erfc in fixed point for determinism though. I'm not saying there aren't any situations where other systems are justified, but you probably won't know if you fall into any of them without the kind of numerical analysis that most codebases will never receive.
anematode 3mo ago
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 3mo ago
  > 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.
  - nish__ 3mo ago
    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 3mo ago
      Representations other than the standard IEEE-754 can store floats in arbitrary precision.
  - mananaysiempre 3mo ago
    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 https://inria.hal.science/hal-04159652v2

by sjrd 3mo ago

Retr0id 3mo ago

Tangential, but wow do they really register a new domain for each year and renew it in perpetuity?

yzydserd 3mo ago
arith2027.org taken, arith2028.org available.
- Retr0id 3mo ago
  Well, there's an arbitrage opportunity if I ever saw one
  - voxl 3mo ago
    They would just choose a different domain name, it's not that important and the previous years tend to forward link anyway.
  - pclmulqdq 3mo ago
    I go to the conference frequently and know the organizing committee. It depends on the year (2025 and 2026 did it, but not 2024). And if someone decides to register arith20xx.org, I doubt the conference would buy it.

torginus 3mo ago

I never understood why fixed precision, and integer math isn't more popular. In engineering, we used fixed point all the time, it ran on much simpler hardware and the error is mathematically easy to model. IEEE 754 floats are not only suspect when it comes to theory, but are often outperformed with integers smaller than the mantissa (so less than 24 bits of int can beat a 32 bit float), when it comes to things like loss of precision.

AlotOfReading 3mo ago
I recommend pretty much everyone avoid fixed point and other float alternatives, barring exceptional cases after you've done your own numerical analysis, or you lack floating point hardware (rare these days). Yes, fixed point can use simpler hardware. That's also a completely irrelevant consideration for software. The vast majority of processors are optimized for floats now and some operations (e.g. division) are actually faster. The precision argument also falls apart. Any float with mantissa >= X+Y can get exactly the same results as a QX.Y fixed point. The float will actually perform better across the same range because you have to round it to perform like the fixed point. That means more precision, lower error, automatic normalization, better overflow behavior, a larger working range, etc. And it'll probably be just as fast, unless you're bottlenecked on memory bandwidth of inputs (unlikely). When you inevitably want an exp() or another special function, it's a heck of a lot easier to call libm than implement your own and it will perform better. Floats are also much easier to get right for your coworkers that aren't numerical analysts.
- hilariously 3mo ago
  fixed-point provides uniform precision, exact integer-scaled arithmetic, is deterministic whereas floating point is more convenient but its not a panacea
  - AlotOfReading 3mo ago
    As I said, floats can provide results that are no worse than a specified fixed point type. So if you want uniform absolute precision, just round down to the required precision. Floating point is generally deterministic in practice with a fairly minor amount of effort, the major remaining issue being library rounding. I actually wrote a library that guarantees this for arbitrary code, with some small, obvious caveats like standard library precision. And the conference talks linked above note, the standard library issues are an increasingly solved problem for modern toolchains. The remaining cases are mostly things you won't do in fixed point. Let me know if you're aware of anyone computing erfc in fixed point for determinism though. I'm not saying there aren't any situations where other systems are justified, but you probably won't know if you fall into any of them without the kind of numerical analysis that most codebases will never receive.

anematode 3mo ago

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 3mo ago
> 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.
- nish__ 3mo ago
  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 3mo ago
    Representations other than the standard IEEE-754 can store floats in arbitrary precision.
- mananaysiempre 3mo ago
  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 https://inria.hal.science/hal-04159652v2