[cfp-interest 3764] Re: Rounding terminology

[Jim Thomas]

> On Jan 8, 2026, at 7:47 PM, Damian McGuckin <damianm at esi.com.au> wrote:
> 
> 
> I personally do not believe that "rounding mode" should ever appear as it does now. It should always be used as "rounding direction mode" to avoid any confusion with "rounding precision mode". This means that there is no such thing as a dynamic rounding mode. It is always the dynamic rounding direction mode. Mind you, you could add to Section 3 the implication
> 
> 	"rounding mode" implies "rounding direction mode"
> 
> which would make life easier and reduce the number of changes.

“Rounding mode” and “dynamic rounding mode” would make sense where they might refer to an implementation extension rounding mode such as a rounding precision mode. 

CFP decided to go with “rounding direction mode” instead of just “rounding mode”. However, looking online it appears “rounding mode” often and almost universally refers to rounding direction modes. Maybe we should reconsider and pursue Damian’s thought to explicitly say the standard will generally use “rounding mode” to refer to rounding direction modes.
> 
> Anyway, going through Jim's excellent work (and pre-empting Jerome's review) only because it impacts my Annex F work due next meeting:
> 
> On Mon, 5 Jan 2026, Jim Thomas wrote:
> 
>> Understanding of terms:
> 
> Jim - Rounding direction - method of rounding
>   ("toward zero", "to nearest with ties to even", ...)
> 
> ... Really clear. I like it.
> 
> Remember these are what is implies by "rounding direction macros" like "FE_TONEAREST" and so on.
> 
> Jim - Rounding direction mode - system variable whose values are rounding
> directions, sometimes used to refer to the value of the mode variable
> 
> ... Really clear. I like it.
> 
> Do we need to add that this is called static if the implementation does not allow it to change, or dynamic if the implementation allows change?
> There are multiple "constant rounding direction modes" which can get
> defined by a #pragma.
> 
> Jim - Default rounding direction - rounding direction in the absence of any constant or dynamic mode change
> 
> Really clear.
> 
> Current rounding direction - value of applicable (constant or dynamic)
> rounding direction mode
> 
> Hmmm. Less clear.
> 
> Is my interpretation following correct?  Is so, then I will deem it as "really clear". If not, maybe
> 
>   Current rounding direction - value of applicable (constant or if
>   no constant then dynamic or if no dynamic then default ) rounding
>   direction mode.

I think your (loosely worded) interpretation is correct.
> 
> Either way, do Jim's definitions above need to appear in Section 3
> 
> The standard defines the Default rounding direction that the compiler should assume before compilation starts . I assume that this can be changed by a compiler flag.

Yes. Such flags imply non conformance.
> 
> You can change the default

Not just the default.

> rounding active in a given block at compile time

The change is specified at compile time, but the specified rounding direction is active at execution time too.

> with a user specified
> 
> 	#pragma STDC FENV_ROUND ....
> 
> where .... is a "rounding direction macro name" (which reflects some rounding direction) which updates the "constant rounding direction mode" for that block, i.e. it is active only for the code block in which it appears. Once specified, it will not allow the "dynamic rounding direction mode" to take effect within that block unless the .... was DYNAMIC.
> 
> You can change the rounding direction at run time with
> 
> 	fesetround(....)
> 
> as long as the implementation supports dynamic rounding. This will over-ride the default or compile flagr rounding direction

Compiler flags are not covered by the standard. It’s up to the implementation to say what the effects are (including what overrides what). 


> but it will only over-ride a constant rounding direction if the #pragma said DYNAMIC. Am I correct

Yes

> 
> Here are some statistics on usage.
> 
>    current rounding direction mode - 20
>    current rounding direction (only) - 28
>    current rounding mode - 5
> 
>    default rounding direction mode - 0
>    default rounding direction (only) - 2
>    default rounding mode - 3
> 
>    static rounding direction mode - 0
>    static rounding direction (only) - 0
>    static rounding mode - 1
> 
>    constant rounding direction mode - 2
>    constant rounding direction (only) - 1
>    constant rounding mode - 17
> 
>    dynamic rounding direction mode - 9
>    dynamnic rounding direction (only) - 3
>    dynamic rounding mode - 4
> 
> As far as I can tell from your above definitions, there is no such thing as the default rounding mode or a default rounding direction mode, just a
> 
> 	default rounding direction
> 
> as defined by the standard (or mandated by a compiler flag)

> 
> Likewise, there only a
> 
> 	static rounding direction
> 
> which defaults to the default rounding direction or if given by #pragma.

I don’t understand.

> 
> Or does static mean "constant"???

“Static” has a different meaning in C. The one instance of "static rounding mode” is a mistake.

> 
> Similarly there is only a
> 
> 	current rounding direction
> 
> The rounding direction mode is the system variable that contains or is used to change the the current rounding direction. It would appear that this really only needs to be mentioned when talking about
> 
> 	fegetround()
> or
> 	fesetround()
> 
> That said, I believe that
> 
> 	fegetround()
> 
> returns the current rounding direction (by reading the rounding direction mode variable)

It returns the current dynamic rounding direction (i.e. current value of the dynamic rounding direction mode). It does not return the current rounding direction if set by a pragma.

> and
> 
> 	fesetround()
> 
> updates the current rounding direction (by writing the rounding direction mode variable).

Fegetround and fesetround deal only with the dynamic rounding direction mode, which does not necessarily give the current rounding direction.
> 
> I do not believe that the use in 7.6.6.3 and 7.6.6.4
> 
> 	dynamic rounding direction
> 
> by itself, i.e. without "mode" following makes sense because it is reading from or writing to the rounding direction mode which by definition is dynamic.

Instances of “dynamic rounding direction” are preceded by “current”, which I think makes sense. Maybe I’m missing your point.

-  Jim Thomas

> 
> Thanks - Damian