[Python-Dev] Not-a-Number (original) (raw)

Tim Peters tim.peters at gmail.com
Sat Apr 30 16:17:28 CEST 2011

[Greg Ewing]

Taking a step back from all this, why does Python allow NaNs to arise from computations at all?

[Mark Dickinson]

History, I think.  There's a c.l.p. message from Tim Peters somewhere saying something along the lines that he'd love to make (e.g.,) 1e300 * 1e300 raise an exception instead of producing an infinity, but dare not for fear of the resulting outcry from people who use the current behaviour.  Apologies if I've misrepresented what he actually said---I'm failing to find the exact message at the moment.

If it weren't for backwards compatibility, I'd love to see Python raise exceptions instead of producing IEEE special values:  IOW, to act as though the divide-by-zero, overflow and invalidoperation FP signals all produce an exception.

Exactly. It's impossible to create a NaN from "normal" inputs without triggering div-by-0 or invalid_operation, and if overflow were also enabled it would likewise be impossible to create an infinity from normal inputs. So, 20 years ago, that's how I arranged Kendall Square Research's default numeric environment: enabled those three exception traps by default, and left the underflow and inexact exception traps disabled by default. It's not just "naive" users initially baffled by NaNs and infinities; most of KSR's customers were heavy duty number crunchers, and they didn't know what to make of them at first either.

But experts do find them very useful (after climbing the 754 learning curve), so there was also a simple function call (from all the languages we supported - C, C++, FORTRAN and Pascal), to establish the 754 default all-traps-disabled mode:

 As a bonus, perhaps there could be a mode that allowed 'nonstop' arithmetic, under which infinities and nans were produced as per IEEE 754:

 with math.nonstoparithmetic():  ... But this is python-ideas territory.

All of which is just moving toward the numeric environment 754 was aiming for from the start: complete user control over which exception traps are and aren't currently enabled. The only quibble I had with that vision was its baffle-99%-of-users requirement that they all be disabled by default.

As Kahan wrote, it's called "an exception" because no matter what you do, someone will take exception to your policy ;-) That's why user control is crucial in a 754 environment. He wanted even more control than 754 recommends (in particular, he wanted the user to be able to specify which value was returned when an exception triggered; e.g., in some apps it may well be more useful for overflow to produce a NaN than an infinity, or to return the largest normal value with the correct sign).

Unfortunately, the hardware and academic types who created 754 had no grasp of how difficult it is to materialize their vision in software, and especially not of how very difficult it is to backstitch a pleasant wholly conforming environment into an existing language. As a result, I'm afraid the bulk of 754's features are stilled viewed as "a nuisance" by a vast majority of users :-(

More information about the Python-Dev mailing list