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
<gil...@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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
