[Cfp-interest 2829] Re: CFP review of TS-4 revisions

[Jim Thomas]

> Fred J. Tydeman tydeman at tybor.com <mailto:cfp-interest%40oakapple.net?Subject=Re%3A%20%5BCfp-interest%202818%5D%20Re%3A%20CFP%20review%20of%20TS-4%20revisions&In-Reply-To=%3C100.2817020017a1da64.005%40tybor.com%3E>Mon Aug 14 13:48:07 PDT 2023
> On Sun, 6 Aug 2023 08:58:54 -0700 Jim Thomas wrote:
> >
> >https://wiki.edg.com/pub/CFP/WebHome/cfp4r-20230806.pdf
> >
> 
> Fred's comments on TS 18661-4
> 
> 5.1 page 2, line 6:  Is there a problem with freestanding
> implementations and <math.h> and trying to access the FP exception
> flags? [C23 4.0 Conformance, paragraph 7]
Is this a question about the TS or C? According to C23 4 #7 a strictly conforming program that defines __STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__ can’t access exception flags because it can’t set the FENV_ACCESS state to “on”.
> 
> 6.0 page 3, line 8:  Why "may" for SNaN?
Annex F doesn’t require support for signaling NaNs. The TSes don’t add a stricter requirement here.
> 
> 6.1 page 3, line 17: Can one get the extended functions without having
> to get the extended types?  Should there be functions for _Decimal32,
> _Decimal64, _Decimal128 without having to get extended types?
I assume you mean “extension” instead of “extended”. Yes, the intention is that 

#define __STDC_WANT_IEC_60559_TYPES_EXT__

is needed only for the functions for extension types in Annex H. To fully express the feature and want macro dependencies in the synopses gets messy. E.g. d32, d64, and d128 functions may be declared without TYPES but other dN or dNx functions require TYPES. Here’s a suggestion:

Just before 6.1 insert the paragraph:

For each of the following synopses, an implementation shall declare the functions suffixed with fN or fNx for each supported corresponding binary floating type and shall declare the functions suffixed with dN or dNx for each supported corresponding decimal floating type. (See C23 Annex H.)

and delete

#define __STDC_WANT_IEC_60559_TYPES_EXT__

from each synopsis.

Just before 7.1 insert the paragraph:

For each of the following synopses, an implementation shall declare the functions suffixed with fN or fNx for each supported corresponding binary floating type. (See C23 Annex H.)

and delete

#define __STDC_WANT_IEC_60559_TYPES_EXT__

from each synopsis.

> 
> 6.2 page 4, line 25:  Why does infinity have a higher precedence than
> NaN?  
NaN here refers to quiet NaN. Infinity has the higher precedence because |+/-inf| + |x| = +inf for any (finite or infinite) number x. It’s the same reasoning as for hypot(inf, qNaN) = +inf.
> What about SNaN?
These are <math.h> functions so they get the <math.h> specification for signaling NaNs. If the implementation supports signaling NaNs, an sNaN argument should raise “invalid” and return a qNaN.
> 
> 6.3 page 5, line 25:  Why does infinity have a higher precedence than
> NaN?  What about SNaN?
Same as above.
> 
> 7.* Instead of sum and error, would sum and residual be better?
> "error"  in the Returns section seems misleading. 
Use of “error” follows IEEE 754.

I suppose looking at just the Returns section could be misleading, but a Returns section isn’t the specification. For example, several of the functions in 7.12.9 have a Returns section that just says “The xxx functions return the rounded integer value.” 
> 
> 7.0 page 10, line 27:  Also independent of flush-to-zero mode.
There’s no flush-to-zero mode recognized by C23 Annex F or TS-4. In only appears once in C23 in a footnote.

However, TS-5 has an ABRUPT_UNDERFLOW action for its alternate exception handling pragma. This action is specified in 754 and it explicitly affects the augmented arithmetic operations. Our TSes don’t include this part of the specification. We should consider adding it in TS-5.

- Jim Thomas
> 
> 
> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com <http://mailman.oakapple.net/mailman/listinfo/cfp-interest>      Testing, numerics, programming
> +1 (702) 608-6093      Vice-chair of INCITS/C (ANSI "C")
> Sample C17+FPCE tests: http://www.tybor.com <http://www.tybor.com/>
> Savers sleep well, investors eat well, spenders work forever.
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230820/ae3f8868/attachment.htm>