How to perform round to even with floating point numbers

Question

In regards to IEEE-754 single precision floating point, how do you perform round to nearest, where ties round to the nearest even digit in the required position (the default and by far the most common mode)?

Basically I have the guard bit, round bit, and sticky bit. So if we form those into a vector and call it GRS, then the following rules apply:

1. If G = 0, round down (do nothing)
2. If G = 1, and RS == 10 or RS == 01, round up (add one to mantissa)
3. if GSR = 111, round to even

So I am not sure how to perform the round to nearest. Any help is greatly appreciated.

Solution 1

Just to make sure we're on the same page, G is the most significant bit of the three, R comes next and S can be thought of as the least significant bit because its value partially represents the even less significant bits that have been truncated in the calculations. These three bits are only used while doing calculations and aren't stored in the floating-point variable before or after the calculations.

This is what you should do in order to round the result to the nearest even number using G, R and S:

GRS - Action
0xx - round down = do nothing (x means any bit value, 0 or 1)
100 - this is a tie: round up if the mantissa's bit just before G is 1, else round down=do nothing
101 - round up
110 - round up
111 - round up

Rounding up is done by adding 1 to the mantissa in the mantissa's least significant bit position just before G. If the mantissa overflows (its 23 least significant bits that you will store become zeroes), you have to add 1 to the exponent. If the exponent overflows, you set the number to +infinity or -infinity depending on the number's sign.

In the case of a tie, you add 1 to the mantissa if the mantissa is odd and you add nothing if it's even. That's what makes the result rounded to the nearest even value.

Solution 2

Just wanted to add that S bit is not just a bit following GR bits. If there are bits available after GRS bits, it actually is a logical OR of those, including S bit.
In other words, if there is any bit following GR bits that is 1 then the S bit value will be 1.

Solution 3

Consider the following for rounding when you have a set of bits lower than the precision you are keeping:

1. If the least significant bit you are keeping is 0, just add 0x7ff....f to rounding bits.
2. If the least significant bit you are keeping is 1, just add 0x800....0 to rounding bits.

I think this implements the desired behavior doing only one test.

Comments

[Veridian]

Do you even need the round bit? Can't you just look at the guard bit and the sticky bit becomes the OR of the round and old sticky bit?

[Alexey Frunze]

You may use none of these bits if you aren't very concerned about rounding. They just help you get a more accurate result.

[Veridian]

well I am concerned about rounding, so does my comment "Can't you just look at the guard bit and the sticky bit becomes the OR of the round and old sticky bit?" make sense?

[Alexey Frunze]

It does not. The sticky bit does not depend on what's to the left of it, it depends on what gets into it or past it to the right.

[inherithandle]

Could you explain how that table(GRS action) is derived? Or any material and link would be useful.

[Alexey Frunze]

@inherithandle See, for example, the On Rounding section of this page.

[Veridian]

@AlexeyFrunze, that link is broken. Do you have another reference? Thanks

[Alexey Frunze]

@Veridian wayback machine ?

[sam hocevar]

@Veridian your observation “can't you just look at the guard bit and the sticky bit becomes the OR of the round and old sticky bit” is absolutely correct in the case you presented, and indeed the round bit is not necessary. However, it is required in the case of subtractions, when the result underflows and needs to be shifted left. When that happens, a third bit is needed to decide what to do in the tie case.