Open kgryte opened 2 months ago
@oleksandr-pavlyk's comment that this is useful also to avoid dealing with moving a Python scalar to GPU/accelerator if it's written as 1/x
and that's why it was added to dpctl
seems like an additional reason to do this.
So +1 for adding this, with "should" for floating-point types only (as suggested). That way it's a straightforward signal that this is portable, without placing a new implementation burden on any known library.
This RFC proposes the addition of a new API in the array API specification for computing the element-wise reciprocal.
Overview
Based on array comparison data, the API is available across all major array libraries in the PyData ecosystem.
reciprocal
was originally identified in https://github.com/data-apis/array-api/issues/187 as a potential standardization candidate and has been mentioned by downstream libraries (see Intheon case study).Prior art
Proposal
Questions
1/x
may be appear to be a trivial operation not warranting a dedicated API, there can be benefits should the API be mapped to dedicated hardware instructions. One can argue that this is best dealt with at the compiler level and end users should not be concerned with potential micro-optimizations. However, for larger datasets, there can be real-world benefits to explicit avoidance of division operations and array libraries may choose to avoid relying on compiler magic to implement polynomial approximations to the reciprocal. Given that this is implemented by all considered array libraries and straightforward to implement (similar to the standard already includingnegative
andpositive
), are there any reasons to not include this API?