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
For devices that have different capabilities (support for float64/float16 may or may not be present),
the type promotion graph adopted by array-API must be different.
Functions xp.can_cast (ref) and xp.result_type (ref) allow for signatures where all inputs are data types.
For such inputs the device information is not available, but xp.can_cast(xp.float32, xp.float64) is True for devices that support float64, but should be False to devices that do not.
The only variability in data type support across devices, per SYCL spec, exists for 'float64' and 'float16'. In SYCL these capabilities are queries via device aspects. This is only relevant since standardization in SYCL gives us confidence that every other data-type is going to be supported.
So I would like to open for discussion the following proposal
xp.can_cast and xp_result_type need to acquire device keyword support with default value of None to mean that device capabilities are determined from argument arrays, if present, and or from capabilities of the default device otherwise.
Alternative name for the keyword is acceptable too, as long it can used to convey device capabilities.
The text was updated successfully, but these errors were encountered:
@oleksandr-pavlyk thanks for this proposal. The use case is clear to me, and it seems like we should support it. I am wondering though if it isn't already supported. Here are the input parameter descriptions:
can_cast: from (Union[dtype, array]) – input data type or array from which to cast.
result_type: arrays_and_dtypes (Union[array, dtype]) – an arbitrary number of input arrays and/or dtypes.
If you pass in an array rather than a dtype, it has to already have device info attached to it. So I'd expect can_cast(x, xp.float64) to return False in case x.device does not support that dtype.
@rgommers Yes, if x is an array, the device information is available. It is the use case can_cast(dtype, xp.float64), or rather result_type(xp.int64, xp.uint64) that I worry about. This should promote to the default floating point data type which is device specific.
The issue was again discussed at a meeting, and it was decided that adding device keyword is going to be a burden to current libraries.
The way to query device specific type promotion graph is to use array objects instead of dtype objects. Perhaps a note in the specification for these functions may be added requiring implementations to do that, and noting that output of xp.can_cast(array, to_) may differ from output of xp.can_cast(array.dtype, to_).
For devices that have different capabilities (support for float64/float16 may or may not be present),
the type promotion graph adopted by array-API must be different.
Functions
xp.can_cast
(ref) andxp.result_type
(ref) allow for signatures where all inputs are data types.For such inputs the device information is not available, but
xp.can_cast(xp.float32, xp.float64)
isTrue
for devices that support float64, but should beFalse
to devices that do not.The only variability in data type support across devices, per SYCL spec, exists for 'float64' and 'float16'. In SYCL these capabilities are queries via device aspects. This is only relevant since standardization in SYCL gives us confidence that every other data-type is going to be supported.
So I would like to open for discussion the following proposal
xp.can_cast
andxp_result_type
need to acquiredevice
keyword support with default value ofNone
to mean that device capabilities are determined from argument arrays, if present, and or from capabilities of the default device otherwise.Alternative name for the keyword is acceptable too, as long it can used to convey device capabilities.
The text was updated successfully, but these errors were encountered: