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
This seems to have slipped under the radar. Could you remind me what are the motivating use cases? IIUC, one was float32->complex64, which is now IMO adequately handled by 1j*float32_array -> complex64_array. Was there something about signed/unsigned integers? My search-foo is failing me
Hmm, not sure if there was a real-world motivating case for signed/unsigned integers, but in general I still think this is rather nice to have. Suppose you are using something like this in a context of parametrising over dtype kinds, something like
dtype_id=1.0ifdtype_kind=="float"else1j# or more casesx*=dtype_id
can become
x=xp.astype(x, kind=dtype_kind)
which is not only cleaner but also semantically much nicer IMO!
I took a brief look at implementing a close-to-array-agnostic version of this, but I think it is quite difficult to satisfy the 'lowest-precision data type' clauses of the spec with the tools we currently have available in the standard.
On the bright side, that gives me confidence that adding this to the standard is the right way to go. I think it does mean, though, that the implementations in array-api-compat will be better off leaning heavily on promotion utilities specific to each array library, or perhaps hardcoding known lowest-precision dtypes / promotion tables.
Activity
ev-br commentedon Oct 28, 2025
This seems to have slipped under the radar. Could you remind me what are the motivating use cases? IIUC, one was float32->complex64, which is now IMO adequately handled by
1j*float32_array -> complex64_array. Was there something about signed/unsigned integers? My search-foo is failing melucascolley commentedon Oct 28, 2025
Hmm, not sure if there was a real-world motivating case for signed/unsigned integers, but in general I still think this is rather nice to have. Suppose you are using something like this in a context of parametrising over dtype kinds, something like
can become
which is not only cleaner but also semantically much nicer IMO!
ev-br commentedon Oct 29, 2025
This is the int/uint discussion I was trying to remember:
data-apis/array-api#859 (comment)
lucascolley commentedon Jun 5, 2026
any further thoughts @ev-br ?
lucascolley commentedon Jun 26, 2026
gentle bump
ev-br commentedon Jun 30, 2026
(Assuming the ping is for me) thanks for the ping! I'm bandwidth-limited for next the couple of weeks at least, won't be able get to it "soon".
lucascolley commentedon Aug 12, 2026
gentle bump @ev-br, would you be happy to see a PR for this?
ev-br commentedon Aug 13, 2026
Yes certainly! Happy to review a PR for this
lucascolley commentedon Aug 13, 2026
I took a brief look at implementing a close-to-array-agnostic version of this, but I think it is quite difficult to satisfy the 'lowest-precision data type' clauses of the spec with the tools we currently have available in the standard.
On the bright side, that gives me confidence that adding this to the standard is the right way to go. I think it does mean, though, that the implementations in array-api-compat will be better off leaning heavily on promotion utilities specific to each array library, or perhaps hardcoding known lowest-precision dtypes / promotion tables.