Device-specific type promotion rules

[oleksandr-pavlyk]

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.

[rgommers]

@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.

[oleksandr-pavlyk]

@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.

[kgryte]

@oleksandr-pavlyk Circling back here. Did you have further thoughts you'd like to share here or on the linked PR?

https://github.com/data-apis/array-api/pull/691

[oleksandr-pavlyk]

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_).