Existe um sistema por trás da magia da análise de algoritmos?

Há muitas perguntas sobre como analisar o tempo de execução de algoritmos (ver, por exemplo, tempo de execução, análise e algoritmo de análise ). Muitos são semelhantes, por exemplo, aqueles que solicitam uma análise de custos de loops aninhados ou algoritmos de dividir e conquistar, mas a maioria das respostas parece ser feita sob medida.

Por outro lado, as respostas para outra pergunta geral explicam o quadro geral (em particular a análise assintótica) com alguns exemplos, mas não como sujar as mãos.

Existe um método geral estruturado para analisar o custo dos algoritmos? O custo pode ser o tempo de execução (complexidade do tempo) ou alguma outra medida de custo, como o número de comparações executadas, a complexidade do espaço ou qualquer outra coisa.

^{Isso deveria se tornar uma pergunta de referência que pode ser usada para apontar iniciantes; daí seu escopo mais amplo que o usual. Tome cuidado para fornecer respostas gerais, apresentadas didaticamente, ilustradas por pelo menos um exemplo, mas, no entanto, abrangem muitas situações. Obrigado!}

Traduzindo código para matemática

Dada uma semântica operacional (mais ou menos) formal , você pode traduzir o código (pseudo-) de um algoritmo literalmente em uma expressão matemática que fornece o resultado, desde que você possa manipular a expressão em uma forma útil. Isso funciona bem para aditivos medidas custo, tais como o número de comparações, swaps, declarações, acessos à memória, ciclos algumas necessidades máquina abstrata, e assim por diante.

Exemplo: Comparações no Bubblesort

Considere este algoritmo que classifica uma determinada matriz 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

Digamos que queremos realizar a análise usual do algoritmo de classificação, que é contar o número de comparações de elementos (linha 5). Notamos imediatamente que essa quantidade não depende do conteúdo da matriz A, apenas do seu comprimento . Portanto, podemos traduzir os loops (aninhados) literalmente em somas (aninhadas); a variável de loop se torna a variável de soma e o intervalo é transferido. Nós temos:$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}$ ,

onde é o custo para cada execução da linha 5 (que contamos).$1$

Exemplo: Swaps no Bubblesort

por o subprograma que consiste em linhas para e por os custos para executar esse subprograma (uma vez).$P_{i,j}$ij$C_{i,j}$

Agora, digamos que queremos contar swaps , é com que frequência é executado. Este é um "bloco básico", que é um subprograma que é sempre executado atomicamente e tem algum custo constante (aqui, ). A contratação de tais blocos é uma simplificação útil que geralmente aplicamos sem pensar ou falar sobre isso.$P_{6,8}$$1$

Com uma tradução semelhante à anterior, chegamos à seguinte fórmula:

$\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 o estado da matriz antes da -ésima iteração de .$(i,j)$$P_{5,9}$

Observe que eu uso vez de como parâmetro; em breve veremos o porquê. Eu não adiciono e como parâmetros de já que os custos não dependem deles aqui (no modelo de custo uniforme , que é); em geral, eles apenas podem.$A$$n$$i$$j$$C_{5,9}$

Claramente, os custos de dependem do conteúdo de (os valores e , especificamente), portanto, temos que prestar contas disso. Agora enfrentamos um desafio: como "desembrulhamos" ? Bem, podemos deixar explícita a dependência do conteúdo de :$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}$ .

Para qualquer matriz de entrada, esses custos são bem definidos, mas queremos uma declaração mais geral; precisamos fazer suposições mais fortes. Vamos investigar três casos típicos.

1. O pior caso

   Apenas olhando a soma e observando que , podemos encontrar um limite superior trivial para o custo:$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}$ .

   Mas isso pode acontecer , ou seja, existe um para esse limite superior ser alcançado? Como se vê, sim: se introduzirmos uma matriz inversamente classificada de elementos distintos em pares, toda iteração deve executar uma troca¹. Portanto, derivamos o número exato de piores casos de trocas de Bubblesort.$A$

2. O melhor caso

   Por outro lado, há um limite inferior trivial:

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

   Isso também pode acontecer: em uma matriz que já está classificada, o Bubblesort não executa uma única troca.

