<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>