Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

DOC: Fixup promotion doc #27102

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

Merged
merged 1 commit into from
Aug 4, 2024
Merged

DOC: Fixup promotion doc #27102

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions 13 doc/source/reference/arrays.promotion.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -146,6 +146,7 @@ The result dtype has a precision as low as possible without appearing to the
left of either input dtype in the diagram.

Note the following specific rules and observations:

1. When a Python ``float`` or ``complex`` interacts with a NumPy integer
the result will be ``float64`` or ``complex128`` (yellow border).
NumPy booleans will also be cast to the default integer.[#default-int]
Expand Down Expand Up @@ -185,6 +186,7 @@ but the operation will sometimes dictate that result.
Division always returns floating point values and comparison always booleans.

This leads to what may appear as "exceptions" to the rules:

* NumPy comparisons with Python integers or mixed precision integers always
return the correct result. The inputs will never be cast in a way which
loses precision.
Expand All @@ -206,6 +208,7 @@ NumPy extends the promotion to non-numerical types, although in many cases
promotion is not well defined and simply rejected.

The following rules apply:

* NumPy byte strings (``np.bytes_``) can be promoted to unicode strings
(``np.str_``). However, casting the bytes to unicode will fail for
non-ascii characters.
Expand Down Expand Up @@ -243,14 +246,14 @@ are not relevant to the final results and where the use of incorrect byte-order
could drastically slow down evaluation.


.. [#hist-reasons]: To a large degree, this may just be for choices made early
.. [#hist-reasons] To a large degree, this may just be for choices made early
on in NumPy's predecessors. For more details, see `NEP 50 <NEP50>`.

.. [#NEP50]: See also `NEP 50 <NEP50>` which changed the rules for NumPy 2.0.
Previous versions of NumPy would sometimes return higher precision results
based on the input value of Python scalars.
.. [#NEP50] See also :ref:`NEP 50 <NEP50>` which changed the rules for
NumPy 2.0. Previous versions of NumPy would sometimes return higher
precision results based on the input value of Python scalars.
Further, previous versions of NumPy would typically ignore the higher
precision of NumPy scalars or 0-D arrays for promotion purposes.

.. [#default-int]: The default integer is marked as ``int64`` in the schema
.. [#default-int] The default integer is marked as ``int64`` in the schema
but is ``int32`` on 32bit platforms. However, normal PCs are 64bit.
Loading
Morty Proxy This is a proxified and sanitized view of the page, visit original site.