<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;">The subject line refers to the comment:<div><br><div><div>CA-N3073-006</div><div>5.2.4.2.2 te </div><div>Comments</div><div>The deployment impact of making a change to</div><div>the floating-point model by clarifying that model</div><div>parameters are to be chosen such that all</div><div>normalized floating-point numbers are</div><div>representable is unknown. Both AIX and Linux on</div><div>Power use values of “p” for “double-double” that</div><div>does not match the new definition in the CD.</div><div>Proposed change</div><div>For float, double, and long double: Add new</div><div>*_MODEL_MANT_DIG and *_MODEL_EPSILON</div><div>macros with the definitions of the *_MANT_DIG</div><div>and *_EPSILON macros from the CD.</div><div>For float, double, and long double: Modify the</div><div>definitions of *_MANT_DIG and *_EPSILON by</div><div>adding “in relation to implementation-defined</div><div>model parameters not subject to the restriction</div><div>that the floating type is able to represent all</div><div>normalized floating-point numbers”.</div><div><br></div><div><div>Following are my initial thoughts about CA-N3073-006. They are intended as input to CFP discussion of the comment. Ideally, we’ll be able to arrive at a CFP response by email without needing the teleconference tentatively scheduled for Wednesday, January 18.</div><div><br></div><div><div>The proposed change to the existing *_MANT_DIG and *_EPSILON macros, i.e. adding “in relation to implementation-defined model parameters not subject to the restriction that the floating type is able to represent all normalized floating-point numbers” would seem to undermine the very notion of precision as a property of the type. What would the type precision p mean? What use could be made of the macros (with the proposed changes)?</div><div><br></div><div>How do the AIX and Linux implementations referred to in the comment currently define the macros?</div><div><br></div><div>In C18, 5.2.4.2.2 #4, “In addition to normalized floating-point numbers (f1 > 0 if x ≠ 0), floating types may be able to contain other kinds of floating-point numbers …” is problematic grammatically and could be taken to mean floating types do contain the normalized numbers. Users might well have assumed that normalized model numbers are represented in the type (which has been generally true) and used the relevant macros accordingly. The change proposed in the comment would indicate that most users should switch to the new macros. A better approach would seem to be for implementations mentioned in the comment to introduce their own macros suitable for their interpretation of the parameters.</div><div><br></div><div>If it is deemed necessary to allow unrepresentable normalized numbers, then the following might be considered:</div><div><br></div><div>Change the first sentence of 5.2.4.2.2 #8:</div><div><br></div><div>Floating types shall be able to represent signed zeros or an unsigned zero and all normalized floating-point numbers.</div><div><br></div><div>to:</div><div><br></div><div>Floating types shall be able to represent signed zeros or an unsigned zero and should be able to represent all normalized floating-point numbers. Whether the type can represent all normalized floating-point numbers is implementation defined.</div><div><br></div><div>-<span class="Apple-tab-span" style="white-space: pre;"> </span>Jim Thomas</div><br class="Apple-interchange-newline"></div></div><div><br><blockquote type="cite"><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">Joseph Myers <joseph@codesourcery.com><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;"><b>[SC22WG14.22874] CFP views on CA-N3073-006</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">January 11, 2023 at 3:05:52 PM PST<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;"><sc22wg14@open-std.org><br></span></div><br><div><div>N3073 (updated Canada comments) includes a new comment CA-N3073-006, which <br>I think the CFP group should provide views on. (Personally I don't think <br>new macros are needed there; in particular, any uses of LDBL_EPSILON for <br>double-double tended in my experience to need to override the value, to <br>replace one with the old semantics with one with (or close to) the new <br>(N2326) semantics, and indeed the change to *_EPSILON in N2326 is arguably <br>a defect fix for part of the issue originally reported in DR#467.)<br><br>(The other new floating-point-related comments in N3073 shouldn't need CFP <br>comments: CA-N3073-003 is a duplicate of GB-016, while CA-N3073-002 and <br>CA-N3073-004 are routine editorial comments.)<br><br>-- <br>Joseph S. Myers<br>joseph@codesourcery.com<br></div></div></blockquote></div><br></div></div></body></html>