On 4/27/2012 17:39, Adam Skutt wrote:
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.
Mathematics is more than arithmetics with real numbers. We can use FP
too (we actually do that!). We can say that NaN = NaN but that's just an
exception we're willing to make. We shouldn't say that the equivalence
relation rules shouldn't be followed just because *sometimes* we break them.
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.
Maybe wrong expectations of equality, since 0.1 (the real number) is
/not/ a floating point.
Don't confuse the representation of floating points with the floating
point themselves.
It's even
potentially possible to compare two floating point variables twice and
get different results each time[1]!
We should look at the specification and not the single implementations.
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.
Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list
