[issue32171] Inconsistent results for fractional power of -infinity

[Pierre Denis]

Pierre Denis  added the comment:

> 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!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32171] Inconsistent results for fractional power of -infinity

[Tim Peters]

Tim Peters  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32171] Inconsistent results for fractional power of -infinity

[Mark Dickinson]

Mark Dickinson  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32171] Inconsistent results for fractional power of -infinity

[Pierre Denis]

Pierre Denis  added the comment:

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!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32171] Inconsistent results for fractional power of -infinity

[Tim Peters]

Tim Peters  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32171] Inconsistent results for fractional power of -infinity

[Mark Dickinson]

Mark Dickinson  added the comment:

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

--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32171] Inconsistent results for fractional power of -infinity

[Mark Dickinson]

Mark Dickinson  added the comment:

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.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32171] Inconsistent results for fractional power of -infinity

[Mark Dickinson]

Mark Dickinson  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32171] Inconsistent results for fractional power of -infinity

[Mark Dickinson]

Mark Dickinson  added the comment:

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.

--
nosy:  -tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32171] Inconsistent results for fractional power of -infinity

[Tim Peters]

Tim Peters  added the comment:

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

--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32171] Inconsistent results for fractional power of -infinity

[Ned Deily]

Change by Ned Deily :


--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32171] Inconsistent results for fractional power of -infinity

[Pierre Denis]

New submission from Pierre Denis :

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

--
messages: 307256
nosy: pdenis
priority: normal
severity: normal
status: open
title: Inconsistent results for fractional power of -infinity
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com