Hashing utilizzando alberi di ricerca anziché elenchi

11

Sto lottando con hashing e materiale binario dell'albero di ricerca. E ho letto che invece di usare liste per memorizzare voci con gli stessi valori di hash, è anche possibile usare alberi di ricerca binari. E provo a capire quale sia il tempo di esecuzione peggiore e medio per le operazioni

insert,
find e
delete

è degno resp. caso medio. Migliorano rispetto alle liste?

— Forrest Gump
fonte

Se si ha accesso a un'analisi rigorosa dei tempi di esecuzione delle tabelle hash con concatenamento lineare (ovvero elenchi lineari), sostituire la parte in cui sono collegati i costi medi sugli elenchi lineari con i risultati medi del caso di un'implementazione di un albero di ricerca bilanciata. Il resto è meccanico. (Ovviamente, aiuta.)

— Raffaello

4

Per gli elenchi, l'inserimento, la ricerca e l'eliminazione sono rispettivamente in , , . Gli elenchi ordinati sono peggiori. La ricerca binaria stessa è per array ordinati, in cui le operazioni sono in , , . Se desideri operazioni di "inserimento" ed "eliminazione", hai bisogno di qualcosa di più della semplice ricerca binaria. $O(1)$ $O(n)$ $O(n)$ $O(n)$ $O(\log n)$ $O(n)$

Probabilmente vuoi qualcosa come alberi di ricerca binari . È molto più facile trovare riferimenti a riguardo una volta che hai la terminologia corretta. Queste operazioni sono nel momento peggiore , ad esempio per le implementazioni che utilizzano alberi AVL e alberi rosso-neri . $O(\log n)$

— jmad
fonte

1

È tutto corretto, ma non vedo come risponda alla domanda posta.

— rgrig,

Non era la stessa domanda a tutti in quel momento. (Anche la cronologia delle modifiche non ha la domanda originale. Strano.) Potrei aggiornare la mia risposta ma diventerebbe ridondante con quella di Gilles.

— jmad,

4

Nel peggiore dei casi, se ti capita di memorizzare solo elementi con gli stessi valori di hash, una tabella di hash memorizza tutti gli elementi nello stesso bucket. Se usi gli elenchi per memorizzare gli elementi di un bucket, la ricerca è nel peggiore dei casi (dove è il numero di elementi nella tabella - più in generale, è il numero di elementi nel bucket più grande), perché devi cercare l'intero elenco se stai cercando un elemento che non è presente nella tabella. La ricerca positiva (dove sai che l'elemento è presente) ha la stessa complessità: hai bisogno di se stai cercando l'ultimo elemento dell'elenco. La cancellazione ha la stessa complessità (è necessario $O(n)$ $n$ $n$ $n-1 = \Theta(n)$ $n-1$ ricerche se ti capita di eliminare l'ultimo elemento). L'inserimento è anche se è necessario verificare la presenza di un elemento esistente o se si consentono duplicati (nel qual caso è possibile inserire l'elemento all'inizio dell'elenco). $O(n)$ $O(1)$

Con alberi di ricerca binari bilanciati , la complessità del caso peggiore viene ridotta a , poiché la profondità di un albero di ricerca bilanciato cresce logaritmicamente nelle dimensioni dell'albero per definizione di bilanciamento. $O(\log n)$

Con una distribuzione media dei dati, gli elementi sono distribuiti su diversi bucket e vi sono poche collisioni, quindi la complessità è vicina a indipendentemente dalla struttura dei dati utilizzata in caso di collisioni. $O(1)$

Con ricerche casuali in una distribuzione di dati scelta in modo contraddittorio in cui tutti gli elementi sono nello stesso bucket, la lunghezza media dell'elenco che deve essere attraversata è , quindi la complessità media della ricerca in questa situazione è . Con un albero, la media è , come nel caso peggiore. $n$ $n/2$ $\Theta(n)$ $\Theta(\log n)$

— Gilles 'SO- smetti di essere malvagio'
fonte

2

"con una distribuzione media dei dati" dovrebbe leggere "con una funzione hash sufficientemente casuale"

— JeffE