È possibile velocizzare una tabella hash utilizzando alberi di ricerca binari per il concatenamento separato?

Voglio implementare una tabella hash utilizzando alberi di ricerca binaria per ridurre la complessità della ricerca nel processo di concatenamento separato da O (n) (utilizzando l'elenco collegato) a O (registro n) (utilizzando BST). Questo può essere fatto, e se sì, allora come? Sarebbe più facile capire se la soluzione è graduale, l'implementazione della logica.

Voglio ridurre il tempo di ricerca nella tabella hash (compilare usando il concatenamento separato), ma allo stesso tempo non voglio aumentare il tempo di inserimento. Per il mio progetto non posso modificare la funzione hash per ridurre le collisioni. Ma a causa della scalabilità, si verificano collisioni. Sto cercando di trovare un modo per aggirare, in modo da poter in qualche modo lavorare con il miglior accesso e inserire il tempo nel caso in cui si verifichi una collisione ... cioè per gestire lo stato attuale delle cose piuttosto che ristrutturare l'intero algoritmo. Se non esegue il pan out, sarà necessario ristrutturare. Quindi qualche idea?

Quello che stai chiedendo è possibile dati i tuoi vincoli.

Analisi

Il punto di forza di una tabella hash è la sua velocità di ricerca e inserimento rapida. Per ottenere quella velocità, si deve rinunciare a qualsiasi parvenza di ordine nella tabella: cioè le voci sono tutte confuse. Un elenco è accettabile da utilizzare come voce di tabella poiché, sebbene l'attraversamento sia O (n), gli elenchi tendono ad essere brevi supponendo che la tabella hash sia sufficientemente grande e che gli oggetti memorizzati nella tabella siano sottoposti a hash utilizzando un algoritmo di hash di buona qualità.

Un albero di ricerca binario (BST) ha un rapido inserimento e ricerca in O (log ₂ n). Impone inoltre una restrizione agli elementi che memorizza: deve esserci un modo per ordinare gli elementi. Dati due elementi A e B memorizzati nell'albero, deve essere possibile determinare se A precede B o se hanno un ordine equivalente.

Una tabella hash non impone tale restrizione: gli elementi in una tabella hash devono avere due proprietà. Innanzitutto, ci deve essere un modo per determinare se sono equivalenti; secondo, ci deve essere un modo per calcolare un codice hash deterministico. L'ordine non è un requisito.

Se gli elementi della tabella hash hanno un ordine, è possibile utilizzare un BST come voce della tabella hash per contenere oggetti con lo stesso codice hash (collisioni). Tuttavia, a causa di un BST con ricerca e inserimento O (log ₂ n), ciò significa che il caso peggiore per l'intera struttura (tabella hash più BST) è tecnicamente migliore dell'uso di un elenco come voce di tabella. A seconda dell'implementazione di BST richiederà più spazio di archiviazione di un elenco, ma probabilmente non molto di più.

Si noti che normalmente l'overhead e il comportamento di un BST non portano nulla al tavolo nelle situazioni del mondo reale come secchi di tabella hash, motivo per cui le scarse prestazioni teoriche di un elenco sono accettabili. In altre parole, la tabella hash compensa la debolezza dell'elenco posizionando meno elementi in ciascun elenco (bucket). Tuttavia : il problema specificava che la tabella hash non può aumentare di dimensioni e che le collisioni sono più frequenti di quanto sia tipico in una tabella hash.

Implementazione

Non inserirò qui il codice perché onestamente non è davvero necessario e tu non hai dato una lingua comunque.

Quello che vorrei fare è semplicemente copiare qualsiasi tabella hash standard contenuta nella libreria standard della tua lingua in una nuova classe, quindi cambiare il tipo di bucket della tabella da un elenco a un albero. A seconda della lingua e della sua libreria standard, questa può essere una cosa molto banale da fare.

Normalmente non invoco a copiare e incollare la codifica in questo modo. Tuttavia, è un modo semplice per ottenere una struttura di dati testata in battaglia molto rapidamente.

L'uso di un albero binario per la gestione delle collisioni in una tabella hash non è solo possibile, ma è stato fatto.

Walter Bright è meglio conosciuto come l'inventore del linguaggio di programmazione D , ma ha anche scritto una variante ECMAScript chiamata DMDScript . In passato, un titolo principale di DMDScript (o forse un antenato - mi sembra di ricordare il nome DScript) era che i suoi hashtable tendevano a superare quelli in molti linguaggi simili. Il motivo: gestione delle collisioni mediante alberi binari.

Non ricordo esattamente da dove provenga, ma gli alberi utilizzati erano ingenui alberi binari, senza schema di equilibrio parziale (non AVL, rosso-nero o altro) che ha senso supponendo che la stessa hashtable venga ridimensionata quando diventa troppo piena e non si ottengono tassi assurdamente improbabili di collisioni di hash, gli alberi binari dovrebbero essere sempre piccoli. Fondamentalmente, il caso peggiore è sempre lo stesso dell'utilizzo di un elenco collegato per la gestione delle collisioni (tranne che si paga il prezzo di due puntatori per nodo anziché uno), ma il caso medio riduce la quantità di ricerca all'interno di ciascun bucket hash.