<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">Everything about floating
        point is difficult and fiddly and resists a one-size-fits-all
        treatment.  Joe recently did some work to characterize the
        various ways floats can be compared -- representational
        equivalence, bitwise equivalence, and the traditional `==`, and
        put these in the spec of Float/Double, so we would have a
        vocabulary to discuss them.<br>
        <br>
        The main differences between these treatments are the treatment
        of NaN and signed zeroes.  (And for $REASONS, there are multiple
        NaN bit patterns.)  <br>
        <br>
        Representational equality means "same number", where all NaN
        values are the same.  Float::equals uses representational
        equality.<br>
        <br>
        Bitwise equality means "same bit pattern".<br>
        <br>
        The `==` operator says that 0 == -0 and that NaN is equal to
        nothing, not even itself.  <br>
        <br>
        For comparing a variable to a constant, representational
        equality is the obvious interpretation; `case nnn` means "is it
        the number nnn".  This allows you to say `case NaN` and `case
        -0` and get the right answer (all of these relations agree on
        what to do about 1.0).  <br>
        <br>
        For Valhalla's `==`, which we've decided means "substitutible"
        or "indistinguishable from", then bitwise equality is the
        obvious answer.  Its sad that these are all different, and each
        case requires getting experts in a room to hash it out, but
        that's life with floating point.<br>
        <br>
        Your claim about refactoring anomalies is not right; the
        refactoring you offer will work for your example which uses
        3.14, because `==` agrees with r.e. at the "regular" floating
        point values.  Where it will fail is for NaN, as `==` has its
        own weird opinions about NaN.  But `== NaN` is intrinsically
        useless anyway, since it folds to false, and anyone who knows
        what NaN is already knows this (probably by having been bitten
        by it).  <br>
      </font></font><br>
    <div class="moz-cite-prefix">On 1/26/2023 9:25 AM, <a class="moz-txt-link-abbreviated" href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:226409753.5913335.1674743136668.JavaMail.zimbra@u-pem.fr">
      
      <div style="font-family: arial, helvetica, sans-serif; font-size:
        12pt; color: #000000">
        <div><br>
        </div>
        <div><br>
        </div>
        <hr id="zwchr" data-marker="__DIVIDER__">
        <div data-marker="__HEADERS__">
          <blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
            </b>"Angelos Bimpoudis" <a class="moz-txt-link-rfc2396E" href="mailto:angelos.bimpoudis@oracle.com"><angelos.bimpoudis@oracle.com></a><br>
            <b>To: </b>"Remi Forax" <a class="moz-txt-link-rfc2396E" href="mailto:forax@univ-mlv.fr"><forax@univ-mlv.fr></a><br>
            <b>Cc: </b>"amber-spec-experts"
            <a class="moz-txt-link-rfc2396E" href="mailto:amber-spec-experts@openjdk.org"><amber-spec-experts@openjdk.org></a><br>
            <b>Sent: </b>Thursday, January 26, 2023 2:55:31 PM<br>
            <b>Subject: </b>Re: Draft JEP on Primitive types in
            patterns, instanceof, and switch<br>
          </blockquote>
        </div>
        <div>
          <style style="display:none;">P {margin-top:0;margin-bottom:0;}</style></div>
        <div data-marker="__QUOTED_TEXT__">
          <blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
            <div style="font-family: "Segoe UI", "Segoe
              UI ", "Helvetica Neue", sans-serif;
              font-size: 11pt; color: rgb(0, 0, 0); background-color:
              rgb(255, 255, 255);" class="elementToProof">
              Thanks for the quick reply. </div>
            <div style="font-family: "Segoe UI", "Segoe
              UI ", "Helvetica Neue", sans-serif;
              font-size: 11pt; color: rgb(0, 0, 0); background-color:
              rgb(255, 255, 255);" class="elementToProof">
              <br>
            </div>
            <div style="font-family: "Segoe UI", "Segoe
              UI ", "Helvetica Neue", sans-serif;
              font-size: 11pt; color: rgb(0, 0, 0); background-color:
              rgb(255, 255, 255);" class="elementToProof">
              I think there is one important factor here. By quickly
              inspecting the issues in the links, <span style="background-color:rgb(255, 255,
                255);display:inline !important" class="ContentPasted0">IIUC,<span class="ContentPasted0 ContentPasted1 ContentPasted5"> the
                  semantics of floating-point constants there follow the
                  semantics of <code>==</code>​. So -0 and 0 compare
                  equal there (e.g., <a href="https://github.com/rust-lang/rust/issues/41620#issuecomment-300587182" id="LPNoLPOWALinkPreview" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/rust-lang/rust/issues/41620#issuecomment-300587182</a>). </span></span></div>
            <div style="font-family: "Segoe UI", "Segoe
              UI ", "Helvetica Neue", sans-serif;
              font-size: 11pt; color: rgb(0, 0, 0); background-color:
              rgb(255, 255, 255);" class="elementToProof">
              <span style="background-color:rgb(255, 255,
                255);display:inline !important" class="ContentPasted0"><span class="ContentPasted0 ContentPasted1"><br>
                </span></span></div>
            <div style="font-family: "Segoe UI", "Segoe
              UI ", "Helvetica Neue", sans-serif;
              font-size: 11pt; color: rgb(0, 0, 0); background-color:
              rgb(255, 255, 255);" class="elementToProof">
              <span style="background-color:rgb(255, 255,
                255);display:inline !important" class="ContentPasted0"><span class="ContentPasted0 ContentPasted1">The JEP follows
                  the road
                </span><span class="ContentPasted0 ContentPasted1
                  ContentPasted3" style="font-size: 11pt;">of
                  "representation equivalence" as described in <a href="https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Double.html#fpNumericalEq" style="margin:0px;background-color:rgb(255, 255,
                    255)" class="ContentPasted4 moz-txt-link-freetext" 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></span></span></div>
            <div style="font-family: "Segoe UI", "Segoe
              UI ", "Helvetica Neue", sans-serif;
              font-size: 11pt; color: rgb(0, 0, 0); background-color:
              rgb(255, 255, 255);" class="elementToProof">
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>In terms of semantics Double::equals may be better than
            double == double, this seems to be the direction that Java
            is choosing (Valhhalla also used Double::equals for value
            types containing a double).<br>
          </div>
          <div><br data-mce-bogus="1">
          </div>
          <div>But it means that introducing a "when" is not a valid
            refactoring<br data-mce-bogus="1">
          </div>
          <div>  case double 3.14 -> ...<br>
          </div>
          <div>can not be refactored to<br data-mce-bogus="1">
          </div>
          <div>  case double x when x == 3.14 -> ...<br data-mce-bogus="1">
          </div>
          <div><br data-mce-bogus="1">
          </div>
          <div>Most of my students thinks in terms of equivalence,
            breaking this kind of refactoring make the proposed
            semantics not intuitive. <br data-mce-bogus="1">
          </div>
          <div><br data-mce-bogus="1">
          </div>
          <div>That's why i think it's better to not allow double/float
            constants, so people have to be explicit about the semantics
            they want.<br data-mce-bogus="1">
          </div>
          <div><br data-mce-bogus="1">
          </div>
          <div>regards,<br data-mce-bogus="1">
          </div>
          <div>Rémi<br data-mce-bogus="1">
          </div>
          <div><br data-mce-bogus="1">
          </div>
          <blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
            <div style="font-family: "Segoe UI", "Segoe
              UI ", "Helvetica Neue", sans-serif;
              font-size: 11pt; color: rgb(0, 0, 0); background-color:
              rgb(255, 255, 255);" class="elementToProof"><span style="background-color:rgb(255, 255,
                255);display:inline !important" class="ContentPasted0"><span class="ContentPasted0 ContentPasted1 ContentPasted3" style="font-size: 11pt;"><br>
                </span></span></div>
            <div style="font-family: "Segoe UI", "Segoe
              UI ", "Helvetica Neue", sans-serif;
              font-size: 11pt; color: rgb(0, 0, 0); background-color:
              rgb(255, 255, 255);" class="elementToProof">
              <span style="background-color:rgb(255, 255,
                255);display:inline !important" class="ContentPasted0"><span class="ContentPasted0 ContentPasted1 ContentPasted3" style="font-size: 11pt;"><br>
                </span></span></div>
            <hr style="display:inline-block;width:98%">
            <div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Remi Forax
                <a class="moz-txt-link-rfc2396E" href="mailto:forax@univ-mlv.fr"><forax@univ-mlv.fr></a><br>
                <b>Sent:</b> 26 January 2023 14:16<br>
                <b>To:</b> Angelos Bimpoudis
                <a class="moz-txt-link-rfc2396E" href="mailto:angelos.bimpoudis@oracle.com"><angelos.bimpoudis@oracle.com></a><br>
                <b>Cc:</b> amber-spec-experts
                <a class="moz-txt-link-rfc2396E" href="mailto:amber-spec-experts@openjdk.org"><amber-spec-experts@openjdk.org></a><br>
                <b>Subject:</b> [External] : Re: Draft JEP on Primitive
                types in patterns, instanceof, and switch</font>
              <div> </div>
            </div>
            <div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
                  <div class="PlainText">> From: "Angelos Bimpoudis"
                    <a class="moz-txt-link-rfc2396E" href="mailto:angelos.bimpoudis@oracle.com"><angelos.bimpoudis@oracle.com></a><br>
                    > To: "amber-dev" <a class="moz-txt-link-rfc2396E" href="mailto:amber-dev@openjdk.org"><amber-dev@openjdk.org></a><br>
                    > Sent: Thursday, January 26, 2023 10:48:47 AM<br>
                    > Subject: Draft JEP on Primitive types in
                    patterns, instanceof, and switch<br>
                    <br>
                    > Hello all,<br>
                    <br>
                    > I would like to share this draft JEP with you
                    about primitive types in patterns,<br>
                    > instanceof, and switch:<br>
                    <br>
                    > <a href="https://openjdk.org/jeps/8288476" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://openjdk.org/jeps/8288476</a><br>
                    <br>
                    > "Enhance pattern matching by allowing primitive
                    types to appear anywhere in<br>
                    > patterns. Extend instanceof to support
                    primitive types, and extend switch to<br>
                    > allow primitive constants as case labels."<br>
                    <br>
                    > Comments very much welcomed!<br>
                    <br>
                    > Many thanks,<br>
                    > Angelos<br>
                    <br>
                    I still think that the semantics proposed for
                    pattern matching on primitive types is useless
                    complexity with the perverse side effect of
                    normalizing the usage of "default" in pattern
                    matching (too many examples of this JEP are using
                    "default") but we already discussed that. <br>
                    <br>
                    Allowing switching on double and float constants is
                    just wrong. <br>
                    Rust is actually trying to remove that feature <br>
                    [ <a href="https://urldefense.com/v3/__https://github.com/rust-lang/rust/issues/41255__;!!ACWV5N9M2RV99hQ!NfJ7KspB447oMGi0NoEyXC6s_w3vD1N-SBu5hiD4kMVAkmwDWPNbymH83iOnrkakPoayD6vwGwuB5NvedJfjH9LU$" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">
https://urldefense.com/v3/__https://github.com/rust-lang/rust/issues/41255__;!!ACWV5N9M2RV99hQ!NfJ7KspB447oMGi0NoEyXC6s_w3vD1N-SBu5hiD4kMVAkmwDWPNbymH83iOnrkakPoayD6vwGwuB5NvedJfjH9LU$</a> 
                    |
                    <a href="https://urldefense.com/v3/__https://github.com/rust-lang/rust/issues/41255__;!!ACWV5N9M2RV99hQ!NfJ7KspB447oMGi0NoEyXC6s_w3vD1N-SBu5hiD4kMVAkmwDWPNbymH83iOnrkakPoayD6vwGwuB5NvedJfjH9LU$" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">
https://urldefense.com/v3/__https://github.com/rust-lang/rust/issues/41255__;!!ACWV5N9M2RV99hQ!NfJ7KspB447oMGi0NoEyXC6s_w3vD1N-SBu5hiD4kMVAkmwDWPNbymH83iOnrkakPoayD6vwGwuB5NvedJfjH9LU$</a> 
                    ]
                    <br>
                    <br>
                    I see no point to make the same mistake. <br>
                    <br>
                    Otherwise, the rest is fine. <br>
                    <br>
                    Rémi<br>
                  </div>
                </span></font></div>
            <br>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>