From Newsgroup: comp.arch

There is a clear use case for roundTiesToOdd (correctly rounding
calculations for later conversion to a lower precision), this is
why Power implements it for its 128-bit HW.

Why didn't make this into IEEE 754-2019? Will it (likely) be
in a future revision?

Terje, maybe you can shed some light on this.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Thomas Koenig wrote:

There is a clear use case for roundTiesToOdd (correctly rounding
calculations for later conversion to a lower precision), this is
why Power implements it for its 128-bit HW.

Why didn't make this into IEEE 754-2019? Will it (likely) be
in a future revision?

Terje, maybe you can shed some light on this.

The WG discussions are private, but I can confirm that rounding modes
are on the table.

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:

Thomas Koenig wrote:

There is a clear use case for roundTiesToOdd (correctly rounding
calculations for later conversion to a lower precision), this is
why Power implements it for its 128-bit HW.

Why didn't make this into IEEE 754-2019? Will it (likely) be
in a future revision?

Terje, maybe you can shed some light on this.

The WG discussions are private,

An interesting difference from the only other computer-related
standards committee (well, two committees, J3 and WG15) that
I am familar with, for Fortran. There is an open mailing list
and all papers submitted to the committee can be found on their
website. Plus, there is a github site for gathering proposals which
is also frequented by committeee members, but that appears to be
of somewhat less utility because it overflows with somewhat good
and not-so-good ideas, and people want to turn Fortran into Rust
or Python, or a combination of both.

but I can confirm that rounding modes
are on the table.

POWER has an additional bit reserved for future rounding modes,
I guess that is a good idea, then...
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 10 Nov 2025 06:59:19 +0000, Thomas Koenig wrote:

There is a clear use case for roundTiesToOdd (correctly rounding
calculations for later conversion to a lower precision), this is why
Power implements it for its 128-bit HW.

I see that what IEEE 754 does have is round to nearest with ties to even; allegedly, according to the Wikipedia article, this is the recommended
option. There is also a round to nearest with ties to "away", that is, to
the larger magnitude; this is provided as an option for decimal arithmetic only.

If rounding ties to odd makes conversion to a lower precision more likely
to be correct, I'm surprised that it isn't the preferred option. But I
think I'd have to learn more about numerical analysis to make an
intelligent comment on this matter.

John Savard
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Fri, 28 Nov 2025 05:19:31 +0000, John Savard wrote:

But I think I'd have to learn more about numerical analysis to make an intelligent comment on this matter.

I had thought that rounding ties to even would result in the correct
rounding for a reduced precision... if the precision were reduced only by
one bit, which is a case that does not occur in practice.

But now I've found another Wikipedia article which clarified things for
me. It turns out that rounding ties to odd does have one important
benefit. It means that the rounding of ties, at least, will never result
in the exponent of the result changing.

Since rounding to nearest when it isn't a tie can still change the
exponent, it's not clear to me that this is all that important. Rounding
to even or to odd both have the virtue of avoiding bias, of course.

John Savard
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

This caused me to think...

The difference between rounding ties to even or to odd changes only a
small number of calculations in the least significant bit.

So if you could switch between these two rounding modes, and you did a calculation both ways, and got wildly different results... this would let
you know that the problem, or your algorithm for dealing with it, is so
wildly ill-conditioned that your results in either case are not valid.

And then I came up with an evil idea...

Who wants to do a calculation twice? With a suitable new floating-point format, perhaps one could do the calculation just once.

Inspired by UNUMs and POSITs, I see this new floating point format as
looking like this:

If the LSB is 0, then one has a regular floating-point number, except the mantissa/significand is one bit shorter.

If the LSB is 1, the format is changed to indicate the number is in a
special format, which indicates that it is actually _two_ numbers.

The special format has two forms.

Form A: a portion of the significand is indicated, and that portion now
has two possible values. So, for example, the last four bits are replaced
with two possible values for their first two bits, and the precision of
the number loses two bits.

Form B: the numbers are allowed to be completely different. One bit is the
LSB that is 1, another bit indicates Form B, so now these two numbers are
one bit shorter than half the full length of the number.

This is crazy enough that I haven't yet made the effort to flesh out the format of a Form A dual number.

The loss of precision can be large, so the results of a computation done
with this new numeric format would differ from what you would get from
doing the computation twice. The idea is that in addition to rounding ties
to either odd or even, one could use it to compare, say, always rounding
up to always rounding down (or always towards zero/truncating or always
away from zero).

John Savard
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Fri, 28 Nov 2025 05:42:58 -0000 (UTC), John Savard wrote:

So if you could switch between these two rounding modes, and you did
a calculation both ways, and got wildly different results... this
would let you know that the problem, or your algorithm for dealing
with it, is so wildly ill-conditioned that your results in either
case are not valid.

Prof Kahan was well ahead of you there. He already recommends doing
testing with all the existing IEEE 754 rounding modes, for precisely
this reason.

It’s not foolproof, but it can be a useful indicator.
--- Synchronet 3.21a-Linux NewsLink 1.2