Come evitare il ridimensionamento in cascata durante il ridimensionamento delle tabelle hash?

Con i metodi convenzionali di risoluzione delle collisioni come il concatenamento separato e il sondaggio lineare / quadratico, la sequenza della sonda per una chiave può essere arbitrariamente lunga - viene semplicemente mantenuta breve con un'alta probabilità mantenendo basso il fattore di carico della tabella. Le collisioni durante il rimodellamento non sono quindi un problema in quanto non influiscono sul fattore di carico.

Tuttavia, con l'hash del cuculo (e altri metodi che offrono il tempo di ricerca O (1) nel caso peggiore?), Un ridimensionamento deve avvenire quando la sequenza della sonda per un tasto diventa troppo lunga. Ma quando i tasti vengono rimescolati durante il rehash, è possibile che creino una sequenza sonda troppo lunga per un tasto, richiedendo un altro ridimensionamento, possibilmente diversi, se ciò accade più volte di seguito. La probabilità è piccola, specialmente con una buona funzione hash, ma l'ho visto accadere.

Esiste un modo - a parte quello di generare esplicitamente una funzione hash perfetta durante il rehash - per garantire che i ridimensionamenti non possano essere messi in cascata in questo modo? Forse specifico per un determinato schema di risoluzione delle collisioni? La letteratura che ho incontrato finora sembra sorvolare completamente la questione. Tieni presente che sono anche interessato a ridurre le tabelle hash, non solo a farle crescere.

Chiedi come evitare le ripetizioni a cascata ma hai già dato la risposta nel tuo post. Tieni la probabilità che si verifichino piccoli eventi negativi .

Dal momento che menzioni l'hash del cuculo. La probabilità che tu ottenga una lunga sequenza di sondaggio è$O(1/n^2)$. Quindi, se ripeti, stai inserendo$n$elementi da zero. La probabilità che il rehash non abbia successo è quindi$O(1/n)$, quindi con probabilità molto alta hai successo. In previsione hai bisogno solo di un numero costante di tentativi. Se noti che hai problemi con il rehashing, dovresti aumentare le dimensioni della tabella e modificare il fattore di carico. In alternativa puoi selezionare una famiglia migliore di funzioni hash.

Credo di avere una soluzione, ispirata all'hashing lineare :

Se la (e) funzione (i) di hash viene mantenuta costante (cioè non modificata durante il ridimensionamento) e la tabella viene sempre cresciuta raddoppiando gli slot, allora dopo che la tabella è cresciuta, sostiene che

$H \mod 2L = \begin{cases} H \mod L + L & \text{or} \\ H \mod L \end{cases}$

dove è l'hash di una chiave e è il vecchio numero di slot. Ciò significa che una chiave rimane dove si trova o si sposta in uno slot univoco nell'area appena allocata, che è garantita essere vuota.$H$$L$

Per applicare questo al hash del cuculo (d-ary), è sufficiente ridimensionare ciascuno dei sottotitoli singolarmente e non spostare le chiavi tra i sottotitoli.

Per ridurre la tabella, è necessario confermare che uno di è vacante per ogni chiave nella tabella e, in tal caso, spostali tutti nei rispettivi slot . Ovviamente, questo è ... Non sono sicuro che ci sia un modo migliore per farlo che eseguire il controllo per ogni cancellazione una volta che il fattore di carico scende sotto la metà.$\lbrace H \mod \frac{L}{2} + \frac{L}{2}, ~ H \mod \frac{L}{2} \rbrace$$H \mod \frac{L}{2}$$O(n)$