[cfp-interest 3722] Re: Comments on cfp3691 RoundingMode

[Jim Thomas]

> Damian McGuckin damianm at esi.com.au <mailto:cfp-interest%40oakapple.net?Subject=Re%3A%20%5Bcfp-interest%203720%5D%20Re%3A%20Comments%20on%20cfp3691%20RoundingMode&In-Reply-To=%3C919032e-6c28-7e53-58cd-96d4fdfdfc71%40esi.com.au%3E>
> Tue Nov 11 00:09:53 PST 2025
> On Mon, 10 Nov 2025, Jim Thomas wrote:
> 
> > 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.
> 
> I have largely reverted to the old words.
> 
> > Confusion and Vagueness
> > My understanding: A mode is a variable.
> 
> The fact that we have a different interpretation just says the words being 
> used in C2Y currently are unclear. I asked some random people to explain
> the text in C2Y to me and they all got confused.
> 
> My understanding is that a mode is like a state or enum. There are five 
> possible "rounding direction mode"s each of which are invariant and have a 
> 1:1 relationship with an ISO/IEC 60559 rounding direction attribute. The 
> "current rounding direction mode" or the "default rounding direction mode" 
> can have one of those five invariant "rounding direction modes" (or some
> other value if an implementation defines it).
C2Y 7.6.1 says: "A floating-point control mode is a system variable whose value may be set by the user to affect the subsequent behavior of floating-point arithmetic.”

The meaning of “mode" in IEEE 754 is the same.

754-1985 has the definition:

mode. A variable that a user may set, sense, save, and restore to control the
execution of subsequent arithmetic operations. 

754-2019 refers to the “dynamic-mode variable”, e.g. in: "The implementation initializes a dynamic-mode variable to the default value for the dynamic mode."

Speaking loosely one might say "the rounding direction mode is “upward”." This is a casual way of saying "the value of the rounding mode variable is the “upward” rounding direction." Similarly one might say "x is zero" to mean "the value of the x variable is zero". I suspect a reader's thinking of “rounding direction mode” as referring to a value of the rounding direction mode variable is harmless, though not strictly correct per established definitions.
> 
> See my explanations. They may still be inadequate. They most likely are,
> 
> C never lets you get directly at the "current rounding direction mode". 
> The fegetround() routine returns a value which is equal to one of the 
> "rounding direction macros" and which reflects the "current rounding 
> direction mode" while fesetround() accepts an argument of a "rounding 
> direction macro" which you can use to change the "current rounding 
> direction mode" if the implementation allows you to change it at all 
> during execution, i.e. the mode is dynamic. Those macros are normally bit 
> masks from the control registers but we do not need to tell people that.
> 
> > 7.6.6.3#2 says the function "gets the current value of the dynamic rounding
> > direction mode?, which is what it does.
> 
> No.
fegetround determines (gets) the value of the rounding direction mode. How it represents that mode value to the caller is stated in the Returns section. It has to get the mode value to know what to return. The choice of the word “gets” vs “determines” comes from “get(ter) and set(ter)” being common in computer science. AI says a getter "provides controlled access to the internal state of an object without directly exposing the attribute”, which is what happens with fegetround.

> 
> It returns a value which is a "rounding direction macro" which reflects 
> the current "rounding direction mode". C2Y uses the word "reflects" for 
> this sort of relationship. In an implementation which does not allow 
> dynamic rounding, it returns the default rounding direction mode which is 
> also the current one. For an implementation which allows dynamic rounding 
> direction modes, it always returns the current rounding direction mode, 
> which by the way is also the default rounding direction mode if no 
> execution time change of that has been made to occur.
> 
> > 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.
> 
> See above.
> 
> > 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.
> 
> > I don?t see a benefit of changing the comma to ?with?.
> 
> It makes it easier to deal with in sentences with punctuation.
Is it a problem if in quotes, e.g. “to nearest, ties to even”? References to the rounding directions shown in a table should probably be quoted.

- Jim Thomas
> 
> > 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.
> 
> I got rid of the mentioned "rounding direction" to avoid confusion.
> 
> Thanks - Damian
> 



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