On Sun, 29 May 2011 23:31:19 +0000, Steven D'Aprano wrote: >> That's overstating it. There's a good argument to be made for raising an >> exception. > > If so, I've never heard it, and I cannot imagine what such a good > argument would be. Please give it.
Exceptions allow you to write more natural code by ignoring the awkward cases. E.g. writing "x * y + z" rather than first determining whether "x * y" is even defined then using a conditional. >> Bear in mind that an exception is not necessarily an error, >> just an "exceptional" condition. > > True, but what's your point? Testing two floats for equality is not an > exceptional condition. NaN itself is an exceptional condition which arises when a result is undefined or not representable. When an operation normally returns a number but a specific case cannot do so, it returns not-a-number. The usual semantics for NaNs are practically identical to those for exceptions. If any intermediate result in a floating-point expression is NaN, the overall result is NaN. Similarly, if any intermediate calculation throws an exception, the calculation as a whole throws an exception. If x is NaN, then "x + y" is NaN, "x * y" is NaN, pretty much anything involving x is NaN. By this reasoning both "x == y" and "x != y" should also be NaN. But only the floating-point types have a NaN value, while bool doesn't. However, all types have exceptions. >>> The correct answer to "nan == nan" is False, they are not equal. >> >> There is no correct answer to "nan == nan". > > Why on earth not? Why should there be a correct answer? What does NaN actually mean? Apart from anything else, defining "NaN == NaN" as False means that "x == x" is False if x is NaN, which violates one of the fundamental axioms of an equivalence relation (and, in every other regard, "==" is normally intended to be an equivalence relation). The creation of NaN was a pragmatic decision on how to handle exceptional conditions in hardware. It is not holy writ, and there's no fundamental reason why a high-level language should export the hardware's behaviour verbatim. >> Arguably, "nan != nan" should also be false, >> but that would violate the invariant "(x != y) == !(x == y)". > > I cannot imagine what that argument would be. Please explain. A result of NaN means that the result of the calculation is undefined, so the value is "unknown". If x is unknown and y is unknown, then whether x is equal to y is itself unknown, and whether x differs from y is also unknown. -- http://mail.python.org/mailman/listinfo/python-list