[Python-ideas] Floating point contexts in Python core
oscar.j.benjamin at gmail.com
Thu Oct 11 00:42:06 CEST 2012
On 9 October 2012 02:07, Guido van Rossum <guido at python.org> wrote:
> On Mon, Oct 8, 2012 at 5:32 PM, Oscar Benjamin
> <oscar.j.benjamin at gmail.com> wrote:
>> On 9 October 2012 01:11, Guido van Rossum <guido at python.org> wrote:
>>> On Mon, Oct 8, 2012 at 5:02 PM, Greg Ewing <greg.ewing at 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
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  as well as numpy , gmpy ,
sympy  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
More information about the Python-ideas