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: https://github.com/python/cpython/commit/9ab44b509a935011beb8e9108a2271ee728e8ad4#diff-b7e3652f51768cec742ef07326413ad0

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

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.

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

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.

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

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

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!

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

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.

> So this justifies things like `sqrt(-0.0)` giving a zero result (rather than being considered invalid)

Well, I didn’t noticed that the wolf was already in the henhouse! This choice seems disputable for me because it is precisely a case where f(-0.0) should NOT behave as f(+0.0). The treatment of functions like atan2 and 1/x lets me think that the standards tend to follow the results of one-sided limits. So, I’m surprised that pow and sqrt functions in IEEE754/C99 standards are treated in this unfettered way.

That being said, I’m not involved at all in IEEE/C99 standards; that’s probably why I look at this from a pristine point of view. Provided that I accept the "axioms" of these standards, the explanations you both give are very convincing. I understand well that self-consistency is utmost important, maybe even above consistency with mathematical rules. Also, I concede that the standards are well-established and considerable efforts have been made to validate their different implementations (including Python).

BTW, congratulations to you guys that made the effort to understand the standards and rigorously implementing them in Python!