3 ms·

Makes perfect sense . NaN is a special type indicating one can't reason about it normal way. It is an unknown or value that can't be represented. When compar

Makes perfect sense . NaN is a special type indicating one can't reason about it normal way. It is an unknown or value that can't be represented. When comparing, think of it like comparing two bags of unknown amount of apples. One bag has NaN count of apples Other bag has NaN count of apples Do the two bags have equal number of apples? I wish all languages used nulls the way SQL does.

caditinpiscinam 7mo ago
Respectfully, I disagree. If NaNs were meant to represent unknown quantities, then they would return false for all comparisons. But NaN != NaN is true. Assuming that two unknowns are always different is just as incorrect as assuming that they're always the same. I'd also push back on the idea that this behavior makes sense. In my experience it's a consistent source of confusion for anyone learning to program. It's one of the clearest violations of the principle of least astonishment in programming language design. As others have noted, it makes conscientious languages like Rust do all sorts of gymnastics to accommodate. It's a weird edge case, and imo a design mistake. "Special cases aren't special enough to break the rules." Also, I think high level languages should avoid exposing programmers to NaN whenever possible. Python gets this right: 0/0 should be an error, not a NaN.
- glkindlmann 7mo ago
  As a standard for floating point representation and computation, IEEE 754 solved multiple long-standing serious problems better than anything that came before it. I don't think its sensible to judge it with a PL design lens like "principle of least astonishment"; certainly not as if IEEE754 is a peer to Rust or Python. Or, you could learn about the surprise, frustration, and expense involved in trying to write portable numeric code in the 1970s, prior to IEEE 754: https://people.eecs.berkeley.edu/~wkahan/ieee754status/754story.html https://people.eecs.berkeley.edu/~wkahan/ieee754status/754st...
- happytoexplain 7mo ago
  `NaN == NaN` vs `NaN != NaN` forces us to pick which idea to violate: 1. A value of a given type, either a literal or a value in memory, should represent a single concrete value, semantically (`5` represents the number five). 2. Classical logic (if A = B is true, then A != B is false). I vote for violating #1, because we control those terms better. Is it weird that we invented a value that represents "unrepresentable" (as opposed to representing "no value")? Yes, but there are practical reasons for why we did it. It would be much more weird/surprising to violate classical logic.
glkindlmann 7mo ago
I like this justifiation of NaN != NaN; it emphasizes that NaN has representional intent, more than just some bit pattern. We take for granted that (except for things like x86 extended precision registers) floating point basically works the same everywhere, which was the huge victory of IEEE 754. It easy to lose sight of that huge win, and to be ungrateful, when one's first introduction to IEEE 754 are details like NaN!=NaN.
deleted 7mo ago
[deleted]
paulddraper 7mo ago
It makes no sense. 1/0 is an error (SIGFPE). log(-5) is a value (NaN). --- I suppose you could have this "no reflexive equality" sentinel, but it applied so randomly in languages as to be eternally violate the principle of least astonishment.

caditinpiscinam 7mo ago

Respectfully, I disagree. If NaNs were meant to represent unknown quantities, then they would return false for all comparisons. But NaN != NaN is true. Assuming that two unknowns are always different is just as incorrect as assuming that they're always the same. I'd also push back on the idea that this behavior makes sense. In my experience it's a consistent source of confusion for anyone learning to program. It's one of the clearest violations of the principle of least astonishment in programming language design. As others have noted, it makes conscientious languages like Rust do all sorts of gymnastics to accommodate. It's a weird edge case, and imo a design mistake. "Special cases aren't special enough to break the rules." Also, I think high level languages should avoid exposing programmers to NaN whenever possible. Python gets this right: 0/0 should be an error, not a NaN.

glkindlmann 7mo ago
As a standard for floating point representation and computation, IEEE 754 solved multiple long-standing serious problems better than anything that came before it. I don't think its sensible to judge it with a PL design lens like "principle of least astonishment"; certainly not as if IEEE754 is a peer to Rust or Python. Or, you could learn about the surprise, frustration, and expense involved in trying to write portable numeric code in the 1970s, prior to IEEE 754: https://people.eecs.berkeley.edu/~wkahan/ieee754status/754story.html https://people.eecs.berkeley.edu/~wkahan/ieee754status/754st...
happytoexplain 7mo ago
`NaN == NaN` vs `NaN != NaN` forces us to pick which idea to violate: 1. A value of a given type, either a literal or a value in memory, should represent a single concrete value, semantically (`5` represents the number five). 2. Classical logic (if A = B is true, then A != B is false). I vote for violating #1, because we control those terms better. Is it weird that we invented a value that represents "unrepresentable" (as opposed to representing "no value")? Yes, but there are practical reasons for why we did it. It would be much more weird/surprising to violate classical logic.

glkindlmann 7mo ago

I like this justifiation of NaN != NaN; it emphasizes that NaN has representional intent, more than just some bit pattern. We take for granted that (except for things like x86 extended precision registers) floating point basically works the same everywhere, which was the huge victory of IEEE 754. It easy to lose sight of that huge win, and to be ungrateful, when one's first introduction to IEEE 754 are details like NaN!=NaN.

deleted 7mo ago

[deleted]

paulddraper 7mo ago

It makes no sense. 1/0 is an error (SIGFPE). log(-5) is a value (NaN). --- I suppose you could have this "no reflexive equality" sentinel, but it applied so randomly in languages as to be eternally violate the principle of least astonishment.