<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Indeed. During the early
explorations for this feature we got fooled by values for which
casting from T to U lost precision, but the corresponding cast
back from U to T was also imprecise, and so the round-trip T
-> U -> T preserved the input value. We scratched our
heads over this for a while.<br>
<br>
<br>
</font></font><br>
<div class="moz-cite-prefix">On 11/16/2022 10:15 AM, Dan Heidinga
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJq4Gi42e2-SRLOB+OimPYmc_kD2HgDdtr9pm5X2X=RH2SPn3g@mail.gmail.com">
<div dir="ltr">It's good to hear that you and others are thinking
through the details on how float/doubles will work.
<div><br>
</div>
<div>I still have some concern with user-intuition when writing
pattern matching code over floating point values if users base
their intuition on their experience with widening casts to
float. There's a great sample program (JLS Example 5.1.2-1)
which shows the loss of precision when casting a large int to
a float which I would try to express with pattern matching
roughly as:</div>
<div><br>
</div>
<div>record FloatBox(float f) {}</div>
<div>int big = 1234567890;</div>
<div>FloatBox box = new FloatBox(big);</div>
<div>if (box instanceof FloatBox(int i)) { </div>
<div> // pattern won't match here</div>
<div>}</div>
<div><br>
</div>
<div>I think users would be surprised reading the code that the
pattern doesn't match because converting back to an int would
lose precession.</div>
<div><br>
</div>
<div>The equivalent non-pattern code would be pretty clear that
it accepted the loss of precession:</div>
<div><br>
</div>
<div>if (box instanceof FLoatBox) {</div>
<div> int i = (int)box.f();</div>
<div> ....</div>
<div>}</div>
<div><br>
</div>
<div>Users will find it confusing when the pattern seems to
match "sometimes" though this is likely due to existing
confusion related to floating types. Maybe expanding on the
expected implementation will make it easier to build a mental
model for when the match will succeed?</div>
<div><br>
</div>
<div>--Dan</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Nov 15, 2022 at 6:13
PM Joseph D. Darcy <<a href="mailto:joe.darcy@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">joe.darcy@oracle.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
11/15/2022 12:13 PM, Brian Goetz wrote:<br>
><br>
><br>
> On 11/15/2022 2:55 PM, Dan Heidinga wrote:<br>
>> Hi Angelos,<br>
>><br>
>> The overall direction and writeup for this looks good
to me. I think <br>
>> we need to be more specific about how doubles &
floats fit into this <br>
>> though as they are perpetual source of special cases.<br>
><br>
> Indeed, floating point is the gift that keeps on giving.<br>
><br>
> Joe recently did some nice work in the spec of Float and
Double, <br>
> outlining the various different ways in which floats can
be compared. <br>
> This allows language features like pattern matching,
casting, and <br>
> switch to appeal to "compared by FooBar comparison",
rather than <br>
> spelling it out for each use.<br>
><br>
><br>
FYI, the new text in question is:<br>
<br>
<a href="https://urldefense.com/v3/__https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Double.html*fpNumericalEq__;Iw!!ACWV5N9M2RV99hQ!NLeYfZTwyKuJa79r6BKK7vCpK18EfV6UFYQATED31R-rgD9GThj4b5Apwa-MjRhTkfthC6sXdBLheOEVZLA$" rel="noreferrer" target="_blank" moz-do-not-send="true">https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Double.html#fpNumericalEq</a><br>
<br>
For the cases in the draft JEP, there have been separate
discussions <br>
working through the details. Putting aside how it might be
implemented, <br>
for the<br>
<br>
floating-point type -> integral type<br>
<br>
cases, conceptually if the same real number can be presented
in the <br>
floating-point type and the integral type, then the conversion
is exact. <br>
(While floating-point values are often thought of as "fuzzy,"
each <br>
finite floating-point value represents some particular real
number. <br>
Finite binary floating-point values are sums of the powers of
2 where <br>
the exponent difference of the powers is bounded by the
significand <br>
width of the floating-point format in question.) The main
special case <br>
is how conversion of -0.0 to an integral type is defined for
purposes of <br>
instanceof. The desired double -> float behavior can be
inferred from <br>
IEEE 754 concepts.<br>
<br>
HTH,<br>
<br>
-Joe<br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>