Inconsistent results for fractional power of -infinity

[piedenis]

BPO	32171
Nosy	@tim-one, @mdickinson, @piedenis

^{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 = None
closed_at = <Date 2017-11-29.22:03:03.702>
created_at = <Date 2017-11-29.21:29:52.072>
labels = ['3.8', 'type-bug', '3.7', 'invalid']
title = 'Inconsistent results for fractional power of -infinity'
updated_at = <Date 2017-12-01.17:33:16.967>
user = 'https://github.com/piedenis'

bugs.python.org fields:

activity = <Date 2017-12-01.17:33:16.967>
actor = 'pdenis'
assignee = 'none'
closed = True
closed_date = <Date 2017-11-29.22:03:03.702>
closer = 'mark.dickinson'
components = []
creation = <Date 2017-11-29.21:29:52.072>
creator = 'pdenis'
dependencies = []
files = []
hgrepos = []
issue_num = 32171
keywords = []
message_count = 11.0
messages = ['307256', '307258', '307259', '307260', '307261', '307262', '307263', '307265', '307281', '307338', '307397']
nosy_count = 3.0
nosy_names = ['tim.peters', 'mark.dickinson', 'pdenis']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue32171'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5', 'Python 3.6', 'Python 3.7', 'Python 3.8']

[piedenis]

Python returns inconsistent results when negative infinity is raised to a non-integer power. This happens with the ** operator as well as with the pow and math.pow functions. The most blatant symptom occurs with power 0.5, which is expectedly equivalent to a square root:

>>> float('-inf') ** 0.5
inf
>>> pow(float('-inf'), 0.5)
inf
>>> import math
>>> math.pow(float('-inf'), 0.5)
inf

Mathematically, these operations are invalid if we restrict to real numbers. Also, if we extend to complex numbers, the results are wrong since the result should be infj, which is the value returned by cmath.sqrt(float('-inf')).

IMHO, there are three possible ways to fix this:

1. raise an exception ValueError
2. return nan
3. return (nan + nanj)

Discussion:

• Solution 1) is consistent with current handling of *finite* negative base with non-integer exponent; also, it is consistent with math.sqrt(float('-inf')), which raises ValueError.

• I expected solution 2) to be more in line with IEEE754 … until I read the following statement in this specification: "pow(x, y) signals the invalid operation exception for finite x<0 and finite non-integer y". I’m not an expert of this topic but I think that there is miss here since IEEE754 does not state what happens for *infinite* x<0 and finite non-integer y.

• Solution 3) emphasizes the fact that, although the result is generally undefined, it belongs to complex type.

• In any case, the solution should be consistent also with the case with negative fractional exponent… even if I would tend to accept that (float('-inf')**-0.5) == 0.0 is mathematically sensible!

• The test assertions shall be updated in Python standard test suite (test_float.py).

Note that Python 2.6 behaves consistently for all negative bases, finite or not finite: it raises ValueError exception with the message "negative number cannot be raised to a fractional power". The behavior described here seems to be introduced in this commit: 9ab44b5#diff-b7e3652f51768cec742ef07326413ad0

[tim-one]

As a comment in the referenced patch says, the intent of the patch was to make behavior match the C99 spec. Among other things, C99's annex F (section F.9.4.4 "The pow functions") says:

"""
— pow(−∞, y) returns −0 for y an odd integer < 0.
— pow(−∞, y) returns +0 for y < 0 and not an odd integer.
— pow(−∞, y) returns −∞ for y an odd integer > 0.
— pow(−∞, y) returns +∞ for y > 0 and not an odd integer.
"""

So the case you show is doing what the standard specifies, under the last of those (y=0.5, which is > 0 and not an odd integer).

[mdickinson]

We follow C99 for this case, which says (C99 F 9.4.4):

pow(−∞, y) returns +∞ for y > 0 and not an odd integer.

Oddly, this clause seems to be missing from section 9.2.1 of IEEE 754. Nevertheless, I believe it's the right thing to do.

IEEE 754 _does_ say:

pow (x, y) signals the invalid operation exception for finite x < 0 and finite non-integer y.

The omission of -inf here is notable, and suggests that it's _not_ intended that the pow(-inf, 0.5) case should be considered invalid.

[mdickinson]

See also this posting [1], where the omission is discussed, and Vincent Lefevre suggests that the behaviour should be:

pow (±inf, y) is +inf with no exception
for finite y > 0 and not an odd integer

[1] http://grouper.ieee.org/groups/754/email/msg03969.html

[mdickinson]

Having read through the rest of that grouper.ieee.org, thread, there doesn't seem to be any disagreement with what Vincent suggests. So I believe that Python's behaviour is consistent with (a) C99, (b) MPFR, and (c) the spirit of IEEE 754. Closing here.

[mdickinson]

Sorry, Tim. It looks as though I un-nosied you (de-nosied you?) accidentally. Not sure how that happened.

[tim-one]

No worries, Mark :-) Odd things happen sometimes when people are editing near the same time. BTW, of course I agree with closing this!

[piedenis]

Thanks, Tim & Mark. This indeed clarifies and gives a good rationale on Python implementation. Nevertheless, despite the authority arguments, I continue to wonder what is the rationale for these specifications. Probably the debate should move to the standards C99 and IEEE754 themselves.
Agreed to close the ticket on Python... waiting a change to the standards!

[mdickinson]

I continue to wonder what is the rationale for these specifications

So I can't speak with any authority: I'm only an interested bystander when it comes to IEEE 754, but I believe this particular behaviour stems from two desires:

1. The desire that for a general floating-point operation f, f(-0.0) should behave in much the same way as f(+0.0): if one is valid, the other should be too, and in the majority of cases they should give the same result (possibly modulo sign of zero again, and noting that in cases like atan2 there are good reasons to have 0.0 and -0.0 give different results). So this justifies things like sqrt(-0.0) giving a zero result (rather than being considered invalid) and log(-0.0) giving -inf. In the case of interest, this justifies the rule pow(-0.0, y) = 0.0 for y positive and not an odd integer. Note the sign of the result there: what's really going on is that we can't assign a sensible sign to the result (except when y is an integer), and so it makes sense to return the more "standard" of the two zeros.

2. The desire to respect symmetries in pow (and other functions). In particular, we should have pow(1/x, y) = 1/pow(x, y). Now plug in x = -0.0 and y = 0.5, and we get:

   pow(-inf, 0.5) = 1/pow(-0.0, 0.5) = 1/0.0 = inf

I guess also: historically, C99 Annex F got there first on specifying corner cases for the more interesting mathematical operations (IEEE 754-1985 only covered basic arithmetic operations; coverage of the transcendental functions and friends didn't happen until IEEE 754-2008), and without a good reason to do otherwise, it makes sense for IEEE 754-2008 to follow what C99 did. So perhaps we should really be asking the C standardisation folks for their rationale.

Don't ask me about sqrt(-0.0) returning -0.0 rather than 0.0, though. I have no idea on that one. (Well, I have some ideas about _why_ that ended up being the IEEE 754 specification. I'm still not convinced that it was the right thing to do.)

[tim-one]

Mark, indeed, in the email from Vincent Lefevre you linked to, his entire argument was: (a) we already specified what happens when the base is a zero; so, (b) for each of the six pow(a_zero, y) cases we specified, derive a matching rule for an inf base via:

pow(an_inf, y) = 1/pow(1/an_inf, y) = 1/pow(the_same_sign_zero, y)

Looking at the other msgs in that thread, everyone found that instantly compelling.

Pierre, give up ;-) These standards are years old already, so it's exceedingly unlikely any specified behavior will ever change again, for "backward compatibility" reasons alone.