Wie kann man Algorithmen beschreiben, beweisen und analysieren?

Bevor ich The Art of Computer Programming (TAOCP) gelesen habe , habe ich diese Fragen nicht gründlich untersucht. Ich würde Pseudocode verwenden, um Algorithmen zu beschreiben, sie zu verstehen und die Laufzeit nur über Wachstumsordnungen zu schätzen. Das TAOCP ändert meine Meinung gründlich.

TAOCP verwendet Englisch gemischt mit Schritten und Gehe zu, um den Algorithmus zu beschreiben, und verwendet Flussdiagramme, um den Algorithmus leichter darzustellen. Es scheint auf niedrigem Niveau zu sein, aber ich finde, dass es einige Vorteile gibt, insbesondere bei Flussdiagrammen, die ich oft ignoriert habe. Wir können jeden der Pfeile mit einer Aussage über den aktuellen Stand der Dinge zum Zeitpunkt der Berechnung beschriften und einen induktiven Beweis für den Algorithmus erstellen. Der Autor sagt:

Es ist die Behauptung des Autors, dass wir wirklich verstehen, warum ein Algorithmus nur dann gültig ist, wenn wir den Punkt erreichen, an dem unser Verstand alle Behauptungen implizit ausgefüllt hat, wie dies in Abb. 4 getan wurde.

Ich habe solche Sachen nicht erlebt. Ein weiterer Vorteil ist, dass wir zählen können, wie oft jeder Schritt ausgeführt wird. Mit Kirchhoffs erstem Gesetz lässt sich das leicht überprüfen. Ich habe die Laufzeit nicht genau analysiert, sodass bei der Schätzung der Laufzeit möglicherweise weggelassen wurden.$\pm1$

Die Analyse von Wachstumsordnungen ist manchmal nutzlos. Beispielsweise können wir keine Quicksortierung von Heapsortierung unterscheiden, da sie alle , wobei E X die erwartete Anzahl der Zufallsvariablen X ist. Daher sollten wir die Konstante E analysieren ( T 1 ( n ) ) = A 1 n lg n + B 1 n + O ( log n $E(T(n))=\Theta(n\log n)$$EX$$X$$E(T_1(n))=A_1n\lg n+B_1n+O(\log n)$und , so können wir T 1 und T 2 besser vergleichen. Und manchmal sollten wir auch andere Größen wie Abweichungen vergleichen. Nur eine grobe Analyse der Wachstumsordnungen der Laufzeit reicht nicht aus. Wie TAOCP$E(T_2(n))=A_2\lg n+B_2n+O(\log n)$$T_1$$T_2$ übersetzt die Algorithmen in Assemblersprache und berechnet die Laufzeit. Es ist zu schwer für mich, deshalb möchte ich einige Techniken kennen, um die Laufzeit etwas gröber zu analysieren, was auch für übergeordnete Sprachen wie C, C ++ nützlich ist oder Pseudocodes.

Und ich möchte wissen, welcher Beschreibungsstil hauptsächlich in Forschungsarbeiten verwendet wird und wie diese Probleme zu behandeln sind.

Es gibt eine Vielzahl von realisierbaren Ansätzen. Welches am besten geeignet ist, hängt davon ab

• was du versuchst zu zeigen,
• wie viel Detail Sie wollen oder brauchen.

Wenn es sich bei dem Algorithmus um einen allgemein bekannten Algorithmus handelt, den Sie als Unterroutine verwenden, bleiben Sie häufig auf einer höheren Ebene. Wenn der Algorithmus das zu untersuchende Hauptobjekt ist, möchten Sie wahrscheinlich detaillierter werden. Dasselbe gilt für Analysen: Wenn Sie eine grobe Obergrenze für die Laufzeit benötigen, verfahren Sie anders, als wenn Sie eine genaue Anzahl von Anweisungen wünschen.

Ich werde Ihnen drei Beispiele für den bekannten Algorithmus Mergesort geben, die dies hoffentlich veranschaulichen.

Hohes Level

Der Algorithmus Mergesort nimmt eine Liste, teilt sie in zwei (ungefähr) gleich lange Teile auf, rekursiert auf diese Teillisten und führt die (sortierten) Ergebnisse zusammen, so dass das Endergebnis sortiert wird. Bei einzelnen oder leeren Listen wird die Eingabe zurückgegeben.

Dieser Algorithmus ist offensichtlich ein korrekter Sortieralgorithmus. Das Aufteilen und Zusammenführen der Liste kann jeweils in der Zeit implementiert werden , was eine Wiederholung für die Worst-Case-Laufzeit T ( n ) = 2 T ( n ) ergibt$\Theta(n)$. Durch das MasterTheorem, diese auswertet bisT(n)egr& THgr;(nlogn).$T(n) = 2T\left(\frac{n}{2}\right) + \Theta(n)$$T(n) \in \Theta(n\log n)$

Mittleres Level

Der Algorithmus Mergesort ist durch folgenden Pseudocode gegeben:

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
}

