<div dir="ltr"><div dir="ltr"></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024 at 11:21 PM Hubert Tong <<a href="mailto:hubert.reinterpretcast@gmail.com" target="_blank">hubert.reinterpretcast@gmail.com</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 dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024 at 2:10 AM Fred J. Tydeman <<a href="mailto:tydeman@tybor.com" target="_blank">tydeman@tybor.com</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">On Tue, 23 Apr 2024 22:56:50 -0600 (PDT) Fred J. Tydeman wrote:<br>
><br>
>It is no different than frexp( DBL_TRUE_MIN*2.2, &exp);<br>
>which returns DBL_TRUE_MIN*1.1 (which is not underflow)<br>
<br>
Oops.  Wrong example.  That frexp() would return a value<br>
between 0.5 and 1.0.<br>
<br>
long double a = 1.L + DBL_TRUE_MIN;<br>
long double b;<br>
<br>
b = a / 2.L;  /* would return 0.5L + DBL_TRUE_MIN/2.L */<br></blockquote><div><br></div><div>
<div>The value of `b` in your example is 0.5L (because 0.5L + DBL_TRUE_MIN/2.L is not representable in the type).</div>  <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Which is not an underflow<br></blockquote><div><br></div><div>I forgot to use scare quotes; silly me. Please move past the "underflow" terminology (although underflow does occur with respect to the second component of the double-double): The wording of frexp can be read as insisting that the result is exact.<br></div><div><br></div>If an exact result is not required, then `x` and `p` should be defined in terms of operations based on `value` (as opposed to now, where an operation involving `x` and `p` is supposed to result in `value`). `value` in the case presented is not the correctly-rounded result for any returned value `x`.</div><div><br></div><div>A more subtle change would be to change `x` to not be in code font. I believe being in code font implies a value representable by the corresponding type.<br></div></div></blockquote><div><br></div><div>I suppose the "math" interpretation leads to a situation where</div><div>frexpl(2.L - DBL_TRUE_MIN)</div><div><br></div><div>can be read as calculating x (mathematically) as 1.L - 0.5*DBL_TRUE_MIN, which would then round to a value of 1.L.</div><div><br></div><div>Technically, there is no specification issue because the input is not a floating-point number under the model (has a value not represented by the model); however, it may be helpful to specify that the range restriction is upon the correctly-rounded result (if that is the intent).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
---<br>
Fred J. Tydeman        Tydeman Consulting<br>
<a href="mailto:tydeman@tybor.com" target="_blank">tydeman@tybor.com</a>      Testing, numerics, programming<br>
+1 (702) 608-6093      Vice-chair of INCITS/C (ANSI "C")<br>
Sample C17+FPCE tests: <a href="http://www.tybor.com" rel="noreferrer" target="_blank">http://www.tybor.com</a><br>
Savers sleep well, investors eat well, spenders work forever.<br>
</blockquote></div></div>
</blockquote></div></div>
</div>