Skip to content
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

doc: define complex scalar <op> fp array #871

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ev-br
Copy link

@ev-br ev-br commented Dec 10, 2024

Address gh-841, which continued from #478. If I read the discussion right, there is a general support for allowing binary operations between a python complex scalar and a floating-point array.

The proposed wording tries to be explicit about preserving the precision: (1j*single_precision_array).dtype == single_precision_complex and (1j*double_precision_array).dtype == double_precision_complex. As long as we don't have to worry about half- or extended precision, being explicit feels simplest.

@rgommers rgommers added this to the v2024 milestone Dec 11, 2024
@kgryte kgryte added API change Changes to existing functions or objects in the API. topic: Complex Data Types Complex number data types. topic: Type Promotion Type promotion. Needs Changes Pull request which needs changes before being merged. labels Dec 12, 2024
Comment on lines +149 to +152
.. note::
Mixing a Python ``complex`` and an array with a real-valued data type is allowed; the result is an array of the data type of the same *precision* as the array operand. In other word, ``1j <op> float32_array`` results in a ``complex64`` array; ``1j <op> float64_array`` results in a ``complex128`` array.

Behavior is not specificed when mixing ``complex`` scalars with integer arrays; this may give ``complex64``, ``complex128``, or raise an exception. Behavior is implementation-specific.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would we want to add a versionchanged directive for this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typically, I add all version changed directives at the same time after compiling the changelog, not on a PR-by-PR basis. While it is thus far common for us to release a December version, this isn't guaranteed, so I have typically avoided adding such annotations until the spec release has been finalized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API change Changes to existing functions or objects in the API. Needs Changes Pull request which needs changes before being merged. topic: Complex Data Types Complex number data types. topic: Type Promotion Type promotion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants