Skip to content

DOC: Surprising result of type promotion with Python's builtin type classes #27325

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

Closed
matthiasdiener opened this issue Sep 2, 2024 · 3 comments · Fixed by #27404
Closed

DOC: Surprising result of type promotion with Python's builtin type classes #27325

matthiasdiener opened this issue Sep 2, 2024 · 3 comments · Fixed by #27404

Comments

@matthiasdiener
Copy link
Contributor

matthiasdiener commented Sep 2, 2024

Issue with current documentation:

After reading Data type promotion in NumPy, NEP50, and Changes to NumPy data type promotion, the following type promotion scenario with Python's builtin scalar types (i.e., not scalar values) is still surprising to me:

>>> np.result_type(7, np.array([1], np.float32))
dtype('float32')  # Ok, the scalar value '7' does not impact type promotion per NEP50

>>> np.result_type(type(7), np.array([1], np.float32))
dtype('float64')  # Surprisingly, the *type* of the scalar value '7' does impact promotion

# Similar situations happen with Python's float and complex types.

What I assume happens is that Python's int type is converted internally to an np.int64 (this is on a 64-bit system):

>>> np.result_type(int)
dtype('int64')

, and np.int64 is then used for the type promotion.

However, I could not find this scenario explained in the docs.

cc @inducer

Idea or request for content:

I'd suggest adding an explanation to Data type promotion in NumPy, perhaps in the "Exceptions to the general promotion rules" section. I'd be happy to open a PR if that is helpful.

@mhvk
Copy link
Contributor

mhvk commented Sep 2, 2024

Hmm, that may simply be an oversight: I think the type really ought to have the same effect as passing in the number. ping @seberg

@seberg
Copy link
Member

seberg commented Sep 3, 2024

Not really an oversight, although one could have tried to change it. It just keeps doing what it always does, np.dtype(int) being the default integer dtype.
Within the context of result_type not going there would make sense, but in general np.dtype(int) probably needs to keep working, so...

@matthiasdiener
Copy link
Contributor Author

This is probably what you had in mind, but just to spell it out - could the rules be changed to "Like scalar values, Python's scalar types don't influence the result type"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy