<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><meta charset="UTF-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Thanks, Joseph.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Please see suggested responses below.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">- Jim Thomas, CFP</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br><div><br><blockquote type="cite"><div>On Oct 12, 2023, at 2:01 PM, Joseph Myers <<a href="mailto:joseph@codesourcery.com">joseph@codesourcery.com</a>> wrote:</div><br class="Apple-interchange-newline"><div><div>Some comments on the N3163 revision of TS 18661-4:<br><br>1. Page vii has a duplicate paragraph: the paragraph starting "ISO/IEC TR<span class="Apple-converted-space"> </span><br>24732:2009 introduced" appears twice (starting lines 25 and 30).<br></div></div></blockquote><div><br></div>Right. Delete one of them.<br><blockquote type="cite"><div><div><br><br>2. Why are the reduction functions now restricted to IEC 60559 types (so<span class="Apple-converted-space"> </span><br>an implementation that has a non-IEC-60559 long double wouldn't provide<span class="Apple-converted-space"> </span><br>them for long double, for example)? There's nothing particularly specific<span class="Apple-converted-space"> </span><br>to IEC 60559 formats about these functions - and indeed, even the Annex F<span class="Apple-converted-space"> </span><br>functions in C23 that go in Annex F because of how closely related they<span class="Apple-converted-space"> </span><br>are to such formats (totalorder and payload functions) are defined for all<span class="Apple-converted-space"> </span><br>of float, double and long double if the implementation defines<span class="Apple-converted-space"> </span><br>__STDC_IEC_60559_BFP__, even if long double has a non-IEC-60559 format. <br>(Maybe the restriction makes more sense for the augmented arithmetic<span class="Apple-converted-space"> </span><br>functions.)<br></div></div></blockquote><div><br></div>Agree. The facts that an Annex F<span class="Apple-converted-space"> </span><b>long double</b><span class="Apple-converted-space"> </span>type has to include all the values of the IEC 60559<span class="Apple-converted-space"> </span><b>double</b><span class="Apple-converted-space"> </span>type and has to support floating-point exceptions is sufficient for supporting the reduction functions.</div><div><br></div><div>On page 2, lines 23-25, change:</div><div><br></div><blockquote style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;"><div>Each function in this subclause is declared in<span class="Apple-converted-space"> </span><b><math.h></b><span class="Apple-converted-space"> </span>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.</div></blockquote><div><br></div><div>to:</div><div><br></div><blockquote style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;"><div>Each function in this subclause is declared in<span class="Apple-converted-space"> </span><b><math.h></b><span class="Apple-converted-space"> </span>if and only if the corresponding type is supported according to C23 Annex F or Annex H.</div></blockquote><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div><div><br><br>3. Is "Whether and how rounding direction modes affect functions in this<span class="Apple-converted-space"> </span><br>subclause are implementation defined and may be indeterminate." intended<span class="Apple-converted-space"> </span><br>to relate to dynamic rounding directions (restating F.10#13), to constant<span class="Apple-converted-space"> </span><br>rounding directions (overriding the general rules in 7.6.2 and 7.6.3) or<span class="Apple-converted-space"> </span><br>both?<br></div></div></blockquote><div><br></div>It is intended to relate to both. </div><div><br></div><div>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."</div><div><br></div><div>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."</div><div><br></div><div>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.”</div><div><br></div><div>Would it help to change the TS-4 paragraph on page 3 line 11 from:</div><div><br></div><blockquote style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;"><div>Whether and how rounding direction modes affect functions in this subclause are implementation defined and may be indeterminate.</div></blockquote><div><br></div><div>to:</div><div><br></div><blockquote style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;"><div><div>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.</div></div></blockquote><div><div><br></div></div><div><br><blockquote type="cite"><div><div><br><br>4. The statement "For each of the following synopses, an implementation<span class="Apple-converted-space"> </span><br>shall declare the functions suffixed with fN or fNx only if it defines<span class="Apple-converted-space"> </span><br>__STDC_WANT_IEC_60559_TYPES_EXT__ and supports the corresponding binary<span class="Apple-converted-space"> </span><br>floating type. An implementation shall declare the functions suffixed with<span class="Apple-converted-space"> </span><br>dN or dNx only if it defines __STDC_WANT_IEC_60559_TYPES_EXT__ and<span class="Apple-converted-space"> </span><br>supports the corresponding decimal floating type. (See C23 Annex H.)"<span class="Apple-converted-space"> </span><br>doesn't seem quite right.<br><br>(a) It should be the application, not the implementation, that defines the<span class="Apple-converted-space"> </span><br>WANT macros before including the relevant header. This issue also applies<span class="Apple-converted-space"> </span><br>to the same wording for the augmented arithmetic functions.<br></div></div></blockquote><div><br></div></div><div>Agree.</div><div><br></div><div><blockquote type="cite"><div><div>(b) The functions for _Decimal32, _Decimal64 and _Decimal128 should not<span class="Apple-converted-space"> </span><br>depend on __STDC_WANT_IEC_60559_TYPES_EXT__ - that macro should only<span class="Apple-converted-space"> </span><br>affect _FloatN, _FloatNx, _DecimalNx types, and _Decimal N for N not 32,<span class="Apple-converted-space"> </span><br>64 or 128, for consistency with other functions.<br></div></div></blockquote><div><br></div>Agree. </div><div><br></div><div>To address both of these ...</div><div><br></div><div>On page 3 lines 14-18 change:</div><div><br></div><blockquote style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;"><div><div>For each of the following synopses, an implementation shall declare the functions suffixed with <b>f</b><i>N</i> or <b>f</b><i>N</i><b>x</b> only if it defines <b>__STDC_WANT_IEC_60559_TYPES_EXT__</b> and supports the corresponding binary floating type. An implementation shall declare the functions suffixed with <b>d</b><i>N</i> or <b>d</b><i>N</i><b>x</b> only if it defines <b>__STDC_WANT_IEC_60559_TYPES_EXT__</b> and supports the corresponding decimal floating type. (See C23 Annex H.)</div></div></blockquote><div><br></div><div>to:</div><div><br></div><div><div><div><div><blockquote style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;"><div><div>For each of the following synopses, an implementation shall declare the functions suffixed with <b>f</b><i>N</i> or <b>f</b><i>N</i><b>x</b> only if it supports the corresponding binary floating type and the macro <b>__STDC_WANT_IEC_60559_TYPES_EXT__</b> is defined at the point in the code where <b><math.h></b> is first included. An implementation shall declare the functions suffixed with <b>d</b><i>N</i> for <i>N</i> ≠ 32, 64 or 128 or with <b>d</b><i>N</i><b>x</b> only if it supports the corresponding decimal floating type and the macro <b>__STDC_WANT_IEC_60559_TYPES_EXT__</b> is defined at the point in the code where <b><math.h></b> is first included.. (See C23 Annex H.)</div></div></blockquote></div></div></div></div><div><br></div><div><div><blockquote type="cite"><br>5. Is a call to a reduc_sum function where the array members include a<span class="Apple-converted-space"> </span><br>positive infinity, a negative infinity and a quiet NaN intended to be<span class="Apple-converted-space"> </span><br>required to signal "invalid" (that seems to be what the wording says), or<span class="Apple-converted-space"> </span><br>is that intended to be unspecified ("Numerical results and exceptional<span class="Apple-converted-space"> </span><br>behavior, including the “invalid” floating-point exception, might differ<span class="Apple-converted-space"> </span><br>due to the precision of intermediates and the order of evaluation."),<span class="Apple-converted-space"> </span><br>similar to fma (0, Inf, NaN)? Likewise for reduc_sumprod and other<span class="Apple-converted-space"> </span><br>functions.<br></blockquote><div><br></div>The TS (and IEC 60559) specification requires<span class="Apple-converted-space"> </span><b>reduc_sum</b><span class="Apple-converted-space"> </span>where the array members include a positive infinity, a negative infinity and a quiet NaN to signal “invalid”.</div><div><br></div><div>The IEEE 754 email forum recently discussed the inconsistency in the current IEEE 754 specifications for its fma and dot (<b>reduc_sumprod</b><span class="Apple-converted-space"> </span>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.</div><div><br></div><div>TS-4 follows the IEC 60559 specification.</div><div><br></div><div><br><blockquote type="cite"><br>--<span class="Apple-converted-space"> </span><br>Joseph S. Myers<br><a href="mailto:joseph@codesourcery.com">joseph@codesourcery.com</a></blockquote></div></div></div></div></body></html>