On Thu, Oct 4, 2012 at 7:19 AM, MRAB firstname.lastname@example.org wrote:
Think of it this way:
Calculation A returns NaN for some reason
Calculation B also returns NaN for some reason
Have they really returned the same result? Just because they're both NaN doesn't mean that they're the _same_ NaN...
Someone who performs two calculations with float numbers should never compare their results for equality. It's really a bug to rely on that comparison:
# this is a bug # since the result of this comparison for regular numbers is unpredictable # so doesn't it really matter how this behaves when NaNs are compared? if a/b == c/d: # ...
On the other hand, comparing a number to another number, when none of the two numbers are involved in a calculation, is perfectly fine:
# this is not a bug # too bad that it won't work as expected # when input1 == input2 == 'nan' a = float(input1) b = float(input2) if a == b: # ...
So it seems to me your argument is this: "let's break the expectations of developers who are writing valid code, in order to partially meet the expectations of developers who are writing buggy code". If so, I disagree.