Como descrever algoritmos, provar e analisá-los?

Antes de ler A arte da programação de computadores (TAOCP) , não considerei essas questões profundamente. Eu usaria pseudo-código para descrever algoritmos, entendê-los e estimar o tempo de execução apenas sobre ordens de crescimento. O TAOCP muda completamente de idéia.

O TAOCP usa inglês misturado com etapas e vá para descrever o algoritmo e usa fluxogramas para visualizar o algoritmo mais rapidamente. Parece baixo, mas acho que há algumas vantagens, especialmente no fluxograma, que eu ignorei bastante. Podemos rotular cada uma das setas com uma afirmação sobre o estado atual das coisas no momento em que o cálculo atravessa essa seta e fazer uma prova indutiva do algoritmo. O autor diz:

É a afirmação do autor que realmente entendemos por que um algoritmo é válido somente quando atingimos o ponto em que nossas mentes preencheram implicitamente todas as afirmações, como foi feito na Fig.4.

Eu não experimentei essas coisas. Outra vantagem é que podemos contar o número de vezes que cada etapa é executada. É fácil verificar a primeira lei de Kirchhoff. Não analisei exatamente o tempo de execução; portanto, $\pm1$ pode ter sido omitido quando eu estava estimando o tempo de execução.

A análise das ordens de crescimento às vezes é inútil. Por exemplo, não podemos distinguir quicksort de heapsort porque eles são todos $E(T(n))=\Theta(n\log n)$ , onde $EX$ é o número esperado de variável aleatória $X$ , portanto devemos analisar a constante, digamos, $E(T_1(n))=A_1n\lg n+B_1n+O(\log n)$e $E(T_2(n))=A_2\lg n+B_2n+O(\log n)$ , assim podemos comparar $T_1$ e $T_2$ melhor. E também, às vezes, devemos comparar outras quantidades, como variações. Apenas uma análise aproximada das ordens de crescimento do tempo de execução não é suficiente. Como TAOCP traduz os algoritmos para a linguagem assembly e calcula o tempo de execução. É muito difícil para mim, então eu quero conhecer algumas técnicas para analisar o tempo de execução um pouco mais a fundo, o que também é útil para linguagens de nível superior, como C, C ++ ou pseudo-códigos.

E quero saber que estilo de descrição é usado principalmente em trabalhos de pesquisa e como tratar esses problemas.

Existe uma enorme variedade de abordagens viáveis. Qual é o mais adequado depende da

• o que você está tentando mostrar,
• quantos detalhes você deseja ou precisa.

Se o algoritmo é amplamente conhecido e usado como sub-rotina, você geralmente permanece em um nível superior. Se o algoritmo for o principal objeto sob investigação, você provavelmente desejará ser mais detalhado. O mesmo pode ser dito para análises: se você precisar de um limite superior de tempo de execução aproximado, proceda de maneira diferente de quando deseja contagens precisas de instruções.

Vou dar três exemplos para o conhecido algoritmo Mergesort, que espero ilustrar isso.

Alto nível

O algoritmo Mergesort pega uma lista, divide-a em duas (aproximadamente) partes igualmente longas, repete-se nessas listas parciais e mescla os resultados (classificados) para que o resultado final seja classificado. Em listas singleton ou vazias, ele retorna a entrada.

