From 6231b88d99219d6be0bcd264e6a3b4d714180cd3 Mon Sep 17 00:00:00 2001 From: Florian Unger <florian.unger@posteo.net> Date: Sun, 16 May 2021 23:17:25 +0200 Subject: [PATCH] ein paar Tippfehler, letzte subsubsection auskommentiert --- 301_dynamische_Arrays.tex | 46 ++++++++++++++++++++------------------- 1 file changed, 24 insertions(+), 22 deletions(-) diff --git a/301_dynamische_Arrays.tex b/301_dynamische_Arrays.tex index 7f694da..99e458a 100644 --- a/301_dynamische_Arrays.tex +++ b/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. -- GitLab