data-apis
Minor clarification on allowed rounding mode
The accuracy section of this standard states
The results of element-wise arithmetic operations ...
for floating-point operands must return the nearest representable value
according to IEEE 754-2019 and a supported rounding mode.
I believe this intends to allow (optionally, and not by default) the use of directed rounding, i.e., the IEEE 754-2019 rounding attributes roundTowardPositive, roundTowardNegative, and roundTowardZero.
However, directed rounding does not, in general, return the nearest representable value--only an attribute that rounds to nearest does that.
IEEE 754-2019 defines the term "correctly rounded", which I suggest is preferred here:
The results of element-wise arithmetic operations ...
for floating-point operands must return the correctly rounded value
according to IEEE 754-2019 and a supported rounding mode.
By the way, I would support a recommendation that array libraries offer directed rounding as an option. One way to try to assess the effects of roundoff upon a floating-point computation is to repeat the computation in arithmetic of the same precision but rounded differently, say TowardNegative, TowardPositive, and maybe TowardZero, besides "to nearest", and compare three or four results. I'm quoting Prof. W. Kahan.
Though far from foolproof, rounding every inexact arithmetic operation (but not constants)
in the same direction for each of two or three directions besides the default "to nearest"
is very likely to confirm accidentally exposed hypersensitivity to roundoff.
When feasible, this scheme offers the best Benefit/Cost ratio [of the five he mentions].
The paper is Mindless.pdf.
Ref: https://github.com/data-apis/array-api/pull/882. This PR should close this issue.
Re: directed rounding. Agreed, this would be ideal; however, I do not believe any array libraries (e.g., NumPy et al) support this at the moment. We can revisit adding such language to the spec once there is ecosystem support and real-world implementations.
