JDK-8257086: Clarify differences between {Float, Double}.equals and == by jddarcy · Pull Request #1699 · openjdk/jdk

jddarcy · 2020-12-08T16:29:49Z

Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values.

Once the wording is worked out, I'll replicate it for the analogous methods on Float.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8257086: Clarify differences between {Float, Double}.equals and ==

Reviewers

Stuart Marks (@stuart-marks - Reviewer) ⚠️ Review applies to b419ca7
bpb - Reviewer ⚠️ Added manually

Download

$ git fetch https://git.openjdk.java.net/jdk pull/1699/head:pull/1699
$ git checkout pull/1699

bridgekeeper · 2020-12-08T16:32:35Z

👋 Welcome back darcy! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2020-12-08T16:33:33Z

@jddarcy The following label will be automatically applied to this pull request:

core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2020-12-08T16:44:24Z

Webrevs

bplb · 2020-12-08T17:10:27Z

src/java.base/share/classes/java/lang/Double.java

     *
     * <p>also has the value {@code true}. However, there are two
-     * exceptions:
+     * exceptions where the properties of an equivalence relations are


type: relations -> relation.

bplb · 2020-12-08T17:10:33Z

src/java.base/share/classes/java/lang/Double.java

+
+     * This method imposes a total order on {@code Double} objects
+     * with two differences compared to the incomplete order defined the
+     * by Java language numerical comparison operators ({@code <, <=,


Typo: defined the by Java -> defined by the Java.

Will fix; thanks.

stuart-marks · 2020-12-08T17:59:41Z

I'll note initially that the original bug is about equals and == whereas this change also covers compareTo and additional comparison operators < and >. I believe covering this additional material IS important, as these concepts are all closely related.

While this material is covering the right ground, I'd say that it's too verbose for a method specification. It feels like it's being compressed to fit into a method specification and thus doesn't do the topic justice.

(One additional concept that ought to be covered is that compareTo is consistent with equals. This should be asserted in the method specification, but trying to explain it in a method specification seems difficult.)

I'll suggest a couple alternatives. One is to put a full, combined explanation into class doc somewhere, say in Double. The various methods can then make some terse assertions and then refer to the combined explanation. Float could refer to Double instead of replicating the text.

Another alternative is to put this explanation into the java.lang package specification. This might be a good fit, since there is already some explanation there of the boxed primitives.

jddarcy · 2020-12-08T22:12:29Z

I'll note initially that the original bug is about equals and == whereas this change also covers compareTo and additional comparison operators < and >. I believe covering this additional material IS important, as these concepts are all closely related.

While this material is covering the right ground, I'd say that it's too verbose for a method specification. It feels like it's being compressed to fit into a method specification and thus doesn't do the topic justice.

(One additional concept that ought to be covered is that compareTo is consistent with equals. This should be asserted in the method specification, but trying to explain it in a method specification seems difficult.)

I'll suggest a couple alternatives. One is to put a full, combined explanation into class doc somewhere, say in Double. The various methods can then make some terse assertions and then refer to the combined explanation. Float could refer to Double instead of replicating the text.

Another alternative is to put this explanation into the java.lang package specification. This might be a good fit, since there is already some explanation there of the boxed primitives.

I added discussion of compareTo as well as equals to the scope of the bug since they are sibling surprising deviations from what is expected and have the same root cause. (I took care to say "incomplete order" rather than "partial order" since a partial order requires reflexivity.)

The interface java.lang.Comparable gives a definition of "consistent with equals." I didn't verify it doesn't have an anchor to link to, but we don't typically link to the definition. However, I wouldn't be adverse to having "consistent with equals" link to Comparable; that would be more obvious than expecting the reader to follow the "Specified by: compareTo in interface Comparable" link javadoc generates for the method.

I think the Float and Double equals and compareTo methods should at least get pointers to any new section added -- I think a standalone section in the package javadoc by itself would have low discoverability.

I'm make another iteration over the text; thanks.

stuart-marks · 2020-12-10T01:32:24Z

Great, let me know if you'd like me to provide some text for any particular topics in this area.

bridgekeeper · 2021-01-07T01:34:18Z

@jddarcy This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

jddarcy · 2021-01-28T07:15:05Z

Great, let me know if you'd like me to provide some text for any particular topics in this area.

Before sending out another iteration in code, there the draft javadoc text of a discussion at the end of the class-level discussion of java.lang.Double:

Floating-point Equality, Equivalence,
and Comparison
IEEE 754 floating-point values include finite nonzero values,
signed zeros ({@code +0.0} and {@code -0.0}), signed infinities
{@linkplain Double#POSITIVE_INFINITY positive infinity} and
{@linkplain Double#NEGATIVE_INFINITY negative infinity}), and
{@linkplain Double#NaN NaN} (not-a-number).
An equivalence relation on a set of values is a boolean
relation on pairs of values that is reflexive, symmetric, and
transitive. A set can have multiple equivalence relations defined
for it. For example, {@link java.util.HashMap HashMap} compares
keys in the set of objects using the equivalence relation of {@link
Object#equals Object.equals} while {@link java.util.IdentityHashMap
IdentityHashMap} compares keys in the set of objects using the
equivalence relation of reference equality.
For floating-point values to be used in data structures like
sets and maps, the {@linkplain Double#equals equals} or {@linkplain
Double#compareTo comparison} method must satisfy the usual
requirements of being an equivalence relation or analogous
requirement for comparison methods. However, surprisingly, the
built-in {@code ==} operation on floating-point values does
not implement an equivalence relation. Despite not
defining an equivalence relation, the semantics of the IEEE 754
{@code ==} operator were deliberately designed to meet other needs
of numerical computation. There are two exceptions where the
properties of an equivalence relations are not satisfied by {@code
==} on floating-point values:
- If {@code v1} and {@code v2} are both NaN, then {@code v1
- == v2} has the value {@code false}. Therefore, for two NaN
- arguments the reflexive property of an equivalence
- relation is not satisfied by the {@code ==} operator.
- If {@code v1} represents {@code +0.0} while {@code v2}
- represents {@code -0.0}, or vice versa, then {@code v1 == v2} has
- the value {@code true} even though {@code +0.0} and {@code -0.0}
- are distinguishable under various floating-point operations. For
- example, {@code 1.0/+0.0} evaluates to positive infinity while
- {@code 1.0/-0.0} evaluates to negative infinity and
- positive infinity and negative infinity are neither equal to each
- other nor equivalent to each other.
For ordered comparisons using the built-in comparison operator
({@code <}, {@code <=}, etc.), NaN values have another anomalous
situation: a NaN is neither less than, greater than, nor equal to
any value, including itself. This means the trichotomy of

comparison does not hold.
To provide the appropriate semantics for {@code equals} and {@code
compareTo} methods, those methods cannot simply to wrappers around
{@code ==} or ordered comparison operations. Instead, {@link
Double#equals equals} defines NaN arguments to be equal to each
other and defines {@code +0.0} to not be equal to {@code
-0.0}, restoring reflexivity. For comparisons, {@link
Double#compareTo compareTo} defines a total order where {@code
-0.0} is less than {@code +0.0} and where a NaN is equal to itself
and considered greater than positive infinity.
The operational semantics of {@code equals} and {@code
compareTo} are expressed in terms of {@linkplain doubleToLongBigs
bit-wise converting} the floating-point values to integral values
The natural ordering implemented by {@link compareTo
compareTo} is {@linkplain Comparable consistent with equals}; that
is values are only reported as equal by {@code equals} if {@code
compareTo} on those objects returns zero.
@jls 4.2.3 Floating-Point Types, Formats, and Values
@jls 4.2.4. Floating-Point Operations
@jls 15.21.1 Numerical Equality Operators == and !=

Comments?

Thanks,

mlbridge · 2021-01-28T19:23:44Z

Mailing list message from Bernd Eckenfels on core-libs-dev:

I like the text it?s good to mix object and value identities. I would only miss unequal behavior of NaN in the description.

Gruss
Bernd

--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Joe Darcy <darcy at openjdk.java.net>
Gesendet: Thursday, January 28, 2021 8:17:39 AM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Betreff: Re: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and ==

On Thu, 10 Dec 2020 01:32:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

Great, let me know if you'd like me to provide some text for any particular topics in this area.

Before sending out another iteration in code, there the draft javadoc text of a discussion at the end of the class-level discussion of java.lang.Double:

* <h2><a id=equivalenceRelation>Floating-point Equality, Equivalence,
* and Comparison</a></h2>
*
* IEEE 754 floating-point values include finite nonzero values,
* signed zeros ({@code +0.0} and {@code -0.0}), signed infinities
* {@linkplain Double#POSITIVE_INFINITY positive infinity} and
* {@linkplain Double#NEGATIVE_INFINITY negative infinity}), and
* {@linkplain Double#NaN NaN} (not-a-number).
*
* An equivalence relation on a set of values is a boolean
* relation on pairs of values that is reflexive, symmetric, and
* transitive. A set can have multiple equivalence relations defined
* for it. For example, {@link java.util.HashMap HashMap} compares
* keys in the set of objects using the equivalence relation of {@link
* Object#equals Object.equals} while {@link java.util.IdentityHashMap
* IdentityHashMap} compares keys in the set of objects using the
* equivalence relation of reference equality.
*
* For floating-point values to be used in data structures like
* sets and maps, the {@linkplain Double#equals equals} or {@linkplain
* Double#compareTo comparison} method must satisfy the usual
* requirements of being an equivalence relation or analogous
* requirement for comparison methods. However, surprisingly, the
* built-in {@code ==} operation on floating-point values does
* not implement an equivalence relation. Despite not
* defining an equivalence relation, the semantics of the IEEE 754
* {@code ==} operator were deliberately designed to meet other needs
* of numerical computation. There are two exceptions where the
* properties of an equivalence relations are not satisfied by {@code
* ==} on floating-point values:
*
* <ul>
*
* <li>If {@code v1} and {@code v2} are both NaN, then {@code v1
* == v2} has the value {@code false}. Therefore, for two NaN
* arguments the reflexive property of an equivalence
* relation is not satisfied by the {@code ==} operator.
*
* <li>If {@code v1} represents {@code +0.0} while {@code v2}
* represents {@code -0.0}, or vice versa, then {@code v1 == v2} has
* the value {@code true} even though {@code +0.0} and {@code -0.0}
* are distinguishable under various floating-point operations. For
* example, {@code 1.0/+0.0} evaluates to positive infinity while
* {@code 1.0/-0.0} evaluates to negative infinity and
* positive infinity and negative infinity are neither equal to each
* other nor equivalent to each other.
*
* </ul>
*
* For ordered comparisons using the built-in comparison operator
* ({@code <}, {@code <=}, etc.), NaN values have another anomalous
* situation: a NaN is neither less than, greater than, nor equal to
* any value, including itself. This means the trichotomy of
* comparison does not hold.
*
* To provide the appropriate semantics for {@code equals} and {@code
* compareTo} methods, those methods cannot simply to wrappers around
* {@code ==} or ordered comparison operations. Instead, {@link
* Double#equals equals} defines NaN arguments to be equal to each
* other and defines {@code +0.0} to not be equal to {@code
* -0.0}, restoring reflexivity. For comparisons, {@link
* Double#compareTo compareTo} defines a total order where {@code
* -0.0} is less than {@code +0.0} and where a NaN is equal to itself
* and considered greater than positive infinity.
*
* The operational semantics of {@code equals} and {@code
* compareTo} are expressed in terms of {@linkplain doubleToLongBigs
* bit-wise converting} the floating-point values to integral values
*
* The natural ordering implemented by {@link compareTo
* compareTo} is {@linkplain Comparable consistent with equals}; that
* is values are only reported as equal by {@code equals} if {@code
* compareTo} on those objects returns zero.
*
* @jls 4.2.3 Floating-Point Types, Formats, and Values
* @jls 4.2.4. Floating-Point Operations
* @jls 15.21.1 Numerical Equality Operators == and !=

Comments?

Thanks,

-------------

PR: https://git.openjdk.java.net/jdk/pull/1699

stuart-marks · 2021-01-29T03:15:52Z

I took the liberty of making an editing pass over the proposed text. Along with a few editorial and markup adjustments, the key changes are as follows:

I moved discussion of interaction with Set and Map to the end, after all the issues have been set up.
I added the concept of substitution alongside the equivalence relation. AFAIK substitution (or substitutability) is not part of an equivalence relation, but it seems that in many systems, equivalence implies substitutability. Of course, the point is that it doesn't apply for -0.0 and +0.0.

We'll see how well this survives github markup. If it doesn't work out, I can email the text file. (Triple backquotes seem to do the trick.)

 * <h2><a id=equivalenceRelation>Floating-point Equality, Equivalence,
 * and Comparison</a></h2>
 *
 * IEEE 754 floating-point values include finite nonzero values,
 * signed zeros ({@code +0.0} and {@code -0.0}), signed infinities
 * {@linkplain Double#POSITIVE_INFINITY positive infinity} and
 * {@linkplain Double#NEGATIVE_INFINITY negative infinity}), and
 * {@linkplain Double#NaN NaN} (not-a-number).
 *
 * <p>An <em>equivalence relation</em> on a set of values is a boolean
 * relation on pairs of values that is reflexive, symmetric, and
 * transitive. For more discussion of equivalence relations, see
 * the {@link Object#equals Object.equals} specification. Additionally,
 * In a numeric expression, values that are equivalent can generally
 * be <em>substituted</em> for one another without changing the value
 * of the expression, though there are exceptions.
 * 
 * <p>Notably, the
 * built-in {@code ==} operation on floating-point values does
 * <em>not</em> implement an equivalence relation. Despite not
 * defining an equivalence relation, the semantics of the IEEE 754
 * {@code ==} operator were deliberately designed to meet other needs
 * of numerical computation. There are two exceptions where the
 * properties of an equivalence relations are not satisfied by {@code
 * ==} on floating-point values:
 *
 * <ul>
 *
 * <li>If {@code v1} and {@code v2} are both NaN, then {@code v1
 * == v2} has the value {@code false}. Therefore, for two NaN
 * arguments the <em>reflexive</em> property of an equivalence
 * relation is <em>not</em> satisfied by the {@code ==} operator.
 *
 * <li>If {@code v1} represents {@code +0.0} while {@code v2}
 * represents {@code -0.0}, or vice versa, then {@code v1 == v2} has
 * the value {@code true} even though {@code +0.0} and {@code -0.0}
 * are distinguishable under various floating-point operations. For
 * example, {@code 1.0/+0.0} evaluates to positive infinity while
 * {@code 1.0/-0.0} evaluates to <em>negative</em> infinity and
 * positive infinity and negative infinity are neither equal to each
 * other nor equivalent to each other. Thus, {@code +0.0} and {@code
 * -0.0} may not be substituted for each other in general.
 *
 * </ul>
 *
 * <p>For ordered comparisons using the built-in comparison operators
 * ({@code <}, {@code <=}, etc.), NaN values have another anomalous
 * situation: a NaN is neither less than, greater than, nor equal to
 * any value, including itself. This means the <em>trichotomy of
 * comparison</em> does <em>not</em> hold.
 * 
 * <p>To provide the appropriate semantics for {@code equals} and {@code
 * compareTo} methods, those methods cannot simply to wrappers around
 * {@code ==} or ordered comparison operations. Instead, {@link
 * Double#equals equals} defines NaN arguments to be equal to each
 * other and defines {@code +0.0} to <em>not</em> be equal to {@code
 * -0.0}, restoring reflexivity. For comparisons, {@link
 * Double#compareTo compareTo} defines a total order where {@code
 * -0.0} is less than {@code +0.0} and where a NaN is equal to itself
 * and considered greater than positive infinity.
 *
 * <p>The operational semantics of {@code equals} and {@code
 * compareTo} are expressed in terms of {@linkplain #doubleToLongBits
 * bit-wise converting} the floating-point values to integral values.
 *
 * <p>The <em>natural ordering</em> implemented by {@link #compareTo
 * compareTo} is {@linkplain Comparable consistent with equals}. That
 * is, its values are reported as equal by {@code equals} if and only
 * if {@code compareTo} on those objects returns zero.
 * 
 * <p>The adjusted behaviors defined for {@code equals} and {@code
 * compareTo} allow instances of wrapper classes to work properly with
 * conventional data structures. For example, defining NaN
 * values to be {@code equals} to one another allows NaN to be used as
 * an element of a {@link java.util.HashSet HashSet} or as the key of
 * a {@link java.util.HashMap HashMap}. Similarly, defining {@code
 * compareTo} as a total ordering, including {@code +0.0}, {@code
 * -0.0}, and NaN, allows instances of wrapper classes to be used as
 * elements of a {@link java.util.SortedSet SortedSet} or as keys of a
 * {@link java.util.SortedMap SortedMap}.
 *
 * @jls 4.2.3 Floating-Point Types, Formats, and Values
 * @jls 4.2.4. Floating-Point Operations
 * @jls 15.21.1 Numerical Equality Operators == and !=

mlbridge · 2021-01-29T03:45:43Z

Mailing list message from Joe Darcy on core-libs-dev:

Hi Stuart,

On 1/28/2021 7:19 PM, Stuart Marks wrote:

On Thu, 28 Jan 2021 07:15:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

Great, let me know if you'd like me to provide some text for any particular topics in this area.

Great, let me know if you'd like me to provide some text for any particular topics in this area.
Before sending out another iteration in code, there the draft javadoc text of a discussion at the end of the class-level discussion of java.lang.Double:

[snip]

Comments?

Thanks,
I took the liberty of making an editing pass over the proposed text. Along with a few editorial and markup adjustments, the key changes are as follows:

1) I moved discussion of interaction with Set and Map to the end, after all the issues have been set up.

2) I added the concept of substitution alongside the equivalence relation. AFAIK substitution (or substitutability) is not part of an equivalence relation, but it seems that in many systems, equivalence implies substitutability. Of course, the point is that it _doesn't_ apply for -0.0 and +0.0.

Yes; substitutability was an implicit concept in the earlier write-up;
it is an improvement to call it out my name.

I'll work on integrating this version into an update of the PR with
references from the equals and compareTo methods, etc.

Thanks,

-Joe

stuart-marks

Overall good! Just some whitespace errors and a couple typos as noted.

stuart-marks · 2021-01-29T18:53:07Z

src/java.base/share/classes/java/lang/Double.java

+ * comparison</i> does <em>not</em> hold.
+ * 
+ * <p>To provide the appropriate semantics for {@code equals} and {@code
+ * compareTo} methods, those methods cannot simply to wrappers around


I think this should be "cannot simply be wrappers".

openjdk · 2021-01-30T00:12:48Z

@jddarcy This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8257086: Clarify differences between {Float, Double}.equals and ==

Reviewed-by: smarks, bpb

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 16 new commits pushed to the master branch:

54e7a64: 8260576: Typo in compiler/runtime/safepoints/TestRegisterRestoring.java
a6d9505: 8260864: ProblemList two security/krb5 tests on Linux
9880c4c: 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java
55d62a5: 8213226: [TESTBUG] Reduce the usage of CDSTestUtils.executeAndLog()
b6a7367: 8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS
50f9a70: 8217327: G1 Post-Cleanup region liveness printing should not print out-of-date efficiency
e963ebd: 8260004: Shenandoah: Rename ShenandoahMarkCompact to ShenandoahFullGC
df33595: 8260309: Shenandoah: Clean up ShenandoahBarrierSet
181d63f: 8260522: Clean up warnings in hotspot JTReg runtime tests
02d586e: 8259398: Super word not applied to a loop with byteArrayViewVarHandle
... and 6 more: https://git.openjdk.java.net/jdk/compare/8a9004da9b30c2ea3c616a0ef29be66f546faa78...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

stuart-marks

I did another full reread. Everything looks good!

jddarcy · 2021-02-02T02:27:42Z

/reviewer credit bpb

openjdk · 2021-02-02T02:28:10Z

@jddarcy
Reviewer bpb successfully credited.

jddarcy · 2021-02-02T02:33:28Z

/integrate

openjdk · 2021-02-02T02:34:16Z

@jddarcy Since your change was applied there have been 16 commits pushed to the master branch:

54e7a64: 8260576: Typo in compiler/runtime/safepoints/TestRegisterRestoring.java
a6d9505: 8260864: ProblemList two security/krb5 tests on Linux
9880c4c: 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java
55d62a5: 8213226: [TESTBUG] Reduce the usage of CDSTestUtils.executeAndLog()
b6a7367: 8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS
50f9a70: 8217327: G1 Post-Cleanup region liveness printing should not print out-of-date efficiency
e963ebd: 8260004: Shenandoah: Rename ShenandoahMarkCompact to ShenandoahFullGC
df33595: 8260309: Shenandoah: Clean up ShenandoahBarrierSet
181d63f: 8260522: Clean up warnings in hotspot JTReg runtime tests
02d586e: 8259398: Super word not applied to a loop with byteArrayViewVarHandle
... and 6 more: https://git.openjdk.java.net/jdk/compare/8a9004da9b30c2ea3c616a0ef29be66f546faa78...master

Your commit was automatically rebased without conflicts.

Pushed as commit 474dba2.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Initial work for JDK-8257086.

8193683

openjdk bot added the core-libs core-libs-dev@openjdk.org label Dec 8, 2020

Fix whitespace

15ce6ad

openjdk bot added the rfr Pull request is ready for review label Dec 8, 2020

bplb reviewed Dec 8, 2020

View reviewed changes

jddarcy added 2 commits January 13, 2021 11:46

Merge branch 'master' into JDK-8257086

308b387

Merge branch 'master' into JDK-8257086

b184333

jddarcy added 2 commits January 29, 2021 09:24

Update reworked wording from @smarks.

9b0f4f5

Merge branch 'master' into JDK-8257086

9d80e27

openjdk bot removed the rfr Pull request is ready for review label Jan 29, 2021

stuart-marks approved these changes Jan 29, 2021

View reviewed changes

Editing pass on changes in Double; add accommodations in Float.

072c40d

openjdk bot added ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 30, 2021

jddarcy added 2 commits January 29, 2021 17:53

Fix typos noticed by @bplb.

b419ca7

Merge branch 'master' into JDK-8257086

235f50b

stuart-marks approved these changes Feb 2, 2021

View reviewed changes

Fix type in URL in Float.java.

7c977bd

openjdk bot closed this Feb 2, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Feb 2, 2021

jddarcy deleted the JDK-8257086 branch February 9, 2021 20:08

Conversation

jddarcy commented Dec 8, 2020 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Download

Uh oh!

bridgekeeper bot commented Dec 8, 2020

Uh oh!

openjdk bot commented Dec 8, 2020

Uh oh!

mlbridge bot commented Dec 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

bplb Dec 8, 2020

Choose a reason for hiding this comment

Uh oh!

bplb Dec 8, 2020

Choose a reason for hiding this comment

Uh oh!

jddarcy Jan 30, 2021

Choose a reason for hiding this comment

Uh oh!

stuart-marks commented Dec 8, 2020

Uh oh!

jddarcy commented Dec 8, 2020

Uh oh!

stuart-marks commented Dec 10, 2020

Uh oh!

bridgekeeper bot commented Jan 7, 2021

Uh oh!

jddarcy commented Jan 28, 2021

Floating-point Equality, Equivalence,

Uh oh!

mlbridge bot commented Jan 28, 2021

Uh oh!

stuart-marks commented Jan 29, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Jan 29, 2021

Uh oh!

stuart-marks left a comment

Choose a reason for hiding this comment

Uh oh!

stuart-marks Jan 29, 2021

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Jan 30, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stuart-marks left a comment

Choose a reason for hiding this comment

Uh oh!

jddarcy commented Feb 2, 2021

Uh oh!

openjdk bot commented Feb 2, 2021

Uh oh!

jddarcy commented Feb 2, 2021

Uh oh!

openjdk bot commented Feb 2, 2021

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

jddarcy commented Dec 8, 2020 •

edited by openjdk bot

Loading

mlbridge bot commented Dec 8, 2020 •

edited

Loading

stuart-marks commented Jan 29, 2021 •

edited

Loading

openjdk bot commented Jan 30, 2021 •

edited

Loading