Float and integer arithmetic follow two different paradigms
Integer arithmetic demands preemptive checks to avoid undefined behavior, but floats work differently: errors produce NaN or infinity that propagate safely, so checking the final result for finiteness is more robust. The author argues that common epsilon-based guards are broken and that LLMs still get this wrong.
Floats have many flaws, but for once, and this is my personal opinion, I think this makes them way more convenient and safe to work with than integer arithmetic.
- weinzierl
The "integer arithmetic paradigm" would mean either checking after (almost) every operation or living with potentially incorrect results.
The first is terribly inefficient, the second is just wrong (even if insanely common).
This is sad because there is no reason at all why integers couldn’t follow what OP calls the "float paradigm". It doesn’t even have to be slow. Most modern processors (if we ignore x86) support some form of sticky arithmetic flags. Unfortunately, programming languages don’t support them, so they aren’t used.
There is also something to be said about
the special treatment division by zero gets.
- a_e_k
For the float stuff, beware of `-ffinite-math-only`. If enabled, `isfinite()` and may compile out as assumed true (with similar assumptions around `isnan()` and `isinf()`).
And `-ffinite-math-only` is enabled by `-ffast-math` which in turn is enabled by `-Ofast`.
- dooglius
FWIW one can configure floating point exceptions at runtime at no overhead, see `man 3 fenv`