You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
BUG: Inconsistent behaviour of return type of int64.__pow__ #8809
changed the title [-]BUG: Inconsistent behaviour of return type of uint64.__pow__[/-][+]BUG: Inconsistent behaviour of return type of __pow__[/+]on Mar 22, 2017
changed the title [-]BUG: Inconsistent behaviour of return type of __pow__[/-][+]BUG: Inconsistent behaviour of return type of int64.__pow__[/+]on Mar 22, 2017
Output: (p = python, i = int, u = uint, s = scalar, 0,1,2 = 0d,1d,2d)
p si 0i 1i 2i su 0u 1u 2u
p p i i i i f f u u
si i i i i i f f u u
0i i i i i i f f u u
1i i i i i i i i f f
2i i i i i i i i f f
su f f f i i u u u u
0u f f f i i u u u u
1u u u u f f u u u u
2u u u u f f u u u u
This is the result of NumPy's "type demotion" rules for mixed scalar/array operations. When a positive-dimensional array and a 0-dimensional array or array scalar participate in a binary operation, the scalar gets "type demoted" based on its value, so 3 gets demoted to uint8, and the result dtype is uint64. On the other hand, when both operands are scalar, NumPy treats 3 as having dtype np.int_, which is signed, and numpy can't find an integer dtype big enough to hold all values of uint64 and int_, so it uses float64.
The Stack Overflow question also showed what looked like NumPy using a floating-point power implementation for the uint64 output case. I don't know why that was happening, but it seems to have been fixed at some point after the question was asked.
Activity
[-]BUG: Inconsistent behaviour of return type of uint64.__pow__[/-][+]BUG: Inconsistent behaviour of return type of __pow__[/+][-]BUG: Inconsistent behaviour of return type of __pow__[/-][+]BUG: Inconsistent behaviour of return type of int64.__pow__[/+]ahaldane commentedon May 8, 2017
Isn't this a problem with all ufuncs?
Extending your example a little, and testing for multiplication
a*b:Output: (p = python, i = int, u = uint, s = scalar, 0,1,2 = 0d,1d,2d)
the power operation gives the same table.
ahaldane commentedon May 8, 2017
Also, this is loosely related to #8231 and the related discussions on the mailing list last year about integer powers:
First in June under subject "Integers to integer powers, let's make a decision ", then in October under the same thread plus others like "fpower".
(but to be clear, this is a somewhat different issue)
eric-wieser commentedon Jan 4, 2018
The shape inconsistencies is #10322 again
FrozenBob commentedon Nov 16, 2020
This is the result of NumPy's "type demotion" rules for mixed scalar/array operations. When a positive-dimensional array and a 0-dimensional array or array scalar participate in a binary operation, the scalar gets "type demoted" based on its value, so 3 gets demoted to uint8, and the result dtype is uint64. On the other hand, when both operands are scalar, NumPy treats 3 as having dtype np.int_, which is signed, and numpy can't find an integer dtype big enough to hold all values of uint64 and int_, so it uses float64.
This is documented in the docs for
numpy.result_type. (The implementation is inconvert_datatype.c.)The Stack Overflow question also showed what looked like NumPy using a floating-point power implementation for the uint64 output case. I don't know why that was happening, but it seems to have been fixed at some point after the question was asked.
seberg commentedon Nov 19, 2022
Closing as duplicate of gh-22624