<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>FYI, for some additional context, a discussion was added to
      java.lang.Double a few release ago on the different kinds of
      equivalence-like relationships that are useful to define over
      floating-point values: numerical equality, bit-wise equivalence,
      and representation equivalence.</p>
    <p>   
<a class="moz-txt-link-freetext" href="https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Double.html#equivalenceRelation">https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Double.html#equivalenceRelation</a><br>
    </p>
    <p>HTH,</p>
    <p>-Joe<br>
    </p>
    <div class="moz-cite-prefix">On 3/12/2024 12:29 PM, Brian Goetz
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:a9bfd3be-7259-4124-b320-2a7a8169a89f@oracle.com">
      
      <font size="4" face="monospace">Without diving into operator
        overloading, I think you have this bit backwards:</font><br>
      <br>
      <div class="moz-cite-prefix">On 3/11/2024 6:38 PM, Stephen
        Colebourne wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:CACzrW9Az22f-sGbLRdkEON3JccYV2TY74T-VNAVNHRx=43YFHg@mail.gmail.com">
        <pre class="moz-quote-pre" wrap="">== *will* be widely used as the equals operator
irrespective of the authors' wishes. Just as it is for Enum and Class
objects. This will inevitably lead to bug reports where == on two
different NaN returns false.
</pre>
      </blockquote>
      <br>
      But, this is not the case; there is no case where float== says any
      NaNs are equal to any other, even themselves.  Float== treats
      _all_ NaNs as unequal, even the same NaN bit pattern, even the
      same variable (f == f).  <br>
      <br>
      The anomaly created by the proposed Object== semantics is that a
      value type with a float field may treat the two as Object==, when
      the component fields are not float==, because float== uses neither
      bitwise nor representational equivalence, regardless of NaN bit
      patterns.  But we will see such anomalies whether we pick
      representational or bitwise comparison for values, because float==
      is already weird.<br>
      <br>
    </blockquote>
  </body>
</html>