Das Projekt hat einen stabilen Zwischenstatus erreicht und ist grundsätzlich inzwischen so aufge-stellt, dass es den prognostizierten Wachstum der Unternehmensdaten mitmachen wird. Algathakann sich etwas zurücklehnen und genießt es, dass ihre Freizeit wieder Normalniveau erreichthat. Bei langen Puzzle-Abenden entspannt sie und kommt dabei fast auf andere Gedanken. Fast. . .Sie grinst und kann sich des Vergleichs nicht verwehren, dass sie es auch im Projekt geschaffthat, all die einzelnen Bestandteile an den richtigen Platz zu bringen – genau wie bei ihrem abend-lichen Vergnügen zur Entspannung.

.

13 Zusammenfassung

Hiccup: Thank you for summing that up.(How to Train Your Dragon, 2010)

Aufbau des Kapitels

13.1 Mengenproblem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

13.2 Sortieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

13.3 Kürzeste Wege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

13.4 Rundreise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

13.5 Maximaler Fluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

13.1 Mengenproblem

Zur Verwaltung von Datenmengen wurden verschiedene, konzeptionell z.T.sehr unterschiedliche Datenstrukturen präsentiert. Tabelle 13.1 vergleichtdie Laufzeiten für die drei wichtigsten Operationen: Suchen, Einfügen undLöschen.

Wir möchten abschließend noch ein paar wenige Daumenregeln liefern,die dem Leser eventuell helfen, für die jeweils aktuelle Anwendungssitua-tion eine passende Datenstruktur zu finden. Wir strukturieren diese Hand-reichung anhand einiger weniger Fragen.

Wie groß ist die Datenmenge? Falls die Größe der Datenmenge. . .

• sehr klein (< ca.100) ist: Ein unsortiertes Feld kann reichen;sonst: ein binärer Suchbaum.

• moderat (< ca.1 000 000) ist: Balancierte Bäume, z.B. AVL-Bäu-me, oder Hash-Tabellen.

• sehr groß (≥ ca.1 000 000) ist und ggf. nicht in den Hauptspei-cher passt: B-Bäume oder erweiterbares Hashing.

Wie groß ist die Dynamik der gespeicherten Elemente? Bei einer hohenDynamik sind Bäume den Hash-Tabellen vorzuziehen, um Rehashingbzw. teure Re-Organisation einer erweiterbaren Hash-Tabelle zu ver-meiden. Liegt gar keine Dynamik vor, kann die Datenstruktur für denZugriff optimiert werden, z.B. als balancierter Baum, optimaler Such-baum oder durch Anpassung der Hash-Funktion zum perfekten Ha-shing ohne Kollisionen.

K. Weicker, N. Weicker, Algorithmen und Datenstrukturen, DOI 10.1007/978-3-8348-2074-7_13, © Springer Fachmedien Wiesbaden 2013

326 Kapitel 13. Zusammenfassung

Tabelle 13.1: Laufzeitenvergleich der Datenstrukturen für das Mengenproblem

Datenstruktur Suchen Einfügen Löschen Anmerkung

unsortiertes Feld O(n) Θ(1) O(n) gilt auch für dynamische Feldersortiertes Feld O(log n)/

O(log log n)1Θ(n) Θ(n) 1 bei Interpolationssuche und

Gleichverteilung

unsortierte Liste O(n) Θ(1) O(n)sortierte Liste O(n) O(n) O(n)Skipliste avg.: O(log n) avg.: O(log n) avg.: O(log n) Worst-Case: O(n)binärer Suchbaum avg.: O(log n) avg.: O(log n) avg.: O(log n) Worst-Case: O(n); dieser tritt bei

vorsortierten Daten einAVL-Baum O(log n) O(log n) O(log n)Hash-Tabelle vorhandener Schlüssel: Θ(1), neuer Schlüssel: 1

1−α bei Brent’s-Algorithmus undFüllgrad α

