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

[Jim Thomas]

> On Apr 14, 2026, at 3:42 PM, Damian McGuckin <damianm at esi.com.au> wrote:
> 
> 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.

Yikes! That should say “operations in Table F.3", as it does in C23. Somehow it got changed in a C2Y draft.

> 
> 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.

The table doesn’t use lines within cells that way. A comma is also needed in your third column after "F.10.7.10”.

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