Pefekt hashcode

Det skal også være hurtigt, og behøver ikke være perfekt. Da det bare er tal, så er mit forslag at lægge dem sammen med +

There aint no such thing as a 'perfect' hashcode. Perfektion ville være hvis enhver mulig nøgle blev hashed ned til et unikt nummer imellem 0 og antallet af poster. cant be did.

Men vi kan da prøve at gøre numrene nogenlunde unikke, og til det er der 2 primære metoder:
1) foldning
2) xor

hvis fx dine nøgler er tekststrenge, så kan de strenge representeres som en sekvens af bytes som igen i sidste ende er en sekvens af bits. Du fastlægger en længde for dine numre svarede til det dogbbelte af hvor stor du foreventer hashteabellen kan blive, fx hvs der næppe nogensinde kommer mere en 200 poster vil 9 bit være en god lengde (0..511) og så folder du sekvensen af bits i zigsag og xorer dem sammen
eg: streng "abcd" har bitsekvens(ascii) 01100001 01100010 01100011 01100100
den sekvens foldes til
011000010        første 9 bit ventre mod højre
100100011        næste ni højre mod venstre
100011011        og så forlæns igen
____00100        og baglæns. osv.
jeg har skrevet '_' for de manglende fire bit tilsidst, bare fyld ud med nuller.
000000100
og den søjle 9-bit tal xor'es så sammen til et enkelt 9-bit nummer:
011111110

Det plejer at være en nogenlunde effektiv måde at få forskellige numre selvom nøglerne ofte er rimeligt ens. (fx: "mine baby billeder", "min babys billeder", "mine babe billeder", ...)

Ja, der er åbenbart mange forslag. Jeg brugte SUNs eget forslag..

Erik: tjah, to objekter som begge inderholder to tal: obj1 = 1,5 obj2=3,3. Overhovedet ikke ens, men de bliver sammenlignet sådan..

Jakob: Jeg tog godt nok suns forslag, men du må gerne få point, fordi jeg synes din forklaring giver noget mere mening :) Svar?

Ja, de 2 objekter giver samme hashværdi hvis man summerer dem. Det er ikke noget problem, og i øvrigt heller ikke noget du kan gardere dig imod. Faktisk kunne du sætte din hashfunktion til altid at aflevere det samme tal, fx. 7913, og dit program vil stadig køre (måske langsommere, men køre).

Du husker lige at du også skal lave din equals-funktion, ikke?

Jo, jeg ville egentlig kun have lavet min equals, men mit HashSet object ville ikke sortere, hvis ikke jeg havde min hashcode. Hvorfor skal man have begge - Man burde da kunne nøjes med bare equals()

nej

equals og hashCode skal være konsistente for at du kan få konsistent opførsel
ud af din kode

citat fra docs:

    * If two objects are equal according to the equals(Object)  method, then calling the hashCode method on each of the two objects must produce the same integer result.
    * It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.