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

docs: add note that cross-kind comparisons are undefined #822

Merged
merged 3 commits into from
Oct 31, 2024

Conversation

asmeurer
Copy link
Member

Does the language here look OK? Should we add anything along the lines of "comparisons with promotable types should promote first" (so that the result is numerically correct)?

Fixes #819.

Copy link
Contributor

@kgryte kgryte left a comment

Choose a reason for hiding this comment

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

The language looks okay to me. Left comments for a small grammar correction and the need to add a missing note. Once addressed, LGTM.

@kgryte kgryte changed the title Add note that cross-kind comparisons are undefined docs: add note that cross-kind comparisons are undefined Sep 19, 2024
@kgryte kgryte added this to the v2024 milestone Sep 19, 2024
@kgryte kgryte added Narrative Content Narrative documentation content. Needs Changes Pull request which needs changes before being merged. labels Sep 19, 2024
asmeurer and others added 2 commits September 19, 2024 13:00
@asmeurer
Copy link
Member Author

Done

@fancidev
Copy link

For my understanding, by “comparison of arrays without a corresponding promotable data type”, do you mean that there does not exist a type where both array are promotable to, or do you mean the array has a type that can no longer be promoted “further”? I’m asking because the reference issue involves an example of int64 vs uint64, for which both interpretations apply, so it doesn’t seem entirely clear to me.

@asmeurer
Copy link
Member Author

"Promotion" in the context of the standard only applies to two or more data types. So it's referring to the former interpretation.

Copy link
Contributor

@kgryte kgryte left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks, @asmeurer!

@kgryte kgryte removed the Needs Changes Pull request which needs changes before being merged. label Oct 31, 2024
@kgryte
Copy link
Contributor

kgryte commented Oct 31, 2024

Should we add anything along the lines of "comparisons with promotable types should promote first" (so that the result is numerically correct)?

I believe this is already implied, as, practically speaking, in order to perform comparison, promotion is necessary (e.g., as automatically happens when comparing a float and a double in C). If we later find that we need to make this more explicit, we can address in a follow-up PR.

@kgryte kgryte merged commit 6d205d7 into data-apis:main Oct 31, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Narrative Content Narrative documentation content.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Comparing arrays of different dtype kinds
3 participants