[cfp-interest 3716] Comments on cfp3691 RoundingMode

[Jim Thomas]

Relevant to CFP Nov 12 agenda topic

Rounding modes, terminology (M-L)
•	[cfp-interest 3691] Re: Changes to Annex F   Damian McGuckin

below are some comments on

https://wiki.edg.com/pub/CFP/WebHome/RoundingMode-20251030.pdf

- Jim Thomas


3.15#1
3.14
CFP agreed on changing to “rounding direction mode”. I don’t see the reason for the other wording changes.
However, changing to “subject to the rounding direction” (without mentioning mode) seems like an improvement. See below.

NOTE: ...
I think the current definition suffices to define uses of “correctly rounded” such as in “result is correctly rounded”.

5.3.5.3.3#23
FLT_ROUNDS (applying only to addition) is a legacy macro. We’ve had no WG14 or user requests to change the specification.

Other Occurrences
There are 51 occurrences to check. E.g. maybe not change in J.3.7 (12).
There might also be place where “rounding direction” would be better than “rounding direction mode”. See below.

Confusion and Vagueness
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).

7.6.6.3#2 says the function "gets the current value of the dynamic rounding direction mode”, which is what it does. 
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.

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.

Rounding direction					Macro
toward zero						FE_TOWARDZERO
to nearest, ties to even				FE_TONEAREST
upward (toward positive infinity)		FE_UPWARD
downward (toward negative infinity)	FE_DOWNWARD
to nearest, ties away from zero		FE_TONEARESTFROMZERO

I don’t see a benefit of changing the comma to “with”.

F.5#5
Yes, add “mode” in first sentence.
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.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20251110/b006da79/attachment.htm>