Wir beweisen die Richtigkeit durch Induktion. Für Listen der Länge Null oder Eins ist der Algorithmus trivial korrekt. Nehmen Sie als Induktionshypothese an, dass mergesortbei Listen mit einer Länge von höchstens für ein willkürliches, aber festes natürliches n > 1 die Leistung korrekt ist . Nun sei L eine Liste der Länge n + 1 . Durch Induktionshypothese, und halten (nicht abnehmend) sortierte Versionen der ersten resp. zweite Hälfte von L nach den rekursiven Aufrufen. Daher wählt die Schleife in jeder Iteration das kleinste Element aus, das noch nicht untersucht wurde, und hängt es an ; somit handelt es sich um eine nicht zunehmend sortierte Liste, die alle Elemente von enthält$n$$n>1$$L$$n+1$leftright$L$whileresultresultleftund right. Die Umkehrung ist eine nicht abnehmend sortierte Version von , bei der es sich um das zurückgegebene - und gewünschte - Ergebnis handelt.$L$

Zählen wir zur Laufzeit Elementvergleiche und Listenoperationen (die die Laufzeit asymptotisch dominieren). Listen mit einer Länge von weniger als zwei verursachen keine. Für Listen mit einer Länge von haben wir die Operationen, die durch das Vorbereiten der Eingaben für die rekursiven Aufrufe verursacht werden, diejenigen aus den rekursiven Aufrufen selbst sowie die Schleife und eine . Beide rekursiven Parameter können mit jeweils höchstens n Listenoperationen berechnet werden. Die Schleife wird genau n Mal ausgeführt und jede Iteration verursacht höchstens einen Elementvergleich und genau zwei Listenoperationen. Das Finale kann implementiert werden, um 2 $n>1$whilereverse$n$while$n$reverse$2n$Listenoperationen - Jedes Element wird aus der Eingabe entfernt und in die Ausgabeliste eingefügt. Daher erfüllt die Anzahl der Vorgänge die folgende Wiederholung:

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

Da eindeutig nicht abnimmt, ist es ausreichend, n = 2 k für asymptotisches Wachstum zu berücksichtigen . In diesem Fall vereinfacht sich die Wiederholung zu$T$$n=2^k$

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

Durch den Master - Satz erhalten wir , die zur Laufzeit erstreckt .$T \in \Theta(n \log n)$mergesort

Ultra-Low-Level

Betrachten Sie diese (verallgemeinerte) Implementierung von Mergesort in 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+

Dies schließt bereits Beweise für die Richtigkeit und Kündigung ein. Finden Sie einen (fast) vollständigen Korrektheitsbeweis hier .

Für die "Laufzeit", also die Anzahl der Vergleiche, kann eine ähnliche Wiederholung wie im vorherigen Abschnitt eingerichtet werden. Anstatt den Hauptsatz zu verwenden und die Konstanten zu vergessen, können Sie ihn auch analysieren, um eine Näherung zu erhalten, die asymptotisch der wahren Größe entspricht. Die vollständige Analyse finden Sie in [1]; Hier ist eine grobe Übersicht (sie muss nicht unbedingt zum Isabelle / HOL-Code passen):

Wie oben ist die Wiederholung für die Anzahl der Vergleiche

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

where $e_n$ is the number of comparisons needed for merging the partial results². In order to get rid of the floors and ceils, we perform a case distinction over whether $n$ is even:

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

Using nested forward/backward differences of $f_n$ and $e_n$ we get that

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

The sum matches the right-hand side of Perron's formula. We define the Dirichlet generating series of $\Delta\kern-.2em\nabla f_k$ as

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

which together with Perron's formula leads us to

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

Evaluation of $\boxminus(s)$ depends on which case is analysed. Other than that, we can -- after some trickery -- apply the residue theorem to get

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

where $A$ is a periodic function with values in $[-1,-0.9]$.

1. Mellin transforms and asymptotics: the mergesort recurrence by Flajolet and Golin (1992)
2. Best case: $e_n = \left\lfloor\frac{n}{2}\right\rfloor$
   Worst case: $e_n = n-1$
   Average case: $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}$

Dijkstra's "A discipline of Programming" is all about analyzing and proving algorithms and designing for provability. In the preface to that book, Dijkstra explains how a very simple constructed mini-language that is properly designed to be analyzed suffices to explain many algorithms formally:

When starting on a book like this, one is immediately faced with the question: "Which programming language am I going to use?", and this is not a mere question of presentation! A most important, but also a most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language, this influence is -- whether we like it or not -- an influence on our thinking habits. Having analyzed that influence to the best of my knowledge, I had come to the conclusion that none of the existing programming languages, nor a subset of them, would suit my purpose; on the other hand I knew myself so unready for the design of a new programming language that I had taken a vow not to do so for the next five years, and I had a most distinct feeling that that period had not yet elapsed! (Prior to that, among many other things, this monograph had to be written.) I have tried to resolve this conflict by only designing a mini-language suitable for my purposes, by making only those commitments that seemed unavoidable and sufficiently justified.

Later he explains just how small he managed to get his mini-language.

I owe the reader an explanation why I have kept the mini-language so small that it does not even contain procedures and recursion. ... The point is that I felt no need of them in order to get my message across, viz. how a carefully chose separation of concerns is essential for the design of in all respect, high-quality programs; the modest tools of the mini-language gave us already more than enough latitude for nontrivial, yet very satisfactory designs.