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

Add complex number support to equal #528

Merged
merged 5 commits into from
Dec 13, 2022
Merged

Add complex number support to equal #528

merged 5 commits into from
Dec 13, 2022

Conversation

kgryte
Copy link
Contributor

@kgryte kgryte commented Nov 28, 2022

This PR

  • adds complex number support to equal by documenting special cases. By convention, equality is determined by independently comparing real and imaginary components respectively and then performing a logical AND (i.e., if x = a + bj and y = c + dj, then x == y iff a == c AND b == d.
  • follows precedent in Python, Julia, NumPy, and elsewhere.
  • does not embrace the one-infinity model in which all infinities in the complex plane map to a single infinity (see Riemann sphere), as doing so would lead to unintuitive results when casting real-valued infinities to complex infinities.
  • adds a design document discussing complex number equality comparison and general considerations for specifying complex number behavior within the specification.

References

@kgryte kgryte added API change Changes to existing functions or objects in the API. topic: Complex Data Types Complex number data types. labels Nov 28, 2022
@kgryte kgryte added this to the v2022 milestone Nov 28, 2022
Copy link
Member

@rgommers rgommers left a comment

Choose a reason for hiding this comment

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

The discussion on complex number equality looks good to me (I have added a note on refactoring the content regarding complex numbers into a single doc to gh-533). The specified behavior matches current array library implementations, so we should be all good there.

It'd be good to fix the duplicate content issue here before merging, easiest to do it now.

- If ``x1_i`` is ``-0`` and ``x2_i`` is either ``+0`` or ``-0``, the result is ``True``.
- If ``x1_i`` is ``+0`` and ``x2_i`` is either ``+0`` or ``-0``, the result is ``True``.
- If ``x1_i`` is a finite number, ``x2_i`` is a finite number, and ``x1_i`` equals ``x2_i``, the result is ``True``.
- In the remaining cases, the result is ``False``.
Copy link
Member

Choose a reason for hiding this comment

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

This is 100% duplicate content, please refer to equal instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, we chose to duplicate content, where applicable, early on during spec writing, so this is the case for all relevant APIs. This should be fine to do as a single pass for all applicable array object APIs.

Copy link
Member

Choose a reason for hiding this comment

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

This strategy creates a bunch of extra work for ourselves for no real gain, so not ideal - but I'll ignore it in the open PRs. I'll go ahead and merge this.

@rgommers rgommers merged commit 73a1a91 into main Dec 13, 2022
@rgommers rgommers deleted the cmplx-equal branch December 13, 2022 17:09
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. topic: Complex Data Types Complex number data types.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants