<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><div><br><blockquote type="cite"><div>On Feb 2, 2023, at 1:04 PM, Hans Boehm <boehm@acm.org> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr">I think many people are also surprised by the fact, pointed out by Vincent here, and already mentioned in a footnote, that -0.1 is effectively rounded in the opposite direction of what was specified, something you can't tell without carefully reading in the standard that negation is not part of the constant's matissa (though it clearly is for the exponent). </div></div></blockquote><div><br></div><div>This is a long standing and well know problem. There are attempts to minimize the problem and warn about it. See (in N3054):</div><br>6.4.4.2 #12 NOTE 1 (In a previous message I mistakenly referred to 6.4.4.3.)<br>7.24.1.5 #4 footnote 355<br>7.24.1.6 #4 (Since the strtodN functions are new, we were able to require negation before rounding.)</div><div>F.5 #5 (For implementations that support Annex F "IEC 60559 floating-point arithmetic”, the strtod functions are required to negate before rounding.)</div><div><br></div><div>- Jim Thomas<br><div><br></div><br><blockquote type="cite"><div><div dir="ltr">I'm becoming more convinced that ideally explicit rounding should operate on a different type that requires rounding direction to be explicitly specified for every operation. The syntax will be ugly, but users might actually get it right. I'm also unclear as to whether explicit rounding modes are used enough to motivate implementers to actually invest effort here.<div><br></div><div>The WG21/SG6 discussion of my rounding mode paper is scheduled for Thursday evening PST, next week.<br><div><br></div><div>Hans</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 2, 2023 at 10:20 AM Jim Thomas <<a href="mailto:jaswthomas@sbcglobal.net" target="_blank">jaswthomas@sbcglobal.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div>Some more thoughts about floating constants …</div><div><br></div><div>Email messages</div><ul><li>[Cfp-interest 2673] Re: floating constants issue Vincent Lefevre</li></ul></div></div><div><ul><li>[Cfp-interest 2676] Re: floating constants issue Jim Thomas</li><li>[Cfp-interest 2669] Re: floating constants issue Hans Boehm</li><li>[Cfp-interest 2677] Re: floating constants issue Jim Thomas</li></ul></div><div><br></div><div>discuss issues following from the specification that constant rounding modes affect floating constants. </div><div><br></div><div>Rationale for the current specification is that it provides a way to control the rounding direction of floating constants. Without it, to get the value for a particular rounding of a decimal floating constant, one might need to replace the constant with an exact hexadecimal constant with the value of the rounded decimal constant, or one might be able to use an execution time operation (e.g. strtod) in place of the constant, provided the context didn’t require a constant. The rounding direction pragmas couldn’t be used to determine bounds without such extra attention for constants. </div><div><br></div><div>The problem Vincent pointed out in the example in 7.6.2 NOTE 1 shows constant rounding modes can’t be completely implemented with dynamic rounding controls, because constants are affected by constant modes but not by dynamic modes. The note can be fixed by replacing the first sentence</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Constant rounding modes could be implemented using dynamic rounding modes as illustrated in the following example: ...</div></blockquote><div><br></div><div>with</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Constant rounding modes could be implemented using dynamic rounding modes as illustrated in the following example, except that this method does not interpret inexact floating constants according to the constant rounding mode as required. </div></blockquote><div><br></div><div>The note will still serve to illustrate the relationship between constant and dynamic rounding modes. </div><div><br></div><div>Hans showed a possibly surprising implication of identical forms having different values because of constant rounding modes. Yes, constant rounding modes (as specified) need to be used with the awareness that inexact floating constants might get different values. Finding floating constants not affected by constant rounding modes might be surprising too.</div><div><br></div><div>- Jim Thomas</div><div><br><blockquote type="cite"><div>On Feb 1, 2023, at 9:38 AM, Jim Thomas <<a href="mailto:jaswthomas@sbcglobal.net" target="_blank">jaswthomas@sbcglobal.net</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br><br><blockquote type="cite"><div>On Jan 31, 2023, at 8:14 AM, Hans Boehm <<a href="mailto:boehm@acm.org" target="_blank">boehm@acm.org</a>> wrote:</div><br><div><div dir="ltr">I think this means that the same integer constant expression can now evaluate to different integers depending on the rounding mode.<span> </span></div></div></blockquote><div><br></div>Yes, I think that’s right.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br><blockquote type="cite"><div><div dir="ltr">Thus<div><br></div><div>int a[1 + (int)0.99999999999999999999999999999999999)]; may not be type compatible with itself, if it occurs in different rounding mode contexts.</div></div></div></blockquote></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>I'm not enough of a language lawyer and C compiler expert to determine whether this can be made to work. But I suspect the reason for the original rule was that somebody thought it couldn't.</div></div></div></blockquote><div><br></div>I’d guess the original rule was to disallow the translator from giving different results because of internal reasons unrelated to the semantics of the source code.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">- Jim Thomas</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Hans</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 31, 2023 at 7:40 AM Jim Thomas <<a href="mailto:jaswthomas@sbcglobal.net" target="_blank">jaswthomas@sbcglobal.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On Jan 30, 2023, at 5:51 PM, Vincent Lefevre <<a href="mailto:vincent@vinc17.net" target="_blank">vincent@vinc17.net</a>> wrote:</div><br><div><div>On 2023-01-30 15:19:52 -0800, Jim Thomas wrote:<br><blockquote type="cite">6.4.4.2 #8 says:<br><br>All floating constants of the same source form 83) shall convert to the same internal format with the same value.<br><br>With the FENV_ROUND and FENV_DEC_ROUND pragmas this is no longer true. For example, 7.6.2 #4 for FENV_ROUND says "Floating constants (6.4.4.2) of a standard floating type that occur in the scope of a constant rounding mode shall be interpreted according to that mode."<br><br>This was pointed out in a recent email which I was unable to find. Thanks to the sender.<br></blockquote><br>I posted the remark about 6.4.4.2 #8 in Cfp-interest 2634:<br> <a href="http://mailman.oakapple.net/pipermail/cfp-interest/2023-January/002648.html" target="_blank">http://mailman.oakapple.net/pipermail/cfp-interest/2023-January/002648.html</a><br><br>But I hadn't noticed the issue with FENV_ROUND.<br><br><blockquote type="cite">A fix would be to replace the sentence with something like:<br><br>All floating constants of the same source form shall convert to the same internal format. All floating constants of the same source form that are subject to the same translation-time rounding direction (either the default or a rounding direction set by an FENV_ROUND or FENV_DEC_ROUND pragma) shall convert to the same internal format with the same value.<br><br>or<br><br>All floating constants of the same source form shall convert to the same internal format and, provided they are subject to the same translation-time rounding direction (either the default or a rounding direction set by an FENV_ROUND or FENV_DEC_ROUND pragma), to the same value.<br></blockquote><br>Both are unclear. What if it is set to FE_DYNAMIC?<br></div></div></blockquote><div><br></div><div>Maybe</div><div><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>All floating constants of the same source form shall convert to the same internal format and, provided they are subject to the same translation-time rounding direction (either the default or a constant rounding mode other that FE_DYNAMIC set by an FENV_ROUND or FENV_DEC_ROUND pragma), to the same value.</div><div><br></div></blockquote>But that would suggest that same-form floating constants could have different values under FE_DYNAMIC. Setting to FE_DYNAMIC should not affect the translation time conversion of floating constants in that they would still get default translation-time rounding.<div><br><blockquote type="cite"><br>BTW, is there a way to restore the static rounding mode when<br>outside external declarations? This would be important if one<br>wants to use this pragma in a header file.<br></blockquote><div><br></div>It can be “restored" to FE_DYNAMIC which serves as a “default”.</div><div><br></div><div>- Jim Thomas<br><blockquote type="cite"><br>--<span> </span><br>Vincent Lefèvre <<a href="mailto:vincent@vinc17.net" target="_blank">vincent@vinc17.net</a>> - Web: <<a href="https://www.vinc17.net/" target="_blank">https://www.vinc17.net/</a>><br>100% accessible validated (X)HTML - Blog: <<a href="https://www.vinc17.net/blog/" target="_blank">https://www.vinc17.net/blog/</a>><br>Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)<br>_______________________________________________<br>Cfp-interest mailing list<br><a href="mailto:Cfp-interest@oakapple.net" target="_blank">Cfp-interest@oakapple.net</a><br><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest" target="_blank">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</a><br></blockquote><div><br></div></div><br></div>_______________________________________________<br>Cfp-interest mailing list<br><a href="mailto:Cfp-interest@oakapple.net" target="_blank">Cfp-interest@oakapple.net</a><br><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest" rel="noreferrer" target="_blank">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</a><br></blockquote></div></div></blockquote></div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Cfp-interest mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><a href="mailto:Cfp-interest@oakapple.net" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Cfp-interest@oakapple.net</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</a></div></blockquote></div><br></div></blockquote></div>
</div></blockquote></div><br></body></html>