undefined | Better HN

0 pointsexmadscientist1y ago0 comments

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.

0 comments

2 comments · 2 top-level

fweimer1y ago

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.

hollerith1y ago

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

j / k navigate · click thread line to collapse