6 ms·

Would anything actually break if NaN == NaN equalled true?

moomin 4y ago
Yes, in surprising places. But the most obvious thing is that comparing float values would become significantly more expensive.
- derriz 4y ago
  Could you explain how/why?
  - crote 4y ago
    Virtually all architectures have floats implemented in hardware - including NaN behavior. This means things like IEEE 754 float comparison is done in a single instruction, executed in a single cycle. Explicitly checking for NaNs would (at least) double the cycle count in cases where that branch is not taken, and having to deal with the custom comparison is even worse. This is not helped by the fact that there isn't a single NaN value: there are both positive and negative NaNs, and there are 23 bits which are usually ignored but for which some values do have specific meaning. To make it even worse, modern CPUs include vector extensions, allowing you to operate on multiple values at once. With AVX-512, you can compare 32 floats per clock cycle. I would not be surprised if switching to a custom comparison made some edge cases over 100x slower.
    - anonymoushn 4y ago
      Comparing the raw bits using instructions intended for integers is quite fast.
      - masklinn 4y ago
        NaN is not a single value, it's a multitude of them: a NaN is defined by all exponent bits being set to 1, so in a double there are 2^53 different possible NaN bit patterns (though only 2^52 values, because the sign bit is not part of the "NaN value", and possibly half that if you interpret signaling as a variable property of a fixed value)
        anonymoushn 4y ago
        Yes. Many applications do not require that at most 1 nan and at most 1 zero be allowed in each collection but do have trouble if some items are not equal to themselves.
derriz 4y ago
I can't see it. I've no idea what problem was solved by the current weird IEEE behavior. It must have been a biggy because this solution means your domain now loses the property that, in general, x == x. This property is a fundamental axiomatic feature of any notion of equality. A non-reflexive equality isn't just weird - it's daft/stupid/surprising.
- morelisp 4y ago
  > I've no idea what problem was solved by the current weird IEEE behavior. The same problem that's solved by having a lot of proofs say "for all y != 0, ..." If NaN == NaN, then you can no longer assume that x/z == y/z implies x == y. Which is also a fundamental (though non-axiomatic) result of arithmetic! NaN is an effort to represent partial functions in code that usually expects totality. It's not the best way but it's pretty good, and making NaN == NaN is also not how we'd do it with decades of hindsight.
josephcsible 4y ago
Isn't "if(x != x)" the canonical way to test whether x is NaN? That seems like quite a big thing to break.
- jeroenhd 4y ago
  Most languages have some kind of isNaN(value) method in my experience. Even C and C++ have an isnan method (C since ±1999, but other platforms had the macro before: https://repo.or.cz/w/glibc.git/blob/HEAD:/sysdeps/ieee754/dbl-64/s_isnan.c https://repo.or.cz/w/glibc.git/blob/HEAD:/sysdeps/ieee754/db...) People do probably rely on NaN ≠ NaN but I think that's more of a side effect of compatibility than anything else.
  - morelisp 4y ago
    Go's implementation of math.IsNaN is return f != f
sedatk 4y ago
Yes that would mean that sqrt(-1) equals to 0/0 for example, which might open a new portal to hell.

Yes, in surprising places. But the most obvious thing is that comparing float values would become significantly more expensive.

derriz 4y ago
Could you explain how/why?
- crote 4y ago
  Virtually all architectures have floats implemented in hardware - including NaN behavior. This means things like IEEE 754 float comparison is done in a single instruction, executed in a single cycle. Explicitly checking for NaNs would (at least) double the cycle count in cases where that branch is not taken, and having to deal with the custom comparison is even worse. This is not helped by the fact that there isn't a single NaN value: there are both positive and negative NaNs, and there are 23 bits which are usually ignored but for which some values do have specific meaning. To make it even worse, modern CPUs include vector extensions, allowing you to operate on multiple values at once. With AVX-512, you can compare 32 floats per clock cycle. I would not be surprised if switching to a custom comparison made some edge cases over 100x slower.
  - anonymoushn 4y ago
    Comparing the raw bits using instructions intended for integers is quite fast.
    - masklinn 4y ago
      NaN is not a single value, it's a multitude of them: a NaN is defined by all exponent bits being set to 1, so in a double there are 2^53 different possible NaN bit patterns (though only 2^52 values, because the sign bit is not part of the "NaN value", and possibly half that if you interpret signaling as a variable property of a fixed value)
      - anonymoushn 4y ago
        Yes. Many applications do not require that at most 1 nan and at most 1 zero be allowed in each collection but do have trouble if some items are not equal to themselves.

derriz 4y ago

I can't see it. I've no idea what problem was solved by the current weird IEEE behavior. It must have been a biggy because this solution means your domain now loses the property that, in general, x == x. This property is a fundamental axiomatic feature of any notion of equality. A non-reflexive equality isn't just weird - it's daft/stupid/surprising.

morelisp 4y ago
> I've no idea what problem was solved by the current weird IEEE behavior. The same problem that's solved by having a lot of proofs say "for all y != 0, ..." If NaN == NaN, then you can no longer assume that x/z == y/z implies x == y. Which is also a fundamental (though non-axiomatic) result of arithmetic! NaN is an effort to represent partial functions in code that usually expects totality. It's not the best way but it's pretty good, and making NaN == NaN is also not how we'd do it with decades of hindsight.

josephcsible 4y ago

Isn't "if(x != x)" the canonical way to test whether x is NaN? That seems like quite a big thing to break.

jeroenhd 4y ago
Most languages have some kind of isNaN(value) method in my experience. Even C and C++ have an isnan method (C since ±1999, but other platforms had the macro before: https://repo.or.cz/w/glibc.git/blob/HEAD:/sysdeps/ieee754/dbl-64/s_isnan.c https://repo.or.cz/w/glibc.git/blob/HEAD:/sysdeps/ieee754/db...) People do probably rely on NaN ≠ NaN but I think that's more of a side effect of compatibility than anything else.
- morelisp 4y ago
  Go's implementation of math.IsNaN is return f != f

sedatk 4y ago

Yes that would mean that sqrt(-1) equals to 0/0 for example, which might open a new portal to hell.