4 ms·
IEEE-754 NaN and Infinity have nothing to do with optimization. They come straight from math: * What is +1/0? It has to be +Infinity -- nothing else will do.
by exmadscientist 2y ago
IEEE-754 NaN and Infinity have nothing to do with optimization. They come straight from math:
* What is +1/0? It has to be +Infinity -- nothing else will do.
* What is -1/0? It has to be -Infinity -- nothing else will do.
* What is 0/0? There's no way to tell from the information we've got -- it's undefined: Not A Number. (However, should 0/0 come up as a result of taking the quotient of two functions that happen to both reach zero at a point, then sometimes the limit of that quotient is meaningful, and might have a numerical result.)
IEEE-754 chose to signal these things in-band, so we get NaN and Infinity to deal with in our floats and doubles.
- hollerith 2y agoNaN and Infinity have nothing to do with optimization only if your mental model of CPUs is extremely simplistic.
- fweimer 2y agoI'm pretty sure IEEE 754 covers trapping floating point math. It's not just about in-band signaling. It's unfortunate that the standard is proprietary, so we can't easily reference it to figure out what it says. Anyway, most CPUs support a trapping mode, after all. Here's an example with glibc: #define _GNU_SOURCE #include <fenv.h> volatile double x = 1.0; volatile double y; volatile double quotient; int main(void) { feenableexcept(FE_DIVBYZERO); quotient = x / y; } As far as I understand it, overall support for trapping math is poor because not much code is trapping-aware. It would be quite annoying if JSON parsing results in SIGFPE due to an Inexect trap, for example.