<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Jim Thomas <<a href="mailto:jaswthomas@sbcglobal.net">jaswthomas@sbcglobal.net</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Re: (SC22WG14.12761) Observations on N1631</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">October 4, 2012 11:36:04 AM PDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Joseph S. Myers <<a href="mailto:jsm@polyomino.org.uk">jsm@polyomino.org.uk</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Cc: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><a href="mailto:sc22wg14@open-std.org">sc22wg14@open-std.org</a><br></span></div><br><div>Joseph, many thanks for finding these issues and reporting them so clearly. Please see below.<br><br>-Jim<br><br>On Oct 4, 2012, at 8:50 AM, Joseph S. Myers wrote:<br><br><blockquote type="cite">On Wed, 3 Oct 2012, Joseph S. Myers wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- Is it also recommended practice for comparison and classification <br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> *macros* to raise that exception for signaling NaNs, unless specified <br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> otherwise? If so, should that be stated explicitly, so it's part of <br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> the recommended practice included in the FE_SNANS_ALWAYS_SIGNAL <br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> semantics?<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Yes, the recommended practice applies to the comparison and <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">classification macros. The new issignaling macro explicitly states that <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">it determines its result "without raising a floating-point exception". <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Other classification macros should, according to the recommended <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">practice, raise the "invalid" floating-point exception if an argument is <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">a signaling NaN. So should the comparison macros. Suggested changes to <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the descriptions of the comparison macros in 7.12.14 are intended to <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">admit the recommended practice (but not require it). Is there something <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">we're missing?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">What's missing is something saying "macro" alongside "function", so that <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this is explicitly included in the recommended practice (and so included <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">in what must be implemented if FE_SNANS_ALWAYS_SIGNAL is defined).<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Also: is raising the exception really the correct thing to do for <br></blockquote><blockquote type="cite">*classification* macros? They correspond to the non-computational <br></blockquote><blockquote type="cite">operations listed in 754-2008 5.7.2 General operations - which says "They <br></blockquote><blockquote type="cite">are never exceptional, even for signaling NaNs.". So I'd have thought it <br></blockquote><blockquote type="cite">would be a more accurate binding if the classification macros, old and new <br></blockquote><blockquote type="cite">- and signbit, and the new totalorder functions, and copysign / fabs / <br></blockquote><blockquote type="cite">negation as I mentioned earlier - were explicitly listed as not raising <br></blockquote><blockquote type="cite">the exception for signaling NaNs (and then you could insert the word <br></blockquote><blockquote type="cite">"macro" in the recommended practice, to make it explicit there what the <br></blockquote><blockquote type="cite">*comparison* macros must do for signaling NaNs if FE_SNANS_ALWAYS_SIGNAL, <br></blockquote><blockquote type="cite">with the other macros having been explicitly excluded individually).<br></blockquote><br>You are right. 754-2008 is clear that its classification operations do not raise the "invalid" exception for signaling NaN arguments. We will look for appropriate changes in the spec.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">Notes:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">* The binding of isZero to x == 0.0f, given in the table on page 8, is no <br></blockquote><blockquote type="cite">longer a correct binding in the presence of signaling NaNs if == signals <br></blockquote><blockquote type="cite">but isZero is non-computational and should not signal.<br></blockquote><br>Looks like we need an iszero() macro. <br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">* isnan (x) is no longer equivalent to isunordered (x, x) if isnan does <br></blockquote><blockquote type="cite">not signal for signaling NaN input but isunordered does. I don't think <br></blockquote><blockquote type="cite">anything in the text suggests they are equivalent; this is more a note <br></blockquote><blockquote type="cite">that could be relevant to C11 F.9.3, about a transformation <br></blockquote><blockquote type="cite">implementations may currently do that isn't valid for signaling NaNs.<br></blockquote><br>Right.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">-- <br></blockquote><blockquote type="cite">Joseph S. Myers<br></blockquote><blockquote type="cite"><a href="mailto:joseph@codesourcery.com">joseph@codesourcery.com</a><br></blockquote><br></div></blockquote></div><br></body></html>