B-Baum O(log n) O(log n) O(log n) Konstante der Laufzeit hängt vonder Baumtiefe und damit von derOrdnung m ab

Erweiterbares Hashing Θ(1) Ω(1) 2 Θ(1) 3 2 wegen der Vergrößerung derAdresstabelle

3 ohne Verschmelzen vonBlöcken und Verkleinern derAdresstabelle

selbstorganisierte Liste avg.: Θ(1) 4 Θ(1) avg.: Θ(1) 4 4 amortisierte Laufzeit

Was ist über Zugriffswahrscheinlichkeiten der Elemente bekannt?

Liegen stark ungleichgewichtige Zugriffswahrscheinlichkeiten für dieeinzelnen Elemente vor, können sich Techniken wie die selbstorga-nisierte Liste oder für unveränderliche Datenmengen die optimalenSuchbäume lohnen.

Müssen alle Elemente ausgegeben werden? Dann sind Hash-Tabellenkritisch zu hinterfragen – insbesondere wenn eine sortierte Reihenfol-ge der Daten erwartet wird.

Wie wird auf die Elemente zugegriffen? Besondere Regeln, auf welcheElemente zugegriffen wird, wie oft zugegriffen wird und wann Ele-mente entfernt werden, kann andere Datenstrukturen nahe legen. Ein-maliger Zugriff mit Entfernen des Elements entsprechend irgendwel-cher Vorgaben kann beispielsweise durch eine Prioritätswarteschlangenoch besser erfüllt werden.

13.2. Sortieren 327

13.2 Sortieren

Die verschiedenen behandelten Sortieralgorithmen werden mit ihren Lauf-zeiten im Best-, Average- und Worst-Case in der Tabelle 13.2 dargestellt.

Auch bei den Sortieralgorithmen soll mit einigen knappen Fragen eineHandreichung für die Wahl des passenden Algorithmus geliefert werden.

Wie viele Elemente werden sortiert? Ist die Anzahl der zu sortierendenDatenelemente. . .

• klein (< ca. 100): Insertionsort oder Bubblesort.

• groß (< ca. 2 000 000): Quicksort oder Heapsort sind eine guteWahl, aber auch Shellsort oder Radix-Sort können berücksichtigtwerden.

• sehr groß (≥ ca. 2 000 000) und kann nicht im Hauptspeicher ge-halten werden: Mehrphasen-Mergesort, evtl. reicht auch Einfü-gen in einen B-Baum und anschließende sortierte Ausgabe allerElemente

Sind die Daten vorsortiert? Insertionsort hat Vorteile gegenüber anderenVerfahren. Bei Standard-Quicksort kann evtl. der Worst-Case eintre-ten, was durch Randomisierung, d.h. die zufällige Wahl eines Ele-ments im Feld als Pivot verhindert werden kann.

Tabelle 13.2: Laufzeitenvergleich der Sortieralgorithmen

Algorithmus Best-Case Avg.-Case Worst-Case Anmerkung

Bubblesort Θ(n) Θ(n2) Θ(n2) stabilInsertionsort Θ(n) Θ(n2) Θ(n2) stabil, ordnungsverträglich

Shellsort Ω(n · log n) — O(√n3) 1 1 mit Schrittweiten (2i+1 −1); mit anderen

Schrittweiten ist O(3√n4) möglich

Selectionsort Θ(n2) Θ(n2) Θ(n2)Insertionsort (AVL) O(n · log n) O(n · log n) O(n · log n) großer zusätzlicher SpeicherbedarfMergesort Θ(n · log n) Θ(n · log n) Θ(n · log n) zusätzlicher Speicherbedarf, stabilQuicksort Θ(n · log n) Θ(n · log n) Θ(n2) Worst-Case tritt sogar bei sortierten Daten

einHeapsort O(n · log n) O(n · log n) O(n · log n) leicht höhere Konstante als bei QuicksortStraight-Mergesort Θ(n · log n) Θ(n · log n) Θ(n · log n) bessere Laufzeitkonstante als Mergesort,

