<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;"><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Jun 5, 2025, at 4:04 AM, Vincent Lefevre <vincent@vinc17.net> wrote:</div><br class="Apple-interchange-newline"><div><div>In C23 5.2.5.3.4p10 and the latest C2y draft (N3550) 5.3.5.3.4p10,<br>"how the preferred quantum exponents of the operands, Q(x), Q(y),<br>etc." does not make sense because the operands already have a<br>quantum exponent (there is nothing preferred for the operands).<br>The notion of *preferred* quantum exponent is just used for the<br>choice of the quantum exponent of a result. So this should be<br>"how the quantum exponents of the operands, Q(x), Q(y), etc."<br>(i.e. remove "preferred").<br></div></div></blockquote><div><br></div>Agreed.</div><div><br><blockquote type="cite"><div><div><br>Moreover, the notion of preferred quantum exponent is used only<br>for exact results. In IEEE 754, this is perfectly specified thanks<br>to correct rounding. But C23/C2y does not require correct rounding<br>for all operations (F.3p20: "However, correct rounding, which<br>ISO/IEC 60559 specifies for its operations, is not required for<br>the C functions in the table."). So this is ambiguous for such<br>functions because an implementation does not need to determine<br>whether a result is exact or not (possibly except in special cases<br>given in Annex F, but the exactness is not explicit).<br></div></div></blockquote><div><br></div><div>Right.</div><div><br></div><div>In the preceding paragraph (5.3.5.3.4 #9), we might consider something like</div><div><br></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><div>… When exact, these operations produce a result with their preferred quantum exponent, or as close to it as possible within the limitations of the type. When inexact<span style="background-color: rgb(255, 251, 0);">, or when the implementation is not able to determine exactness*),</span> these operations produce a result with the least possible quantum exponent. </div></div></div></blockquote><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><span style="background-color: rgb(255, 251, 0);">*) It is assumed the implementation will determine exactness if the operation is specified to be correctly rounded or a particular result is specified for the argument. On the other hand, for example, an implementation might fail to determine exactness for <font face="Courier New">rootnd32(.125DF, 3)</font> though returning the exact numerical value .5. The special cases for the transcendental functions covered in F.10.2, F.10.3 and F.10.4 include all the cases where those functions, even if correctly rounded, can be exact.</span></div></blockquote><div><br></div><div><div>Also, in Table 5.2, the two rows for conversion from non-decimal floating type could be just one row:</div></div><div><br></div><div><div><span style="background-color: rgb(255, 251, 0);"><span class="Apple-tab-span" style="white-space: pre;"> </span>| conversion from non-decimal floating type | 0 |</span></div><div><div><div><br></div><div>Inexact conversion is covered by the general rule, as with other operations.</div><div><br></div><div>- Jim Thomas</div></div><div><br></div></div></div><div><blockquote type="cite"><br>-- <br>Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/><br>100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/><br>Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)<br>_______________________________________________<br>cfp-interest mailing list<br>cfp-interest@oakapple.net<br>http://mailman.oakapple.net/mailman/listinfo/cfp-interest<br></blockquote><div><br></div></div><br></body></html>