In Java, I have a class that represents a point with int coordinates
public class Point { int x = -1; int y = -1; public Point (int xNew, int yNew) { x = xNew; y = yNew; } public boolean equals (Object o) { // no need for (o instanceof Point) by design return x == ((Point)o).x && y == ((Point)o).y; } }
I'm using objects of class Point
as keys in a HashMap
and as elements in a HashSet
.
What would be the best candidate for the hashCode
function? I would make it double so that the left part is x and the right part is y, for example: x = 4, y = 12
, then the hashCode
returns 4.12
. But by the implementation, it cannot be double, only int.
This is not an option:
public int hashCode() { // no need to check for exception parseInt since x and y are valid by design return Integer.parseInt(Integer.toString(x) + Integer.toString(y)); }
because values x
and y
can be too long, so that together they will not be converted.
1) If two objects are equal (i.e. the equals() method returns true), they must have the same hashcode. 2) If the hashCode() method is called multiple times on the same object, it must return the same result every time. 3) Two different objects can have the same hash code.
If two objects have the same hashcode then they are NOT necessarily equal. Otherwise you will have discovered the perfect hash function. But the opposite is true: if the objects are equal, then they must have the same hashcode .
hashCode in Java is a function that returns the hashcode value of an object on calling. It returns an integer or a 4 bytes value which is generated by the hashing algorithm. The process of assigning a unique value to an object or attribute using an algorithm, which enables quicker access, is known as hashing.
hashcode() is computed via jvm argument -XX:hashCode=N where N can be a number from [0-5]... Depending on an application you may see unexpected performance hits when .
You can't change the type of hashCode
, nor should you want to.
I'd just go with something like:
public int hashCode() { return x * 31 + y; }
Note that this means that (a, b) is different to (b, a) for most cases (unlike e.g. adding or XOR-ing). This can be useful if you often end up with keys for the "switched" values in real life.
It isn't unique - but hash codes don't have to be. They just have to be the same for equal values (for correctness), and (for efficiency) "usually" different for non-equal values, with a reasonable distribution.
In general, I usually follow the same kind of pattern as Josh Bloch suggests in Effective Java:
public int hashCode() { int hash = 17; hash = hash * 31 + field1Hash; hash = hash * 31 + field2Hash; hash = hash * 31 + field3Hash; hash = hash * 31 + field4Hash; ... return hash; }
Where field1Hash
would be the hash code for reference type fields (or 0 for a null reference), the int
itself for int values, some sort of hash from 64 bits to 32 for long
etc.
EDIT: I can't remember the details of why 31 and 17 work well together. The fact that they're both prime may be useful - but from what I remember, the maths behind why hashes like this are generally reasonable (though not as good as hashes where the distribution of likely values is known in advance) is either difficult or not well understood. I know that multiplying by 31 is cheap (shift left 5 and subtract the original value)...
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With