3. O caso médio

   O pior e o melhor dos casos abrem uma lacuna. Mas qual é o número típico de swaps? Para responder a essa pergunta, precisamos definir o que "típico" significa. Em teoria, não temos motivos para preferir uma entrada a outra e, portanto, geralmente assumimos uma distribuição uniforme entre todas as entradas possíveis, ou seja, todas as entradas são igualmente prováveis. Nós nos restringimos a matrizes com elementos distintos aos pares e, portanto, assumimos o modelo de permutação aleatória .

   Em seguida, podemos reescrever nossos custos dessa maneira²:

   $\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)})$

   Agora temos que ir além da simples manipulação de somas. Observando o algoritmo, observamos que toda troca remove exatamente uma inversão em (nós sempre trocamos os vizinhos³). Ou seja, o número de swaps realizadas em é exatamente o número de inversões de . Assim, podemos substituir as duas somas internas e obter$A$$A$$\operatorname{inv}(A)$$A$

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

   Para nossa sorte, o número médio de inversões foi determinado como sendo

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

   qual é o nosso resultado final. Observe que esse é exatamente metade do custo do pior caso.

1. Observe que o algoritmo foi cuidadosamente formulado para que "a última iteração" i = n-1do loop externo que nunca faz nada não seja executada.
2. " " é uma notação matemática para "valor esperado", que aqui é apenas a média.$\mathbb{E}$
3. Aprendemos ao longo do caminho que nenhum algoritmo que apenas troca elementos vizinhos pode ser assintoticamente mais rápido que o Bubblesort (mesmo em média) - o número de inversões é um limite inferior para todos esses algoritmos. Isso se aplica a, por exemplo, Classificação de inserção e Classificação de seleção .

O método geral

Vimos no exemplo que temos que traduzir a estrutura de controle em matemática; Vou apresentar um conjunto típico de regras de tradução. Também vimos que o custo de qualquer subprograma pode depender do estado atual , que é (aproximadamente) os valores atuais das variáveis. Como o algoritmo (geralmente) modifica o estado, o método geral é um pouco complicado de anotar. Se você começar a se sentir confuso, sugiro que você volte ao exemplo ou crie o seu.

Denotamos com o estado atual (imagine-o como um conjunto de atribuições de variáveis). Quando executamos um programa iniciando no estado , acabamos no estado (fornecido termina).$\psi$P$\psi$$\psi / \mathtt{P}$P

• Declarações individuais

  Dada apenas uma declaração S;, você atribui a ela . Isso normalmente será uma função constante.$C_S(\psi)$

• Expressões

  Se você tiver uma expressão Eda forma E1 ∘ E2(por exemplo, uma expressão aritmética em que ∘possa haver adição ou multiplicação, adicione custos recursivamente:

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

  Observe que

  • o custo de operação pode não ser constante, mas depende dos valores de e e$c_{\circ}$$E_1$$E_2$
  • avaliação de expressões pode mudar o estado em vários idiomas,

  então você pode ter que ser flexível com esta regra.

• Seqüência

  Dado um programa Pcomo sequência de programas Q;R, você adiciona os custos ao

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

• Condicionais

  Dado um programa Pdo formulário if A then Q else R end, os custos dependem do estado:

  $\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}$

  Em geral, a avaliação Apode muito bem mudar o estado, daí a atualização para os custos de cada filial.

• For-Loops

  Dado um programa Pdo formulário for x = [x1, ..., xk] do Q end, atribua custos

  $\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\}})$

  onde é o estado antes do processamento para obter valor , ou seja, após a iteração ter sido definida como , ..., .$\psi_i$Qxixx1xi-1

  Observe as constantes extras para manutenção de loop; a variável do loop deve ser criada ( ) e atribuída seus valores ( ). Isso é relevante, pois$c_{\text{init_for}}$$c_{\text{step_for}}$

  • computar o próximo xipode ser caro e
  • um forloop com corpo vazio (por exemplo, depois de simplificar em uma melhor configuração com um custo específico) não terá custo zero se executar iterações.

• While-Loops

  Dado um programa Pdo formulário while A do Q end, atribua custos

  $\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}$

  Ao inspecionar o algoritmo, essa recorrência costuma ser bem representada como uma soma semelhante à dos for-loops.

  Exemplo: considere este pequeno algoritmo:

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

  Ao aplicar a regra, obtemos

  $\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}$

  com alguns custos constantes para as declarações individuais. Assumimos implicitamente que estes não dependem do estado (os valores de e ); isso pode ou não ser verdade na "realidade": pense em transbordamentos!$c_{\dots}$ix

  Agora temos que resolver essa recorrência para . Observamos que nem o número de iterações, nem o custo do corpo do loop dependem do valor de , para que possamos eliminá-lo. Ficamos com esta recorrência:$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}$

  Isso resolve com meios elementares para

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

  reintroduzir o estado completo simbolicamente; se , então .$\psi = \{ \dots, x := 5, \dots\}$$\psi(x) = 5$

• Chamadas de procedimento

  Dado um programa Pdo formulário M(x)para alguns parâmetros em xque Mé um procedimento com o parâmetro (nomeado) p, atribua custos

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

  Observe novamente a constante extra (que pode de fato depender de !). As chamadas de procedimento são caras devido à maneira como são implementadas em máquinas reais e às vezes dominam o tempo de execução (por exemplo, avaliando a recorrência do número de Fibonacci ingenuamente).$c_{\text{call}}$$\psi$

  Descrevo alguns problemas semânticos que você possa ter com o estado aqui. Você desejará distinguir o estado global e o local para chamadas de procedimento. Vamos supor que passamos apenas para o estado global aqui e obtemos Mum novo estado local, inicializado definindo o valor de ppara x. Além disso, xpode ser uma expressão que (geralmente) supomos que seja avaliada antes de ser aprovada.

  Exemplo: considere o procedimento

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

  De acordo com as regras, obtemos:

  $\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*}$

  Observe que desconsideramos o estado global, pois facclaramente não acessa nenhum. Essa recorrência específica é fácil de resolver para

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

Nós cobrimos os recursos de idioma que você encontrará no pseudo-código típico. Cuidado com os custos ocultos ao analisar pseudo-código de alto nível; em caso de dúvida, desdobre. A notação pode parecer complicada e certamente é uma questão de gosto; os conceitos listados não podem ser ignorados. No entanto, com alguma experiência, você poderá ver imediatamente quais partes do estado são relevantes para qual medida de custo, por exemplo, "tamanho do problema" ou "número de vértices". O resto pode ser descartado - isso simplifica significativamente as coisas!

Se você acha que agora isso é muito complicado, saiba: é ! Obter custos exatos de algoritmos em qualquer modelo que seja tão próximo de máquinas reais que permita previsões de tempo de execução (mesmo as relativas) é um esforço árduo. E isso nem sequer considera cache e outros efeitos desagradáveis ​​em máquinas reais.

Portanto, a análise de algoritmos é frequentemente simplificada a ponto de ser matematicamente tratável. Por exemplo, se você não precisar de custos exatos, poderá superestimar ou subestimar a qualquer momento (para limites superiores ou inferiores): reduzir o conjunto de constantes, livrar-se de condicionais, simplificar somas e assim por diante.

Uma nota sobre custo assintótico

O que você normalmente encontrará na literatura e nas redes é a "análise Big-Oh". O termo apropriado é análise assintótica , o que significa que, em vez de derivar custos exatos, como fizemos nos exemplos, você atribui os custos apenas a um fator constante e no limite (grosso modo, "para grandes ").$n$

Isso é (geralmente) justo, pois declarações abstratas têm alguns custos (geralmente desconhecidos) na realidade, dependendo da máquina, sistema operacional e outros fatores, e tempos de execução curtos podem ser dominados pelo sistema operacional que está configurando o processo em primeiro lugar e outros enfeites. Então você fica com alguma perturbação.

Aqui está como a análise assintótica se relaciona com essa abordagem.

1. Identifique operações dominantes (que induzem custos), ou seja, operações que ocorrem com mais frequência (até fatores constantes). No exemplo do Bubblesort, uma opção possível é a comparação na linha 5.

   Como alternativa, vincule todas as constantes para operações elementares pelo respetivo máximo (de cima). mínimo (abaixo) e faça a análise usual.

