<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.12733) 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;">September 30, 2012 3:14:33 PM 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><br>Joseph,<br><br>Thanks for the further comments. Please see responses below.<br><br>-Jim<br><br>On Sep 27, 2012, at 5:45 PM, Joseph S. Myers wrote:<br><br><blockquote type="cite">Some more observations, these ones relating to signaling NaNs, and cases <br></blockquote><blockquote type="cite">where C11 specifies something in math.h as a macro rather than a function:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">* The recommended practice for signaling NaNs (page 18, lines 4-5) is that <br></blockquote><blockquote type="cite">"[6] Any floating-point operator or <math.h> function with a signaling NaN <br></blockquote><blockquote type="cite">input, unless explicitly specified otherwise, raises an "invalid" <br></blockquote><blockquote type="cite">floating-point exception.". This raises a couple of questions:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> - Is it also recommended practice for comparison and classification <br></blockquote><blockquote type="cite"> *macros* to raise that exception for signaling NaNs, unless specified <br></blockquote><blockquote type="cite"> otherwise? If so, should that be stated explicitly, so it's part of <br></blockquote><blockquote type="cite"> the recommended practice included in the FE_SNANS_ALWAYS_SIGNAL <br></blockquote><blockquote type="cite"> semantics?<br></blockquote><br>Yes, the recommended practice applies to the comparison and classification macros. The new issignaling macro explicitly states that it determines its result "without raising a floating-point exception". Other classification macros should, according to the recommended practice, raise the "invalid" floating-point exception if an argument is a signaling NaN. So should the comparison macros. Suggested changes to the descriptions of the comparison macros in 7.12.14 are intended to admit the recommended practice (but not require it). Is there something we're missing?<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"> - Does this recommended practice include recommending that negation, <br></blockquote><blockquote type="cite"> fabs and copysign raise that exception for signaling NaNs? (Those <br></blockquote><blockquote type="cite"> being quiet-computational operations in 754-2008, I'm not sure what <br></blockquote><blockquote type="cite"> the intent of 754-2008 is regarding what they do with signaling NaNs - <br></blockquote><blockquote type="cite"> 5.5.1 says "signal no exception", unconditionally, but 6.2 refers to <br></blockquote><blockquote type="cite"> "Every general-computational and quiet-computational operation <br></blockquote><blockquote type="cite"> involving one or more input NaNs, *none of them signaling* ..." (my <br></blockquote><blockquote type="cite"> emphasis).)<br></blockquote><br>The intention in 754-2008 and the CFP spec is that these operations raise no floating-point exceptions, even if the input is a signaling NaN. 754-2008 clearly states this in 5.5.1, and doesn't contradict itself in 6.2 (although 6.2 could have been more definitive). However, I don't see were C11 or the CFP spec says this, except by reference to 754. We'll look into it.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">* The iseqsig macro is specified to produce a domain error for NaN <br></blockquote><blockquote type="cite">arguments. Is this meant to require setting errno if math_errhandling & <br></blockquote><blockquote type="cite">MATH_ERRNO is nonzero - or not, because the wording about what domain <br></blockquote><blockquote type="cite">errors mean (C11 7.12.1 paragraph 2) is only for functions, not macros?<br></blockquote><br>Maybe we could say directly (without reference to domain errors) that errno is set to EDOM if math_errhandling & MATH_ERRNO is nonzero and an argument is a NaN.<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>