[jira] [Resolved] (NUMBERS-201) FP64 equals is not consistent with hashCode

["Alex Herbert (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NUMBERS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Herbert resolved NUMBERS-201.
----------------------------------
    Fix Version/s: 1.2
       Resolution: Fixed

Added in commit:

9ddacacfe074ec16bff0440d2c04b3428ba7a2f4

 

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