3 ms·

You seem to be equating having a NaN in a result as being undetectable corruption. The whole point of NaN is that you don't end up with silent data corruption,

You seem to be equating having a NaN in a result as being undetectable corruption. The whole point of NaN is that you don't end up with silent data corruption, you end up with an unusable value: unusable in the sense that it infects further calculations instead of covering it up with a value that looks valid. r = (x / y) + 1 If y was 0, I wouldn't want r to equal 1; if r was 1 (or anything other than NaN, really) then that would be silent data corruption. That some languages have a literal form of NaN that can be typed into code and that has a type that is the same as the type of floating point numbers leads one to believe that an equality operator can/should be used to test for NaN. Really, a literal form of NaN is kind of a blight on such a language: the only way to obtain a value that is NaN should be via a calculation that results in it, there is very little need for a literal form, except for the case where you want to store the result of a calculation that might be NaN (to record that the calculation was corrupted). But in the wide range of cases, if someone was typing a literal NaN into their code, that would be a code smell: NaN is a legit result of a calculation, but not a legit input to a calculation because it infects any calculation it touches, and since there's not a legit reason to have it as an input, there's no reason to have a literal form that can be typed into the code. As for floating point exceptions vs testing for NaN: x = performcalculation() if isNan(x) { abort } y = performFurtherCalc(x) if isNan(y) { abort } This can be done at every point an additional value is introduced to the calculation, to determine if the result is sane or not. Floating point exceptions do these checks for you.

lmm 5y ago
> The whole point of NaN is that you don't end up with silent data corruption, you end up with an unusable value: unusable in the sense that it infects further calculations instead of covering it up with a value that looks valid. NaN values are slightly better than silently returning a valid value like 0, agreed. But having NaN silently corrupt a datastructure when you insert it into it is not what anyone asked for. Either make NaN a well-behaved value with well-behaved equality, or make it immediately explode like an exception. > As for floating point exceptions vs testing for NaN: x = performcalculation() if isNan(x) { abort } y = performFurtherCalc(x) if isNan(y) { abort } That's horrible ergonomics, that's like something from the '70s. I know there are still languages that lack proper sum types and high-level composition, but any serious language that can't solve that properly at least has some kind of language-level hack like exceptions.

lmm 5y ago

> The whole point of NaN is that you don't end up with silent data corruption, you end up with an unusable value: unusable in the sense that it infects further calculations instead of covering it up with a value that looks valid. NaN values are slightly better than silently returning a valid value like 0, agreed. But having NaN silently corrupt a datastructure when you insert it into it is not what anyone asked for. Either make NaN a well-behaved value with well-behaved equality, or make it immediately explode like an exception. > As for floating point exceptions vs testing for NaN: x = performcalculation() if isNan(x) { abort } y = performFurtherCalc(x) if isNan(y) { abort } That's horrible ergonomics, that's like something from the '70s. I know there are still languages that lack proper sum types and high-level composition, but any serious language that can't solve that properly at least has some kind of language-level hack like exceptions.