On Apr 27, 8:07 am, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote: > Useful... maybe, conceptually sound... no. > Conceptually, NaN is the class of all elements which are not numbers, > therefore NaN = NaN.
NaN isn't really the class of all elements which aren't numbers. NaN is the result of a few specific IEEE 754 operations that cannot be computed, like 0/0, and for which there's no other reasonable substitute (e.g., infinity) for practical applications . In the real world, if we were doing the math with pen and paper, we'd stop as soon as we hit such an error. Equality is simply not defined for the operations that can produce NaN, because we don't know to perform those computations. So no, it doesn't conceptually follow that NaN = NaN, what conceptually follows is the operation is undefined because NaN causes a halt. This is what programming languages ought to do if NaN is compared to anything other than a (floating-point) number: disallow the operation in the first place or toss an exception. Any code that tries such an operation has a logic error and must be fixed. However, when comparing NaN against floating point numbers, I don't see why NaN == NaN returning false is any less conceptually correct than any other possible result. NaN's very existence implicitly declares that we're now making up the rules as we go along, so we might as well pick the simplest set of functional rules. Plus, floating point numbers violate our expectations of equality anyway, frequently in surprising ways. 0.1 + 0.1 + 0.1 == 0.3 is true with pen and paper, but likely false on your computer. It's even potentially possible to compare two floating point variables twice and get different results each time[1]! As such, we'd have this problem with defining equality even if NaN didn't exist. We must treat floating-point numbers as a special case in order to write useful working programs. This includes defining equality in a way that's different from what works for nearly every other data type. Adam [1] Due to register spilling causing intermediate rounding. This could happen with the x87 FPU since the registers were 80-bits wide but values were stored in RAM as 64-bits. This behavior is less common now, but hardly impossible. -- http://mail.python.org/mailman/listinfo/python-list
