Splay albero potenziale funzione: perché sommare i registri delle dimensioni?


16

Sto insegnando un corso sulle strutture dati e tratterò gli alberi di lancio all'inizio della prossima settimana. Ho letto il documento sugli alberi di splay molte volte e ho familiarità con l'analisi e l'intuizione dietro la struttura dei dati. Tuttavia, non riesco a trovare una solida intuizione per la potenziale funzione che Sleator e Tarjan usano nella loro analisi.

L'analisi funziona assegnando ciascun elemento nell'albero del peso arbitrario , quindi impostando la dimensione s ( x ) di un nodo come la somma dei pesi dei nodi del sottoalbero con radice in x . Quindi prendono il registro di questo valore per ottenere il rango r ( x ) del nodo, quindi r ( x ) = log s ( x ) . Infine, la potenziale funzione dell'albero viene definita come la somma dei ranghi di tutti i nodi.wis(x)xr(x)r(x)=logs(x)

Comprendo che questa potenziale funzione funziona correttamente e posso seguire l'analisi, ma non vedo perché sceglierebbero questo potenziale. L'idea di assegnare una dimensione a ciascun nodo ha senso per me, poiché se si sommano le dimensioni, si ottiene la lunghezza del percorso ponderata dell'albero. Tuttavia, non riesco a capire perché abbiano deciso di prendere i tronchi dei pesi e poi riassumerli invece - non vedo alcuna proprietà naturale dell'albero a cui questo corrisponde.

La potenziale funzione dell'albero di splay corrisponde ad alcune proprietà naturali dell'albero? C'è un motivo particolare, oltre a "funziona", che avrebbero scelto questo potenziale? (Sono particolarmente curioso perché questo set di note del corso menziona che "l'analisi è magia nera. [N] o idea di come scoperto")

Grazie!


Ho già sentito questa spiegazione "è magia nera". Hai provato a inviare e-mail a Sleator e Tarjan?
jbapple,

@jbapple Non li ho ancora inviati via email, poiché speravo che "la comunità in generale" sarebbe stata in grado di dare una mano. Ho anche pensato che fare un rumore metallico a qualcuno sul lavoro svolto 30 anni fa potrebbe non suscitare necessariamente una risposta. :-)
templatetypedef il

Non ne ho molta familiarità, ma guardo il documento molto approssimativamente, penso che l'unica ragione sia che vogliono avere delle piccole modifiche da potenziali funzioni dopo l'operazione di splay, ad esempio se sostituiamo il con il registro di registro o con l o g * sembra ancora tutto funziona bene (non mi proverò, ma sembra solo bisogno di un semplice mathwork). Ma se lo lasciamo come s , allora l'ammortamento analizza mentre è corretto, ma non è un buon limite superiore (qualcosa come ( m + n ) 2 ). Non è affatto correlato a nessuna proprietà dell'albero. loglogloglogs(m+n)2
Saeed

Ho sempre riordinato il rango di x come "la profondità dell'albero di ricerca binaria ideale contenente i discendenti di x", ma è più un'intuizione mnemonica che utile.
Jeffε,

Risposte:


13

Come trovare il potenziale della somma dei registri

Consideriamo l'algoritmo BST che per ogni accesso per l'elemento x , riordina solo gli elementi nel percorso di ricerca P di x chiamato percorso precedente, in un albero chiamato albero dopo. Per ogni elemento di una , lasciate s ( un ) e s ' ( un ) siano le dimensioni del sottoalbero con radice in una prima e dopo il riarrangiamento rispettivamente. Così s ( un ) e s ' ( un ) possono variare se e solo se un P .AxPxas(a)s(a)as(a)s(a)aP

Inoltre, riorganizza costantemente molti elementi nel percorso di ricerca in qualsiasi momento. Chiamiamo questo tipo di algoritmo "locale". Ad esempio, l'albero di visualizzazione è locale. Riorganizza solo al massimo 3 elementi alla volta di zig, zigzig e zigzag.A

Ora, qualsiasi algoritmo locale che crea "molte" foglie nell'albero secondario, come lo splay tree, ha la seguente bella proprietà.

Possiamo creare una mappatura tale chef:PP

  1. Esistono linearmente molti , dove s ( f ( a ) ) s ( a ) / 2 .aPs(f(a))s(a)/2
  2. Ci sono costantemente molti , dove s ( f ( a ) )aPs(f(a)) può essere grande ma banalmente al massimo .n
  3. Altri elementi , s ( f ( a ) ) s ( a )aPs(f(a))s(a) .

Possiamo vederlo spiegando il cambiamento del percorso di ricerca. La mappatura è in realtà abbastanza naturale. Questo documento, A Global Geometric View of Splaying , mostra esattamente i dettagli su come vedere l'osservazione sopra.

Dopo aver saputo questo fatto, è molto naturale scegliere il potenziale della somma dei registri. Perché possiamo usare il potenziale cambiamento degli elementi di tipo 1 per pagare l'intero riarrangiamento. Inoltre, per elementi di altro tipo, dobbiamo pagare per il potenziale cambiamento al massimo logaritmico. Quindi, possiamo derivare il costo ammortizzato del logaritmo.

Penso che il motivo per cui la gente pensa che questa sia "magia nera" è che l'analisi precedente non "spiega" il cambiamento complessivo del percorso di ricerca e vede cosa succede realmente in un solo passaggio. Invece, mostrano il cambiamento di potenziale per ogni "trasformazione locale", e quindi mostrano che questi potenziali cambiamenti possono essere magicamente telescopizzati.

PS Il documento mostra anche alcune limitazioni del potenziale di somma dei registri. Cioè, si può dimostrare la soddisfazione del lemma di accesso attraverso il potenziale di somma dei registri solo per l'algoritmo locale.

Interpretazione del potenziale di somma dei registri

C'è un altro modo per definire il potenziale di BST nel documento di Georgakopoulos e McClurkin che è essenzialmente lo stesso del potenziale di somma dei tronchi nel documento di Sleator Tarjan. Ma questo mi dà una buona intuizione.

w(u)uW(u)uu

Ora, invece di definire il rango sui nodi, definiamo il rango ai bordi, che hanno chiamato fattore di progresso .

pf(e)=log(W(u)/W(v)).

E il potenziale dell'albero èS

Φ(S)=eSpf(e).

(u,v)uvW(u)/W(v)

Osserva che questo è quasi uguale al potenziale di Sleator Tarjan ed è additivo sui percorsi.

modifica: Si scopre che questa definizione alternativa e l'intuizione alla base è stata descritta molto tempo fa da Kurt Mehlhorn. Vedi il suo libro "Strutture di dati e algoritmi" Volume I, Sezione III. 6.1.2 Splay Trees, pagine 263 - 274.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.