commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: svn commit: r1343616 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/geometry/partitioning/utilities/OrderedTuple.java
Date Tue, 29 May 2012 20:22:58 GMT
My IDE (IntelliJ) provides automatic generation of equals/hashCode.
Can't you use something like that?

On Tue, May 29, 2012 at 4:12 PM, Gilles Sadowski
<gilles@harfang.homelinux.org> wrote:
> Hi.
>
>> [...]
>> >>> --- commons/proper/math/trunk/src/main/java/org/apache/commons/math3/geometry/partitioning/utilities/OrderedTuple.java
(original)
>> >>> +++ commons/proper/math/trunk/src/main/java/org/apache/commons/math3/geometry/partitioning/utilities/OrderedTuple.java
Tue May 29 09:14:37 2012
>> >>> @@ -301,12 +301,12 @@ public class OrderedTuple implements Com
>> >>>     /** {@inheritDoc} */
>> >>>     @Override
>> >>>     public int hashCode() {
>> >>> -        return Arrays.hashCode(components)   ^
>> >>> -               ((Integer) offset).hashCode() ^
>> >>> -               ((Integer) lsb).hashCode()    ^
>> >>> -               ((Boolean) posInf).hashCode() ^
>> >>> -               ((Boolean) negInf).hashCode() ^
>> >>> -               ((Boolean) nan).hashCode();
>> >>> +        return Arrays.hashCode(components)        ^
>> >>> +               Integer.valueOf(offset).hashCode() ^
>> >>> +               Integer.valueOf(lsb).hashCode()    ^
>> >>
>> >> As noted in the JIRA, the conversion to Integer is completely
>> >> unnnecessary; just use the int value.
>> >>
>> >>> +               Boolean.valueOf(posInf).hashCode() ^
>> >>> +               Boolean.valueOf(negInf).hashCode() ^
>> >>> +               Boolean.valueOf(nan).hashCode();
>> >>
>> >> Similarly here.
>> >
>> > So you suggest I use somehting like (using different constants for
>> > different fields just to spread more the has values):
>> >
>> >  Arrays.hashCode(components) ^ offset ^ (lsb << 7) ^
>> >  (posInf ?  43422 : 875342) ^ (negInf ? 86535631 : 632442767) ^
>> >  (nan ? 51108941 : 64234)
>> >
>> > Would this be more consistent with what you have in mind ?
>>
>> Yes.
>>
>> What I suggested was effectively to inline the hashCode() methods for
>> Integer and Boolean, i.e. to eliminate the boxing.
>>
>> That would have resulted in the identical hash code as before.
>>
>> However, as you point out, the original hash code was probably not
>> ideal in that it did not distinguish the fields.
>>
>> I don't know whether XOR is the best choice for combining the fields.
>> LANGs HashBuilder uses multiplication and addition, which is easy to
>> extend to any number of fields.
>
> Yes, IIRC the recommended recipe in Bloch's book was something like:
> ---
>   int result = 17;
>   long l = Double.doubleToLongBits(field1);
>   result = 37 * result + (int)(l ^ (l >>> 32));
>   l = Double.doubleToLongBits(field2);
>   result = 37 * result + (int)(l ^ (l >>> 32));
>   return result;
> ---
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message