Uh oh!
There was an error while loading. Please reload this page.
Add searchsorted to the specification - #699
Conversation
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
kgryte
commented
Jan 11, 2024
@rgommers This PR should be ready for final sign off. |
rgommers
left a comment
There was a problem hiding this comment.
Reviewed again, all comments were addressed and this PR looks good to me. I'll plan to merge it later today or tomorrow.
asmeurer
commented
Apr 24, 2024
Shouldn't the language be "x1 should be a one-dimensional array" instead of "x1 must be a one-dimensional array"? |
| Default: ``'left'``. | ||
| sorter: Optional[array] | ||
| array of indices that sort ``x1`` in ascending order. The array must have the same shape as ``x1`` and have an integer data type. Default: ``None``. |
There was a problem hiding this comment.
Should we only require this to be the default array index type?
There was a problem hiding this comment.
Why would that be necessary?
This PR
searchsortedto the specification #688 by adding a specification forsearchsortedto the Array API specification.x1be a one-dimensional array. PyTorch and TensorFlow allowx1to be multi-dimensional; however, NumPy et al do not. In this PR, I've chosen to restrictx1to a one-dimensional array, as this is the lowest common denominator. The specification can be extended in the future to accommodate multi-dimensionalx1(stacking) in the future.x2be an array. CuPy and TensorFlow require thatx2be an array, while NumPy, PyTorch, and others allowx2to be a scalar. In this PR, I've chosen to restrictx2to be an array. For the scalar use case, downstream consumers can wrap scalar values as zero-dimensional arrays.