[Cfp-interest 2914] Re: [SC22WG14.23916] N3163 TS 18661-4 revision

[Jim Thomas]

Below is a draft response (reviewed Rajan) to Joseph’s comments. Please review it and send comments by noon PDT / 7 PM UTC tomorrow (Oct 14). Later tomorrow I’ll incorporate your comments in a CFP email response to WG 14 (which is meeting to discuss TS-4r this coming Monday).

- Jim Thomas 


> On Oct 12, 2023, at 2:01 PM, Joseph Myers <joseph at codesourcery.com <mailto:joseph at codesourcery.com>> wrote:
> 
> Some comments on the N3163 revision of TS 18661-4:
> 
> 1. Page vii has a duplicate paragraph: the paragraph starting "ISO/IEC TR 
> 24732:2009 introduced" appears twice (starting lines 25 and 30).

Right. Delete one of them.
> 
> 
> 2. Why are the reduction functions now restricted to IEC 60559 types (so 
> an implementation that has a non-IEC-60559 long double wouldn't provide 
> them for long double, for example)?  There's nothing particularly specific 
> to IEC 60559 formats about these functions - and indeed, even the Annex F 
> functions in C23 that go in Annex F because of how closely related they 
> are to such formats (totalorder and payload functions) are defined for all 
> of float, double and long double if the implementation defines 
> __STDC_IEC_60559_BFP__, even if long double has a non-IEC-60559 format.  
> (Maybe the restriction makes more sense for the augmented arithmetic 
> functions.)

Agree. The facts that an Annex F long double type has to include all the values of the IEC 60559 double type and has to support floating-point exceptions is sufficient for supporting the reduction functions.

On page 2, lines 23-25, change:

Each function in this subclause is declared in <math.h> if and only if the corresponding type is an IEC 60559 type supported according to C23 Annex F or an IEC 60559 arithmetic interchange or extended type supported according to C23 Annex H.

to:

Each function in this subclause is declared in <math.h> if and only if the corresponding type is supported according to C23 Annex F or Annex H.

The detailed specification of the augmented arithmetic functions is intended specifically for IEC 60559 binary types. CFP hasn’t investigated generalizing the specification for other types.

> 
> 
> 3. Is "Whether and how rounding direction modes affect functions in this 
> subclause are implementation defined and may be indeterminate." intended 
> to relate to dynamic rounding directions (restating F.10#13), to constant 
> rounding directions (overriding the general rules in 7.6.2 and 7.6.3) or 
> both?

It is intended to relate to both. 

It is consistent with F.10#13, which says "Whether the functions not listed in the "Operation binding" table in F.3 honor the rounding direction mode is implementation-defined, unless explicitly specified otherwise."

However it is not consistent with 7.6.2#4 (and by analogy 7.6.3) which says "invocations of functions other than those indicated in the table below shall not be affected by constant rounding modes."

Maybe 7.6.2#4 should have said "invocations of functions other than those indicated in the table below shall not be affected by constant rounding modes, unless explicitly specified otherwise.”

Would it help to change the TS-4 paragraph on page 3 line 11 from:

Whether and how rounding direction modes affect functions in this subclause are implementation defined and may be indeterminate.

to:

Whether and how rounding direction modes affect functions in this subclause are implementation defined and may be indeterminate. This applies to constant as well as dynamic rounding modes, C23 7.6.2 notwithstanding.


> 
> 
> 4. The statement "For each of the following synopses, an implementation 
> shall declare the functions suffixed with fN or fNx only if it defines 
> __STDC_WANT_IEC_60559_TYPES_EXT__ and supports the corresponding binary 
> floating type. An implementation shall declare the functions suffixed with 
> dN or dNx only if it defines __STDC_WANT_IEC_60559_TYPES_EXT__ and 
> supports the corresponding decimal floating type. (See C23 Annex H.)" 
> doesn't seem quite right.
> 
> (a) It should be the application, not the implementation, that defines the 
> WANT macros before including the relevant header.  This issue also applies 
> to the same wording for the augmented arithmetic functions.

Agree.

> (b) The functions for _Decimal32, _Decimal64 and _Decimal128 should not 
> depend on __STDC_WANT_IEC_60559_TYPES_EXT__ - that macro should only 
> affect _FloatN, _FloatNx, _DecimalNx types, and _Decimal N for N not 32, 
> 64 or 128, for consistency with other functions.

Agree. 

To address both of these ...

On page 3 lines 14-18 change:

For each of the following synopses, an implementation shall declare the functions suffixed with fN or fNx only if it defines __STDC_WANT_IEC_60559_TYPES_EXT__ and supports the corresponding binary floating type. An implementation shall declare the functions suffixed with dN or dNx only if it defines __STDC_WANT_IEC_60559_TYPES_EXT__ and supports the corresponding decimal floating type. (See C23 Annex H.)

to:

For each of the following synopses, an implementation shall declare the functions suffixed with fN or fNx only if it supports the corresponding binary floating type and the macro __STDC_WANT_IEC_60559_TYPES_EXT__ is defined at the point in the code where <math.h> is first included. An implementation shall declare the functions suffixed with dN for N ≠ 32, 64 or 128 or with dNx only if it supports the corresponding decimal floating type and the macro __STDC_WANT_IEC_60559_TYPES_EXT__ is defined at the point in the code where <math.h> is first included.. (See C23 Annex H.)

> 
> 5. Is a call to a reduc_sum function where the array members include a 
> positive infinity, a negative infinity and a quiet NaN intended to be 
> required to signal "invalid" (that seems to be what the wording says), or 
> is that intended to be unspecified ("Numerical results and exceptional 
> behavior, including the “invalid” floating-point exception, might differ 
> due to the precision of intermediates and the order of evaluation."), 
> similar to fma (0, Inf, NaN)?  Likewise for reduc_sumprod and other 
> functions.

The TS (and IEC 60559) specification requires reduc_sum where the array members include a positive infinity, a negative infinity and a quiet NaN to signal “invalid”.

The IEEE 754 email forum recently discussed the inconsistency in the current IEEE 754 specifications for its fma and dot (reduc_sumprod in TS-4) operations: whether fma(infinity, 0, qNAN) signals “invalid” is implementation defined, but similar cases for the dot operation are required to signal “invalid". There has been no 754 committee action on this issue regarding a future direction.

TS-4 follows the IEC 60559 specification.

- Jim Thomas

> 
> -- 
> Joseph S. Myers
> joseph at codesourcery.com <mailto:joseph at codesourcery.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20231013/e5691d0d/attachment.htm>