Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Device-specific type promotion rules #672

Open
oleksandr-pavlyk opened this issue Aug 7, 2023 · 4 comments · May be fixed by #889
Open

Device-specific type promotion rules #672

oleksandr-pavlyk opened this issue Aug 7, 2023 · 4 comments · May be fixed by #889
Labels
topic: Device Handling Device handling. topic: Type Promotion Type promotion.
Milestone
v2024

Comments

@oleksandr-pavlyk
Copy link
Contributor

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 rgommers added topic: Type Promotion Type promotion. topic: Device Handling Device handling. labels Aug 8, 2023
@rgommers
Copy link
Member

rgommers commented Aug 8, 2023

@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
Copy link
Contributor Author

@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 kgryte added this to the v2023 milestone Sep 21, 2023
@kgryte kgryte mentioned this issue Sep 21, 2023
Closed
@kgryte
Copy link
Contributor

kgryte commented Oct 18, 2023

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

#691

@asmeurer asmeurer mentioned this issue Dec 7, 2023
Closed
@oleksandr-pavlyk
Copy link
Contributor Author

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

@kgryte kgryte modified the milestones: v2023, v2024 Feb 14, 2024
@github-project-automation github-project-automation bot moved this to Stage 1 in Proposals Aug 29, 2024
kgryte added a commit to kgryte/array-api that referenced this issue Jan 23, 2025
@kgryte
feat: apply type promotion rules according to the device context
7c0bd0b 
Closes: data-apis#672
@kgryte kgryte linked a pull request Jan 23, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: Device Handling Device handling. topic: Type Promotion Type promotion.
Projects
Proposals
Status: Stage 1
Milestone
v2024
3 participants
@rgommers @kgryte @oleksandr-pavlyk