Lecture 7 Flashcards
(23 cards)
Welches Grundproblem tritt bei einem statischen Array auf, wenn pushBack öfter als die ursprüngliche Feldgröße ausgeführt wird?
Das Feld ist voll, weil seine Länge w fest beim Anlegen gewählt wurde und nicht automatisch wächst.
Was ist die erste (naive) Strategie, ein statisches Array dynamisch zu vergrößern?
Bei Überlauf ein neues Array der Länge w + c (konstanter Zuwachs c) anlegen und alle Elemente kopieren.
Wie hoch sind die Gesamtkosten für n pushBack-Operationen mit diesem konstanten Zuwachs?
Θ(n²), weil nach jeweils c Einfügungen ein Kopiervorgang von wachsender Größe Θ(w) erfolgt, was eine arithmetische Reihe ergibt.
Welche Wachstumsstrategie verbessert dieses Ergebnis drastisch?
Bei Überlauf das Array auf die doppelte Größe 2 w reallokieren (geometrisches Wachstum).
Wann wird das Array in dieser Strategie wieder verkleinert?
Wenn die Zahl der Elemente n auf höchstens w/4 sinkt, wird die Kapazität auf w/2 reduziert.
Welche beiden Konstanten steuern das Verhalten der Implementierung?
β = 2 (Wachstumsfaktor) und α = 4 (maximaler Speicheroverhead).
Was übernimmt die Methode reallocate(new_w)?
Sie legt ein neues statisches Feld der Größe new_w an, kopiert alle n Elemente hinein und ersetzt das alte Feld.
Welche Worst-Case-Kosten hat ein einzelner pushBack, wenn es zu einem reallocate kommt?
Θ(n), da alle n bestehenden Elemente kopiert werden müssen.
Warum sagt diese Worst-Case-Betrachtung allein wenig über die Praxis aus?
Weil teure Re-Allokationen selten auftreten und viele pushBack-Aufrufe nur O(1) kosten; entscheidend ist daher die amortisierte Analyse.
Formuliere das Lemma zur amortisierten Laufzeit der dynamischen Feldoperationen.
Für ein anfangs leeres Feld kann jede Folge von n pushBack und popBack in O(n) Zeit verarbeitet werden ⇒ amortisiert O(1) pro Operation.
Wie werden die Kosten in der Zeugenzuordnung (credit scheme) verteilt?
Eine Vergrößerung (n → 2n) wird den vorangegangenen n/2 pushBack s zugerechnet; eine Verkleinerung (n → n/2) den letzten n/4 popBack s.
Warum bekommt jede Einfüge- oder Löschoperation höchstens einmal Re-Allokationskosten zugewiesen?
Weil eine Operation immer nur dem nächsten Re-Allokationsereignis zugeordnet wird; danach liegt sie außerhalb des betrachteten Intervalls.
Warum sorgt die Halbierungsregel dafür, dass sich reallocate-Aufwand nicht „aufschaukelt“?
Nach einer Halbierung wachsen die Elemente erst wieder bis w/2 → genügend günstige Operationen, bevor erneut kopiert werden muss.
Was ist das Ziel einer amortisierten Analyse?
Die durchschnittlichen Kosten pro Operation einer ganzen Folge von Operationen abzuschätzen, auch wenn einzelne Operationen sehr teuer sein können.
Grundidee der Accounting- (Token-) Methode in einem Satz?
Verteile bei jeder Operation eine feste Anzahl Token (≙ kosten), die sofortige Arbeit bezahlen und ein Guthaben für künftige teure Operationen ansammeln.
Welche zwei Regeln muss eine Token-Verteilung erfüllen, damit der amortisierte Beweis korrekt ist?
Nicht-Negativitätsinvariante: Das gespeicherte Token-Guthaben darf nie unter 0 fallen; (2) Die Summe aller verteilten Token deckt die Summe der realen (tatsächlichen) Kosten.
Wie viele Token werden einem einzelnen pushBack in einem dynamisch verdoppelnden Feld zugewiesen?
3 Token: 1 Token für den tatsächlichen Einfügezugriff und 2 Token als Guthaben für das zukünftige Kopieren seiner Zelle beim nächsten Re-Allocate. (Ergebnis aus der in den Folien vorgerechneten Verteilung)
Warum reicht es, dass ein Element beim Vergrößern nur einmal kopiert wird?
Nach der Verdoppelung liegt jedes Element in der ersten Hälfte des neuen Felds und wird erst beim übernächsten Überlauf erneut kopiert; die genau dafür beiseitegelegten Token sind dann bereits vorhanden
Was bedeutet der Begriff “Token-Laufzeit” in diesem Kontext?
Das ist die amortisierte Kostenangabe in Token pro Operation; sie spiegelt, wie viele Token jede Operation maximal „ausgeben“ darf, um alle realen Kosten langfristig zu decken.
Wie wird in der Accounting-Methode das Verkleinern (Halbieren) eines Feldes bezahlt?
Jeder popBack, der später zur Bedingung α·n ≤ w führt, hinterlegt einen Token; sobald genug Token gesammelt sind (≈ n/4 Stück), finanzieren sie das Kopieren von n/2 Elementen in das halb so große Feld.
Wie zeigt man mit der Token-Methode formal, dass m beliebige pushBack/popBack höchstens O(m) Zeit kosten?
Man beweist
(i) jede Operation verteilt ≤ konstante Token → O(m) Token gesamt;
(ii) aufgrund der Invariante deckt diese Tokensumme alle realen Kopier- und Zugriffskosten → Gesamtkosten ≤ konstante · m.
Nenne ein klassisches Beispiel (aus VL 6), bei dem amortisierte Analyse O(1) ergibt, obwohl der Worst Case O(n) ist.
Inkrementieren einer n-Bit-Binärzahl (increment): Worst Case = Flip aller Bits (O(n)), aber erwartete bzw. amortisierte Kosten pro Aufruf = O(1).
Weshalb ist amortisierte Analyse kein Ersatz für Worst-Case-Analyse?
Sie macht keine Aussage für einzelne Operationen: In zeitkritischen Echtzeit-Systemen kann ein seltener, aber sehr teurer Schritt dennoch problematisch sein. Amortisierte Resultate gelten nur über Sequenzen.
