Perché usare un numero primo in hashCode?

Mi chiedevo solo perché i numeri primi sono usati nel hashCode()metodo di una classe ? Ad esempio, quando si utilizza Eclipse per generare il mio hashCode()metodo, viene sempre 31utilizzato il numero primo :

public int hashCode() {
     final int prime = 31;
     //...
}

Riferimenti:

Ecco un buon primer su Hashcode e l'articolo su come funziona l'hashing che ho trovato (C # ma i concetti sono trasferibili): Linee guida e regole di Eric Lippert per GetHashCode ()

Perché vuoi che il numero che stai moltiplicando e il numero di bucket che stai inserendo abbiano fattorizzazioni primarie ortogonali.

Supponiamo che ci siano 8 secchi in cui inserire. Se il numero che stai utilizzando per moltiplicare è un multiplo di 8, il bucket inserito sarà determinato solo dalla voce meno significativa (quella non moltiplicata). Le voci simili si scontreranno. Non va bene per una funzione hash.

31 è un numero primo abbastanza grande che è improbabile che il numero di bucket sia divisibile per esso (e in effetti, le moderne implementazioni Java HashMap mantengono il numero di bucket a una potenza di 2).

I numeri primi sono scelti per distribuire al meglio i dati tra i bucket hash. Se la distribuzione degli input è casuale e uniformemente diffusa, la scelta del codice hash / modulo non ha importanza. Ha un impatto solo quando c'è un certo schema negli input.

Questo è spesso il caso quando si tratta di posizioni di memoria. Ad esempio, tutti gli interi a 32 bit sono allineati agli indirizzi divisibili per 4. Controlla la tabella seguente per visualizzare gli effetti dell'uso di un modulo primo e non primo:

Input       Modulo 8    Modulo 7
0           0           0
4           4           4
8           0           1
12          4           5
16          0           2
20          4           6
24          0           3
28          4           0

Notare la distribuzione quasi perfetta quando si utilizza un modulo primo rispetto a un modulo non primo.

Tuttavia, sebbene l'esempio sopra sia ampiamente inventato, il principio generale è che quando si ha a che fare con uno schema di input , l'uso di un modulo con numeri primi produrrà la migliore distribuzione.

Per quello che vale, Effective Java 2nd Edition rinuncia al problema matematico e dice solo che il motivo per scegliere 31 è:

• Perché è uno strano numero primo, ed è "tradizionale" usare i numeri primi
• È anche uno in meno di una potenza di due, che consente l'ottimizzazione bit a bit

Ecco la citazione completa, dall'articolo 9: Sostituisci sempre hashCodequando esegui l'overrideequals :

Il valore 31 è stato scelto perché è un numero primo dispari. Se fosse pari e la moltiplicazione traboccasse, le informazioni verrebbero perse, poiché la moltiplicazione per 2 equivale allo spostamento. Il vantaggio di usare un numero primo è meno chiaro, ma è tradizionale.

Una bella proprietà di 31 è che la moltiplicazione può essere sostituita da uno spostamento ( §15.19 ) e sottrazione per prestazioni migliori:

 31 * i == (i << 5) - i

Le VM moderne eseguono automaticamente questo tipo di ottimizzazione.

---

Mentre la ricetta in questo articolo offre funzioni hash ragionevolmente buone, non produce funzioni hash all'avanguardia, né le librerie della piattaforma Java forniscono tali funzioni hash dalla versione 1.6. Scrivere tali funzioni di hash è un argomento di ricerca, meglio lasciato ai matematici e agli informatici teorici.

Forse una versione successiva della piattaforma fornirà funzioni hash all'avanguardia per le sue classi e metodi di utilità per consentire ai programmatori medi di costruire tali funzioni hash. Nel frattempo, le tecniche descritte in questo articolo dovrebbero essere adeguate per la maggior parte delle applicazioni.

Piuttosto semplicisticamente, si può dire che l'uso di un moltiplicatore con numerosi divisori comporterà più collisioni di hash . Poiché per un hashing efficace vogliamo ridurre al minimo il numero di collisioni, proviamo a utilizzare un moltiplicatore con meno divisori. Un numero primo per definizione ha esattamente due divisori positivi distinti.

Domande correlate

• HashCode Java da un campo : la ricetta, oltre all'esempio di utilizzo dei costruttori di Apache Commons Lang
• è errato definire un hashcode di un oggetto come somma, moltiplicazione, qualunque sia, di tutti gli hashcode delle variabili di classe?
• Guida per principianti assoluti allo spostamento dei bit?

Ho sentito che 31 è stato scelto in modo che il compilatore possa ottimizzare la moltiplicazione a 5 bit con spostamento a sinistra, quindi sottrarre il valore.

Ecco una citazione un po 'più vicina alla fonte.

Si riduce a:

• 31 è primo, il che riduce le collisioni
• 31 produce una buona distribuzione, con
• un ragionevole compromesso in termini di velocità

Innanzitutto si calcola il valore di hash modulo 2 ^ 32 (la dimensione di un int ), quindi vuoi qualcosa di relativamente primo a 2 ^ 32 (relativamente primo significa che non ci sono divisori comuni). Qualsiasi numero dispari farebbe per quello.

Quindi per una data tabella hash l'indice viene solitamente calcolato dal valore hash modulo della dimensione della tabella hash, quindi si desidera qualcosa che sia relativamente primo rispetto alla dimensione della tabella hash. Spesso le dimensioni delle tabelle hash sono scelte come numeri primi per questo motivo. Nel caso di Java l'implementazione di Sun assicura che la dimensione sia sempre una potenza di due, quindi un numero dispari sarebbe sufficiente anche qui. C'è anche un ulteriore massaggio delle chiavi hash per limitare ulteriormente le collisioni.

L'effetto negativo se la tabella hash e il moltiplicatore avessero un fattore comune npotrebbe essere che in determinate circostanze verrebbero utilizzate solo 1 / n voci nella tabella hash.

Il motivo per cui vengono utilizzati i numeri primi è di ridurre al minimo le collisioni quando i dati mostrano alcuni schemi particolari.

Per prima cosa: se i dati sono casuali, non è necessario un numero primo, puoi eseguire un'operazione mod contro qualsiasi numero e avrai lo stesso numero di collisioni per ogni possibile valore del modulo.

Ma quando i dati non sono casuali, accadono cose strane. Ad esempio, considera i dati numerici che sono sempre multipli di 10.

Se usiamo la mod 4 troviamo:

10 mod 4 = 2

20 mod 4 = 0

30 mod 4 = 2

40 mod 4 = 0

50 mod 4 = 2

Quindi dai 3 possibili valori del modulo (0,1,2,3) solo 0 e 2 avranno collisioni, il che è negativo.

Se utilizziamo un numero primo come 7:

10 mod 7 = 3

20 mod 7 = 6

30 mod 7 = 2

40 mod 7 = 4

50 mod 7 = 1

eccetera

Notiamo anche che 5 non è una buona scelta ma 5 è il primo, il motivo è che tutte le nostre chiavi sono un multiplo di 5. Ciò significa che dobbiamo scegliere un numero primo che non divide le nostre chiavi, scegliendo un numero primo grande è di solito abbastanza.

Quindi, dal punto di vista dell'errore, di essere ripetitivi, il motivo per cui vengono utilizzati i numeri primi è quello di neutralizzare l'effetto dei modelli nei tasti nella distribuzione delle collisioni di una funzione hash.

31 è anche specifico di Java HashMap che utilizza un int come tipo di dati hash. Quindi la capacità massima di 2 ^ 32. Non ha senso usare i numeri primi Fermat o Mersenne più grandi.

In genere consente di ottenere una diffusione più uniforme dei dati tra i bucket hash, in particolare per le chiavi a bassa entropia.