Open hpkfft opened 2 months ago
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.
The accuracy section of this standard states
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
, androundTowardZero
. 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: