[cfp-interest 3866] Re: Comments re Annex F Introduction

[Damian McGuckin]

On Tue, 14 Apr 2026, Jim Thomas wrote:

> These comments referto

>  https://cfp-wiki.esi.com.au/pub/CFP/WebHome/C2Y-F-Introduction-20260401.pdf

> The first statement in your F.3#20 is
> No C function f in Table F.2 and Table F.3 is required to be correctly
> rounded. 
> 
> To the contrary, all C functions in Table F.2 are required to be correctly
> rounded.

That's what I thought and have assumed for decades.  However, when you 
read F.10.1#16, it says not (at least as I read it) - but only for the 
functions.

 	ISO/IEC 60559 specifies correct rounding for the operations in
 	Table F.2 recommended by ISO/IEC 60559, and thereby preserves
 	useful mathematical properties such as symmetry, monotonicity, and
 	periodicity. ... The C functions in the table, however, are not
 	required to be correctly rounded, but implementations should still
 	preserve as many of these useful mathematical properties as
 	possible.

As I said, it is only the functions that are not required to be rounded. 
Anything which is an operator is still required to be rounded.

> In F.3#1, in the convertToIntegerTiesToAway row, second column, add a comma
> after ufromfp.

The fromfp and ufromfp cast refers to the next 2 entries in the 3rd 
column, and lround and llround refer to the next line.  Hence why I 
have the comma. Please check.

> I think the new table about rounding directions (F.3#???) belongs in current
> F.3#10. It could be introduced with something like:
>
>       The C rounding directions refer to the ISO/IEC 60559 rounding
>       direction attributes and correspond to the rounding direction
>       macros (7.6) as shown in Table n.
> 
> 
> followed by the table.

Thanks heaps. I figured it was F.3 but exact where was questionable.

Note that Table F.1 got lost a long time ago. We might need to renumber 
those tables.

> To accomodate decimal, a column for the rounding direction macros for
> decimal could be added to the table and a reference to the table could be
> added at the end of F.3#18. 

There is no room on the width of the page. I dropped the macros which 
starts to make the whole table idea a bit of overkill, unless you replace 
most of F.3#10 with my original table. That also means that F.3#18 needs 
to be redone as a table too.

> Since the only information added by the table is the correspondence between
> the C rounding directions ?toward zero?, etc. and 60559 attributes, that
> correspondence could be stated in words and a table would not be necessary.

Probably not a bad idea.  It saves a whole table but then again, the table 
is easier to read that the text of F.3#10. Do I need to do anything in 
F.3#18 also?  It needs discussion.

> If the table is added, some of the text in #10 and #18 could be omitted.

I do like your idea of dropping the table. But in another sense, I find 
the table more readable (with the binary macros included in a table F.3#10 
and a second table in F.3#18). Hmmm. Pondering ....

> General comment: I haven?t reviewed all of this paper.  The given Rationale
> claims many miscellaneous improvements have been made. With so many
> suggested changes I find it difficult to focus on a specific issue,

The major changes are those to F.2.2 where Infinities and NaNs are better 
organized and cleaner, especially with regard to signaling NaNs. There is 
an overlap that F.10.1 had with F.2.2 that is now fixed.

Likewise with F.3, it is better organized.  The overlap that F.10.1 had 
with F.3 with regard to those cr_-prefixed routines that is not better 
explained.

I think there are typos in F.1 and there is an editorial fix in F.5
with the use of a non technical term for the rounding direction.

I will itemize the Rationale better but not today.

Thanks - Damian