On 9 October 2012 02:07, Guido van Rossum <guido@python.org> wrote:
On Mon, Oct 8, 2012 at 5:32 PM, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
On 9 October 2012 01:11, Guido van Rossum <guido@python.org> wrote:
On Mon, Oct 8, 2012 at 5:02 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
So the question that really needs to be answered, I think, is not "Why is NaN == NaN false?", but "Why doesn't NaN == anything raise an exception, when it would make so much more sense to do so?"
Because == raising an exception is really unpleasant. We had this in Python 2 for unicode/str comparisons and it was very awkward.
Nobody arguing against the status quo seems to care at all about numerical algorithms though. I propose that you go find some numerical mathematicians and ask them.
The main purpose of quiet NaNs is to propagate through computation ruining everything they touch. In a programming language like C that lacks exceptions this is important as it allows you to avoid checking all the time for invalid values, whilst still being able to know if the end result of your computation was ever affected by an invalid numerical operation. The reasons for NaNs to compare unequal are no doubt related to this purpose.
It is of course arguable whether the same reasoning applies to a language like Python that has a very good system of exceptions but I agree with Guido that raising an exception on == would be unfortunate. How many people would forget that they needed to catch those exceptions? How awkward could your code be if you did remember to catch all those exceptions? In an exception handling language it's important to know that there are some operations that you can trust.
If we want to do *anything* I think we should first introduce a floating point context similar to the Decimal context. Then we can talk.
The other thread has gone on for ages now and isn't going anywhere. Guido's suggestion here is much more interesting (to me) so I want to start a new thread on this subject. Python's default handling of floating point operations is IEEE-754 compliant which in my opinion is the obvious and right thing to do. However, Python is a much more versatile language than some of the other languages for which IEEE-754 was designed. Python offers the possibility of a very rich approach to the control and verification of the accuracy of numeric operations on both a function by function and code block by code block basis. This kind of functionality is already implemented in the decimal module [1] as well as numpy [2], gmpy [3], sympy [4] and no doubt other numerical modules that I'm not aware of. It would be a real blessing to numerical Python programmers if either/both of the following were to occur: 1) Support for calculation contexts with floats 2) A generic kind of calculation context manager that was recognised widely by the builtin/stdlib types and also by third party numerical packages. Oscar References: [1] http://docs.python.org/library/decimal.html#context-objects [2] http://docs.scipy.org/doc/numpy/reference/generated/numpy.seterr.html#numpy.... [3] https://gmpy2.readthedocs.org/en/latest/mpfr.html [4] http://docs.sympy.org/dev/modules/mpmath/contexts.html