-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discrepancy between math.pow(0.0, -inf) and 0.0**-inf #88505
Comments
For floats x and y, x ** y and math.pow(x, y) mostly agree. There are three points of difference:
That third discrepancy is a surprising one: in particular, it's the only case where math.pow does not follow IEEE 754 rules. Note that the math.pow behaviour is not accidental. The special cases were based on C99 Annex F (and are documented to do so), but the standards themselves have evolved here. In chronological order:
For Python 3.11, I propose changing the behaviour of math.pow in this corner case so that it returns inf instead of raising. This would make math.pow conformant with IEEE 754, consistent with C11 and later, and consistent with the built-in pow function. |
+1. Although, to be fair, I'd personally be happy if (+-0)**inf returned, say, 1.375 instead ;-) |
+1 from me as well. |
What about math.pow(0.0, -1.0)? Should it return -inf or raise ZeroDivisionError? And what about math.pow(-0.0, -inf)? Should it return inf, -inf or nan or raise an exception? |
Neither: it should raise ValueError, as it does now. This matches IEEE 754 along with the math module's mapping of IEEE 754 floating-point exceptions to Python exceptions.
This should return inf, the same as math.pow(0.0, -inf). The relevant clauses of the C standard and IEEE 754 cover both these cases; I should have written |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: