-
Notifications
You must be signed in to change notification settings - Fork 53
feat: add isin
to the specification
#959
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,51 @@ | ||
__all__ = ["unique_all", "unique_counts", "unique_inverse", "unique_values"] | ||
__all__ = ["isin", "unique_all", "unique_counts", "unique_inverse", "unique_values"] | ||
|
||
|
||
from ._types import Tuple, array | ||
from ._types import Tuple, Union, array | ||
|
||
|
||
def isin( | ||
x1: Union[array, int, float, complex, bool], | ||
x2: Union[array, int, float, complex, bool], | ||
/, | ||
*, | ||
invert: bool = False, | ||
) -> array: | ||
""" | ||
Tests whether each element in ``x1`` is in ``x2``. | ||
|
||
Parameters | ||
---------- | ||
x1: Union[array, int, float, complex, bool] | ||
first input array. **May** have any data type. | ||
x2: Union[array, int, float, complex, bool] | ||
second input array. **May** have any data type. | ||
invert: bool | ||
boolean indicating whether to invert the test criterion. If ``True``, the function **must** test whether each element in ``x1`` is *not* in ``x2``. If ``False``, the function **must** test whether each element in ``x1`` is in ``x2``. Default: ``False``. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So if There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I think that may be true... which in fact might be a bit awkward, because I am not sure if There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As long as nans are never
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I suppose the weird thing is whether There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, sorry, mind-slip. Somehow I sometimes think just inverting can lead to weird things with NaNs, but that only works with the other comparisons not There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, here it only works because of equality comparison IIUC. Otherwise you're completely right, nans throw off logical inversion |
||
|
||
Returns | ||
------- | ||
out: array | ||
an array containing element-wise test results. The returned array **must** have the same shape as ``x1`` and **must** have a boolean data type. | ||
|
||
Notes | ||
----- | ||
|
||
- At least one of ``x1`` or ``x2`` **must** be an array. | ||
|
||
- If an element in ``x1`` is in ``x2``, the corresponding element in the output array **must** be ``True``; otherwise, the corresponding element in the output array **must** be ``False``. | ||
|
||
- Testing whether an element in ``x1`` corresponds to an element in ``x2`` **should** be determined based on value equality (see :func:`~array_api.equal`). For input arrays having floating-point data types, value-based equality implies the following behavior. | ||
|
||
- As ``nan`` values compare as ``False``, if an element in ``x1`` is ``nan`` and ``invert`` is ``False``, the corresponding element in the returned array **should** be ``False``. Otherwise, if an element in ``x1`` is ``nan`` and ``invert`` is ``True``, the corresponding element in the returned array **should** be ``True``. | ||
- As complex floating-point values having at least one ``nan`` component compare as ``False``, if an element in ``x1`` is a complex floating-point value having one or more ``nan`` components and ``invert`` is ``False``, the corresponding element in the returned array **should** be ``False``. Otherwise, if an element in ``x1`` is a complex floating-point value having one or more ``nan`` components and ``invert`` is ``True``, the corresponding element in the returned array **should** be ``True``. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a bit verbose, I don't think it's necessary to give explicit examples with |
||
- As ``-0`` and ``+0`` compare as ``True``, if an element in ``x1`` is ``±0`` and ``x2`` contains at least one element which is ``±0`` | ||
|
||
- if ``invert`` is ``False``, the corresponding element in the returned array **should** be ``True``. | ||
- if ``invert`` is ``True``, the corresponding element in the returned array **should** be ``False``. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same comment here about not duplicating with |
||
|
||
- Comparison of arrays without a corresponding promotable data type (see :ref:`type-promotion`) is unspecified and thus implementation-defined. | ||
""" | ||
|
||
|
||
def unique_all(x: array, /) -> Tuple[array, array, array, array]: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to double-check, are we happy with e.g. torch not allowing complex values here: