Esiste un sistema dietro la magia dell'analisi algoritmica?

Ci sono un sacco di domande su come analizzare il tempo di esecuzione degli algoritmi (vedi, ad esempio, di runtime-analisi e algoritmo di analisi ). Molti sono simili, ad esempio quelli che richiedono un'analisi dei costi di loop nidificati o algoritmi di divisione e conquista, ma la maggior parte delle risposte sembra essere fatta su misura.

D'altra parte, le risposte a un'altra domanda generale spiegano il quadro più ampio (in particolare per quanto riguarda l'analisi asintotica) con alcuni esempi, ma non come sporcarsi le mani.

Esiste un metodo strutturato e generale per analizzare il costo degli algoritmi? Il costo potrebbe essere il tempo di esecuzione (complessità temporale) o qualche altra misura del costo, come il numero di confronti eseguiti, la complessità dello spazio o qualcos'altro.

^{Questo dovrebbe diventare una domanda di riferimento che può essere usata per indicare ai principianti; da qui il suo ambito più ampio del solito. Prestare attenzione a dare risposte generali, presentate in modo didattico, illustrate da almeno un esempio, ma che coprano comunque molte situazioni. Grazie!}

Traduzione del codice in matematica

Data una semantica operativa (più o meno) formale , puoi tradurre il codice (pseudo-) di un algoritmo letteralmente in un'espressione matematica che ti dà il risultato, a condizione che tu possa manipolare l'espressione in una forma utile. Questo funziona bene per misure di costo additivo come numero di confronti, scambi, dichiarazioni, accessi alla memoria, cicli di cui alcune macchine astratte hanno bisogno e così via.

Esempio: confronti in Bubblesort

Considera questo algoritmo che ordina un determinato array A:

 bubblesort(A) do                   1
  n = A.length;                     2
  for ( i = 0 to n-2 ) do           3
    for ( j = 0 to n-i-2 ) do       4
      if ( A[j] > A[j+1] ) then     5
        tmp    = A[j];              6
        A[j]   = A[j+1];            7
        A[j+1] = tmp;               8
      end                           9
    end                             10
  end                               11
end                                 12

Supponiamo di voler eseguire la consueta analisi dell'algoritmo di ordinamento, ovvero contare il numero di confronti tra elementi (riga 5). Notiamo immediatamente che questa quantità non dipende dal contenuto dell'array A, ma solo dalla sua lunghezza . Quindi possiamo tradurre i loop (nidificati) letteralmente in somme (nidificate); la variabile loop diventa la variabile di somma e l'intervallo viene trasferito. Noi abbiamo:$n$for

$\qquad\displaystyle C_{\text{cmp}}(n) = \sum_{i=0}^{n-2} \sum_{j=0}^{n-i-2} 1 = \dots = \frac{n(n-1)}{2} = \binom{n}{2}$ ,

dove è il costo per ogni esecuzione della riga 5 (che contiamo).$1$

Esempio: scambi in Bubblesort

Indicheremo con il sottoprogramma che consiste in righe per e con i costi per l'esecuzione di questo sottoprogramma (una volta).$P_{i,j}$ij$C_{i,j}$

Supponiamo ora di contare gli swap , ovvero la frequenza con cui viene eseguito . Questo è un "blocco di base", ovvero un sottoprogramma che viene sempre eseguito atomicamente e ha un costo costante (qui, ). Contrarre tali blocchi è un'utile semplificazione che spesso applichiamo senza pensarci o parlarne.$P_{6,8}$$1$

Con una traduzione simile a quella precedente, arriviamo alla seguente formula:

$\qquad\displaystyle C_{\text{swaps}}(A) = \sum_{i=0}^{n-2} \sum_{j=0}^{n-i-2} C_{5,9}(A^{(i,j)})$ .

$A^{(i,j)}$ indica lo stato dell'array prima dell'iterazione di .$(i,j)$$P_{5,9}$

Si noti che uso invece di come parametro; vedremo presto perché. Non aggiungo e come parametri di poiché i costi non dipendono da questi qui (nel modello di costo uniforme , cioè); in generale, potrebbero semplicemente.$A$$n$$i$$j$$C_{5,9}$

Chiaramente, i costi di dipendono dal contenuto di (i valori e , nello specifico), quindi dobbiamo tenerne conto. Ora affrontiamo una sfida: come "scartare" ? Bene, possiamo rendere esplicita la dipendenza dal contenuto di :$P_{5,9}$$A$A[j]A[j+1]$C_{5,9}$$A$

$\qquad\displaystyle C_{5,9}(A^{(i,j)}) = C_5(A^{(i,j)}) + \begin{cases} 1 &, \mathtt{A^{(i,j)}[j] > A^{(i,j)}[j+1]} \\ 0 &, \text{else} \end{cases}$ .

Per ogni dato array di input, questi costi sono ben definiti, ma vogliamo una dichiarazione più generale; dobbiamo fare ipotesi più forti. Esaminiamo tre casi tipici.

1. Il caso peggiore

   Solo guardando la somma e notando che , possiamo trovare un limite superiore banale per il costo:$C_{5,9}(A^{(i,j)}) \in \{0,1\}$

   $\qquad\displaystyle C_{\text{swaps}}(A) \leq \sum_{i=0}^{n-2} \sum_{j=0}^{n-i-2} 1 = \frac{n(n-1)}{2} = \binom{n}{2}$ .

   Ma può succedere , cioè c'è una per questo limite superiore raggiunto? A quanto pare, sì: se immettiamo un array inversamente ordinato di elementi distinti a coppie, ogni iterazione deve eseguire uno scambio¹. Pertanto, abbiamo derivato il numero esatto di swap di Bubblesort nel caso peggiore.$A$

2. Il caso migliore

   Al contrario, esiste un limite inferiore banale:

   $\qquad\displaystyle C_{\text{swaps}}(A) \geq \sum_{i=0}^{n-2} \sum_{j=0}^{n-i-2} 0 = 0$ .

   Questo può accadere anche: su un array già ordinato, Bubblesort non esegue un singolo scambio.

3. Il caso medio

   Il peggiore e il migliore dei casi apre abbastanza un vuoto. Ma qual è il numero tipico di swap? Per rispondere a questa domanda, dobbiamo definire cosa significa "tipico". In teoria, non abbiamo motivo di preferire un input a un altro e quindi di solito assumiamo una distribuzione uniforme su tutti i possibili input, ovvero ogni input è ugualmente probabile. Ci limitiamo alle matrici con elementi distinti a coppie e quindi assumiamo il modello di permutazione casuale .

   Quindi, possiamo riscrivere i nostri costi in questo modo²:

   $\qquad\displaystyle \mathbb{E}[C_{\text{swaps}}] = \frac{1}{n!} \sum_{A} \sum_{i=0}^{n-2} \sum_{j=0}^{n-i-2} C_{5,9}(A^{(i,j)})$

   Ora dobbiamo andare oltre la semplice manipolazione delle somme. Osservando l'algoritmo, notiamo che ogni scambio rimuove esattamente una inversione in (scambiamo sempre e solo i vicini³). Cioè, il numero di scambi effettuati su è esattamente il numero di inversioni di . Quindi, possiamo sostituire le due somme interne e ottenere$A$$A$$\operatorname{inv}(A)$$A$

   $\qquad\displaystyle \mathbb{E}[C_{\text{swaps}}] = \frac{1}{n!} \sum_{A} \operatorname{inv}(A)$ .

   Fortunatamente per noi, il numero medio di inversioni è stato determinato essere

   $\qquad\displaystyle \mathbb{E}[C_{\text{swaps}}] = \frac{1}{2} \cdot \binom{n}{2}$

   quale è il nostro risultato finale. Si noti che questa è esattamente la metà del costo peggiore.

1. Si noti che l'algoritmo è stato accuratamente formulato in modo che i = n-1non venga eseguita "l'ultima" iterazione del ciclo esterno che non fa mai nulla.
2. " " è la notazione matematica per "valore atteso", che qui è solo la media.$\mathbb{E}$
3. Impariamo lungo la strada che nessun algoritmo che scambia solo elementi vicini può essere asintoticamente più veloce di Bubblesort (anche in media) - il numero di inversioni è un limite inferiore per tutti questi algoritmi. Questo vale ad esempio per Inserimento inserzione e Selezione ordinamento .

Il metodo generale

Nell'esempio abbiamo visto che dobbiamo tradurre la struttura di controllo in matematica; Presenterò un insieme tipico di regole di traduzione. Abbiamo anche visto che il costo di un dato sottoprogramma può dipendere dallo stato corrente , ovvero (approssimativamente) i valori correnti delle variabili. Poiché l'algoritmo (di solito) modifica lo stato, il metodo generale è leggermente complicato da notare. Se inizi a sentirti confuso, ti suggerisco di tornare all'esempio o inventare il tuo.

Indichiamo con lo stato corrente (immaginatelo come un insieme di assegnazioni di variabili). Quando eseguiamo un programma che inizia in stato , finiamo in stato (fornito termina).$\psi$P$\psi$$\psi / \mathtt{P}$P

• Dichiarazioni individuali

  Dato solo un singolo estratto conto S;, lo assegni costa . Questa sarà in genere una funzione costante.$C_S(\psi)$

• espressioni

  Se si dispone di un'espressione Edel modulo E1 ∘ E2(ad esempio, un'espressione aritmetica in cui ∘può essere aggiunta o moltiplicazione, si sommano i costi in modo ricorsivo:

  $\qquad\displaystyle C_E(\psi) = c_{\circ} + C_{E_1}(\psi) + C_{E_2}(\psi)$ .

  Nota che

  • il costo dell'operazione non sia costante, ma dipende dai valori di e e$c_{\circ}$$E_1$$E_2$
  • la valutazione delle espressioni può cambiare lo stato in molte lingue,

  quindi potresti dover essere flessibile con questa regola.

• Sequenza

  Dato un programma Pcome sequenza di programmi Q;R, si aggiungono i costi a

  $\qquad\displaystyle C_P(\psi) = C_Q(\psi) + C_R(\psi / \mathtt{Q})$ .

• Condizionali

  Dato un programma Pdel modulo if A then Q else R end, i costi dipendono dallo stato:

  $\qquad\displaystyle C_P(\psi) = C_A(\psi) + \begin{cases} C_Q(\psi/\mathtt{A}) &, \mathtt{A} \text{ evaluates to true under } \psi \\ C_R(\psi/\mathtt{A}) &, \text{else} \end{cases}$

  In generale, la valutazione Apuò benissimo cambiare lo stato, quindi l'aggiornamento per i costi delle singole filiali.

• Per-Loops

  Dato un programma Pdel modulo for x = [x1, ..., xk] do Q end, assegnare i costi

  $\qquad\displaystyle C_P(\psi) = c_{\text{init_for}} + \sum_{i=1}^k c_{\text{step_for}} + C_Q(\psi_i \circ \{\mathtt{x := xi\}})$

  dove è lo stato prima dell'elaborazione per value , ovvero dopo l'iterazione con essere impostato su , ..., .$\psi_i$Qxixx1xi-1

  Nota le costanti extra per la manutenzione del circuito; la variabile loop deve essere creata ( ) e assegnata i suoi valori ( ). Questo è rilevante da allora$c_{\text{init_for}}$$c_{\text{step_for}}$

  • calcolare il prossimo xipuò essere costoso e
  • a for-loop con corpo vuoto (ad es. dopo aver semplificato l'impostazione di un caso migliore con un costo specifico) non ha costo zero se esegue iterazioni.

• Mentre-Loops

  Dato un programma Pdel modulo while A do Q end, assegnare i costi

  $\qquad\displaystyle C_P(\psi) \\\qquad\ = C_A(\psi) + \begin{cases} 0 &, \mathtt{A} \text{ evaluates to false under } \psi \\ C_Q(\psi/\mathtt{A}) + C_P(\psi/\mathtt{A;Q}) &, \text{ else} \end{cases}$

  Ispezionando l'algoritmo, questa ricorrenza può essere spesso rappresentata come una somma simile a quella per i for-loop.

  Esempio: considerare questo breve algoritmo:

  while x > 0 do    1
    i += 1          2
    x = x/2         3
  end               4
  

  Applicando la regola, otteniamo

  $\qquad\displaystyle C_{1,4}(\{i := i_0; x := x_0\}) \\\qquad\ = c_< + \begin{cases} 0 &, x_0 \leq 0 \\ c_{+=} + c_/ + C_{1,4}(\{i := i_0 + 1; x := \lfloor x_0/2 \rfloor\}) &, \text{ else} \end{cases}$

  con alcuni costi costanti per le singole dichiarazioni. Partiamo dal presupposto implicito che questi non dipendono dallo stato (i valori di e ); questo può o non può essere vero nella "realtà": pensa agli overflow!$c_{\dots}$ix

  Ora dobbiamo risolvere questa ricorrenza per . Notiamo che né il numero di iterazioni né il costo del corpo del loop dipendono dal valore di , quindi possiamo lasciarlo cadere. Siamo rimasti con questa ricorrenza:$C_{1,4}$i

  $\qquad\displaystyle C_{1,4}(x) = \begin{cases} c_> &, x \leq 0 \\ c_> + c_{+=} + c_/ + C_{1,4}(\lfloor x/2 \rfloor) &, \text{ else} \end{cases}$

  Questo risolve con mezzi elementari per

  $\qquad\displaystyle C_{1,4}(\psi) = \lceil \log_2 \psi(x) \rceil \cdot (c_> + c_{+=} + c_/) + c_>$ ,

  reintrodurre simbolicamente lo stato completo; if , quindi .$\psi = \{ \dots, x := 5, \dots\}$$\psi(x) = 5$

• Chiamate di procedura

  Dato un programma Pdel modulo M(x)per alcuni parametri in xcui Mè una procedura con parametro (denominato) p, assegnare i costi

  $\qquad\displaystyle C_P(\psi) = c_{\text{call}} + C_M(\psi_{\text{glob}} \circ \{p := x\})$ .

  Nota di nuovo la costante extra (che potrebbe in effetti dipendere da !). Le chiamate di procedura sono costose a causa del modo in cui sono implementate su macchine reali e talvolta addirittura dominano il tempo di esecuzione (ad esempio, valutando in modo ingenuo la ricorrenza del numero di Fibonacci).$c_{\text{call}}$$\psi$

  Cerco alcuni problemi semantici che potresti avere con lo stato qui. Dovrai distinguere lo stato globale e tale locale dalle chiamate di procedura. Supponiamo di passare qui solo lo stato globale e di Mottenere un nuovo stato locale, inizializzato impostando il valore di pto x. Inoltre, xpuò essere un'espressione che (di solito) assumiamo di essere valutata prima di passarla.

  Esempio: considerare la procedura

  fac(n) do                  
    if ( n <= 1 ) do         1
      return 1               2
    else                     3
      return n * fac(n-1)    4
    end                      5
  end                        
  

  Secondo le regole, otteniamo:

  $\qquad\displaystyle\begin{align*} C_{\text{fac}}(\{n := n_0\}) &= C_{1,5}(\{n := n_0\}) \\ &= c_{\leq} + \begin{cases} C_2(\{n := n_0 \}) &, n_0 \leq 1 \\ C_4(\{n := n_0 \}) &, \text{ else} \end{cases} \\ &= c_{\leq} + \begin{cases} c_{\text{return}} &, n_0 \leq 1 \\ c_{\text{return}} + c_* + c_{\text{call}} + C_{\text{fac}}(\{n := n_0 - 1\}) &, \text{ else} \end{cases} \end{align*}$

  Si noti che ignoriamo lo stato globale, poiché facchiaramente non si accede a nessuno. Questa ricorrenza particolare è facile da risolvere

  $\qquad\displaystyle C_{\text{fac}}(\psi) = \psi(n) \cdot (c_{\leq} + c_{\text{return}}) + (\psi(n) - 1) \cdot (c_* + c_{\text{call}})$

Abbiamo coperto le funzionalità della lingua che incontrerai nel tipico pseudo codice. Fai attenzione ai costi nascosti quando analizzi lo pseudo codice di alto livello; in caso di dubbio, spiega. La notazione può sembrare ingombrante ed è certamente una questione di gusti; i concetti elencati non possono essere ignorati, comunque. Tuttavia, con una certa esperienza sarai in grado di vedere subito quali parti dello stato sono rilevanti per quale misura di costo, ad esempio "dimensione del problema" o "numero di vertici". Il resto può essere lasciato cadere - questo semplifica notevolmente le cose!

Se pensi ora che sia troppo complicato, tieni presente: lo è ! Derivare i costi esatti degli algoritmi in qualsiasi modello così vicino alle macchine reali da consentire previsioni di runtime (anche relative) è uno sforzo arduo. E questo non sta nemmeno prendendo in considerazione la memorizzazione nella cache e altri effetti negativi su macchine reali.

Pertanto, l'analisi dell'algoritmo è spesso semplificata al punto da essere matematicamente trattabile. Ad esempio, se non sono necessari costi esatti, è possibile sovrastimare o sottostimare in qualsiasi momento (per limiti superiori o inferiori): ridurre l'insieme di costanti, eliminare i condizionali, semplificare le somme e così via.

Una nota sul costo asintotico

Ciò che di solito troverai in letteratura e sui siti web è l '"analisi Big-Oh". Il termine corretto è analisi asintotica , il che significa che invece di derivare costi esatti come abbiamo fatto negli esempi, si danno solo costi fino a un fattore costante e nel limite (approssimativamente parlando, "per big ").$n$

Questo è (spesso) giusto in quanto affermazioni astratte hanno in realtà alcuni costi (generalmente sconosciuti), a seconda della macchina, del sistema operativo e di altri fattori, e tempi di esecuzione brevi possono essere dominati dal sistema operativo che imposta il processo in primo luogo e quant'altro. Quindi ottieni qualche perturbazione, comunque.

Ecco come l'analisi asintotica si collega a questo approccio.

1. Identificare le operazioni dominanti (che inducono costi), ovvero le operazioni che si verificano più spesso (fino a fattori costanti). Nell'esempio di Bubblesort, una possibile scelta è il confronto nella riga 5.

   In alternativa, vincolare tutte le costanti per le operazioni elementari dal loro massimo (dall'alto) risp. il loro minimo (dal basso) ed eseguono la consueta analisi.

2. Eseguire l'analisi utilizzando i conteggi di esecuzione di questa operazione come costo.
3. Quando si semplifica, consentire le stime. Assicurati di consentire le stime dall'alto solo se il tuo obiettivo è un limite superiore ( ) risp. dal basso se vuoi limiti inferiori ( ).$O$$\Omega$

Assicurati di comprendere il significato dei simboli Landau . Ricorda che tali limiti esistono per tutti e tre i casi ; l'uso di non implica un'analisi del caso peggiore.$O$

Ulteriori letture

Ci sono molte altre sfide e trucchi nell'analisi dell'algoritmo. Ecco alcune letture consigliate.

• Come elaborare il runtime degli algoritmi?
  Come descrivere algoritmi, dimostrarli e analizzarli?
• Perché utilizzare i confronti anziché il runtime per confrontare due algoritmi?
  Come possiamo supporre che le operazioni di base sui numeri impieghino un tempo costante?
  Cosa costituisce un'unità di tempo nell'analisi di runtime?
• Risolvere o approssimare relazioni di ricorrenza per sequenze di numeri
• Nozioni di base sull'analisi ammortizzata

Ci sono molte domande intorno all'analisi degli algoritmi che usano tecniche simili a questa.

Conti di esecuzione delle dichiarazioni

C'è un altro metodo, sostenuto da Donald E. Knuth nella sua serie The Art of Computer Programming . Contrariamente a tradurre l'intero algoritmo in una formula , funziona indipendentemente dalla semantica del codice sul lato "mettere insieme le cose" e consente di passare a un livello inferiore solo quando necessario, a partire da una vista "a volo d'aquila". Ogni affermazione può essere analizzata indipendentemente dal resto, portando a calcoli più chiari. Tuttavia, la tecnica si presta bene a un codice piuttosto dettagliato, non molto pseudo codice di livello superiore.

Il metodo

È abbastanza semplice in linea di principio:

1. Assegna a ogni istruzione un nome / numero.
2. Assegna a ogni istruzione un costo .$S_i$$C_i$
3. Determina per ogni istruzione suo numero di esecuzioni .$S_i$$e_i$

4. Calcola i costi totali

   $\qquad\displaystyle C = \sum_{i} e_i \cdot C_i$ .

È possibile inserire stime e / o quantità simboliche in qualsiasi momento, indebolendo risp. generalizzando il risultato di conseguenza.

Tenere presente che il passaggio 3 può essere arbitrariamente complesso. Di solito è lì che devi lavorare con stime (asintotiche) come " " per ottenere risultati.$e_{77} \in O(n \log n)$

Esempio: ricerca della prima profondità

Considera il seguente algoritmo di attraversamento dei grafici:

dfs(G, s) do
  // assert G.nodes contains s
  visited = new Array[G.nodes.size]     1
  dfs_h(G, s, visited)                  2
end 

dfs_h(G, s, visited) do
  foo(s)                                3
  visited[s] = true                     4

  v = G.neighbours(s)                   5
  while ( v != nil ) do                 6
    if ( !visited[v] ) then             7
      dfs_h(G, v, visited)              8
    end
    v = v.next                          9
  end
end

Partiamo dal presupposto che il grafico (non indirizzato) sia dato dagli elenchi di adiacenza sui nodi . Sia il numero di spigoli.$\{0,\dots,n-1\}$$m$

Solo guardando l'algoritmo, vediamo che alcune istruzioni vengono eseguite ugualmente spesso come altre. Presentiamo alcuni segnaposto , e per i conteggi di esecuzione :$A$$B$$C$$e_i$

$\qquad\begin{array}{c|ccccccccc} i & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 \\ \hline e_i & A & A & B & B & B & B+C & C & B-1 & C \end{array}$

In particolare, poiché ogni chiamata ricorsiva nella riga 8 provoca una chiamata nella riga 3 (e una è causata dalla chiamata originale da ). Inoltre, perché la condizione deve essere verificata una volta per iterazione ma poi ancora una volta per lasciarla.$e_8 = e_3-1$foodfs$e_6 = e_5 + e_7$while

È chiaro che . Ora, durante una prova di correttezza, mostreremo che viene eseguito esattamente una volta per nodo; cioè . Ma poi, passiamo in rassegna ogni elenco di adiacenza esattamente una volta e ogni fronte implica due voci in totale (una per ogni nodo incidente); otteniamo iterazioni in totale. Usando questo, deriviamo la seguente tabella:$A=1$foo$B = n$$C = 2m$

$\qquad\begin{array}{c|ccccccccc} i & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 \\ \hline e_i & 1 & 1 & n & n & n & 2m + n & 2m & n-1 & 2m \end{array}$

Questo ci porta a costi totali di esattamente

$\qquad\begin{align*} C(n,m) = (C_1 + C_2 - C_8) &+\ n \cdot (C_3 + C_4 + C_5 + C_6 + C_8) \\ &+\ 2m \cdot (C_6 + C_7 + C_9) \;. \end{align*}$

Istanziando valori adeguati per possiamo ricavare costi più concreti. Ad esempio, se vogliamo contare gli accessi alla memoria (per parola), utilizzeremo$C_i$

$\qquad\begin{array}{c|ccccccccc} i & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 \\ \hline C_i & n & 0 & 0 & 1 & 1 & 0 & 1 & 0 & 1 \end{array}$

e prendi

$\qquad\displaystyle C_{\text{mem}}(n,m) = 3n + 4m$ .

Ulteriori letture

Vedi in fondo all'altra mia risposta .

L'analisi dell'algoritmo, come la dimostrazione del teorema, è in gran parte un'arte (ad esempio ci sono programmi semplici (come il problema di Collatz ) che non sappiamo come analizzare). Possiamo convertire un problema di complessità dell'algoritmo in un problema matematico, come ha risposto in modo esauriente Raphael , ma per esprimere un limite al costo di un algoritmo in termini di funzioni note, siamo lasciati a:

1. Usa tecniche che conosciamo da analisi esistenti, come trovare limiti basati su ricorrenze che comprendiamo o somma / integrali che possiamo calcolare.
2. Cambia l'algoritmo in qualcosa che sappiamo analizzare.
3. Vieni con un approccio completamente nuovo.