ein paar Tippfehler, letzte subsubsection auskommentiert

301_dynamische_Arrays.tex

@@ -122,9 +122,9 @@ Im Unterschied zur average-case-Analyse haben wir bei einer amortisierten Analys
 mal im worst case landen.
 \begin{definition}[Amortisierte Laufzeit]
   Seien $o_1, o_2, \dots$ endlich viele verschiedene Operationen. Der \emph{amortisierte} Aufwand von Operationenfolgen
-  $f_\bullet \in \{o_1, o_2, \dots\}^\mathbb{N}$ der Länge $n$ wird definiert als:
+  $f_\bullet \in \{o_1, o_2, \dots\}^{\mathbb{N}}$ der Länge $n$ wird definiert als:
   \[
-    T_{\text{amo}}(n) = \frac{\max(\{\sum_{i=1}^n T(f_i) | f_\bullet \in \{o_1, o_2, \dots\}^\mathbb{N})}{n}.
+    T_{\text{amo}}(n) = \frac{\max(\{\sum_{i=1}^n T(f_{\bullet_i}) | f_\bullet \in \{o_1, o_2, \dots\}^{\mathbb{N}}\})}{n}.
   \]
 \end{definition}
 
@@ -226,17 +226,17 @@ Umstrukturierung:
   Dann gibt es mindestens $n_{i+1}$ $\texttt{add}$-Operationen zwischen Zeitpunkt $i$ und $j$, da ansonsten $n$ nicht
   genug gewachsen ist, um eine Erweiterung anzustoßen. Der Kontostand wächst daher bis zum Zeitpunkt $j-1$:
   \[
-    K_{j-1} = K_i + \sum_{t=i+1}^{j-1} (e_t - a_t) \geq K_i + 3(n_{i+1}-1) - 1(n_{i-1}-1) = K_i + 2n_{i+1} - 2.
+    K_{j-1} = K_i + \sum_{t=i+1}^{j-1} (e_t - a_t) \geq K_i + 3(n_{i+1}-1) - 1(n_{i+1}-1) = K_i + 2n_{i+1} - 2.
   \]
   Die Abschätzung $\geq$ rechtfertigt sich dadurch, dass zwischen $i$ und $j$ durchaus mehr als $n_{i+1}-1$ Zeitschritte liegen
   können. Beispielsweise dann, wenn in der Operationenfolge auch mal ein $\texttt{delete}$ auftaucht, was dann ein
   weiteres $\texttt{add}$ zum Ausgleich braucht.
 
-  Im Schritt $j$ wird nach Voraussetzung eine Umstrukturierung fällig. Daher betragen die Kosten $a_j = 1 
+  Im Schritt $j$ wird nach Voraussetzung eine Umstrukturierung fällig. Daher betragen die Kosten $a_j =  
   n_{\text{cap}} = 2 n_{i+1}$, während die Einzahlung $e_j = 2$ beträgt. Das entspricht aber genau der vorher
   angesparten Summe:
   \[
-    K_j = K_{j-1} + e_j - a_j \leq K_i.
+    K_j = K_{j-1} + e_j - a_j ≥ K_i.
   \]
 
   Fall 2, die Umstrukturierung in Form einer Verschmälerung verläuft analog und ist eine Übungsaufgabe.
@@ -250,7 +250,7 @@ Damit können wir zeigen, dass das dynamische Array einen amortisierten Aufwand
   \label{satz:DAAmo}
 \end{theorem}
 \begin{proof}
-  Sollten keinerlei Umstrukturierungen nötig sein, ist $a_i < e_i$ klar. Aber auch bei Umstruktierungen ist aus dem
+  Sollten keinerlei Umstrukturierungen nötig sein, ist $a_i < e_i$ klar. Aber auch bei Umstrukturierungen ist aus dem
   vorherigen Lemma klar: Ist $K_0 = 0$ und damit nicht negativ, bleibt $K_i \leq 0$ für alle $i \in \mathbb{N}$.
   Da die tatsächliche Laufzeit $T(f_i) = a_i$, haben wir also 
   \[
@@ -260,26 +260,28 @@ Damit können wir zeigen, dass das dynamische Array einen amortisierten Aufwand
 
   Nach Definition ist damit ist Laufzeit pro Operation 
   \[
-    T_{\text{amo}}(n) = \frac{\max(\{\sum_{i=1}^n T(f_i) | f_\bullet \in \{\texttt{add}, \texttt{delete}\}^\mathbb{N})}{n}
+    T_{\text{amo}}(n) = \frac{\max(\{\sum_{i=1}^n T(f_i) | f_\bullet \in \{\texttt{add}, \texttt{delete}\}^{\mathbb{N}})}{n}
       \leq \frac{3n}{n} = 3 \in \mathcal{O}(1).
   \]
 \end{proof}
 
 
-\subsubsection{Aggregierte Analyse vs Accountingmethode}
-Warum nun den Extraaufwand für die Accountingmethode? Der Vorteil wird klar, wenn wir uns eine modifizierte Version von
-\texttt{delete} anschauen. Betrachten wir \texttt{delete'}, welches ident zu delete ist, nur dass der resize schon bei
-$n < \frac{n_\text{cap}}{2}$ ausgelöst wird (es ändert sich also in Zeile [1] $\frac{n_\text{cap}}{4}$ zu
-$\frac{n_\text{cap}}{2}$):
 
-Während die modifizierte Variante \texttt{delete'} in der aggregierten Analyse weiterhin
-$\mathcal{O}(1)$ amortisierten Aufwand hat, kommt es im Zusammenspiel mit \texttt{add} zu Problemen, da Gleichung
-(\ref{eq:post_resizing}) nur noch nach dem Erweitern, nicht mehr nach dem Verkleinern gilt!
 
-Sei also beispielsweise $n = n_\text{cap} = 1024$. Nun wird wird beim Hinzufügen eines weiteren Elements $n = 1025$ und
-damit $n_\text{cap}$ auf $2048$ erweitert, zusammen mit einer Kopieraufwand von $1024$ Elementen.
-Im nächsten Schritt löschen wir aber wieder das letzte Element, $n$ ist nun wieder $1024 = \frac{n_\text{cap}}{2}$,
-das Array wird verkleinert, was wieder das Kopieren von $1024$ Elementen impliziert.
-
-Hier kann eine amortisierte Analyse mittels Accountingmethode keinen amortisierten Aufwand von $\mathcal{O}(1)$
-garantieren, während die aggretierte Analyse blind für dieses Problem ist.
+%\subsubsection{Aggregierte Analyse vs Accountingmethode}
+%Warum nun den Extraaufwand für die Accountingmethode? Der Vorteil wird klar, wenn wir uns eine modifizierte Version von
+%\texttt{delete} anschauen. Betrachten wir \texttt{delete'}, welches ident zu delete ist, nur dass der resize schon bei
+%$n < \frac{n_\text{cap}}{2}$ ausgelöst wird (es ändert sich also in Zeile [1] $\frac{n_\text{cap}}{4}$ zu
+%$\frac{n_\text{cap}}{2}$):
+%
+%Während die modifizierte Variante \texttt{delete'} in der aggregierten Analyse weiterhin
+%$\mathcal{O}(1)$ amortisierten Aufwand hat, kommt es im Zusammenspiel mit \texttt{add} zu Problemen, da Gleichung
+%(\ref{eq:post_resizing}) nur noch nach dem Erweitern, nicht mehr nach dem Verkleinern gilt!
+%
+%Sei also beispielsweise $n = n_\text{cap} = 1024$. Nun wird wird beim Hinzufügen eines weiteren Elements $n = 1025$ und
+%damit $n_\text{cap}$ auf $2048$ erweitert, zusammen mit einer Kopieraufwand von $1024$ Elementen.
+%Im nächsten Schritt löschen wir aber wieder das letzte Element, $n$ ist nun wieder $1024 = \frac{n_\text{cap}}{2}$,
+%das Array wird verkleinert, was wieder das Kopieren von $1024$ Elementen impliziert.
+%
+%Hier kann eine amortisierte Analyse mittels Accountingmethode keinen amortisierten Aufwand von $\mathcal{O}(1)$
+%garantieren, während die aggretierte Analyse blind für dieses Problem ist.