0

In other words, is the integer returned by hashCode() already an index to an entry of a hash table or does it have to go one step further by compressing itself to an index (by mod the table length maybe)?

OneFlowerOneWorld
  • 67
  • 2
  • 7
  • 1
    No. Hashtables almost always have much fewer buckets than 2^32. The JDK source code comes with the JDK. Why don't you read the source code (or even just the documentation)? – JB Nizet Jun 25 '18 at 21:16
  • 2
    Considering you can put the same object into two (or more) hash tables of differing sizes (or zero hash tables), which table's index do you think the `hashCode` method would return? – Andy Turner Jun 25 '18 at 21:19

1 Answers1

2

No, hashcodes are computed regardless of the targeted hashtable. The hash code of an integer for instance is the integer itself so a hash table would typically need to do a mod hash again to fit it in the table.

Sleiman Jneidi
  • 22,907
  • 14
  • 56
  • 77
  • Then it seems that `hashCode` method can't guarantee collision-free because two hashcodes from two distinct objects may be compressed to the same table index (e.g. hashcode1 = 7, hashcode2 = 14, tableLength = 7, so idx1 = idx2 = 0). If so, what is the point of hashcodes? – OneFlowerOneWorld Jun 25 '18 at 21:26
  • 3
    To make collisions _improbable,_ or at least as improbable as possible. Every hash table implementation has to deal with collisions, you just try to reduce them. – Louis Wasserman Jun 25 '18 at 21:28
  • 1
    @OneFlowerOneWorld moreover, you seem to think that hashCodes are unique. That's not the case. Many objects have the same hashCode. – JB Nizet Jun 25 '18 at 21:33
  • @OneFlowerOneWorld there are 2^64 distinct `Long` values, but only 2^32 possible hash codes. There's simply got to be collision. – Andy Turner Jun 25 '18 at 21:42
  • @JBNizet I think I got more confused here. Then what is `hashCode()` for and how do I make the objects of my own class able to be used as `HashMap` keys? – OneFlowerOneWorld Jun 25 '18 at 21:43
  • You implement hashCode() and equals() as documented, and make your class immutable. Again, hashCode is used to reduce the number of elements to compare when doing a lookup. Imagine you have 500 keys, stored in 100 different buckets (which is a pretty bad hash distribution). That makes 5 keys per bucket. So to know if a key K exists in the hash table, you only have to compare it with 5 other keys (the 5 keys in the bucket selected by the hashCode of K). That's 100 times more efficient than comparing it with 500 other keys. – JB Nizet Jun 25 '18 at 21:50
  • With a decent hash distribution, you typically have 0 or 1 key per bucket, making the lookup very very fast. To get back with the unicity of hashCodes: it's a simple logical problem: there are only 2^32 possible hashCodes. Just take Longs: there are 2^64 of them. So obviously, many of them share the same hashCode. But you usuelly store only a few Long instances in a Map, and the probability to have a collision is thus much smaller. – JB Nizet Jun 25 '18 at 21:51
  • @JBNizet So different hashcodes don't necessarily lead to different buckets but the same hashcodes are bound to access the same bucket and thus we should make hashcodes for different objects (different by the `equals` method) different to reduce the chance of collisions (although no-collision is not guaranteed)? And an `Integer` instance whose value is 65536 doesn't necessarily reside in the 65536th bucket (it depends on the table's length)? – OneFlowerOneWorld Jun 25 '18 at 22:23