[
https://issues.apache.org/jira/browse/NUMBERS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770483#comment-17770483
]
Alex Herbert commented on NUMBERS-201:
--------------------------------------
Updated to allow numerical equality between zeros in commit:
416876836497bb5bf18a75c3df510f1c4d609673
> FP64 equals is not consistent with hashCode
> -------------------------------------------
>
> Key: NUMBERS-201
> URL: https://issues.apache.org/jira/browse/NUMBERS-201
> Project: Commons Numbers
> Issue Type: Bug
> Components: field
> Affects Versions: 1.1
> Reporter: Alex Herbert
> Priority: Trivial
> Fix For: 1.2
>
>
> The FP64 class wraps a {{double}} so that it can be used as a field. The
> implementation of {{equals}} uses Precision with an allowed difference of up
> to 2 ULP:
> {code:java}
> public boolean equals(Object other) {
> if (other instanceof FP64) {
> final FP64 o = (FP64) other;
> return Precision.equals(value, o.value, 1);
> }
> return false;
> }{code}
> The hashCode is generated using Double.hashCode(value).
> The result is that two objects that are equal can generate a different hash
> code. This breaks the contract of Object.equals where two objects that are
> equal have the same hash code.
> Possible fixes:
> # Use the equivalent of (({{{}Double)value).equals(o.value){}}} for a binary
> equality check between values that is consistent with double.
> # Document the class as having an equals method that is not consistent with
> hash code.
> I do not understand the requirement for using Precision. If a user has their
> own tolerance for field equivalence then this should be left to them to set
> the threshold. So I would recommend option 1.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
