add inf and nan to math module

[ethanfurman]

BPO	23185
Nosy	@malemburg, @gvanrossum, @rhettinger, @mdickinson, @pitrou, @vstinner, @ericvsmith, @ethanfurman, @serhiy-storchaka
Files	math_inf_nan.patch math_inf_nan2.patch math_inf_nan3.patch math_inf_nan4.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/mdickinson'
closed_at = <Date 2015-01-11.11:56:31.326>
created_at = <Date 2015-01-07.16:33:44.317>
labels = ['easy', 'type-feature', 'library']
title = 'add inf and nan to math module'
updated_at = <Date 2015-01-13.09:37:33.819>
user = 'https://github.com/ethanfurman'

bugs.python.org fields:

activity = <Date 2015-01-13.09:37:33.819>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2015-01-11.11:56:31.326>
closer = 'mark.dickinson'
components = ['Library (Lib)']
creation = <Date 2015-01-07.16:33:44.317>
creator = 'ethan.furman'
dependencies = []
files = ['37633', '37634', '37635', '37647']
hgrepos = []
issue_num = 23185
keywords = ['patch', 'easy']
message_count = 26.0
messages = ['233580', '233581', '233582', '233583', '233585', '233588', '233591', '233593', '233594', '233595', '233596', '233598', '233601', '233602', '233607', '233630', '233674', '233692', '233720', '233737', '233842', '233843', '233894', '233912', '233917', '233920']
nosy_count = 11.0
nosy_names = ['lemburg', 'gvanrossum', 'rhettinger', 'mark.dickinson', 'pitrou', 'vstinner', 'eric.smith', 'stutzbach', 'ethan.furman', 'python-dev', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue23185'
versions = ['Python 3.5']

[ethanfurman]

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?

[vstinner]

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

[mdickinson]

Sounds good to me.

Do we add a math.neginf

IMO no: -inf should be fine.

[mdickinson]

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.

[mdickinson]

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.

[vstinner]

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

[mdickinson]

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).

[serhiy-storchaka]

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'

[pitrou]

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

[mdickinson]

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.

[mdickinson]

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

AAAARRGH!

[mdickinson]

Here's a patch.