Complessità di unione-ricerca con path-compressione, senza rango

10

Wikipedia afferma che l'unione per grado senza compressione del percorso fornisce una complessità temporale ammortizzata di e che sia l'unione per grado che la compressione del percorso danno una complessità temporale ammortizzata di (dove è il inverso della funzione di Ackerman). Tuttavia, non menziona il tempo di esecuzione della compressione del percorso senza rango sindacale, che è ciò che di solito mi implemento. $O(\log n)$ $O(\alpha(n))$ $\alpha$

Qual è la complessità temporale ammortizzata di union-find con l'ottimizzazione della compressione del percorso, ma senza l'unione con l'ottimizzazione del rango?

complexity-theory time-complexity union-find

— Filip Haglund
fonte

5

Nota che è l'inverso della funzione di Ackerman, non . Qui "inverso" significa l'inverso come una funzione, non il reciproco: cioè, se , , non .

α (n)

$\alpha(n)$

1 / A (n, n))

$1/A(n, n))$

f (n) = A (n, n)

$f(n)=A(n,n)$

α (n) = f^{- 1} (n)

$\alpha(n)=f^{-1}(n)$

1 / f (n)

$1/f(n)$

— DW

Capisco che questa è una domanda relativamente vecchia, ma vedi la mia risposta e un documento pertinente: epubs.siam.org/doi/abs/10.1137/S0097539703439088 . Potrei aver perso un dettaglio o due durante la copia oltre i limiti. In tal caso, ti preghiamo di suggerire una modifica :-)

— BearAqua

4

Seidel e Sharir hanno dimostrato nel 2005 [1] che l'uso della compressione del percorso con collegamenti arbitrari all'incirca su operazioni ha una complessità di circa . $m$ $O((m+n)\log(n))$

Vedi [1], Sezione 3 (Collegamento arbitrario): Let indica il runtime di union-find con operazioni e elementi. Hanno dimostrato quanto segue: $f(m,n)$ $m$ $n$

Rivendicazione 3.1. Per qualsiasi numero intero abbiamo . $k>1$ $f(m, n)\leq (m+(k−1)n)\lceil \log_k(n) \rceil$

Secondo [1], l'impostazione fornisce . $k = \lceil m/n \rceil + 1$

f (m, n) \leq (2 m + n) \log_{⌈ m / n ⌉ + 1} n

$f(m, n)\leq (2m+n) \log_{\lceil m/n\rceil +1}n$

Un limite simile è stato dato usando un metodo più complesso da Tarjan e van Leeuwen in [2], Sezione 3:

Lemma 7 di [2]. Supponiamo che . In qualsiasi sequenza di operazioni impostate implementate utilizzando qualsiasi forma di compattazione e collegamento ingenuo, il numero totale di nodi sui percorsi di ricerca è al massimo Con dimezzamento e collegamenti ingenui, il numero totale di nodi nei percorsi di ricerca è al massimo . $m \geq n$ $(4m + n) \lceil \log_{\lfloor 1 + m/n \rfloor}n \rceil$ $(8m+2n)\lceil \log_{\lfloor 1 + m/n \rfloor} (n) \rceil$

Lemma 9 di [2]. Supponiamo che . In qualsiasi sequenza di operazioni impostate implementate utilizzando la compressione e il collegamento ingenuo, il numero totale di nodi sui percorsi di ricerca è al massimo . $m < n$ $n + 2m \lceil \log n\rceil + m$

[1]: R. Seidel e M. Sharir. Analisi top-down della compressione del percorso. Siam J. Computing, 2005, vol. 34, n. 3, pagg. 515-525.

[2]: R. Tarjan e J. van Leeuwen. Analisi dei casi peggiori di algoritmi set di unione. J. ACM, Vol. 31, n. 2, aprile 1984, pagg. 245-281.

— BearAqua
fonte

2

Non so quale sia il tempo di esecuzione ammortizzato, ma posso citare un possibile motivo per cui in alcune situazioni potresti voler utilizzare entrambi anziché la semplice compressione del percorso: il tempo di esecuzione peggiore per operazione è se usi solo la compressione del percorso, che è molto più grande di se usi sia l'unione per rango che la compressione del percorso. $\Theta(n)$

$n$ $n-1$ $\Theta(n)$ $\Theta(n)$

$O(\log n)$ $O(\log n)$ $O(\log n)$ potrebbe essere utile in un'applicazione interattiva in cui si desidera assicurarsi che nessuna singola operazione possa causare un lungo ritardo (ad esempio, si desidera garantire che nessuna singola operazione possa causare il blocco dell'applicazione per un lungo periodo) o in tempo reale applicazione in cui vuoi assicurarti di soddisfare sempre le garanzie in tempo reale.

— DW
fonte