3 ms·

I think the concept of NaNs are sound, but I think relying on them is fraught with peril, made so by the unobvious test for NaN-ness in many languages (ie, "if

I think the concept of NaNs are sound, but I think relying on them is fraught with peril, made so by the unobvious test for NaN-ness in many languages (ie, "if (x != x)"), and the lure of people who want to turn on "fast math" optimizations which do things like assume NaNs aren't possible and then dead-code-eliminate everything that's guarded by an "x != x" test. Really though, I'm a fan, I just think that we need better means for checking them in legacy languages and we need to entirely do away with "fast math" optimizations.

WalterBright 4y ago
I call them "buggy math" optimizations. The dmd D compiler does not have a switch to enable buggy math.
abnry 4y ago
NaNs are incredibly helpful in numpy. Often I want to take a mean over a collection of lists but the size of each list isn't constant. Np.nanmean works great.
BeetleB 4y ago
> made so by the unobvious test for NaN-ness in many languages (ie, "if (x != x)") Which languages do not have a function to test for NaN? > and the lure of people who want to turn on "fast math" optimizations which do things like assume NaNs aren't possible and then dead-code-eliminate everything that's guarded by an "x != x" test. This is not unique to NaNs. There are plenty of potential floating point problems if you enable those flags.
- maximilianburke 4y ago
  > Which languages do not have a function to test for NaN? Both C and C++. > This is not unique to NaNs. There are plenty of potential floating point problems if you enable those flags. That's why I said in the second part that we need to do away with them.
  - subharmonicon 4y ago
    isnan() has been around since C99.
    - maximilianburke 4y ago
      isnan is a macro, not a function
      - subharmonicon 4y ago
        isnan is a macro in C, function in C++. But either way, it’s an abstraction that provides a standard test for NaNs in those languages.
        BeetleB 4y ago
        I believe the reason he is pointing out this distinction is that if it is a macro, it can be optimized out causing bugs.
        stephencanon 4y ago
        Not in a sound implementation. E.g. in macOS/iOS’s libm, we replace the isnan() macro with a function call if you compile with fast-math precisely to prevent this.
        subharmonicon 4y ago
        Sure with -fast-math or similar compiler options without a way to also say “preserve NaNs”, that could happen with macros, but it can also happen with inline functions where the body is in a header file.
  - deleted 4y ago
    [deleted]
  - BeetleB 4y ago
    > Both C and C++. Seems C++ only added it in C++11. Surprising. > That's why I said in the second part that we need to do away with them. Do away entirely with fast math calculations? That would be horrible. They exist for a very good reason: Some applications are too slow without them. Enabling subnormal numbers can really slow things down. I'd wager that for the majority of programs written, the fast math is as good as the accurate math.
avgcorrection 4y ago
> I think the concept of NaNs are sound, but I think relying on them is fraught with peril Well, allegedly in D at least https://www.reddit.com/r/rust/comments/a1w75c/the_bug_i_did_not_have/eatjtut/ https://www.reddit.com/r/rust/comments/a1w75c/the_bug_i_did_...

WalterBright 4y ago

I call them "buggy math" optimizations. The dmd D compiler does not have a switch to enable buggy math.

abnry 4y ago

NaNs are incredibly helpful in numpy. Often I want to take a mean over a collection of lists but the size of each list isn't constant. Np.nanmean works great.

BeetleB 4y ago

> made so by the unobvious test for NaN-ness in many languages (ie, "if (x != x)") Which languages do not have a function to test for NaN? > and the lure of people who want to turn on "fast math" optimizations which do things like assume NaNs aren't possible and then dead-code-eliminate everything that's guarded by an "x != x" test. This is not unique to NaNs. There are plenty of potential floating point problems if you enable those flags.

maximilianburke 4y ago
> Which languages do not have a function to test for NaN? Both C and C++. > This is not unique to NaNs. There are plenty of potential floating point problems if you enable those flags. That's why I said in the second part that we need to do away with them.
- subharmonicon 4y ago
  isnan() has been around since C99.
  - maximilianburke 4y ago
    isnan is a macro, not a function
    - subharmonicon 4y ago
      isnan is a macro in C, function in C++. But either way, it’s an abstraction that provides a standard test for NaNs in those languages.
      - BeetleB 4y ago
        I believe the reason he is pointing out this distinction is that if it is a macro, it can be optimized out causing bugs.
        stephencanon 4y ago
        Not in a sound implementation. E.g. in macOS/iOS’s libm, we replace the isnan() macro with a function call if you compile with fast-math precisely to prevent this.
        subharmonicon 4y ago
        Sure with -fast-math or similar compiler options without a way to also say “preserve NaNs”, that could happen with macros, but it can also happen with inline functions where the body is in a header file.
- deleted 4y ago
  [deleted]
- BeetleB 4y ago
  > Both C and C++. Seems C++ only added it in C++11. Surprising. > That's why I said in the second part that we need to do away with them. Do away entirely with fast math calculations? That would be horrible. They exist for a very good reason: Some applications are too slow without them. Enabling subnormal numbers can really slow things down. I'd wager that for the majority of programs written, the fast math is as good as the accurate math.

avgcorrection 4y ago

> I think the concept of NaNs are sound, but I think relying on them is fraught with peril Well, allegedly in D at least https://www.reddit.com/r/rust/comments/a1w75c/the_bug_i_did_not_have/eatjtut/ https://www.reddit.com/r/rust/comments/a1w75c/the_bug_i_did_...