2. Execute a análise usando contagens de execução desta operação como custo.
3. Ao simplificar, permita estimativas. Apenas permita estimativas de cima se seu objetivo for um limite superior ( ) resp. abaixo, se você quiser limites inferiores ( ).$O$$\Omega$

Certifique-se de entender o significado dos símbolos Landau . Lembre-se de que esses limites existem para todos os três casos ; usar não implica uma análise do pior caso.$O$

Leitura adicional

Existem muitos outros desafios e truques na análise de algoritmos. Aqui estão algumas leituras recomendadas.

• Como chegar ao tempo de execução dos algoritmos?
  Como descrever algoritmos, provar e analisá-los?
• Por que usar comparações em vez de tempo de execução para comparar dois algoritmos?
  Como podemos assumir que operações básicas sobre números levam tempo constante?
  O que constitui uma unidade de tempo na análise de tempo de execução?
• Resolvendo ou aproximando relações de recorrência para sequências de números
• Noções básicas de análise amortizada

Existem muitas perguntas marcadas como análise de algoritmo que usam técnicas semelhantes a essa.

Contagens de declarações de execução

Existe outro método, defendido por Donald E. Knuth em sua série The Art of Computer Programming . Em contraste com a tradução de todo o algoritmo em uma fórmula , ele funciona independentemente da semântica do código no lado "juntando as coisas" e permite ir para um nível mais baixo somente quando necessário, começando pela visualização "olho de águia". Cada declaração pode ser analisada independentemente do restante, levando a cálculos mais claros. No entanto, a técnica se presta bem a códigos bastante detalhados, e não a pseudo-códigos de nível superior.

O método

É bastante simples em princípio:

1. Atribua a cada declaração um nome / número.
2. Atribua cada instrução algum custo .$S_i$$C_i$
3. Determine para cada instrução seu número de execuções .$S_i$$e_i$

4. Calcular custos totais

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

Você pode inserir estimativas e / ou quantidades simbólicas a qualquer momento, enfraquecendo a resp. generalizando o resultado de acordo.

Esteja ciente de que a etapa 3 pode ser arbitrariamente complexa. Geralmente é lá que você precisa trabalhar com estimativas (assintóticas) como " " para obter resultados.$e_{77} \in O(n \log n)$

Exemplo: pesquisa em profundidade

Considere o seguinte algoritmo gráfico-transversal:

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

Assumimos que o gráfico (não direcionado) é fornecido por listas de adjacência nos nós . Seja o número de arestas.$\{0,\dots,n-1\}$$m$

Apenas olhando para o algoritmo, vemos que algumas instruções são executadas com a mesma frequência que outras. Introduzimos alguns espaços reservados , e para as contagens de execução :$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}$

Em particular, pois todas as chamadas recursivas na linha 8 causam uma chamada na linha 3 (e uma é causada pela chamada original de ). Além disso, porque a condição deve ser verificada uma vez por iteração, mas novamente para que seja deixada.$e_8 = e_3-1$foodfs$e_6 = e_5 + e_7$while

É claro que . Agora, durante uma prova de correção, mostraríamos que é executado exatamente uma vez por nó; isto é, . Porém, iteramos sobre todas as listas de adjacências exatamente uma vez e todas as arestas implicam duas entradas no total (uma para cada nó do incidente); obtemos iterações no total. Usando isso, derivamos a seguinte tabela:$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}$

Isso nos leva a custos totais de exatamente

$\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*}$

Instanciando valores adequados para o , podemos derivar custos mais concretos. Por exemplo, se quisermos contar acessos à memória (por palavra), usaríamos$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 pegue

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

Leitura adicional

Veja no final da minha outra resposta .

A análise de algoritmos, como a prova de um teorema, é amplamente uma arte (por exemplo, existem programas simples (como o problema de Collatz ) que não sabemos como analisar). Podemos converter um problema de complexidade de algoritmo em um matemático, conforme respondido de maneira abrangente por Raphael , mas, a fim de expressar um limite ao custo de um algoritmo em termos de funções conhecidas, resta:

1. Use técnicas que conhecemos das análises existentes, como encontrar limites com base nas recorrências que entendemos ou somar / integrais que podemos calcular.
2. Mude o algoritmo para algo que sabemos analisar.
3. Crie uma abordagem completamente nova.