Thanks to visit codestin.com
Credit goes to github.com

Skip to content

The type conversion problem of array operations #11485

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.

Sign up for GitHub

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

Jump to bottom
Closed
yydcnjjw opened this issue Jul 3, 2018 · 6 comments
Closed

The type conversion problem of array operations #11485

yydcnjjw opened this issue Jul 3, 2018 · 6 comments
Labels
00 - Bug component: numpy.dtype

Comments

@yydcnjjw
Copy link

yydcnjjw commented Jul 3, 2018 

a = np.array([0,255], dtype='uint8')
output：array([  0, 255], dtype=uint8)

a * 2
output：array([  0, 254], dtype=uint8) // become  the top eight after the operation

b = np.array([1, 255], dtype='uint8')
b * 256
output：array([  256, 65280], dtype=uint16) // Automatically become the type of uint16

The change of the variable type depends on the minimum of the array?
@charris
Copy link
Member

charris commented Jul 3, 2018

Hmm, that looks like a bug, and maybe a very old one. The array data type should dominate the scalar unless a float is involved. It may be intended behavior, but I cannot think why.

@seberg
Copy link
Member

seberg commented Jul 3, 2018

Its the old problem of "oh a scalar, lets see what the minimum type is when considering the other array", and if the arrays type happens to be good enoug, it uses that... I.e. the 256 scalar is too large for uint8, so it decides that uint16 is necessary, but 2 fits uint8, so that is taken in the first example.

@charris
Copy link
Member

charris commented Jul 3, 2018

Arggghhhh, I didn't know that was the policy, that's awful. I thought that within the same kind, the array type was always dominant, which is simple to understand and has the virtue that the output type only depends on the code, not the code and the input values.

@seberg
Copy link
Member

seberg commented Jul 3, 2018 via email

@eric-wieser
Copy link
Member

eric-wieser commented Jul 10, 2018 •
edited
Loading

Relevant is #10322, which here looks like:

>>> np.result_type(np.int8, 2)
dtype('int8')
>>> np.result_type(np.int8, 256)
dtype('int16')

@h-vetinari h-vetinari mentioned this issue Jan 25, 2019
Closed
@seberg
Copy link
Member

seberg commented Jan 30, 2024

Closing, this is effectively fixed by NEP 50 adoption in main/NumPy 2.0.

@seberg seberg closed this as completed Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug component: numpy.dtype
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@seberg @charris @eric-wieser @mattip @yydcnjjw