Proposal:

  math.nan = float('nan')
  math.inf = float('inf')

Guido's approval:

https://mail.python.org/pipermail/python-ideas/2015-January/030775.html

Followup question:

Do we add a math.neginf, or somesuch, for float('-inf')? Or just use -math.inf?

Do we add a math.neginf, or somesuch, for float('-inf')? Or just use -math.inf?

I would prefer to only add inf.

It looks like float("-inf") and -float("inf") have exactly the same IEEE 754 representation (at least on my x86_64 CPU):

>>> struct.pack("d", float("-inf")) == struct.pack("d", -float("inf"))
True

Sounds good to me.

Do we add a math.neginf

IMO no: -inf should be fine.

float("-inf") and -float("inf") have exactly the same IEEE 754 representation

Indeed: there's only one negative infinity (and only one positive infinity) in IEEE 754 binary64 format.

Implementation suggestion: if possible, use the _Py_dg_stdnan and _Py_dg_infinity functions from Python/dtoa.c. These are a little safer than the Py_NAN and Py_HUGE_VAL macros, and will give results consistent with the float("inf") and float("nan") constructions.

Oh, NaN can be signed?

>>> struct.pack("d", float("nan"))
b'\x00\x00\x00\x00\x00\x00\xf8\x7f'
>>> struct.pack("d", float("-nan"))
b'\x00\x00\x00\x00\x00\x00\xf8\xff'
>>> struct.pack("d", -float("nan"))
b'\x00\x00\x00\x00\x00\x00\xf8\xff'
>>> struct.pack("d", -float("-nan"))
b'\x00\x00\x00\x00\x00\x00\xf8\x7f'

Why does Python return the same representation for positive and negative NaN?

>>> float("nan")
nan
>>> float("-nan")
nan

Why does Python return the same representation for positive and negative NaN?

History, perhaps? In any case, the sign of a NaN isn't useful information in the same way that the sign of an infinity is. The IEEE 754 standard explicitly refuses to attach any meaning to the sign bit of a NaN. And if we were aiming for a full and faithful representation of NaNs, we'd want to output the payload, too (which is just about as meaningless / meaningful as the sign bit).

There are several different NaNs.

>>> x = struct.unpack('d', b'\x00\x00\x00\x00\x00\x00\xf8\x7f')[0]
>>> x
nan
>>> x == x
False
>>> struct.pack('d', x)
b'\x00\x00\x00\x00\x00\x00\xf8\x7f'
>>> x = struct.unpack('d', b'\x00\x00\x00\x00\x00\x00\xf9\x7f')[0]
>>> x
nan
>>> x == x
False
>>> struct.pack('d', x)
b'\x00\x00\x00\x00\x00\x00\xf9\x7f'

Interesting, but 0*inf and inf-inf return values with the same representation as float('-nan'), not float('nan').

>>> inf = float("inf")
>>> struct.pack('d', 0*inf)
b'\x00\x00\x00\x00\x00\x00\xf8\xff'
>>> struct.pack('d', inf-inf)
b'\x00\x00\x00\x00\x00\x00\xf8\xff'
>>> struct.pack('d', float('nan'))
b'\x00\x00\x00\x00\x00\x00\xf8\x7f'
>>> struct.pack('d', float('-nan'))
b'\x00\x00\x00\x00\x00\x00\xf8\xff'

By tweaking the grammar we can have math.-inf.

but 0*inf and inf-inf return values with the same representation as float('-nan'), not float('nan')

Right: that's because Intel's "default" NaN (i.e., the float it produces as a result of any invalid operation) has its sign bit set.

By tweaking the grammar we can have math.-inf.

AAAARRGH!

Here's a patch.

Thanks for the review comments. Here's an updated patch taking the review comments into account (and fixing the spelling of PY_NAN, which should have been Py_NAN).

One more patch, fixing a misplaced period.

"History, perhaps? In any case, the sign of a NaN isn't useful information in the same way that the sign of an infinity is. The IEEE 754 standard explicitly refuses to attach any meaning to the sign bit of a NaN. And if we were aiming for a full and faithful representation of NaNs, we'd want to output the payload, too (which is just about as meaningless / meaningful as the sign bit)."

So I understand that adding a math.neg_nan would be useless. As adding one constant per possible "NaN" value :-) If I recall correctly the IEEE 754 standard, there is not single NaN value, but a range of NaN.

"Two kinds of NaN: a quiet NaN (qNaN) and a signaling NaN (sNaN). A NaN may carry a payload that is intended for diagnostic information indicating the source of the NaN. The sign of a NaN has no meaning, but it may be predictable in some circumstances." says Wikipedia.

Well, the current definition of math.nan makes sense, it's the same value than float("nan").

Note: On python-ideas, I asked if math.nan and math.inf should be singleton (as it was requested for float("0.0") in issue bpo-4024). The answer is no.

I have an updated patch taking into account the most recent review comments (for which thanks!), but it's at home; I'll upload it this evening (UTC+00:00).

New patch, addressing review comments.

Except of my small suggestion on the doc (see the review), math_inf_nan4.patch looks good to me.

May be make math.inf and math.nan special objects so that for all x (except inf and nan):

x < math.inf
x > -math.inf
not (x < math.nan)
not (x > math.nan)

2015-01-09 8:16 GMT+01:00 Serhiy Storchaka <report@bugs.python.org>:

May be make math.inf and math.nan special objects so that for all x (except inf and nan):

What do you mean? Implement a subtype of float and override some methods?

x < math.inf
x > -math.inf

It's already the case for int, float and decimal.Decimal.

not (x < math.nan)
not (x > math.nan)

Comparison to nan always return False.

I would be better to raise an error when nan is compared to other numbers (I mean operations like a>b, not a==b), but Python was not designed like that (nor the IEEE 754?).

>>> sorted((nan, 1, nan, 2))
[nan, 1, nan, 2]

Sorting with NaN is a common issue :-/ See for example:
https://stackoverflow.com/questions/4240050/python-sort-function-breaks-in-the-presence-of-nan

Anyway, changing NaN behaviour is out of the scope of this issue!

New changeset cf4bf577749c by Mark Dickinson in branch 'default':
Issue bpo-23185: add math.inf and math.nan constants.
https://hg.python.org/cpython/rev/cf4bf577749c

Committed. Thanks for all the helpful review comments!

Should inf and nan be added to cmath too? It has e and pi and isnan() and isinf()...

Also complex(0, math.nan) a value that is printed as "nanj" and complex("nanj") parses and returns such a value, so the point could be made that there should be a constant named complex.nanj.

Guido van Rossum added the comment:

Should inf and nan be added to cmath too? It has e and pi and isnan() and isinf()...

Also complex(0, math.nan) a value that is printed as "nanj" and complex("nanj") parses and returns such a value, so the point could be made that there should be a constant named complex.nanj.

Since it's a different module and we are talking about more and
different constants, I suggest to open a new issue.

Should inf and nan be added to cmath too?

Hmm; probably, yes. I'll open an issue.

so the point could be made that there should be a constant named complex.nanj

Yes, I suppose it could (along with infj, of course). I don't like it much, and I suspect it would get almost no uses. complex(0, inf) and complex(0, nan) seem like good enough spellings.

Opened issue bpo-23229.