Sommario
Type BST (*) Heap
Insert average log(n) 1
Insert worst log(n) log(n) or n (***)
Find any worst log(n) n
Find max worst 1 (**) 1
Create worst n log(n) n
Delete worst log(n) log(n)
Tutti i tempi medi su questa tabella sono gli stessi dei loro periodi peggiori, ad eccezione di Inserisci.
*: ovunque in questa risposta, BST == BST bilanciato, poiché uno sbilanciato fa schifo asintoticamente**: usando una banale modifica spiegata in questa risposta***: log(n)per heap albero puntatore, nper heap di array dinamico
Vantaggi dell'heap binario rispetto a un BST
l'inserimento del tempo medio in un heap binario è O(1), poiché BST lo è O(log(n)). Questa è la caratteristica killer di heap.
Ci sono anche altri cumuli che raggiungono l' O(1)ammortamento (più forte) come il mucchio di Fibonacci , e anche il caso peggiore, come la coda Brodal , anche se potrebbero non essere pratici a causa di prestazioni non asintotiche: i cumuli di Fibonacci o le code Brodal sono usati nella pratica ovunque?
gli heap binari possono essere implementati in modo efficiente su array dinamici o alberi basati su puntatori, BST solo alberi basati su puntatori. Quindi per l'heap possiamo scegliere l'implementazione dell'array più efficiente in termini di spazio, se possiamo permetterci latenze di ridimensionamento occasionali.
la creazione dell'heap binario è il O(n)caso peggiore , O(n log(n))per BST.
Vantaggio di BST rispetto all'heap binario
la ricerca di elementi arbitrari è O(log(n)). Questa è la caratteristica killer dei BST.
Per l'heap, è O(n)in generale, ad eccezione dell'elemento più grande che è O(1).
Vantaggio "falso" dell'heap rispetto a BST
heap è O(1)trovare max, BST O(log(n)).
Questo è un malinteso comune, perché è banale modificare un BST per tenere traccia dell'elemento più grande e aggiornarlo ogni volta che tale elemento può essere modificato: all'inserimento di uno più grande scambiare, alla rimozione trovare il secondo più grande. Possiamo usare l'albero di ricerca binario per simulare il funzionamento dell'heap? (menzionato da Yeo ).
In realtà, questa è una limitazione degli heap rispetto ai BST: l' unica ricerca efficiente è quella per l'elemento più grande.
L'inserto heap binario medio è O(1)
fonti:
Argomento intuitivo:
- i livelli dell'albero inferiore hanno esponenzialmente più elementi rispetto ai livelli superiori, quindi quasi sicuramente nuovi elementi andranno in fondo
- l'inserimento dell'heap inizia dal basso , il BST deve iniziare dall'alto
In un heap binario, aumentare il valore in un determinato indice è anche O(1)per lo stesso motivo. Ma se si desidera farlo, è probabile che si desideri mantenere un indice aggiuntivo aggiornato sulle operazioni di heap Come implementare l' operazione O-logn chiave di riduzione per la coda di priorità basata su min-heap? ad es. per Dijkstra. Possibile senza costi aggiuntivi.
La libreria standard GCC C ++ inserisce benchmark su hardware reale
Ho confrontato C ++ std::set( Red-black tree BST ) e std::priority_queue( dynamic array heap ) per vedere se avevo ragione sui tempi di inserimento, e questo è quello che ho ottenuto:
- codice di riferimento
- trama della trama
- dati della trama
- testato su Ubuntu 19.04, GCC 8.3.0 in un laptop Lenovo ThinkPad P51 con CPU: CPU Intel Core i7-7820HQ (4 core / 8 thread, base 2,90 GHz, cache 8 MB), RAM: 2x Samsung M471A2K43BB1-CRC (2x 16GiB , 2400 Mbps), SSD: Samsung MZVLB512HAJQ-000L7 (512 GB, 3.000 MB / s)
Quindi chiaramente:
il tempo di inserimento dell'heap è sostanzialmente costante.
Possiamo vedere chiaramente i punti di ridimensionamento della matrice dinamica. Dato che calcoliamo una media di ogni 10k inserti per poter vedere qualsiasi cosa sopra il rumore del sistema , tali picchi sono in effetti circa 10k volte più grandi di quanto mostrato!
Il grafico ingrandito esclude essenzialmente solo i punti di ridimensionamento dell'array e mostra che quasi tutti gli inserti sono inferiori a 25 nanosecondi.
BST è logaritmico. Tutti gli inserti sono molto più lenti dell'inserto heap medio.
BST vs hashmap analisi dettagliata su: Qual è la struttura dei dati all'interno di std :: map in C ++?
La libreria standard GCC C ++ inserisce il benchmark su gem5
gem5 è un simulatore di sistema completo e quindi fornisce un orologio infinitamente accurato con m5 dumpstats. Quindi ho provato a usarlo per stimare i tempi per i singoli inserti.
Interpretazione:
l'heap è ancora costante, ma ora vediamo più in dettaglio che ci sono alcune righe e ogni riga superiore è più sparsa.
Ciò deve corrispondere alle latenze di accesso alla memoria eseguite per inserti sempre più alti.
TODO Non riesco davvero a interpretare completamente il BST in quanto non sembra così logaritmico e un po 'più costante.
Con questo maggiore dettaglio, tuttavia, possiamo vedere anche alcune linee distinte, ma non sono sicuro di cosa rappresentino: mi aspetto che la linea di fondo sia più sottile, dal momento che inseriamo la parte inferiore inferiore?
Benchmark con questa configurazione Buildroot su una CPU HPI aarch64 .
BST non può essere implementato in modo efficiente su un array
Le operazioni di heap devono solo fare il bubble up o down di un singolo ramo di un albero, quindi nella O(log(n))peggiore delle ipotesi, in O(1)media.
Mantenere un BST bilanciato richiede rotazioni dell'albero, che possono cambiare l'elemento superiore per un altro, e richiederebbero lo spostamento dell'intero array intorno ( O(n)).
Gli heap possono essere implementati in modo efficiente su un array
Gli indici padre e figlio possono essere calcolati dall'indice corrente come mostrato qui .
Non ci sono operazioni di bilanciamento come BST.
Elimina min è l'operazione più preoccupante in quanto deve essere dall'alto verso il basso. Ma si può sempre fare "percolando" un singolo ramo dell'heap come spiegato qui . Questo porta ad un caso peggiore O (log (n)), poiché l'heap è sempre ben bilanciato.
Se stai inserendo un singolo nodo per ognuno di quelli rimossi, perdi il vantaggio dell'inserto medio asintotico O (1) che heap fornisce in quanto l'eliminazione dominerebbe e potresti anche usare un BST. Dijkstra tuttavia aggiorna i nodi più volte per ogni rimozione, quindi stiamo bene.
Cumuli di array dinamici vs cumuli di alberi di puntatori
Gli heap possono essere implementati in modo efficiente su heap di puntatori: è possibile realizzare implementazioni heap binarie basate su puntatori efficienti?
L'implementazione di array dinamici è più efficiente in termini di spazio. Supponiamo che ogni elemento heap contenga solo un puntatore a un struct:
l'implementazione dell'albero deve memorizzare tre puntatori per ciascun elemento: padre, figlio sinistro e figlio destro. Quindi l'utilizzo della memoria è sempre 4n(3 puntatori ad albero + 1 structpuntatore).
I BST degli alberi necessiterebbero inoltre di ulteriori informazioni di bilanciamento, ad esempio il rosso-nero.
l'implementazione di array dinamici può avere dimensioni 2nsubito dopo il raddoppio. Quindi in media lo sarà 1.5n.
D'altra parte, l'heap dell'albero ha un migliore inserimento nel caso peggiore, perché copiare l'array dinamico di supporto per raddoppiarne le dimensioni prende il O(n)caso peggiore, mentre l'heap dell'albero fa solo nuove piccole allocazioni per ciascun nodo.
Tuttavia, il raddoppio dell'array di supporto viene O(1)ammortizzato, quindi si riduce alla massima latenza. Menzionato qui .
Filosofia
I BST mantengono una proprietà globale tra un genitore e tutti i discendenti (a sinistra più piccolo, a destra più grande).
Il nodo superiore di un BST è l'elemento intermedio, che richiede una conoscenza globale da mantenere (sapendo quanti elementi sempre più piccoli ci sono).
Questa proprietà globale è più costosa da mantenere (log n insert), ma offre ricerche più potenti (log n search).
Heap mantiene una proprietà locale tra genitore e figli diretti (genitore> figli).
Il nodo principale di un heap è il grande elemento, che richiede solo conoscenze locali per mantenere (conoscere il tuo genitore).
Confronto tra BST vs Heap vs Hashmap:
BST: può essere sia ragionevole:
- set non ordinato (una struttura che determina se un elemento è stato precedentemente inserito o meno). Ma l'hashmap tende ad essere migliore grazie all'inserto ammortizzato O (1).
- selezionatrice. Ma l'heap è generalmente migliore in questo, motivo per cui heapsort è molto più conosciuto dell'ordinamento degli alberi
heap: è solo una selezionatrice. Non può essere un set efficiente non ordinato, poiché è possibile verificare rapidamente solo l'elemento più piccolo / più grande.
mappa hash: può essere solo un set non ordinato, non una macchina di smistamento efficiente, poiché l'hash mescola qualsiasi ordine.
Elenco doppiamente collegato
Un elenco doppiamente collegato può essere visto come sottoinsieme dell'heap in cui il primo elemento ha la massima priorità, quindi confrontiamoli anche qui:
- inserimento:
- posizione:
- elenco doppiamente collegato: l'elemento inserito deve essere il primo o l'ultimo, poiché abbiamo solo puntatori a quegli elementi.
- heap binario: l'elemento inserito può finire in qualsiasi posizione. Meno restrittivo dell'elenco collegato.
- tempo:
- elenco doppiamente collegato: il
O(1)caso peggiore dato che abbiamo puntatori agli elementi e l'aggiornamento è davvero semplice
- heap binario:
O(1)medio, quindi peggio dell'elenco collegato. Un compromesso per avere una posizione di inserimento più generale.
- ricerca:
O(n)per entrambi
Un caso d'uso per questo è quando la chiave dell'heap è il timestamp corrente: in tal caso, le nuove voci andranno sempre all'inizio dell'elenco. Quindi possiamo persino dimenticare del tutto il timestamp esatto e mantenere la posizione nell'elenco come priorità.
Questo può essere usato per implementare una cache LRU . Proprio come per le applicazioni heap come Dijkstra , vorrai mantenere una hashmap aggiuntiva dalla chiave al nodo corrispondente dell'elenco, per trovare quale nodo aggiornare rapidamente.
Confronto tra diversi BST bilanciati
Anche se i tempi di inserimento e di ricerca asintotici per tutte le strutture di dati che sono comunemente classificati come "BST bilanciati" che ho visto finora è lo stesso, BBST diversi hanno compromessi diversi. Non l'ho ancora studiato a fondo, ma sarebbe bene riassumere questi compromessi qui:
- Albero rosso-nero . Sembra essere il BBST più comunemente usato dal 2019, ad esempio è quello utilizzato dall'implementazione GCC 8.3.0 C ++
- Albero AVL . Sembra essere un po 'più bilanciato rispetto a BST, quindi potrebbe essere meglio trovare la latenza, al costo di reperti leggermente più costosi. Wiki riassume: "Gli alberi AVL sono spesso confrontati con alberi rosso-neri perché entrambi supportano lo stesso insieme di operazioni e impiegano [lo stesso] tempo per le operazioni di base. Per applicazioni ad alta intensità di ricerca, gli alberi AVL sono più veloci degli alberi rosso-nero perché sono più rigorosamente bilanciati. Analogamente agli alberi rosso-neri, gli alberi AVL sono bilanciati in altezza. Entrambi non sono, in generale, né bilanciati in peso né in mu per ogni mu <1/2; vale a dire, i nodi fratelli possono avere enormemente diverso numero di discendenti ".
- WAVL . Il documento originale menziona i vantaggi di quella versione in termini di limiti alle operazioni di ribilanciamento e rotazione.
Guarda anche
Domanda simile su CS: /cs/27860/whats-the-difference-between-a-binary-search-tree-and-a-binary-heap