Incorrect NaN handling

[waldemarhorwat]

The proposed specification of regular comparisons involving NaNs produces incorrect results per the IEEE 754 spec, which states that a NaN should compare as neither equal, less than, nor greater than anything.

[jessealama]

Thanks for spotting that. I took a look at the spec again. If I understand it correctly, we can compare quiet NaN (which is the only kind of NaN that we intend to model in this proposal, as it currently stands) with any other value using equals, without throwing. If that's right, the next question is: what value should be returned? Looking again at the spec, you're right that (quiet) NaN should not be equal to anything else. I guess the equals function could return undefined in that case?

undefined is an odd thing for a predicate to return, though. I wonder if these considerations suggest reverting to an earlier line of thinking with this proposal, where we only had a cmp operation (no lessThan or equals) that would return -1, 0, 1, and undefined.

As for lessThan, I see you're right. It looks like an exception ought to be thrown if either argument is NaN, even a quiet NaN. Perhaps we should throw an exception (RangeException seems most appropriate to me).

Does that match your understanding?

[littledan]

Thanks for catching this. Let's just follow the IEEE 754 spec, as we do for Number, and return false. The intention of this proposal is to follow IEEE 754, and I hope it's OK for us to land fixes like this during Stage 2.

[jessealama]

I think, after the various iterations we've gone through in the last couple of months (e.g., #162 and #158) I believe that we properly handle NaNs now.