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