<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>Relevant to CFP Nov 12 agenda topic</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>Rounding modes, terminology (M-L)</div></div><div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>[cfp-interest 3691] Re: Changes to Annex F Damian McGuckin</div></div></blockquote><div><br></div><div>below are some comments on</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><a href="https://wiki.edg.com/pub/CFP/WebHome/RoundingMode-20251030.pdf">https://wiki.edg.com/pub/CFP/WebHome/RoundingMode-20251030.pdf</a></div></blockquote><div></div><div><br></div><div>- Jim Thomas</div><div><br></div><div><br></div><div>3.15#1</div><div>3.14</div><div>CFP agreed on changing to “rounding direction mode”. I don’t see the reason for the other wording changes.</div><div>However, changing to “subject to the rounding direction” (without mentioning mode) seems like an improvement. See below.</div><div><br></div><div>NOTE: ...</div><div>I think the current definition suffices to define uses of “correctly rounded” such as in “result is correctly rounded”.</div><div><br></div><div>5.3.5.3.3#23</div><div>FLT_ROUNDS (applying only to addition) is a legacy macro. We’ve had no WG14 or user requests to change the specification.</div><div><br></div><div>Other Occurrences</div><div>There are 51 occurrences to check. E.g. maybe not change in J.3.7 (12).</div><div>There might also be place where “rounding direction” would be better than “rounding direction mode”. See below.</div><div><br></div><div>Confusion and Vagueness</div><div>My understanding: A mode is a variable. The rounding direction mode is a variable whose values are rounding directions. In C user code those values are represented by rounding direction macros. The semantics are that the value of the mode determines how operations (in an applicable dynamic or static scope) are to be rounded. C has two kinds of modes: constant modes (which 60559 calls “attributes" and which have constant/static scope) and dynamic modes (which have dynamic scope).</div><div><br></div><div>7.6.6.3#2 says the function "gets the current value of the dynamic rounding direction mode”, which is what it does. </div><div>7.6.6.3#3 says the function returns "the value of the rounding direction macro representing the current dynamic rounding direction or ....” Here “the current dynamic rounding direction” is the value of the dynamic rounding direction mode as just referred to in #2. The value of the mode is generally better not referred to as a mode.</div><div><br></div><div>A table, similar to the one suggested, listing the rounding directions and the rounding direction macros that represent them seems like a good idea. Maybe in 7.6.1#14.</div><div><br></div><div>Rounding direction<span class="Apple-tab-span" style="white-space:pre"> </span>Macro</div><div>toward zero<span class="Apple-tab-span" style="white-space:pre"> </span>FE_TOWARDZERO</div><div>to nearest, ties to even<span class="Apple-tab-span" style="white-space:pre"> </span>FE_TONEAREST</div><div>upward (toward positive infinity)<span class="Apple-tab-span" style="white-space:pre"> </span>FE_UPWARD</div><div>downward (toward negative infinity)<span class="Apple-tab-span" style="white-space:pre"> </span>FE_DOWNWARD</div><div>to nearest, ties away from zero<span class="Apple-tab-span" style="white-space:pre"> </span>FE_TONEARESTFROMZERO</div><div><div><br></div><div>I don’t see a benefit of changing the comma to “with”.</div></div><div><br></div><div>F.5#5</div><div>Yes, add “mode” in first sentence.</div><div>Given a table (like above), I don’t thank any change is needed in the second sentence. The functions probably don’t know what the effective rounding direction will be when they are called, though the implementation might have rounding-direction-specific versions of the functions to use in the generated code where the rounding direction is known at translation time. "If the rounding direction can be upward or downward" is the general condition for ruling out implementation that just negates the converted unsigned sequence.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>