[exmadscientist]

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.

[fweimer]

I'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.

[hollerith]

NaN and Infinity have nothing to do with optimization only if your mental model of CPUs is extremely simplistic.