Why Does NumPy Check Only Bits m12–m22 When Rounding Float32 to a Subnormal Float16?

Below is an explanation that clarifies the reasoning behind checking only bits m12–m22 in the second part of the OR.

What Is Happening in the Code

When converting from float32 to float16 for numbers that become subnormal in float16, the algorithm aligns the float32 significand into a temporary variable (here, f_sig) with a shifted layout. The conversion process is designed to round to the nearest even value. During this process, the rounding decision is made by looking at:

1. The rounding bit (the first bit that will be dropped) and the bits after that.
2. Whether the half-significand is already even.

The code

CCopied
if (((f_sig & 0x00003fffu) != 0x00001000u) || (f & 0x000007ffu)) {
    f_sig += 0x00001000u;
}

breaks ties correctly by adding one to f_sig unless the bits that would cause a tie are exactly at the round-to-even boundary (that is, when the rounding bit is exactly 1 with all bits after being 0 and the last kept bit is 0, meaning the result is already even).

Why Check Bits m12–m22 Instead of m11–m22?

Once the significand has been shifted into f_sig, the bit that originally came from m11 of the float32 representation is already present in f_sig and effectively forms the least significant bit (LSB) of the half-significand that we’re keeping. In other words, m11 has already been “used” in the rounding decision when choosing an even value.

The second check (f & 0x000007ffu) is performed on the original float32 representation and only examines the 11 bits that come after m11 (i.e. m12 through m22). These bits are lost during the shift, so they must be checked in the original number to see if any nonzero bits are present that would push the value beyond the tie case.

If m11 were included in this check (for example, by using a mask covering m11–m22), it would duplicate a bit whose value has already been accounted for in f_sig’s state. Thus, the algorithm correctly isolates the remainder bits that were lost solely due to the shift (m12–m22), ensuring a proper tie-break decision when rounding.

In Summary

• m11 on Its Own: It has already been shifted into the half-significand (f_sig) and so its effect on rounding (e.g. making the final bit odd or even) is already incorporated.
• m12–m22: These bits tell whether the original number was strictly above the half-way point (i.e. there was extra “fractional” content that wasn’t transferred).
• Result: Rounding up is triggered if there is any nonzero value in m12–m22 (as detected by (f & 0x000007ffu)) or if the remaining bits within f_sig do not exactly represent the tie condition.

This is why the code masks against 0x000007ffu—it is precisely checking the bits beyond m11 (i.e. m12–m22) that could cause the result to round upward.

I hope this clears up why only those bits (m12–m22) are used in the second part of the OR when implementing rounding to nearest even during the conversion.