Esse algoritmo é obviamente um algoritmo de classificação correto. Dividir a lista e mesclá-la podem ser implementadas no tempo , o que nos dá uma recorrência para o pior tempo de execução T ( n ) = 2 T ( $\Theta(n)$. Pelo teorema do mestre, isso é avaliado comoT(n)∈Θ(nlogn).$T(n) = 2T\left(\frac{n}{2}\right) + \Theta(n)$$T(n) \in \Theta(n\log n)$

Nível médio

O algoritmo Mergesort é dado pelo seguinte pseudocódigo:

procedure mergesort(l : List) {
  if ( l.length < 2 ) {
    return l
  }

  left  = mergesort(l.take(l.length / 2)
  right = mergesort(l.drop(l.length / 2)
  result = []

  while ( left.length > 0 || right.length > 0 ) {
    if ( right.length == 0 || (left.length > 0 && left.head <= right.head) ) {
      result = left.head :: result
      left = left.tail
    }
    else {
      result = right.head :: result
      right = right.tail
    }
  }

  return result.reverse
}

mergesort$n$$n>1$$L$$n+1$leftright$L$whileresultresultleftright$L$

$n>1$whilereverse$n$while$n$reverse$2n$operações de lista - cada elemento é removido da entrada e colocado na lista de saída. Portanto, a contagem de operações cumpre a seguinte recorrência:

$\qquad \begin{align}T(0) = T(1) &= 0 \\ T(n) &\leq T\left(\left\lceil\frac{n}{2}\right\rceil\right) + T\left(\left\lfloor\frac{n}{2}\right\rfloor\right) + 7n\end{align}$

$T$$n=2^k$

$\qquad \begin{align}T(0) = T(1) &= 0 \\ T(n) &\leq 2T\left(\frac{n}{2}\right) + 7n\end{align}$

$T \in \Theta(n \log n)$mergesort

Nível ultra baixo

Considere esta implementação (generalizada) do Mergesort em Isabelle / HOL :

types dataset  =  "nat * string"

fun leq :: "dataset \<Rightarrow> dataset \<Rightarrow> bool" where
   "leq (kx::nat, dx) (ky, dy) = (kx \<le> ky)"

fun merge :: "dataset list \<Rightarrow> dataset list \<Rightarrow> dataset list" where
"merge [] b = b" |
"merge a [] = a" |
"merge (a # as) (b # bs) = (if leq a b then a # merge as (b # bs) else b # merge (a # as) bs)"

function (sequential) msort :: "dataset list \<Rightarrow> dataset list" where
  "msort []  = []" |
  "msort [x] = [x]" |
  "msort l   = (let mid = length l div 2 in merge (msort (take mid l)) (msort (drop mid l)))"
by pat_completeness auto
  termination
  apply (relation "measure length")
by simp+

Isso já inclui provas de bem-definição e rescisão. Encontre aqui uma prova de correção (quase) completa .

Para o "tempo de execução", ou seja, o número de comparações, é possível configurar uma recorrência semelhante à da seção anterior. Em vez de usar o teorema mestre e esquecer as constantes, você também pode analisá-lo para obter uma aproximação assintoticamente igual à quantidade verdadeira. Você pode encontrar a análise completa em [1]; Aqui está um esboço (não necessariamente se encaixa no código Isabelle / HOL):

Como acima, a recorrência do número de comparações é

$\qquad \begin{align}f_0 = f_1 &= 0 \\ f_n &= f_{\left\lceil\frac{n}{2}\right\rceil} + f_{\left\lfloor\frac{n}{2}\right\rfloor} + e_n\end{align}$

$e_n$$n$

$\qquad \displaystyle \begin{cases} f_{2m} &= 2f_m + e_{2m} \\ f_{2m+1} &= f_m + f_{m+1} + e_{2m+1} \end{cases}$

$f_n$$e_n$

$\qquad \displaystyle \sum\limits_{k=1}^{n-1} (n-k) \cdot \Delta\kern-.2em\nabla f_k = f_n - nf_1$

$\Delta\kern-.2em\nabla f_k$

$\qquad \displaystyle W(s) = \sum\limits_{k\geq 1} \Delta\kern-.2em\nabla f_k k^{-s} = \frac{1}{1-2^{-s}} \cdot \underbrace{\sum\limits_{k \geq 1} \frac{\Delta\kern-.2em\nabla e_k}{k^s}}_{=:\ \boxminus(s)}$

que, juntamente com a fórmula da Perron, nos leva a

$\qquad \displaystyle f_n = nf_1 + \frac{n}{2\pi i} \int\limits_{3-i\infty}^{3+i\infty} \frac{\boxminus(s)n^s}{(1-2^{-s})s(s+1)}ds$ .

A avaliação de depende de qual caso é analisado. Fora isso, podemos - depois de alguns truques - aplicar o teorema do resíduo para obter$\boxminus(s)$

$\qquad \displaystyle f_n \sim n \cdot \log_2(n) + n \cdot A(\log_2(n)) + 1$

onde é uma função periódica com valores em .$A$$[-1,-0.9]$

1. Transformações e assintóticos de Mellin: a recorrência da fusão de Flajolet e Golin (1992)
2. Melhor caso: Pior caso: Caso médio:en=n-1en=n-⌊$e_n = \left\lfloor\frac{n}{2}\right\rfloor$
   $e_n = n-1$
   $e_n = n - \frac{\left\lfloor\frac{n}{2}\right\rfloor}{\left\lceil\frac{n}{2}\right\rceil + 1} - \frac{\left\lceil\frac{n}{2}\right\rceil}{\left\lfloor\frac{n}{2}\right\rfloor + 1}$

A "Disciplina de Programação" de Dijkstra trata de analisar e provar algoritmos e projetar para provabilidade. No prefácio desse livro, Dijkstra explica como uma minilinguagem construída muito simples, projetada adequadamente para ser analisada, é suficiente para explicar formalmente muitos algoritmos:

Ao iniciar um livro como este, imediatamente se depara com a pergunta: "Qual linguagem de programação eu vou usar?", E isso não éuma mera questão de apresentação! Um aspecto mais importante, mas também mais evasivo, de qualquer ferramenta é sua influência nos hábitos daqueles que se treinam em seu uso. Se a ferramenta é uma linguagem de programação, essa influência é - gostemos ou não - de influenciar nossos hábitos de pensamento. Tendo analisado essa influência da melhor maneira possível, cheguei à conclusão de que nenhuma das linguagens de programação existentes, nem um subconjunto delas, atenderia ao meu propósito; por outro lado, eu me conhecia tão pouco para o design de uma nova linguagem de programação que prometi não fazê-lo pelos próximos cinco anos e tive uma sensação muito distinta de que esse período ainda não havia passado! (Antes disso, entre muitas outras coisas, essa monografia tinha que ser escrita.

Mais tarde, ele explica o quão pequeno conseguiu obter sua mini-linguagem.

Devo ao leitor uma explicação de por que mantive a minilíngua tão pequena que nem sequer contém procedimentos e recursão. ... O ponto é que eu não sentia necessidade deles para transmitir minha mensagem, viz. como uma separação de preocupações cuidadosamente escolhida é essencial para a concepção de todos os aspectos, programas de alta qualidade; as ferramentas modestas da mini-língua já nos deram latitude mais do que suficiente para projetos não triviais, mas muito satisfatórios.