4 ms·

I agree it really doesn't make sense to say two NaNs are definitely equal, but it doesn't seem necessarily true that they aren't equal, either. Semantically, I

I agree it really doesn't make sense to say two NaNs are definitely equal, but it doesn't seem necessarily true that they aren't equal, either. Semantically, I would say NaN == NaN should return undefined (assuming JS here). Of course, it would be weird for == not to return true or false, so in practice that probably isn't a good idea. So I agree with you false is the least bad option.

Sharlin 12y ago
Yes, you'd have to implement tri-state logic, with all its unintuitive implications, in all languages that wanted to use IEEE 754. Clearly not very feasible. In SQL, one of the few languages with tri-state boolean as a first-class data type, null==null does return null.
- Fishkins 12y ago
  Yeah, SQL's handling of nulls tripped me up a couple times while I was getting used to the language.
Dewie 12y ago
> Semantically, I would say NaN == NaN should return undefined (assuming JS here). I thought that the philosophy of JS was to make meaning out of every execution and value, even the meaningless ones? Kind of the opposite of the fail-fast-and-hard philosophy. String index of NaN? JS will find a way.
yourad_io 12y ago
Why wouldn't NaN==NaN return a NaN value, which also has the following property: -> Can't be used as a branching conditional. Think about it: if (NaN) { a; } else { b; } The pedantically-correct answer would be to execute neither, but that wouldn't be very helpful (however fun debugging that might have been). The pragmatically-correct answer, imho, would be to throw an error. Would I rather have a; or b; executed, when I can't trust the conditional value? Neither, by the time the NaN has hit branching code, it's time it escalated into an error. edit: I may have reinvented "Maybe" https://news.ycombinator.com/item?id=7747284 https://news.ycombinator.com/item?id=7747284
- Fishkins 12y ago
  I thought about that, but I like undefined better. Part of the reason is NaN is of type number[0], and I think a number makes less as a return value for a conditional statement than a general non-value (e.g. undefined or null). Also, if someone asked me to evaluate the equality of karamozov's equations at 0, I'd literally say "that's undefined." So the JS undefined value seemed perfect to me (perfect as in the most elegant, not necessarily the most practical). For some reason I hadn't thought about it till you mentioned it, but I do like the idea of throwing an exception when a nonsensical comparison of NaNs happen. Of course that would be inimical to the way JS normally operates. I don't think what you're getting at is exactly Maybe. You're able to easily programmatically determine whether a Maybe has a value, whereas the equality of NaNs is basically unknowable. 0 - Talking in JS again, although it's similar for Java and other languages.
  - yourad_io 12y ago
    > You can ignore invalid data for as long as you want, but you can also draw lines and say "it can't have been ignored if flow gets to here". (from comment I linked above) I was talking about this property of Maybe. I was thinking that assigning a NaN value to a boolean should probably be "fine" (no exception), but using that when branching would mean that this carried-forward-error (which the NaN represents, effectively) is just about to go beyond "infecting" just data, to affecting code flow. So, throw.

Sharlin 12y ago

Yes, you'd have to implement tri-state logic, with all its unintuitive implications, in all languages that wanted to use IEEE 754. Clearly not very feasible. In SQL, one of the few languages with tri-state boolean as a first-class data type, null==null does return null.

Fishkins 12y ago
Yeah, SQL's handling of nulls tripped me up a couple times while I was getting used to the language.

Dewie 12y ago

> Semantically, I would say NaN == NaN should return undefined (assuming JS here). I thought that the philosophy of JS was to make meaning out of every execution and value, even the meaningless ones? Kind of the opposite of the fail-fast-and-hard philosophy. String index of NaN? JS will find a way.

yourad_io 12y ago

Why wouldn't NaN==NaN return a NaN value, which also has the following property: -> Can't be used as a branching conditional. Think about it: if (NaN) { a; } else { b; } The pedantically-correct answer would be to execute neither, but that wouldn't be very helpful (however fun debugging that might have been). The pragmatically-correct answer, imho, would be to throw an error. Would I rather have a; or b; executed, when I can't trust the conditional value? Neither, by the time the NaN has hit branching code, it's time it escalated into an error. edit: I may have reinvented "Maybe" https://news.ycombinator.com/item?id=7747284 https://news.ycombinator.com/item?id=7747284

Fishkins 12y ago
I thought about that, but I like undefined better. Part of the reason is NaN is of type number[0], and I think a number makes less as a return value for a conditional statement than a general non-value (e.g. undefined or null). Also, if someone asked me to evaluate the equality of karamozov's equations at 0, I'd literally say "that's undefined." So the JS undefined value seemed perfect to me (perfect as in the most elegant, not necessarily the most practical). For some reason I hadn't thought about it till you mentioned it, but I do like the idea of throwing an exception when a nonsensical comparison of NaNs happen. Of course that would be inimical to the way JS normally operates. I don't think what you're getting at is exactly Maybe. You're able to easily programmatically determine whether a Maybe has a value, whereas the equality of NaNs is basically unknowable. 0 - Talking in JS again, although it's similar for Java and other languages.
- yourad_io 12y ago
  > You can ignore invalid data for as long as you want, but you can also draw lines and say "it can't have been ignored if flow gets to here". (from comment I linked above) I was talking about this property of Maybe. I was thinking that assigning a NaN value to a boolean should probably be "fine" (no exception), but using that when branching would mean that this carried-forward-error (which the NaN represents, effectively) is just about to go beyond "infecting" just data, to affecting code flow. So, throw.