stabilCountingsort Θ(n+ k) Θ(n+ k) Θ(n+ k) mit der Anzahl k der verschiedenen Schlüs-

sel, stabilRadix-Sort Θ(d · (n+ k)) Θ(d · (n+ k)) Θ(d · (n+ k)) mit d-stelligen Schlüssel über einem k-

elementigen Alphabet, stabilMehrphasen-Mergesort Θ(n · log n) Θ(n · log n) Θ(n · log n)

328 Kapitel 13. Zusammenfassung

Muss der Algorithmus stabil sein? Muss bei gleichen Datenschlüsseln ei-ne vorhandene Vorsortierung gemäß anderer Kriterien erhalten blei-ben, sollten stabile Sortieralgorithmen wie Insertionsort, Radix-SortMergesort oder Straight-Mergesort genutzt werden.

Wie wichtige ist optimale Laufzeit? Handelt es sich um eine Anwendungmit extremen Anforderungen bezüglich der Laufzeit, kann Quicksortüber die Wahl des Pivotelements und mit Insertionsort für kleine Teil-felder noch weiter optimiert werden. Muss jedoch eineΘ(n2)-Laufzeitin jedem Fall verhindert werden, sollte stattdessen Heapsort, Shellsortoder Radix-Sort berücksichtigt werden.

13.3 Kürzeste Wege

