Skip to content

[round.style] Remove "the" to clarify there may be multiple values#8944

Closed
eisenwave wants to merge 1 commit into
cplusplus:mainfrom
eisenwave:patch-64
Closed

[round.style] Remove "the" to clarify there may be multiple values#8944
eisenwave wants to merge 1 commit into
cplusplus:mainfrom
eisenwave:patch-64

Conversation

@eisenwave

Copy link
Copy Markdown
Member

Fixes #8942

The current wording "the one" suggests that a disambiguation takes place in all cases, but that's not true. For binary floating-point numbers with one-digit precision, both 9.5 and 10.0 have an even least significant binary digit and are equally near to 9.75, so rounding is ambiguous in that case.

@eisenwave eisenwave added P3-Other Triaged issue not in P1 or P2 P1-Important Misapplication of paper, malformed code, internal inconsistencies and removed P3-Other Triaged issue not in P1 or P2 labels Apr 19, 2026
@eisenwave

Copy link
Copy Markdown
Member Author

I guess this is P1 by the standard of "normative wording is broken", even though it's not a very impactful problem in this case.

@tkoeppe tkoeppe requested a review from jensmaurer April 20, 2026 16:44
@tkoeppe

tkoeppe commented Apr 20, 2026

Copy link
Copy Markdown
Contributor

I'm not sure whether this is editorial. @jensmaurer?

@jensmaurer

Copy link
Copy Markdown
Member

both 9.5 and 10.0 have an even least significant binary digit

Sorry, I don't follow. 9.5 = 9 + 1/2 and 10.0 = 10 + 0/2. Seems like only 10.0 has an even least significant binary digit.

@eisenwave

Copy link
Copy Markdown
Member Author

Yeah sorry, 9.5 and 10.0 both have an odd least significant digit, not even, when rounded to one digit of precison.

From ISO/IEC 60559:

roundTiesToEven, the floating-point number nearest to the infinitely precise result shall be delivered; if the two nearest floating-point numbers bracketing an unrepresentable infinitely precise result are equally near, the one with an even least significant digit shall be delivered; if that is not possible, the one larger in magnitude shall be delivered (this can happen for one-digit precision, possible with convertToDecimalCharacter for example, as when rounding 9.5 to one digit in which case both 9 and 1× 101 have odd significands)

I don't think any other wording depends on this edge case; it would only be theoretically possible if we specified somethng like std::to_chars with configurable precision in terms of to_nearest mode.

In general, "digit" refers to digits in the significant rather than digits in the decimal representation.

To my understanding, this whole edge case is purely theoretical in C++ (it can take place in some ISO/IEC 60559 operations), so I guess you could even keep it as is and it would make no normative difference. Still, we are defining the counterpart to roundTiesToEven with to_nearest rounding.

@jensmaurer

Copy link
Copy Markdown
Member

If we want to permit the example of 9.5 rounding to 9 vs. 1x10^1, then there is no number with even least significant digit among the choices (both are odd), so removal of "the" in the wording doesn't help.

Sorry, I'm still not seeing an example where this fix would be an improvement.

@eisenwave

Copy link
Copy Markdown
Member Author

Yeah right, the wording is actually fine as is because there are never two candidates with an even least significant digit, so "the one" is fine.

It may just be that there are no such even candiates for tie breaking at all, and that doesn't break the current wording.

@eisenwave eisenwave closed this Apr 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

P1-Important Misapplication of paper, malformed code, internal inconsistencies

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[round.style] Unclear whether the specification is complete and unambiguous

3 participants