Minor clarification on allowed rounding mode

[hpkfft]

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.

[hpkfft]

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.