[cfp-interest 3758] Re: Rounding terminology

[Damian McGuckin]

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.

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.

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.

You can change the default rounding active in a given block at compile 
time 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 but it will only 
over-ride a constant rounding direction if the #pragma said DYNAMIC. Am I 
correct

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.

Or does static mean "constant"???

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) and

 	fesetround()

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

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.

Thanks - Damian