Zur Berechnung der kürzesten Wege in einem Graphen wurden drei ver-schiedene Algorithmen vorgestellt, wobei die Fragestellung jeweils eineandere war. So kann mit der Breitensuche nur in Graphen ohne Kanten-gewichte der kürzeste Weg bestimmt werden. Ferner wurde in die Suchenach allen kürzesten Wegen der Knotenpaare mit einem gemeinsamen Start-knoten (Dijkstra-Algorithmus) und in die Betrachtung der kürzesten Wegezwischen allen Knotenpaaren (Floyd-Warshall-Algorithmus und #V-facheAnwendung des Dijkstra-Algorithmus) unterschieden. Die resultierendenLaufzeiten aller betrachteten Varianten sind in Tabelle 13.3 dargestellt.

Abhängig von den Eigenschaften des Graphen können die folgendenHinweise die Wahl eines Algorithmus beeinflussen.

Wie dicht ist der Graph? Für dünne Graphen mit vergleichsweise weni-gen Kanten, genauer: #E ∈ O( (#V)2

log(#V) ), sollte der Dijkstra-Algorithmusmit dem Heap als Prioritätswarteschlange benutzt werden. Dies giltsowohl für den Vergleich zum Dijkstra-Algorithmus mit dem Feld alsauch, mit Einschränkungen aufgrund der Laufzeitkonstanten, für denVergleich mit dem Floyd-Warshall-Algorithmus für alle Knotenpaare.

Tabelle 13.3: Laufzeitenvergleich der Kürzeste-Wege-Algorithmen

Algorithmus ein Startknoten alle Knotenpaare Anmerkung

Breitensuche mitAdjazenzliste

O(#V +#E) O((#V)2 +#V ·#E) mit Anzahl der Kanten als Distanz

Breitensuche mitAdjazenzmatrix

O((#V)2) O((#V)3) mit Anzahl der Kanten als Distanz

Dijkstra mit Feld O((#V)2) O((#V)3)Dijkstra mit Heap O((#V +#E) · log(#V)) O((#V +#E) ·#V · log(#V))Floyd-Warshall — Θ((#V)3) wesentlich kleinere Laufzeitkonstante

13.4. Rundreise 329

Gelten Eigenschaften bezüglich der Gewichte? Bezüglich der Kantenge-wichte sei darauf hingewiesen, dass der Dijkstra-Algorithmus falscheErgebnisse bei negativen Gewichten liefern kann. Hier sollte auf denFloyd-Warshall-Algorithmus oder hier nicht vorgestellte Algorithmenwie den Bellman-Ford-Algorithmus zurückgegriffen werden. Für sehrgroße Graphen, deren Gewichte alle sehr ähnlich sind, kann es sinn-voll sein, über die Breitensuche eine Näherungslösung zu erzeugen.

Weist der Graph andere Besonderheiten auf? Für verschiedene Graph-eigenschaften existieren schnellere Algorithmen als die hier präsen-tierten. Ein Beispiel wurde in Aufgabe 5.3 für azyklische Graphenthematisiert.

Der Bellman-Ford-Algorithmus hat die Laufzeit O(#V ·#E) und gehtauf die Veröffentlichungen von Bellman (1958) und Ford & Fulkerson(1962) zurück.

13.4 Rundreise

Das Rundreiseproblem ist das schwierigste der in diesem Buch betrachtetenProblem. Tatsächlich ist es NP-vollständig. Daher wird in der Tabelle 13.4neben der Laufzeit auch die Genauigkeit der Algorithmen verglichen.

Eine Entscheidung, welcher Algorithmus genutzt wird, hängt in der Re-gel von der Größe der betrachteten Probleminstanz und der verfügbarenZeit bzw. der gewünschten Genauigkeit des Ergebnisses ab.

Auch hier gibt es teilweise verblüffende Algorithmen für Spezialfälle.So wurde beispielsweise für zweidimensionale geometrische Rundreisepro-bleme in Aufgabe 8.6 ein Algorithmus mit Laufzeit O(n2) skizziert, der diekürzeste bitonische Rundreisen berechnet (vgl. Seite 224).

Tabelle 13.4: Vergleich der Algorithmen für das Rundreiseproblem

Algorithmus Laufzeit Genauigkeit Anmerkung

Backtracking Θ((n−1)!) exakt durch Branch-and-Bound sind bessere Lauf-zeiten möglich

Einfache Greedy-Heuristik Θ(n2) keine GarantieMSB-Approximation O(n2) maximal doppelte

Längenur falls die Dreiecksungleichung für dieGewichte gilt

Evolutionärer Algorithmus keine Garantie keine Garantie in der Praxis oft die besten Ergebnisse

330 Kapitel 13. Zusammenfassung

13.5 Maximaler Fluss

Für das Problem des maximalen Flusses wurden lediglich zwei Variantendesselben Algorithmus vorgestellt, die in Tabelle 13.5 verglichen werden.Es wird jeweils eine Speicherung des Graphen als Adjazenzliste vorausge-setzt.

Tabelle 13.5: Vergleich der Laufzeiten der Maximaler-Fluss-Algorithmen

Algorithmus Laufzeit Anmerkung

Ford-Fulkerson O( fmax ·#E) problematisch ist der Einfluss des maxima-len Flusses auf die Laufzeit

Edmonds-Karp O(#V · (#E)2)

Für die zunächst betrachteten Flussprobleme unter Berücksichtigung derÜbermittlungsdauer/Reisezeit pro Kante sind die Laufzeiten der obigen Al-gorithmen allerdings kaum akzeptabel, da bei der Umwandlung des Pro-blems allein schon die Anzahl der Knoten auf tmax ·#V anwächst (mit demZeithorizont tmax).

Es gibt eine Vielzahl an wesentlich schnelleren Algorithmen. So errei-chen Varianten der Push-Relabel-Algorithmen Laufzeiten wie Θ((#V)3).

Die Push-Relabel-Algorithmen wurden von Goldberg & Tarjan(1988b) eingeführt, wobei insbesondere die Heuristiken nach (Cher-kassky & Goldberg, 1997) für die Laufzeit hilfreich sind.

So. Das war’s. Alle Konzepte des Buchs wurden in diesem Kapitel noch-mals in einen problembezogenen Zusammenhang gebracht und um Emp-fehlungen für die Auswahl der passenden Datenstruktur bzw. des passen-den Algorithmus ergänzt.