<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 19, 2018, at 8:59 AM, Fred J. Tydeman <<a href="mailto:tydeman@tybor.com" class="">tydeman@tybor.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">18661-2 quantize has<br class=""> Nothing about non-canonical encodings. <br class=""></div></div></blockquote><div><br class=""></div>We need a general statement about functions delivering canonical results unless specified otherwise. We say this implicitly through the binding with IEC 60559, but it would be good say it explicitly. It could go in part 1, which introduces the concept of canonical representations into C. 5.2.4.2.2#5a ends with: "Typically, floating-point operations deliver results with canonical representations.” We could append something like: “IEC 60559 operations deliver results with canonical representations, unless specified otherwise." </div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> Nothing about overflow.</div></div></blockquote><div><br class=""></div>The last sentence of the Description could say: The quantize functions do not raise the ”overflow” or “underflow” floating-point exception.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> Nothing about 'invalid' (which would be in Annex F).<br class=""></div></div></blockquote><div><br class=""></div>The decimal functions are intended to be specified in 7.12 to have IEC 60559 behavior. That is, all implementations that choose to provide them must follow IEC 60559. This means we should be able to give the entire specification in 7.12 without saying anything more in Annex F. Note that the Description of the quantize functions states the requirement for” inexact". It could do the same for “invalid":</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>[2] The quantizedN functions compute, if possible, a value with the numerical value of x and the quantum exponent of y. If the quantum exponent is being increased, the value shall be correctly rounded; if the result does not have the same value as x, the “inexact” floating-point exception shall be raised. If the quantum exponent is being decreased and the significand of the result has more digits than the type would allow, the result is NaN, the “invalid” floating-point exception is raised, and a domain error occurs. If one or both operands are NaN the result is NaN. Otherwise if only one operand is infinite, the result is NaN, the “invalid” floating-point exception is raised, and a domain error occurs. If both operands are infinite, the result is DEC_INFINITY with the sign of x, converted to the type of the function. The quantize functions do not raise the”overflow” or “underflow” floating-point exceptions.</div></blockquote><div><br class=""></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">754 has in 5.3.2<br class=""> ...this operation shall not propagate non-canonical encodings:<br class=""> quantize does not signal underflow or overflow.<br class=""> Otherwise if only one operand is infinite then the invalid operation<br class=""> exception is signaled and the result is a NaN.<br class=""><br class="">18661-2 llquantexp has<br class=""> Nothing about 'invalid' for infinite and NaN (which would be in Annex F).<br class=""></div></div></blockquote><div><br class=""></div>Following the approach above:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>[2] The llquantexpdN functions compute the quantum exponent (5.2.4.2.2a) of a finite argument. If x is infinite or NaN, they compute LLONG_MIN, the “invalid” floating-point exception is raised, and a domain error occurs.</div><div><br class=""></div></blockquote>- Jim Thomas<div class=""><br class=""><div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><br class="">---<br class="">Fred J. Tydeman Tydeman Consulting<br class=""><a href="mailto:tydeman@tybor.com" class="">tydeman@tybor.com</a> Testing, numerics, programming<br class="">+1 (702) 608-6093 Vice-chair of PL22.11 (ANSI "C")<br class="">Sample C99+FPCE tests: <a href="http://www.tybor.com" class="">http://www.tybor.com</a><br class="">Savers sleep well, investors eat well, spenders work forever.<br class=""><br class="">_______________________________________________<br class="">Cfp-interest mailing list<br class=""><a href="mailto:Cfp-interest@oakapple.net" class="">Cfp-interest@oakapple.net</a><br class="">http://mailman.oakapple.net/mailman/listinfo/cfp-interest<br class=""><br class=""></div></div></blockquote></div><br class=""></div></body></html>