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

Alexander Belopolsky alexander.belopolsky at gmail.com
Fri Apr 29 18:35:55 CEST 2011

On Fri, Apr 29, 2011 at 11:31 AM, Robert Kern <robert.kern at gmail.com> wrote: ..

And in fact, 0.0/0.0 is covered by the more general rule that x/0.0 raises ZeroDivisionError, not a rule that converts IEEE-754 INVALID exceptions into Python exceptions.

It is unfortunate that official text of IEEE-754 is not freely available and as a result a lot of discussion in this thread is based on imperfect information.

I find Kahan's "Lecture Notes on the Status of IEEE Standard 754 for Binary Floating-Point Arithmetic" [1] a reasonable reference in the absence of the official text. According to Kahan's notes, INVALID operation is defined as follows:

""" Exception: INVALID operation.

Signaled by the raising of the INVALID flag whenever an operation's operands lie outside its domain, this exception's default, delivered only because any other real or infinite value would most likely cause worse confusion, is NaN , which means “ Not a Number.” IEEE 754 specifies that seven invalid arithmetic operations shall deliver a NaN unless they are trapped:

real √(Negative) , 0*∞ , 0.0/0.0 , ∞/∞,
REMAINDER(Anything, 0.0) , REMAINDER( ∞, Anything) ,
∞ - ∞ when signs agree (but ∞ + ∞ = ∞ when signs agree).

Conversion from floating-point to other formats can be INVALID too, if their limits are violated, even if no NaN can be delivered. """

In contrast, Kahan describes DIVIDE by ZERO exception as "a misnomer perpetrated for historical reasons. A better name for this exception is 'Infinite result computed Exactly from Finite operands.'"

Other operations that produce a NaN and issue an IEEE-754 INVALID signal do not raise a Python exception.

Some do:

math.sqrt(-1) Traceback (most recent call last): File "", line 1, in ValueError: math domain error

I think the only exception are the operations involving infinity. The likely rationale is that since infinity is not produced by python arithmetics, those who use inf are likely to expect inf*0 etc. to produce nan.

The following seems to be an oversight:

1e300 * 1e300 inf

compared to

1e300 ** 2 Traceback (most recent call last): File "", line 1, in OverflowError: (34, 'Result too large')

[1] http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps

More information about the Python-Dev mailing list