You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Traceback (most recent call last):
Cell In[5], line 5
xp.searchsorted(a, 42)
File ~/miniforge3/envs/dev/lib/python3.13/site-packages/array_api_strict/_flags.py:395 in wrapper
return func(*args, **kwargs)
File ~/miniforge3/envs/dev/lib/python3.13/site-packages/array_api_strict/_searching_functions.py:78 in searchsorted
if x1.dtype notin _real_numeric_dtypes or x2.dtype notin _real_numeric_dtypes:
AttributeError: 'int' object has no attribute 'dtype'
This is a bit annoying as it requires to instead write: xp.searchsorted(a, xp.asarray(42, device=a.device)) which feels unnecessarily verbose.
Even PyTorch accepts the following without complaining, for instance:
requires that x2 be an array. CuPy and TensorFlow require that x2 be an array, while NumPy, PyTorch, and others allow x2 to be a scalar. In this PR, I've chosen to restrict x2 to be an array. For the scalar use case, downstream consumers can wrap scalar values as zero-dimensional arrays.
Indeed, thanks for looking this up. Still, I think that calling searchsorted with a scalar as second argument is quite common, and it's easy to forget about passing the device argument when developing with numpy on a CPU and then get the code crash when running with another on GPUs.
I think we could make the spec evolve and handle the discrepancy in scalar support via array_api_compat.
changed the title [-]Make `xp.searchsorted` accept Python scalars for the second argument[/-][+]RFC: add scalar support to `xp.searchsorted`[/+]on Nov 13, 2025
Activity
lucascolley commentedon Aug 22, 2025
I guess this is similar to #860
lucascolley commentedon Aug 22, 2025
This was at least a conscious decision originally, #699 (comment)
ogrisel commentedon Aug 25, 2025
Indeed, thanks for looking this up. Still, I think that calling
searchsortedwith a scalar as second argument is quite common, and it's easy to forget about passing the device argument when developing with numpy on a CPU and then get the code crash when running with another on GPUs.I think we could make the spec evolve and handle the discrepancy in scalar support via
array_api_compat.lucascolley commentedon Aug 25, 2025
Yes, I think I am +1 because the usage feels similar to
xp.where.kgryte commentedon Aug 25, 2025
I'll go ahead and add this to the next array API workgroup meeting as a discussion topic.
kgryte commentedon Nov 13, 2025
I've opened #982 for adding scalar support to the second argument in
searchsorted.[-]Make `xp.searchsorted` accept Python scalars for the second argument[/-][+]RFC: add scalar support to `xp.searchsorted`[/+]feat: add scalar argument support to `searchsorted`