Alda - User contributions [en]

Main Page

2012-10-04T16:14:37Z

Ukoethe: /* Übungsaufgaben */

== Vorlesung Algorithmen und Datenstrukturen ==

Dr. Ullrich Köthe, Universität Heidelberg, Sommersemester 2012

Die Vorlesung findet '''dienstags''' und '''donnerstags''' jeweils um 14:15 Uhr in INF 227 (KIP), HS 2 statt.

=== Klausur und Nachprüfung ===

Die '''Abschlussklausur''' findet am Dienstag, dem 31.7.2012 von 10:00 bis 12:00 Uhr im HS 1 in INF 306 statt. Zur Klausur wird zugelassen, wer mindestens 50% der Übungspunkte erreicht. (Hinweis: Sie benötigen einen Lichtbildausweis, um sich bei der Klausur zu indentifizieren!) Die Nachklausur finet am 4.10.2012, 10:00 bis 12:00 im großen Seminarraum des HCI, Speyerer Str. 6 statt.
* '''[[Media:2012-Klausur-1.pdf|Ergebnis der Klausur vom 31.7.2012]]''' (anonymisiert)
* '''[[Media:2012-Klausur-2.pdf|Ergebnis der 2. Klausur vom 4.10.2012]]''' (anonymisiert)


=== Leistungsnachweise ===
Für alle Leistungsnachweise ist die erfolgreiche Teilnahme an den Übungen erforderlich. Für Leistungspunkte bzw. den Klausurschein muss außerdem die schriftliche Prüfung bestanden werden. Einzelheiten werden noch bekanntgegeben.


=== Übungsbetrieb ===
* Termine und Räume:
** Mo 14:00 - 16:00 Uhr, INF 227 (KIP), Seminarraum 2.402 (Tutor: Sven Ebser [mailto:sven@ebsers.de sven AT ebsers.de])
** Di 9:00 - 11:00 Uhr, INF 227 (KIP), Seminarraum 2.403 (Tutor: Christoph Koke [mailto:koke@kip.uni-heidelberg.de koke AT kip.uni-heidelberg.de])
** Di 11:00 - 13:00 Uhr, INF 227 (KIP), Seminarraum 2.403 (Tutor: Kai Karius [mailto:kai.karius@googlemail.com kai.karius AT googlemail.com])
** Mi 14:00 - 16:00 Uhr, INF 227 (KIP), Seminarraum 2.401 (Tutor: Stephan Meister [mailto:stephan.meister@iwr.uni-heidelberg.de stephan.meister AT iwr.uni-heidelberg.de])
* Die Übungsgruppen werden über [https://www.mathi.uni-heidelberg.de/muesli/lecture/view/169 MÜSLI] verwaltet. Dort erfolgt auch die Anmeldung.

* [[Main Page#Übungsaufgaben|Übungsaufgaben]] (Übungszettel mit Abgabetermin, Musterlösungen). Lösungen bitte per Email an den jeweiligen Übungsgruppenleiter.
* Zur Klausur wird zugelassen, wer mindestens 50% der Übungspunkte erreicht. Außerdem muss jeder Teilnehmer eine Lösung (bzw. einen Teil davon) in der Übungsgruppe vorrechnen.
* Durch das Lösen von Bonusaufgaben und gute Mitarbeit in den Übungen können Sie Zusatzpunkte erlangen. Zusatzpunkte werden auch vergeben, wenn Sie größere Verbesserungen an diesem Wiki vornehmen. Damit solche Verbesserungen der richtigen Person zugeordnet werden, sollten Sie dafür ein eigenes Wiki-Login verwenden, das Ihnen Stephan Meister oder Ullrich Köthe auf Anfrage gerne einrichten.

=== Prüfungsvorbereitung ===

Zur Hilfe bei der Prüfungsvorbereitung hat Andreas Fay [http://de.neemoy.com/quizcategories/31/ Quizfragen] erstellt.

=== Literatur ===

* R. Sedgewick: Algorithmen (empfohlen für den ersten Teil, bis einschließlich Graphenalgorithmen)
* J. Kleinberg, E.Tardos: Algorithm Design (empfohlen für den zweiten Teil, einschließlich Graphenalgorithmen)
* T. Cormen, C. Leiserson, R.Rivest: Algorithmen - eine Einführung (empfohlen zum Thema Komplexität)
* Wikipedia und andere Internetseiten (sehr gute Seiten über viele Algorithmen und Datenstrukturen)

=== Gliederung der Vorlesung ===

# [[Einführung]] (17.4.2012)
#* Definition von Algorithmen und Datenstrukturen, Geschichte
#* Fundamentale Algorithmen: create, assign, copy, swap, compare etc.
#* Fundamentale Datenstrukturen: Zahlen, Container, Handles
#* Python-Grundlagen

# [[Container]] (19.4.2012)
#* Anforderungen von Algorithmen an Container
#* Einteilung der Container
#* Grundlegende Container: Array, verkettete Liste, Stack und Queue
#* Sequenzen und Intervalle (Ranges)

# [[Sortieren]] (24. und 26.4.2012)
#* Spezifikation des Sortierproblems
#* Selection Sort und Insertion Sort
#* Merge Sort
#* Quick Sort und seine Varianten
#* Vergleich der Anzahl der benötigten Schritte
#* Laufzeitmessung in Python

# [[Korrektheit]] (3. und 8.5.2012)
#* Definition von Korrektheit, Algorithmen-Spezifikation
#* Korrektheitsbeweise versus Testen
#* Vor- und Nachbedingungen, Invarianten, Programming by contract
#* Testen, Execution paths, Unit Tests in Python
#* Ausnahmen (exceptions) und Ausnahmebehandlung in Python

# [[Effizienz]] (10. und 15.5.2012)
#* Laufzeit und Optimierung: Innere Schleife, Caches, locality of reference
#* Laufzeit versus Komplexität
#* Landausymbole (O-Notation, <math>\Omega</math>-Notation, <math>\Theta</math>-Notation), Komplexitätsklassen
#* Bester, schlechtester, durchschnittlicher Fall
#* Amortisierte Komplexität

# [[Suchen]] (22. und 24.5.2012)
#* Sequentielle Suche
#* Binäre Suche in sortierten Arrays, Medianproblem
#* Suchbäume, balancierte Bäume
#* selbst-balancierende Bäume, Rotationen
#* Komplexität der Suche

# [[Sortieren in linearer Zeit]] (29.5.2012)
#* Permutationen
#* Sortieren als Suchproblem
#* Bucket Prinzip, Bucket Sort

# [[Prioritätswarteschlangen]] (31.5.2012)
#* Heap-Datenstruktur
#* Einfüge- und Löschoperationen
#* Heapsort
#* Komplexität des Heaps

# [[Assoziative Arrays]] (5.6.2012)
#* Datenstruktur-Dreieck für assoziative Arrays
#* Definition des abstrakten Datentyps
#* JSON-Datenformat
#* Realisierung durch sequentielle Suche und durch Suchbäume

# [[Hashing und Hashtabellen]] (5.6.und 12.6.2012)
#* Implementation assoziativer Arrays mit Bäumen
#* Hashing und Hashfunktionen
#* Implementation assoziativer Arrays als Hashtabelle mit linearer Verkettung bzw. mit offener Adressierung
#* Anwendung des Hashing zur String-Suche: Rabin-Karp-Algorithmus

# [[Iteration versus Rekursion]] (14.6.2012)
#* Typen der Rekursion und ihre Umwandlung in Iteration
#* Auflösung rekursiver Formeln mittels Master-Methode und Substitutionsmethode

# [[Generizität]] (19.6.2012)
#* Abstrakte Datentypen, Typspezifikation
#* Required Interface versus Offered Interface
#* Adapter und Typattribute, Funktoren
#* Beispiel: Algebraische Konzepte und Zahlendatentypen
#* Operator overloading in Python

# [[Graphen und Graphenalgorithmen]] (21.6. bis 5.7.2012)
#* Einführung
#* Graphendatenstrukturen, Adjazenzlisten und Adjazenzmatrizen
#* Gerichtete und ungerichtete Graphen
#* Vollständige Graphen
#* Planare Graphen, duale Graphen
#* Pfade, Zyklen
#* Tiefensuche und Breitensuche
#* Zusammenhang, Komponenten
#* Gewichtete Graphen
#* Minimaler Spannbaum
#* Kürzeste Wege, Best-first search (Dijkstra)
#* Most-Promising-first search (A*)
#* Problem des Handlungsreisenden, exakte Algorithmen (erschöpfende Suche, Branch-and-Bound-Methode) und Approximationen
#* Erfüllbarkeitsproblem, Darstellung des 2-SAT-Problems durch gerichtete Graphen, stark zusammenhängende Komponenten












# [[Randomisierte Algorithmen]] (10. und 12.7.2012)
#* Zufallszahlen, Zyklenlänge, Pitfalls
#* Zufallszahlengeneratoren: linear congruential generator, Mersenne Twister
#* Randomisierte vs. deterministische Algorithmen
#* Las Vegas vs. Monte Carlo Algorithmen
#* Beispiel für Las Vegas: Randomisiertes Quicksort
#* Beispiele für Monte Carlo: Randomisierte Lösung des k-SAT Problems
#* RANSAC-Algorithmus, Erfolgswahrscheinlichkeit, Vergleich mit analytischer Optimierung (Methode der kleinsten Quadrate)

# [[Greedy-Algorithmen und Dynamische Programmierung]] (17.7.2012)
#* Prinzipien, Aufwandsreduktion in Entscheidungsbäumen
#* bereits bekannte Algorithmen: minimale Spannbäume nach Kruskal, kürzeste Wege nach Dijkstra
#* Beispiel: Interval Scheduling Problem und Weighted Interval Scheduling Problem
#* Beweis der Optimalität beim Scheduling Problem: "greedy stays ahead"-Prinzip, Directed Acyclic Graph bei dynamischer Programmierung

# [[NP-Vollständigkeit]] (19.7.2012)
#* die Klassen P und NP
#* NP-Vollständigkeit und Problemreduktion

# Reserve und/oder Wiederholung (24. und 26.7.2012)

== Übungsaufgaben ==

zur Zeit nicht freigeschaltet.
<!-----
(im PDF Format). Die Abgabe erfolgt am angegebenen Tag bis 14:00 Uhr per Email an den jeweiligen Übungsgruppenleiter. Bei Abgabe bis zum folgenden Montag 11:00 Uhr werden noch 50% der erreichten Punkte angerechnet. Danach wird die Musterlösung freigeschaltet. Erreichbare Punkte (ohne Bonusaufgaben): 466.

# [[Media:Übung-1.pdf|Übung]] (Abgabe 24.4.2012) und [[Media:Uebung-1-Musterloesung.pdf|Musterlösung]]
#* Python-Tutorial
#* Sieb des Eratosthenes
#* Wert- und Referenzsemantik
#* Dynamisches Array
# [[Media:Uebung-2.pdf|Übung]] (Abgabe 3.5.2012) und [[Media:Uebung-2-Musterloesung.pdf|Musterlösung]]
#* Sortieren: Implementation und Geschwindigkeitsvergleich (Diagramme in Abhängigkeit von der Problemgröße)
#* Entwicklung eines Gewinnalgorithmus für ein Spiel
#* Bonus: Dynamisches Array mit verringertem Speicherverbrauch
# [[Media:Uebung-3.pdf|Übung]] (Abgabe 10.5.2012) und [[Media:Uebung-3-Musterlösung.pdf|Musterlösung]]
#* Experimente zur Effektivität von Unit Tests
#* Bestimmung von Pi mit dem Algorithmus von Archimedes
#* Deque-Datenstruktur: Vor- und Nachbedingungen der Operationen, Implementation und Unit Tests
# [[Media:Uebung-4.pdf|Übung]] (Abgabe '''Montag''' 21.5.2012) und [[Media:muster_blatt4.pdf|Musterlösung]]
#* Theoretische Aufgaben zur Komplexität
#* Amortisierte Komplexität von array.append()
#* Optimierung der Matrizenmultiplikation
# [[Media:Uebung-5.pdf|Übung]] (31.5.2012) und [[Media:muster_blatt5.pdf|Musterlösung]]
#* Implementation und Analyse eines Binärbaumes
#* Anwendung: einfacher Taschenrechner
# [[Media:Uebung-6.pdf|Übung]] (Abgabe '''Freitag''' 8.6.2012) und [[Media:muster_blatt6.pdf|Musterlösung]]
#* Treap-Datenstruktur: Verbindung von Suchbaum und Heap
#* Anwendung: Worthäufigkeiten (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/die-drei-musketiere.txt die-drei-musketiere.txt]. Die Zeichenkodierung in diesem File ist Latin-1.)
#* BucketSort
# [[Media:Uebung-7.pdf|Übung]] (Abgabe 14.6.2012) und [[Media:muster_blatt07.pdf|Musterlösung]]
#* Absichtliche Konstruktion von Kollisionen für eine Hashfunktion
#* Übungen zum Assoziativen Array und zum JSON-Format: Cocktail-Datenbank (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/cocktails.json cocktails.json]. Die Zeichenkodierung in diesem File ist UTF-8.)
# [[Media:Uebung-8.pdf|Übung]] (Abgabe 21.6.2012) und [[Media:muster_blatt8.pdf|Musterlösung]]
#* Übungen zu Rekursion und Iteration: Fibonaccizahlen, Koch-Schneeflocke, Komplexität rekursiver Algorithmen, Umwandlung von Rekursion in Iteration
# [[Media:Uebung-9.pdf|Übung]] (Abgabe 28.6.2012) und [[Media:muster_blatt9.pdf|Musterlösung]]
#* Planare Graphen: Aufstellen von Adjazenzmatrizen und Adjazenzlisten, obere Schranke für die Zahl der Kanten
#* Übungen zur Generizität: Sortieren mit veränderter Ordnung, Iterator für Tiefensuche
# [[Media:Uebung-10.pdf|Übung]] (Abgabe 5.7.2012) und [[Media:muster_blatt10.pdf|Musterlösung]]
#* Fortgeschrittene Graphenaufgaben: Erzeugen einer perfekten Hashfunktion, Routenplaner (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/entfernungen.json entfernungen.json]. Die Zeichenkodierung in diesem File ist UTF-8.)
# [[Media:Uebung-11.pdf|Übung]] (Abgabe 12.7.2012) und [[Media:muster_blatt11.pdf|Musterlösung]] sowie schöne [[Media:ballungsgebiete.pdf|Visualisierung der Ballungsgebiete]] von Thorben Kröger
#* Fortgeschrittene Graphenaufgaben 2: Clusterung mittels minimaler Spannbäume, Bildverarbeitung mit Graphen (Dazu benötigen Sie wieder das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/entfernungen.json entfernungen.json] sowie die Files [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/cells.pgm cells.pgm] und [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/pgm.py pgm.py].)
# [[Media:Uebung-12.pdf|Übung]] (Abgabe 19.7.2012) und [[Media:muster_blatt12.pdf|Musterlösung]]
#* Erfüllbarkeitsproblem, Anwendung: Heim- und Auswärtsspiele im Fussball (Dazu benötigen sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/bundesliga-paarungen-12-13.json bundesliga-paarungen-12-13.json].)
#* Randomisierte Algorithmen: RANSAC für Kreise (Dazu benötigen sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/noisy-circles.txt noisy-circles.txt].)
# [[Media:Bonusuebung.pdf|Übung (Bonus)]] (Achtung: Abgabe bereits am Dienstag, 24.7.2012)
#* Greedy-Algorithmus
#* Weg durch einen Graphen
#* Wiederholungsaufgaben für die Klausur
---!>

== Sonstiges ==
* [[Gnuplot| Gnuplot Kurztutorial]]
* [[Git Kurztutorial]]
* [[neue Startseite|mögliche neue Startseite]]

Main Page

2012-10-04T16:04:57Z

Ukoethe: /* Klausur und Nachprüfung */

== Vorlesung Algorithmen und Datenstrukturen ==

Dr. Ullrich Köthe, Universität Heidelberg, Sommersemester 2012

Die Vorlesung findet '''dienstags''' und '''donnerstags''' jeweils um 14:15 Uhr in INF 227 (KIP), HS 2 statt.

=== Klausur und Nachprüfung ===

Die '''Abschlussklausur''' findet am Dienstag, dem 31.7.2012 von 10:00 bis 12:00 Uhr im HS 1 in INF 306 statt. Zur Klausur wird zugelassen, wer mindestens 50% der Übungspunkte erreicht. (Hinweis: Sie benötigen einen Lichtbildausweis, um sich bei der Klausur zu indentifizieren!) Die Nachklausur finet am 4.10.2012, 10:00 bis 12:00 im großen Seminarraum des HCI, Speyerer Str. 6 statt.
* '''[[Media:2012-Klausur-1.pdf|Ergebnis der Klausur vom 31.7.2012]]''' (anonymisiert)
* '''[[Media:2012-Klausur-2.pdf|Ergebnis der 2. Klausur vom 4.10.2012]]''' (anonymisiert)


=== Leistungsnachweise ===
Für alle Leistungsnachweise ist die erfolgreiche Teilnahme an den Übungen erforderlich. Für Leistungspunkte bzw. den Klausurschein muss außerdem die schriftliche Prüfung bestanden werden. Einzelheiten werden noch bekanntgegeben.


=== Übungsbetrieb ===
* Termine und Räume:
** Mo 14:00 - 16:00 Uhr, INF 227 (KIP), Seminarraum 2.402 (Tutor: Sven Ebser [mailto:sven@ebsers.de sven AT ebsers.de])
** Di 9:00 - 11:00 Uhr, INF 227 (KIP), Seminarraum 2.403 (Tutor: Christoph Koke [mailto:koke@kip.uni-heidelberg.de koke AT kip.uni-heidelberg.de])
** Di 11:00 - 13:00 Uhr, INF 227 (KIP), Seminarraum 2.403 (Tutor: Kai Karius [mailto:kai.karius@googlemail.com kai.karius AT googlemail.com])
** Mi 14:00 - 16:00 Uhr, INF 227 (KIP), Seminarraum 2.401 (Tutor: Stephan Meister [mailto:stephan.meister@iwr.uni-heidelberg.de stephan.meister AT iwr.uni-heidelberg.de])
* Die Übungsgruppen werden über [https://www.mathi.uni-heidelberg.de/muesli/lecture/view/169 MÜSLI] verwaltet. Dort erfolgt auch die Anmeldung.

* [[Main Page#Übungsaufgaben|Übungsaufgaben]] (Übungszettel mit Abgabetermin, Musterlösungen). Lösungen bitte per Email an den jeweiligen Übungsgruppenleiter.
* Zur Klausur wird zugelassen, wer mindestens 50% der Übungspunkte erreicht. Außerdem muss jeder Teilnehmer eine Lösung (bzw. einen Teil davon) in der Übungsgruppe vorrechnen.
* Durch das Lösen von Bonusaufgaben und gute Mitarbeit in den Übungen können Sie Zusatzpunkte erlangen. Zusatzpunkte werden auch vergeben, wenn Sie größere Verbesserungen an diesem Wiki vornehmen. Damit solche Verbesserungen der richtigen Person zugeordnet werden, sollten Sie dafür ein eigenes Wiki-Login verwenden, das Ihnen Stephan Meister oder Ullrich Köthe auf Anfrage gerne einrichten.

=== Prüfungsvorbereitung ===

Zur Hilfe bei der Prüfungsvorbereitung hat Andreas Fay [http://de.neemoy.com/quizcategories/31/ Quizfragen] erstellt.

=== Literatur ===

* R. Sedgewick: Algorithmen (empfohlen für den ersten Teil, bis einschließlich Graphenalgorithmen)
* J. Kleinberg, E.Tardos: Algorithm Design (empfohlen für den zweiten Teil, einschließlich Graphenalgorithmen)
* T. Cormen, C. Leiserson, R.Rivest: Algorithmen - eine Einführung (empfohlen zum Thema Komplexität)
* Wikipedia und andere Internetseiten (sehr gute Seiten über viele Algorithmen und Datenstrukturen)

=== Gliederung der Vorlesung ===

# [[Einführung]] (17.4.2012)
#* Definition von Algorithmen und Datenstrukturen, Geschichte
#* Fundamentale Algorithmen: create, assign, copy, swap, compare etc.
#* Fundamentale Datenstrukturen: Zahlen, Container, Handles
#* Python-Grundlagen

# [[Container]] (19.4.2012)
#* Anforderungen von Algorithmen an Container
#* Einteilung der Container
#* Grundlegende Container: Array, verkettete Liste, Stack und Queue
#* Sequenzen und Intervalle (Ranges)

# [[Sortieren]] (24. und 26.4.2012)
#* Spezifikation des Sortierproblems
#* Selection Sort und Insertion Sort
#* Merge Sort
#* Quick Sort und seine Varianten
#* Vergleich der Anzahl der benötigten Schritte
#* Laufzeitmessung in Python

# [[Korrektheit]] (3. und 8.5.2012)
#* Definition von Korrektheit, Algorithmen-Spezifikation
#* Korrektheitsbeweise versus Testen
#* Vor- und Nachbedingungen, Invarianten, Programming by contract
#* Testen, Execution paths, Unit Tests in Python
#* Ausnahmen (exceptions) und Ausnahmebehandlung in Python

# [[Effizienz]] (10. und 15.5.2012)
#* Laufzeit und Optimierung: Innere Schleife, Caches, locality of reference
#* Laufzeit versus Komplexität
#* Landausymbole (O-Notation, <math>\Omega</math>-Notation, <math>\Theta</math>-Notation), Komplexitätsklassen
#* Bester, schlechtester, durchschnittlicher Fall
#* Amortisierte Komplexität

# [[Suchen]] (22. und 24.5.2012)
#* Sequentielle Suche
#* Binäre Suche in sortierten Arrays, Medianproblem
#* Suchbäume, balancierte Bäume
#* selbst-balancierende Bäume, Rotationen
#* Komplexität der Suche

# [[Sortieren in linearer Zeit]] (29.5.2012)
#* Permutationen
#* Sortieren als Suchproblem
#* Bucket Prinzip, Bucket Sort

# [[Prioritätswarteschlangen]] (31.5.2012)
#* Heap-Datenstruktur
#* Einfüge- und Löschoperationen
#* Heapsort
#* Komplexität des Heaps

# [[Assoziative Arrays]] (5.6.2012)
#* Datenstruktur-Dreieck für assoziative Arrays
#* Definition des abstrakten Datentyps
#* JSON-Datenformat
#* Realisierung durch sequentielle Suche und durch Suchbäume

# [[Hashing und Hashtabellen]] (5.6.und 12.6.2012)
#* Implementation assoziativer Arrays mit Bäumen
#* Hashing und Hashfunktionen
#* Implementation assoziativer Arrays als Hashtabelle mit linearer Verkettung bzw. mit offener Adressierung
#* Anwendung des Hashing zur String-Suche: Rabin-Karp-Algorithmus

# [[Iteration versus Rekursion]] (14.6.2012)
#* Typen der Rekursion und ihre Umwandlung in Iteration
#* Auflösung rekursiver Formeln mittels Master-Methode und Substitutionsmethode

# [[Generizität]] (19.6.2012)
#* Abstrakte Datentypen, Typspezifikation
#* Required Interface versus Offered Interface
#* Adapter und Typattribute, Funktoren
#* Beispiel: Algebraische Konzepte und Zahlendatentypen
#* Operator overloading in Python

# [[Graphen und Graphenalgorithmen]] (21.6. bis 5.7.2012)
#* Einführung
#* Graphendatenstrukturen, Adjazenzlisten und Adjazenzmatrizen
#* Gerichtete und ungerichtete Graphen
#* Vollständige Graphen
#* Planare Graphen, duale Graphen
#* Pfade, Zyklen
#* Tiefensuche und Breitensuche
#* Zusammenhang, Komponenten
#* Gewichtete Graphen
#* Minimaler Spannbaum
#* Kürzeste Wege, Best-first search (Dijkstra)
#* Most-Promising-first search (A*)
#* Problem des Handlungsreisenden, exakte Algorithmen (erschöpfende Suche, Branch-and-Bound-Methode) und Approximationen
#* Erfüllbarkeitsproblem, Darstellung des 2-SAT-Problems durch gerichtete Graphen, stark zusammenhängende Komponenten












# [[Randomisierte Algorithmen]] (10. und 12.7.2012)
#* Zufallszahlen, Zyklenlänge, Pitfalls
#* Zufallszahlengeneratoren: linear congruential generator, Mersenne Twister
#* Randomisierte vs. deterministische Algorithmen
#* Las Vegas vs. Monte Carlo Algorithmen
#* Beispiel für Las Vegas: Randomisiertes Quicksort
#* Beispiele für Monte Carlo: Randomisierte Lösung des k-SAT Problems
#* RANSAC-Algorithmus, Erfolgswahrscheinlichkeit, Vergleich mit analytischer Optimierung (Methode der kleinsten Quadrate)

# [[Greedy-Algorithmen und Dynamische Programmierung]] (17.7.2012)
#* Prinzipien, Aufwandsreduktion in Entscheidungsbäumen
#* bereits bekannte Algorithmen: minimale Spannbäume nach Kruskal, kürzeste Wege nach Dijkstra
#* Beispiel: Interval Scheduling Problem und Weighted Interval Scheduling Problem
#* Beweis der Optimalität beim Scheduling Problem: "greedy stays ahead"-Prinzip, Directed Acyclic Graph bei dynamischer Programmierung

# [[NP-Vollständigkeit]] (19.7.2012)
#* die Klassen P und NP
#* NP-Vollständigkeit und Problemreduktion

# Reserve und/oder Wiederholung (24. und 26.7.2012)

== Übungsaufgaben ==

(im PDF Format). Die Abgabe erfolgt am angegebenen Tag bis 14:00 Uhr per Email an den jeweiligen Übungsgruppenleiter. Bei Abgabe bis zum folgenden Montag 11:00 Uhr werden noch 50% der erreichten Punkte angerechnet. Danach wird die Musterlösung freigeschaltet. Erreichbare Punkte (ohne Bonusaufgaben): 466.

# [[Media:Übung-1.pdf|Übung]] (Abgabe 24.4.2012) und [[Media:Uebung-1-Musterloesung.pdf|Musterlösung]]
#* Python-Tutorial
#* Sieb des Eratosthenes
#* Wert- und Referenzsemantik
#* Dynamisches Array
# [[Media:Uebung-2.pdf|Übung]] (Abgabe 3.5.2012) und [[Media:Uebung-2-Musterloesung.pdf|Musterlösung]]
#* Sortieren: Implementation und Geschwindigkeitsvergleich (Diagramme in Abhängigkeit von der Problemgröße)
#* Entwicklung eines Gewinnalgorithmus für ein Spiel
#* Bonus: Dynamisches Array mit verringertem Speicherverbrauch
# [[Media:Uebung-3.pdf|Übung]] (Abgabe 10.5.2012) und [[Media:Uebung-3-Musterlösung.pdf|Musterlösung]]
#* Experimente zur Effektivität von Unit Tests
#* Bestimmung von Pi mit dem Algorithmus von Archimedes
#* Deque-Datenstruktur: Vor- und Nachbedingungen der Operationen, Implementation und Unit Tests
# [[Media:Uebung-4.pdf|Übung]] (Abgabe '''Montag''' 21.5.2012) und [[Media:muster_blatt4.pdf|Musterlösung]]
#* Theoretische Aufgaben zur Komplexität
#* Amortisierte Komplexität von array.append()
#* Optimierung der Matrizenmultiplikation
# [[Media:Uebung-5.pdf|Übung]] (31.5.2012) und [[Media:muster_blatt5.pdf|Musterlösung]]
#* Implementation und Analyse eines Binärbaumes
#* Anwendung: einfacher Taschenrechner
# [[Media:Uebung-6.pdf|Übung]] (Abgabe '''Freitag''' 8.6.2012) und [[Media:muster_blatt6.pdf|Musterlösung]]
#* Treap-Datenstruktur: Verbindung von Suchbaum und Heap
#* Anwendung: Worthäufigkeiten (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/die-drei-musketiere.txt die-drei-musketiere.txt]. Die Zeichenkodierung in diesem File ist Latin-1.)
#* BucketSort
# [[Media:Uebung-7.pdf|Übung]] (Abgabe 14.6.2012) und [[Media:muster_blatt07.pdf|Musterlösung]]
#* Absichtliche Konstruktion von Kollisionen für eine Hashfunktion
#* Übungen zum Assoziativen Array und zum JSON-Format: Cocktail-Datenbank (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/cocktails.json cocktails.json]. Die Zeichenkodierung in diesem File ist UTF-8.)
# [[Media:Uebung-8.pdf|Übung]] (Abgabe 21.6.2012) und [[Media:muster_blatt8.pdf|Musterlösung]]
#* Übungen zu Rekursion und Iteration: Fibonaccizahlen, Koch-Schneeflocke, Komplexität rekursiver Algorithmen, Umwandlung von Rekursion in Iteration
# [[Media:Uebung-9.pdf|Übung]] (Abgabe 28.6.2012) und [[Media:muster_blatt9.pdf|Musterlösung]]
#* Planare Graphen: Aufstellen von Adjazenzmatrizen und Adjazenzlisten, obere Schranke für die Zahl der Kanten
#* Übungen zur Generizität: Sortieren mit veränderter Ordnung, Iterator für Tiefensuche
# [[Media:Uebung-10.pdf|Übung]] (Abgabe 5.7.2012) und [[Media:muster_blatt10.pdf|Musterlösung]]
#* Fortgeschrittene Graphenaufgaben: Erzeugen einer perfekten Hashfunktion, Routenplaner (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/entfernungen.json entfernungen.json]. Die Zeichenkodierung in diesem File ist UTF-8.)
# [[Media:Uebung-11.pdf|Übung]] (Abgabe 12.7.2012) und [[Media:muster_blatt11.pdf|Musterlösung]] sowie schöne [[Media:ballungsgebiete.pdf|Visualisierung der Ballungsgebiete]] von Thorben Kröger
#* Fortgeschrittene Graphenaufgaben 2: Clusterung mittels minimaler Spannbäume, Bildverarbeitung mit Graphen (Dazu benötigen Sie wieder das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/entfernungen.json entfernungen.json] sowie die Files [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/cells.pgm cells.pgm] und [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/pgm.py pgm.py].)
# [[Media:Uebung-12.pdf|Übung]] (Abgabe 19.7.2012) und [[Media:muster_blatt12.pdf|Musterlösung]]
#* Erfüllbarkeitsproblem, Anwendung: Heim- und Auswärtsspiele im Fussball (Dazu benötigen sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/bundesliga-paarungen-12-13.json bundesliga-paarungen-12-13.json].)
#* Randomisierte Algorithmen: RANSAC für Kreise (Dazu benötigen sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/noisy-circles.txt noisy-circles.txt].)
# [[Media:Bonusuebung.pdf|Übung (Bonus)]] (Achtung: Abgabe bereits am Dienstag, 24.7.2012)
#* Greedy-Algorithmus
#* Weg durch einen Graphen
#* Wiederholungsaufgaben für die Klausur

== Sonstiges ==
* [[Gnuplot| Gnuplot Kurztutorial]]
* [[Git Kurztutorial]]
* [[neue Startseite|mögliche neue Startseite]]

Main Page

2012-10-04T16:04:34Z

Ukoethe: /* Klausur und Nachprüfung */

== Vorlesung Algorithmen und Datenstrukturen ==

Dr. Ullrich Köthe, Universität Heidelberg, Sommersemester 2012

Die Vorlesung findet '''dienstags''' und '''donnerstags''' jeweils um 14:15 Uhr in INF 227 (KIP), HS 2 statt.

=== Klausur und Nachprüfung ===

Die '''Abschlussklausur''' findet am Dienstag, dem 31.7.2012 von 10:00 bis 12:00 Uhr im HS 1 in INF 306 statt. Zur Klausur wird zugelassen, wer mindestens 50% der Übungspunkte erreicht. (Hinweis: Sie benötigen einen Lichtbildausweis, um sich bei der Klausur zu indentifizieren!). Die Nachklausur finet am 4.10.2012, 10:00 bis 12:00 im großen Seminarraum des HCI, Speyerer Str. 6 statt.
* '''[[Media:2012-Klausur-1.pdf|Ergebnis der Klausur vom 31.7.2012]]''' (anonymisiert)
* '''[[Media:2012-Klausur-2.pdf|Ergebnis der 2. Klausur vom 4.10.2012]]''' (anonymisiert)


=== Leistungsnachweise ===
Für alle Leistungsnachweise ist die erfolgreiche Teilnahme an den Übungen erforderlich. Für Leistungspunkte bzw. den Klausurschein muss außerdem die schriftliche Prüfung bestanden werden. Einzelheiten werden noch bekanntgegeben.


=== Übungsbetrieb ===
* Termine und Räume:
** Mo 14:00 - 16:00 Uhr, INF 227 (KIP), Seminarraum 2.402 (Tutor: Sven Ebser [mailto:sven@ebsers.de sven AT ebsers.de])
** Di 9:00 - 11:00 Uhr, INF 227 (KIP), Seminarraum 2.403 (Tutor: Christoph Koke [mailto:koke@kip.uni-heidelberg.de koke AT kip.uni-heidelberg.de])
** Di 11:00 - 13:00 Uhr, INF 227 (KIP), Seminarraum 2.403 (Tutor: Kai Karius [mailto:kai.karius@googlemail.com kai.karius AT googlemail.com])
** Mi 14:00 - 16:00 Uhr, INF 227 (KIP), Seminarraum 2.401 (Tutor: Stephan Meister [mailto:stephan.meister@iwr.uni-heidelberg.de stephan.meister AT iwr.uni-heidelberg.de])
* Die Übungsgruppen werden über [https://www.mathi.uni-heidelberg.de/muesli/lecture/view/169 MÜSLI] verwaltet. Dort erfolgt auch die Anmeldung.

* [[Main Page#Übungsaufgaben|Übungsaufgaben]] (Übungszettel mit Abgabetermin, Musterlösungen). Lösungen bitte per Email an den jeweiligen Übungsgruppenleiter.
* Zur Klausur wird zugelassen, wer mindestens 50% der Übungspunkte erreicht. Außerdem muss jeder Teilnehmer eine Lösung (bzw. einen Teil davon) in der Übungsgruppe vorrechnen.
* Durch das Lösen von Bonusaufgaben und gute Mitarbeit in den Übungen können Sie Zusatzpunkte erlangen. Zusatzpunkte werden auch vergeben, wenn Sie größere Verbesserungen an diesem Wiki vornehmen. Damit solche Verbesserungen der richtigen Person zugeordnet werden, sollten Sie dafür ein eigenes Wiki-Login verwenden, das Ihnen Stephan Meister oder Ullrich Köthe auf Anfrage gerne einrichten.

=== Prüfungsvorbereitung ===

Zur Hilfe bei der Prüfungsvorbereitung hat Andreas Fay [http://de.neemoy.com/quizcategories/31/ Quizfragen] erstellt.

=== Literatur ===

* R. Sedgewick: Algorithmen (empfohlen für den ersten Teil, bis einschließlich Graphenalgorithmen)
* J. Kleinberg, E.Tardos: Algorithm Design (empfohlen für den zweiten Teil, einschließlich Graphenalgorithmen)
* T. Cormen, C. Leiserson, R.Rivest: Algorithmen - eine Einführung (empfohlen zum Thema Komplexität)
* Wikipedia und andere Internetseiten (sehr gute Seiten über viele Algorithmen und Datenstrukturen)

=== Gliederung der Vorlesung ===

# [[Einführung]] (17.4.2012)
#* Definition von Algorithmen und Datenstrukturen, Geschichte
#* Fundamentale Algorithmen: create, assign, copy, swap, compare etc.
#* Fundamentale Datenstrukturen: Zahlen, Container, Handles
#* Python-Grundlagen

# [[Container]] (19.4.2012)
#* Anforderungen von Algorithmen an Container
#* Einteilung der Container
#* Grundlegende Container: Array, verkettete Liste, Stack und Queue
#* Sequenzen und Intervalle (Ranges)

# [[Sortieren]] (24. und 26.4.2012)
#* Spezifikation des Sortierproblems
#* Selection Sort und Insertion Sort
#* Merge Sort
#* Quick Sort und seine Varianten
#* Vergleich der Anzahl der benötigten Schritte
#* Laufzeitmessung in Python

# [[Korrektheit]] (3. und 8.5.2012)
#* Definition von Korrektheit, Algorithmen-Spezifikation
#* Korrektheitsbeweise versus Testen
#* Vor- und Nachbedingungen, Invarianten, Programming by contract
#* Testen, Execution paths, Unit Tests in Python
#* Ausnahmen (exceptions) und Ausnahmebehandlung in Python

# [[Effizienz]] (10. und 15.5.2012)
#* Laufzeit und Optimierung: Innere Schleife, Caches, locality of reference
#* Laufzeit versus Komplexität
#* Landausymbole (O-Notation, <math>\Omega</math>-Notation, <math>\Theta</math>-Notation), Komplexitätsklassen
#* Bester, schlechtester, durchschnittlicher Fall
#* Amortisierte Komplexität

# [[Suchen]] (22. und 24.5.2012)
#* Sequentielle Suche
#* Binäre Suche in sortierten Arrays, Medianproblem
#* Suchbäume, balancierte Bäume
#* selbst-balancierende Bäume, Rotationen
#* Komplexität der Suche

# [[Sortieren in linearer Zeit]] (29.5.2012)
#* Permutationen
#* Sortieren als Suchproblem
#* Bucket Prinzip, Bucket Sort

# [[Prioritätswarteschlangen]] (31.5.2012)
#* Heap-Datenstruktur
#* Einfüge- und Löschoperationen
#* Heapsort
#* Komplexität des Heaps

# [[Assoziative Arrays]] (5.6.2012)
#* Datenstruktur-Dreieck für assoziative Arrays
#* Definition des abstrakten Datentyps
#* JSON-Datenformat
#* Realisierung durch sequentielle Suche und durch Suchbäume

# [[Hashing und Hashtabellen]] (5.6.und 12.6.2012)
#* Implementation assoziativer Arrays mit Bäumen
#* Hashing und Hashfunktionen
#* Implementation assoziativer Arrays als Hashtabelle mit linearer Verkettung bzw. mit offener Adressierung
#* Anwendung des Hashing zur String-Suche: Rabin-Karp-Algorithmus

# [[Iteration versus Rekursion]] (14.6.2012)
#* Typen der Rekursion und ihre Umwandlung in Iteration
#* Auflösung rekursiver Formeln mittels Master-Methode und Substitutionsmethode

# [[Generizität]] (19.6.2012)
#* Abstrakte Datentypen, Typspezifikation
#* Required Interface versus Offered Interface
#* Adapter und Typattribute, Funktoren
#* Beispiel: Algebraische Konzepte und Zahlendatentypen
#* Operator overloading in Python

# [[Graphen und Graphenalgorithmen]] (21.6. bis 5.7.2012)
#* Einführung
#* Graphendatenstrukturen, Adjazenzlisten und Adjazenzmatrizen
#* Gerichtete und ungerichtete Graphen
#* Vollständige Graphen
#* Planare Graphen, duale Graphen
#* Pfade, Zyklen
#* Tiefensuche und Breitensuche
#* Zusammenhang, Komponenten
#* Gewichtete Graphen
#* Minimaler Spannbaum
#* Kürzeste Wege, Best-first search (Dijkstra)
#* Most-Promising-first search (A*)
#* Problem des Handlungsreisenden, exakte Algorithmen (erschöpfende Suche, Branch-and-Bound-Methode) und Approximationen
#* Erfüllbarkeitsproblem, Darstellung des 2-SAT-Problems durch gerichtete Graphen, stark zusammenhängende Komponenten












# [[Randomisierte Algorithmen]] (10. und 12.7.2012)
#* Zufallszahlen, Zyklenlänge, Pitfalls
#* Zufallszahlengeneratoren: linear congruential generator, Mersenne Twister
#* Randomisierte vs. deterministische Algorithmen
#* Las Vegas vs. Monte Carlo Algorithmen
#* Beispiel für Las Vegas: Randomisiertes Quicksort
#* Beispiele für Monte Carlo: Randomisierte Lösung des k-SAT Problems
#* RANSAC-Algorithmus, Erfolgswahrscheinlichkeit, Vergleich mit analytischer Optimierung (Methode der kleinsten Quadrate)

# [[Greedy-Algorithmen und Dynamische Programmierung]] (17.7.2012)
#* Prinzipien, Aufwandsreduktion in Entscheidungsbäumen
#* bereits bekannte Algorithmen: minimale Spannbäume nach Kruskal, kürzeste Wege nach Dijkstra
#* Beispiel: Interval Scheduling Problem und Weighted Interval Scheduling Problem
#* Beweis der Optimalität beim Scheduling Problem: "greedy stays ahead"-Prinzip, Directed Acyclic Graph bei dynamischer Programmierung

# [[NP-Vollständigkeit]] (19.7.2012)
#* die Klassen P und NP
#* NP-Vollständigkeit und Problemreduktion

# Reserve und/oder Wiederholung (24. und 26.7.2012)

== Übungsaufgaben ==

(im PDF Format). Die Abgabe erfolgt am angegebenen Tag bis 14:00 Uhr per Email an den jeweiligen Übungsgruppenleiter. Bei Abgabe bis zum folgenden Montag 11:00 Uhr werden noch 50% der erreichten Punkte angerechnet. Danach wird die Musterlösung freigeschaltet. Erreichbare Punkte (ohne Bonusaufgaben): 466.

# [[Media:Übung-1.pdf|Übung]] (Abgabe 24.4.2012) und [[Media:Uebung-1-Musterloesung.pdf|Musterlösung]]
#* Python-Tutorial
#* Sieb des Eratosthenes
#* Wert- und Referenzsemantik
#* Dynamisches Array
# [[Media:Uebung-2.pdf|Übung]] (Abgabe 3.5.2012) und [[Media:Uebung-2-Musterloesung.pdf|Musterlösung]]
#* Sortieren: Implementation und Geschwindigkeitsvergleich (Diagramme in Abhängigkeit von der Problemgröße)
#* Entwicklung eines Gewinnalgorithmus für ein Spiel
#* Bonus: Dynamisches Array mit verringertem Speicherverbrauch
# [[Media:Uebung-3.pdf|Übung]] (Abgabe 10.5.2012) und [[Media:Uebung-3-Musterlösung.pdf|Musterlösung]]
#* Experimente zur Effektivität von Unit Tests
#* Bestimmung von Pi mit dem Algorithmus von Archimedes
#* Deque-Datenstruktur: Vor- und Nachbedingungen der Operationen, Implementation und Unit Tests
# [[Media:Uebung-4.pdf|Übung]] (Abgabe '''Montag''' 21.5.2012) und [[Media:muster_blatt4.pdf|Musterlösung]]
#* Theoretische Aufgaben zur Komplexität
#* Amortisierte Komplexität von array.append()
#* Optimierung der Matrizenmultiplikation
# [[Media:Uebung-5.pdf|Übung]] (31.5.2012) und [[Media:muster_blatt5.pdf|Musterlösung]]
#* Implementation und Analyse eines Binärbaumes
#* Anwendung: einfacher Taschenrechner
# [[Media:Uebung-6.pdf|Übung]] (Abgabe '''Freitag''' 8.6.2012) und [[Media:muster_blatt6.pdf|Musterlösung]]
#* Treap-Datenstruktur: Verbindung von Suchbaum und Heap
#* Anwendung: Worthäufigkeiten (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/die-drei-musketiere.txt die-drei-musketiere.txt]. Die Zeichenkodierung in diesem File ist Latin-1.)
#* BucketSort
# [[Media:Uebung-7.pdf|Übung]] (Abgabe 14.6.2012) und [[Media:muster_blatt07.pdf|Musterlösung]]
#* Absichtliche Konstruktion von Kollisionen für eine Hashfunktion
#* Übungen zum Assoziativen Array und zum JSON-Format: Cocktail-Datenbank (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/cocktails.json cocktails.json]. Die Zeichenkodierung in diesem File ist UTF-8.)
# [[Media:Uebung-8.pdf|Übung]] (Abgabe 21.6.2012) und [[Media:muster_blatt8.pdf|Musterlösung]]
#* Übungen zu Rekursion und Iteration: Fibonaccizahlen, Koch-Schneeflocke, Komplexität rekursiver Algorithmen, Umwandlung von Rekursion in Iteration
# [[Media:Uebung-9.pdf|Übung]] (Abgabe 28.6.2012) und [[Media:muster_blatt9.pdf|Musterlösung]]
#* Planare Graphen: Aufstellen von Adjazenzmatrizen und Adjazenzlisten, obere Schranke für die Zahl der Kanten
#* Übungen zur Generizität: Sortieren mit veränderter Ordnung, Iterator für Tiefensuche
# [[Media:Uebung-10.pdf|Übung]] (Abgabe 5.7.2012) und [[Media:muster_blatt10.pdf|Musterlösung]]
#* Fortgeschrittene Graphenaufgaben: Erzeugen einer perfekten Hashfunktion, Routenplaner (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/entfernungen.json entfernungen.json]. Die Zeichenkodierung in diesem File ist UTF-8.)
# [[Media:Uebung-11.pdf|Übung]] (Abgabe 12.7.2012) und [[Media:muster_blatt11.pdf|Musterlösung]] sowie schöne [[Media:ballungsgebiete.pdf|Visualisierung der Ballungsgebiete]] von Thorben Kröger
#* Fortgeschrittene Graphenaufgaben 2: Clusterung mittels minimaler Spannbäume, Bildverarbeitung mit Graphen (Dazu benötigen Sie wieder das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/entfernungen.json entfernungen.json] sowie die Files [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/cells.pgm cells.pgm] und [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/pgm.py pgm.py].)
# [[Media:Uebung-12.pdf|Übung]] (Abgabe 19.7.2012) und [[Media:muster_blatt12.pdf|Musterlösung]]
#* Erfüllbarkeitsproblem, Anwendung: Heim- und Auswärtsspiele im Fussball (Dazu benötigen sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/bundesliga-paarungen-12-13.json bundesliga-paarungen-12-13.json].)
#* Randomisierte Algorithmen: RANSAC für Kreise (Dazu benötigen sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/noisy-circles.txt noisy-circles.txt].)
# [[Media:Bonusuebung.pdf|Übung (Bonus)]] (Achtung: Abgabe bereits am Dienstag, 24.7.2012)
#* Greedy-Algorithmus
#* Weg durch einen Graphen
#* Wiederholungsaufgaben für die Klausur

== Sonstiges ==
* [[Gnuplot| Gnuplot Kurztutorial]]
* [[Git Kurztutorial]]
* [[neue Startseite|mögliche neue Startseite]]

File:2012-Klausur-2.pdf

2012-10-04T16:02:49Z

Ukoethe:

File:2012-Klausur-1.pdf

2012-08-08T11:01:47Z

Ukoethe: uploaded a new version of "File:2012-Klausur-1.pdf"

File:2012-Klausur-1.pdf

2012-08-06T12:53:34Z

Ukoethe: uploaded a new version of "File:2012-Klausur-1.pdf"

File:2012-Klausur-1.pdf

2012-08-01T14:18:22Z

Ukoethe: uploaded a new version of "File:2012-Klausur-1.pdf"

File:2012-Klausur-1.pdf

2012-08-01T13:23:36Z

Ukoethe: uploaded a new version of "File:2012-Klausur-1.pdf"

Main Page

2012-08-01T11:29:21Z

Ukoethe: /* Vorlesung Algorithmen und Datenstrukturen */

== Vorlesung Algorithmen und Datenstrukturen ==

Dr. Ullrich Köthe, Universität Heidelberg, Sommersemester 2012

Die Vorlesung findet '''dienstags''' und '''donnerstags''' jeweils um 14:15 Uhr in INF 227 (KIP), HS 2 statt.

=== Klausur und Nachprüfung ===

Die '''Abschlussklausur''' findet am Dienstag, dem 31.7.2012 von 10:00 bis 12:00 Uhr im HS 1 in INF 306 statt. Zur Klausur wird zugelassen, wer mindestens 50% der Übungspunkte erreicht. (Hinweis: Sie benötigen einen Lichtbildausweis, um sich bei der Klausur zu indentifizieren!) Falls notwendig, wird eine Nachklausur kurz vor Beginn des neuen Semesters stattfinden, näheres wird noch bekanntgegeben.
* '''[[Media:2012-Klausur-1.pdf|Ergebnis der Klausur vom 31.7.2012]]''' (anonymisiert)


=== Leistungsnachweise ===
Für alle Leistungsnachweise ist die erfolgreiche Teilnahme an den Übungen erforderlich. Für Leistungspunkte bzw. den Klausurschein muss außerdem die schriftliche Prüfung bestanden werden. Einzelheiten werden noch bekanntgegeben.


=== Übungsbetrieb ===
* Termine und Räume:
** Mo 14:00 - 16:00 Uhr, INF 227 (KIP), Seminarraum 2.402 (Tutor: Sven Ebser [mailto:sven@ebsers.de sven AT ebsers.de])
** Di 9:00 - 11:00 Uhr, INF 227 (KIP), Seminarraum 2.403 (Tutor: Christoph Koke [mailto:koke@kip.uni-heidelberg.de koke AT kip.uni-heidelberg.de])
** Di 11:00 - 13:00 Uhr, INF 227 (KIP), Seminarraum 2.403 (Tutor: Kai Karius [mailto:kai.karius@googlemail.com kai.karius AT googlemail.com])
** Mi 14:00 - 16:00 Uhr, INF 227 (KIP), Seminarraum 2.401 (Tutor: Stephan Meister [mailto:stephan.meister@iwr.uni-heidelberg.de stephan.meister AT iwr.uni-heidelberg.de])
* Die Übungsgruppen werden über [https://www.mathi.uni-heidelberg.de/muesli/lecture/view/169 MÜSLI] verwaltet. Dort erfolgt auch die Anmeldung.

* [[Main Page#Übungsaufgaben|Übungsaufgaben]] (Übungszettel mit Abgabetermin, Musterlösungen). Lösungen bitte per Email an den jeweiligen Übungsgruppenleiter.
* Zur Klausur wird zugelassen, wer mindestens 50% der Übungspunkte erreicht. Außerdem muss jeder Teilnehmer eine Lösung (bzw. einen Teil davon) in der Übungsgruppe vorrechnen.
* Durch das Lösen von Bonusaufgaben und gute Mitarbeit in den Übungen können Sie Zusatzpunkte erlangen. Zusatzpunkte werden auch vergeben, wenn Sie größere Verbesserungen an diesem Wiki vornehmen. Damit solche Verbesserungen der richtigen Person zugeordnet werden, sollten Sie dafür ein eigenes Wiki-Login verwenden, das Ihnen Stephan Meister oder Ullrich Köthe auf Anfrage gerne einrichten.

=== Prüfungsvorbereitung ===

Zur Hilfe bei der Prüfungsvorbereitung hat Andreas Fay [http://de.neemoy.com/quizcategories/31/ Quizfragen] erstellt.

=== Literatur ===

* R. Sedgewick: Algorithmen (empfohlen für den ersten Teil, bis einschließlich Graphenalgorithmen)
* J. Kleinberg, E.Tardos: Algorithm Design (empfohlen für den zweiten Teil, einschließlich Graphenalgorithmen)
* T. Cormen, C. Leiserson, R.Rivest: Algorithmen - eine Einführung (empfohlen zum Thema Komplexität)
* Wikipedia und andere Internetseiten (sehr gute Seiten über viele Algorithmen und Datenstrukturen)

=== Gliederung der Vorlesung ===

# [[Einführung]] (17.4.2012)
#* Definition von Algorithmen und Datenstrukturen, Geschichte
#* Fundamentale Algorithmen: create, assign, copy, swap, compare etc.
#* Fundamentale Datenstrukturen: Zahlen, Container, Handles
#* Python-Grundlagen

# [[Container]] (19.4.2012)
#* Anforderungen von Algorithmen an Container
#* Einteilung der Container
#* Grundlegende Container: Array, verkettete Liste, Stack und Queue
#* Sequenzen und Intervalle (Ranges)

# [[Sortieren]] (24. und 26.4.2012)
#* Spezifikation des Sortierproblems
#* Selection Sort und Insertion Sort
#* Merge Sort
#* Quick Sort und seine Varianten
#* Vergleich der Anzahl der benötigten Schritte
#* Laufzeitmessung in Python

# [[Korrektheit]] (3. und 8.5.2012)
#* Definition von Korrektheit, Algorithmen-Spezifikation
#* Korrektheitsbeweise versus Testen
#* Vor- und Nachbedingungen, Invarianten, Programming by contract
#* Testen, Execution paths, Unit Tests in Python
#* Ausnahmen (exceptions) und Ausnahmebehandlung in Python

# [[Effizienz]] (10. und 15.5.2012)
#* Laufzeit und Optimierung: Innere Schleife, Caches, locality of reference
#* Laufzeit versus Komplexität
#* Landausymbole (O-Notation, <math>\Omega</math>-Notation, <math>\Theta</math>-Notation), Komplexitätsklassen
#* Bester, schlechtester, durchschnittlicher Fall
#* Amortisierte Komplexität

# [[Suchen]] (22. und 24.5.2012)
#* Sequentielle Suche
#* Binäre Suche in sortierten Arrays, Medianproblem
#* Suchbäume, balancierte Bäume
#* selbst-balancierende Bäume, Rotationen
#* Komplexität der Suche

# [[Sortieren in linearer Zeit]] (29.5.2012)
#* Permutationen
#* Sortieren als Suchproblem
#* Bucket Prinzip, Bucket Sort

# [[Prioritätswarteschlangen]] (31.5.2012)
#* Heap-Datenstruktur
#* Einfüge- und Löschoperationen
#* Heapsort
#* Komplexität des Heaps

# [[Assoziative Arrays]] (5.6.2012)
#* Datenstruktur-Dreieck für assoziative Arrays
#* Definition des abstrakten Datentyps
#* JSON-Datenformat
#* Realisierung durch sequentielle Suche und durch Suchbäume

# [[Hashing und Hashtabellen]] (5.6.und 12.6.2012)
#* Implementation assoziativer Arrays mit Bäumen
#* Hashing und Hashfunktionen
#* Implementation assoziativer Arrays als Hashtabelle mit linearer Verkettung bzw. mit offener Adressierung
#* Anwendung des Hashing zur String-Suche: Rabin-Karp-Algorithmus

# [[Iteration versus Rekursion]] (14.6.2012)
#* Typen der Rekursion und ihre Umwandlung in Iteration
#* Auflösung rekursiver Formeln mittels Master-Methode und Substitutionsmethode

# [[Generizität]] (19.6.2012)
#* Abstrakte Datentypen, Typspezifikation
#* Required Interface versus Offered Interface
#* Adapter und Typattribute, Funktoren
#* Beispiel: Algebraische Konzepte und Zahlendatentypen
#* Operator overloading in Python

# [[Graphen und Graphenalgorithmen]] (21.6. bis 5.7.2012)
#* Einführung
#* Graphendatenstrukturen, Adjazenzlisten und Adjazenzmatrizen
#* Gerichtete und ungerichtete Graphen
#* Vollständige Graphen
#* Planare Graphen, duale Graphen
#* Pfade, Zyklen
#* Tiefensuche und Breitensuche
#* Zusammenhang, Komponenten
#* Gewichtete Graphen
#* Minimaler Spannbaum
#* Kürzeste Wege, Best-first search (Dijkstra)
#* Most-Promising-first search (A*)
#* Problem des Handlungsreisenden, exakte Algorithmen (erschöpfende Suche, Branch-and-Bound-Methode) und Approximationen
#* Erfüllbarkeitsproblem, Darstellung des 2-SAT-Problems durch gerichtete Graphen, stark zusammenhängende Komponenten












# [[Randomisierte Algorithmen]] (10. und 12.7.2012)
#* Zufallszahlen, Zyklenlänge, Pitfalls
#* Zufallszahlengeneratoren: linear congruential generator, Mersenne Twister
#* Randomisierte vs. deterministische Algorithmen
#* Las Vegas vs. Monte Carlo Algorithmen
#* Beispiel für Las Vegas: Randomisiertes Quicksort
#* Beispiele für Monte Carlo: Randomisierte Lösung des k-SAT Problems
#* RANSAC-Algorithmus, Erfolgswahrscheinlichkeit, Vergleich mit analytischer Optimierung (Methode der kleinsten Quadrate)

# [[Greedy-Algorithmen und Dynamische Programmierung]] (17.7.2012)
#* Prinzipien, Aufwandsreduktion in Entscheidungsbäumen
#* bereits bekannte Algorithmen: minimale Spannbäume nach Kruskal, kürzeste Wege nach Dijkstra
#* Beispiel: Interval Scheduling Problem und Weighted Interval Scheduling Problem
#* Beweis der Optimalität beim Scheduling Problem: "greedy stays ahead"-Prinzip, Directed Acyclic Graph bei dynamischer Programmierung

# [[NP-Vollständigkeit]] (19.7.2012)
#* die Klassen P und NP
#* NP-Vollständigkeit und Problemreduktion

# Reserve und/oder Wiederholung (24. und 26.7.2012)

== Übungsaufgaben ==

(im PDF Format). Die Abgabe erfolgt am angegebenen Tag bis 14:00 Uhr per Email an den jeweiligen Übungsgruppenleiter. Bei Abgabe bis zum folgenden Montag 11:00 Uhr werden noch 50% der erreichten Punkte angerechnet. Danach wird die Musterlösung freigeschaltet. Erreichbare Punkte (ohne Bonusaufgaben): 466.

# [[Media:Übung-1.pdf|Übung]] (Abgabe 24.4.2012) und [[Media:Uebung-1-Musterloesung.pdf|Musterlösung]]
#* Python-Tutorial
#* Sieb des Eratosthenes
#* Wert- und Referenzsemantik
#* Dynamisches Array
# [[Media:Uebung-2.pdf|Übung]] (Abgabe 3.5.2012) und [[Media:Uebung-2-Musterloesung.pdf|Musterlösung]]
#* Sortieren: Implementation und Geschwindigkeitsvergleich (Diagramme in Abhängigkeit von der Problemgröße)
#* Entwicklung eines Gewinnalgorithmus für ein Spiel
#* Bonus: Dynamisches Array mit verringertem Speicherverbrauch
# [[Media:Uebung-3.pdf|Übung]] (Abgabe 10.5.2012) und [[Media:Uebung-3-Musterlösung.pdf|Musterlösung]]
#* Experimente zur Effektivität von Unit Tests
#* Bestimmung von Pi mit dem Algorithmus von Archimedes
#* Deque-Datenstruktur: Vor- und Nachbedingungen der Operationen, Implementation und Unit Tests
# [[Media:Uebung-4.pdf|Übung]] (Abgabe '''Montag''' 21.5.2012) und [[Media:muster_blatt4.pdf|Musterlösung]]
#* Theoretische Aufgaben zur Komplexität
#* Amortisierte Komplexität von array.append()
#* Optimierung der Matrizenmultiplikation
# [[Media:Uebung-5.pdf|Übung]] (31.5.2012) und [[Media:muster_blatt5.pdf|Musterlösung]]
#* Implementation und Analyse eines Binärbaumes
#* Anwendung: einfacher Taschenrechner
# [[Media:Uebung-6.pdf|Übung]] (Abgabe '''Freitag''' 8.6.2012) und [[Media:muster_blatt6.pdf|Musterlösung]]
#* Treap-Datenstruktur: Verbindung von Suchbaum und Heap
#* Anwendung: Worthäufigkeiten (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/die-drei-musketiere.txt die-drei-musketiere.txt]. Die Zeichenkodierung in diesem File ist Latin-1.)
#* BucketSort
# [[Media:Uebung-7.pdf|Übung]] (Abgabe 14.6.2012) und [[Media:muster_blatt07.pdf|Musterlösung]]
#* Absichtliche Konstruktion von Kollisionen für eine Hashfunktion
#* Übungen zum Assoziativen Array und zum JSON-Format: Cocktail-Datenbank (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/cocktails.json cocktails.json]. Die Zeichenkodierung in diesem File ist UTF-8.)
# [[Media:Uebung-8.pdf|Übung]] (Abgabe 21.6.2012) und [[Media:muster_blatt8.pdf|Musterlösung]]
#* Übungen zu Rekursion und Iteration: Fibonaccizahlen, Koch-Schneeflocke, Komplexität rekursiver Algorithmen, Umwandlung von Rekursion in Iteration
# [[Media:Uebung-9.pdf|Übung]] (Abgabe 28.6.2012) und [[Media:muster_blatt9.pdf|Musterlösung]]
#* Planare Graphen: Aufstellen von Adjazenzmatrizen und Adjazenzlisten, obere Schranke für die Zahl der Kanten
#* Übungen zur Generizität: Sortieren mit veränderter Ordnung, Iterator für Tiefensuche
# [[Media:Uebung-10.pdf|Übung]] (Abgabe 5.7.2012) und [[Media:muster_blatt10.pdf|Musterlösung]]
#* Fortgeschrittene Graphenaufgaben: Erzeugen einer perfekten Hashfunktion, Routenplaner (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/entfernungen.json entfernungen.json]. Die Zeichenkodierung in diesem File ist UTF-8.)
# [[Media:Uebung-11.pdf|Übung]] (Abgabe 12.7.2012) und [[Media:muster_blatt11.pdf|Musterlösung]] sowie schöne [[Media:ballungsgebiete.pdf|Visualisierung der Ballungsgebiete]] von Thorben Kröger
#* Fortgeschrittene Graphenaufgaben 2: Clusterung mittels minimaler Spannbäume, Bildverarbeitung mit Graphen (Dazu benötigen Sie wieder das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/entfernungen.json entfernungen.json] sowie die Files [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/cells.pgm cells.pgm] und [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/pgm.py pgm.py].)
# [[Media:Uebung-12.pdf|Übung]] (Abgabe 19.7.2012) und [[Media:muster_blatt12.pdf|Musterlösung]]
#* Erfüllbarkeitsproblem, Anwendung: Heim- und Auswärtsspiele im Fussball (Dazu benötigen sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/bundesliga-paarungen-12-13.json bundesliga-paarungen-12-13.json].)
#* Randomisierte Algorithmen: RANSAC für Kreise (Dazu benötigen sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/noisy-circles.txt noisy-circles.txt].)
# [[Media:Bonusuebung.pdf|Übung (Bonus)]] (Achtung: Abgabe bereits am Dienstag, 24.7.2012)
#* Greedy-Algorithmus
#* Weg durch einen Graphen
#* Wiederholungsaufgaben für die Klausur

== Sonstiges ==
* [[Gnuplot| Gnuplot Kurztutorial]]
* [[Git Kurztutorial]]
* [[neue Startseite|mögliche neue Startseite]]

File:2012-Klausur-1.pdf

2012-08-01T11:28:48Z

Ukoethe:

Suchen

2012-07-31T14:01:54Z

Ukoethe: /* Suchbäume */

Das Suchen ist eine grundlegende Operation in der Informatik. Viele Probleme in der Informatik können auf Suchaufgaben zurückgeführt werden.

Gemeint ist mit Suchen das Wiederauffinden eines Datensatzes aus einer Menge von früher gespeicherten Datensätzen, oder das Auffinden einer bestimmten Lösung in einem (potentiell großen) Suchraum möglicher Lösungen. Ein paar einleitende Worte zum Suchproblem findet man [http://de.wikipedia.org/wiki/Suche hier].

== Überblick über verschiedene Suchmethoden ==

Um sich der Vielseitigkeit des Suchproblems bewusst zu werden, ist es sinnvoll, sich einen Überblick über verschiedene Suchmethoden zu verschaffen.

Hier sei auch auf einen bereits existierenden Wikipedia-Artikel zu [http://de.wikipedia.org/wiki/Suchverfahren Suchverfahren] verwiesen.

Allen gemeinsam ist die grundlegende Aufgabe, ein Datenelement mit bestimmten Eigenschaften aus einer großen Menge von Datenelementen zu selektieren.
Dies kann, natürlich ohne jeden Anspruch auf Vollständigkeit, nach einer der jetzt diskutierten Methoden geschehen:

* '''Schlüsselsuche''': meint das Suchen von Elementen mit bestimmtem Schlüssel; ein klassisches Beispiel wäre das Suchen in einem Wörterbuch, die Schlüssel entsprechen hier den Wörtern, die Datensätze wären die zu den Wörtern gehörigen Eintragungen.

* '''Bereichssuche''': Im Allgemeinen meint die Bereichssuche in n-Dimensionen die Selektion von Elementen mit Eigenschaften aus einem bestimmten n-dimensionalen Volumen. Im eindimensionalen Fall will man alle Elemente finden, deren Eigenschaft(en) in einem bestimmten Intervall liegen. Die Verallgemeinerung auf n-Dimensionen ist offensichtlich. Ein Beispiel für die Bereichssuche in einer 3D-Kugel wäre ein Handy mit Geolokalisierung, welches alle Restaurants in einem Umkreis von 500m findet. Lineare Ungleichungen werden graphisch durch [http://de.wikipedia.org/wiki/Hyperebene Hyperebenen] repräsentiert. In 2D sind diese Hyperebenen Geraden. Die Ungleichungen können dann den Lösungsraum in irgendeiner Form begrenzen.

* '''Ähnlichkeitssuche''': Finde Elemente, die gegebenen Eigenschaften möglichst ähnlich sind. Ein prominentes Beispiel ist Google (=Ähnlichkeit zwischen Suchbegriffen und Dokumenten) oder das Suchen des nächstengelegenen Restaurants (Ähnlichkeit zwischen eigener Position und Position des Restaurants). Ein wichtiger Spezialfall ist die ''nächste-nachbar Suche''.

* '''Graphensuche''': Hier wäre beispielsweise das Problem optimaler Wege zu nennen (Navigationssuche). Dieser Punkt wird später im Verlauf der Vorlesung noch einmal aufgegriffen werden.

Im jetzt folgenden wird nur noch die ''Schlüsselsuche'' betrachtet werden.

==Sequentielle Suche==

Die ''sequentielle'' oder ''lineare'' Suche ist die einfachste Methode, einen Datensatz zu durchsuchen. Hierbei wird ein Array beispielsweise sequentiell von vorne nach hinten durchsucht. Ein prinzipieller Vorteil der Methode ist, dass auf der Eigenschaft der Datenelemente, nach denen das Array durchsucht wird, keine Ordnung im Sinne von > oder < definiert zu sein braucht, lediglich die Identität (==) muss feststellbar sein. Der folgende Python-Code zeigt, wie man sequentielle Suche einsetzen kann:

a = ... # array mit den zu durchsuchenden Elementen

foundIndex = sequentialSearch(a, key)
# foundIndex == -1 wenn nichts gefunden, 0 <math>\leq </math> foundIndex < len(a) wenn key gefunden (erster Eintrag mit diesem Wert)

Wir verwenden hier die Konvention, dass der zugehörige Arrayindex zurückgegeben wird, falls ein Element mit dem Schlüssel <tt>key</tt> gefunden wird (falls es mehrere solche Elemente gibt, wird das erste zurückgegeben). Das Ergebnis <tt>-1</tt> signalisiert hingegen, dass kein solches Element gefunden wurde. Die Funktion <tt>sequentialSearch</tt> kann folgendermaßen implementiert werden:

def sequentialSearch(a, key):
for i in range(len(a)):
if a[i] == key: # bzw. allgemeiner a[i].key == key
return i
return -1

Wir wollen jetzt die Komplexität dieses Algorithmus bestimmen, wobei die Problemgröße durch <tt>N = len(a)</tt> gegeben ist.

Dabei nimmt man an, dass der Vergleich in der inneren Schleife (<tt>a[i] == key</tt>) jeweils <math> \mathcal{O}(1)</math> ist (diese Annahme könnte verletzt sein, wenn der Vergleichsoperator eine komplizierte Berechnung mit höherer Komplexität ausführen muss). Bei einer erfolglosen Suche wird dieser Vergleich in der for-Schleife N-mal durchgeführt (<math> \mathcal{O}(N)</math>), bei einer erfolgreichen Suche im Mittel (N/2)-mal (ebenfalls <math> \mathcal{O}(N)</math>). Nach der Verschachtelungsregel erhält man also eine gesamte Komplexität von <math> \mathcal{O}(N)</math>.

Der Name ''lineare'' Suche rührt von diesem linearen Anwachsen der Komplexität mit der Arraygröße her.

==Binäre Suche==

Wie wir weiter unten zeigen werden, gestattet es diese Suchmethode, die Gesamtdauer der Suche in großen Datensätzen beträchtlich zu verringern. Die Methode beruht auf dem [http://de.wikipedia.org/wiki/Divide_and_Conquer Divide and Conquer-Prinzip], wobei die Suche in jedem Schritt rekursiv auf eine Hälfte des Datensatzes eingeschränkt wird. Weitere Details zur Methode sind [http://de.wikipedia.org/wiki/Bin%C3%A4re_Suche hier] zu finden.

Die Methode ist nur dann anwendbar beziehungsweise effektiv, wenn folgendes gilt:

# Auf der Eigenschaft der Daten, die zur Suche verwendet wird, ist eine Ordnung im Sinne von < oder > definiert.
# Wir wollen uns auf Datensätze beschränken, die schon fertig aufgebaut sind, in die also keine neuen Elemente mehr eingefügt werden, wenn man mit dem Suchen beginnt. Ist dies nicht der Fall, müsste nach jeder Einfügung das Array neu sortiert werden (unter diesen Umständen wäre die Verwendung eines [[Suchen#Suchb.C3.A4ume|Suchbaumes]] geschickter).

Im Unterschied zur sequenziellen Suche müssen wir jetzt das Array sortieren bevor die Suchfunktion aufgerufen werden kann:

a = [...,...] # array
a.sort() # sortiere über Ordnung des Schlüssels
foundIndex = binSearch(a, key, 0, len(a)) # (Array, Schlüssel, von wo bis wo suchen im Array)
# foundIndex == -1 wenn nichts gefunden, 0 <math>\leq</math> foundIndex < len(a) wenn key gefunden (erster Eintrag mit diesem Wert)

Der folgende Algorithmus zeigt eine beispielhafte Implementierung der Methode:

def binSearch(a, key, start, end): # start ist 1. Index, end ist letzter Index + 1
size = end - start # <math> \mathcal{O}(1)</math>
if size <= 0: # Bereich leer? <math> \mathcal{O}(1)</math>
return -1 # also nichts gefunden, <math> \mathcal{O}(1)</math>
center = (start + end)/2 # Integer Division (d.h. Ergebnis wird abgerundet, wichtig für ganzzahlige Indizes) <math> \mathcal{O}(1)</math>
if a[center] == key: # <math> \mathcal{O}(1)</math>
return center # Schlüssel gefunden, <math> \mathcal{O}(1)</math>
elif a[center] < key: <math> \mathcal{O}(1)</math>
return binSearch(a, key, center + 1, end) # Rekursion in die rechte Teilliste
else:
return binSearch(a, key, start, center) # Rekursion in die linke Teilliste

Zur Berechnung der Komplexität dieses Algorithmus vernachlässigen wir zunächst den Aufwand, den die Sortierung verursacht (wir diskutieren unten, wann dies nicht zulässig ist). Wir setzen <tt>N = len(a)</tt>.

Im obigen Code ist zu erkennen, dass fast alle Anweisungen des Algorithmus die Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel hat auch deren Hintereinanderausführung die Komplexität <math>\mathcal{O}(1)</math>. Es bleibt die Komplexität der Rekursion zu berechnen. Die gesamte Komplexität des Algorithmus (jetzt als Funktion f bezeichnet) setzt sich zusammen aus den oben erwähnten <math>\mathcal{O}(1)</math>-Anweisungen sowie der Rekursion auf einem Teilarray der halben Größe

<math>f(N) = \mathcal{O}(1) + f(N/2) = \mathcal{O}(1) + \mathcal{O}(1) + f(N/4) = ... = \underbrace{\mathcal{O}(1) + ... + \mathcal{O}(1) + \underbrace{f(0)}_{\mathcal{O}(1)\, \rightarrow \,\mathrm{size-Abfrage}}}_{n+1 \,\mathrm{Terme}} </math>

Zur Vereinfachung nehmen wir an <math> N = 2^n </math>, so dass gilt

<math> \rightarrow f(N) = \mathcal{O}(1) \cdot \mathcal{O}(n+1) = \mathcal{O}(n) = \mathcal{O}(\lg N) </math>

Für große Datenmengen ist die ''binäre Suche'' also weit effizienter als die ''lineare Suche''. Verdoppelt sich beispielsweise die zu durchsuchende Datenmenge, so verdoppelt sich der Aufwand für die ''sequentielle Suche'' - bei der ''binären Suche'' hingegen benötigt man lediglich eine zusätzliche Vergleichsoperation.

Für kleine Daten (<math> N = 4,\, 5 </math>) ist die ''sequentielle Suche'' jedoch schneller als die ''binäre Suche'', da hier die rekursiven Funktionsaufrufe teurer als das Mehr an Vergleichen sind. Ein anderer ungünstiger Fall ist gegeben, wenn nur sehr wenige Suchanfragen erfolgen (weniger als <math>\mathcal{O}(N)</math> viele). Dann wird der Aufwand durch das Sortieren des Arrays dominiert, ist also <math>\mathcal{O}(N \lg N) </math>. Auch dann ist sequentielle Suche vorzuziehen.

Eine relativ einfache Möglichkeit, die ''binäre Suche'' zu verbessern, ist die sogenannte ''Interpolationssuche''. Hierbei wird die neue Position für die Suche, also die Mitte des Arrays, durch eine Schätzung ersetzt, die angibt, wo sich der Schlüssel innerhalb des Arrays befinden könnte. Bei der Suche in einem Telefonbuch nach dem Namen Zebra würde man ja auch nicht in der Mitte anfangen. Näheres hierzu im Buch von ''Sedgewick''.

Um sich den Algorithmus der ''binären Suche'' klar zu machen, ist es instruktiv, sich die folgende Tabelle genauer anzusehen, die die sukzessive Belegung der Variablen bei verschiedenen Anfragen beschreibt. Die Testfälle wurden nach dem Prinzip des ''domain partitioning'' gewählt. Das zugehörige Array hat die Einträge

a = [2, 3, 4, 5, 6]

{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"
! gesuchter key !! start !! end !! size !! center !! return (-1 oder index) !! Kommentare
|- bgcolor="#e0e0e0"
| 4 ||0 || 5 || 5 || 2 || 2 || gefunden
|-
| 2 || 0 || 5 || 5 || 2 || || linker Randfall
|-
| ||0 || 2 || 2 || 1 || ||
|-
| || 0 || 1 || 1 || 0 || 0 || gefunden
|- bgcolor="#e0e0e0"
| 1 ||0 || 5 || 5 || 2 || || links außerhalb
|- bgcolor="#e0e0e0"
| ||0 || 2 || 2 || 1 || ||
|- bgcolor="#e0e0e0"
| ||0 || 1 || 1 || 0 || ||
|- bgcolor="#e0e0e0"
| ||0 || 0 || 0 || || -1 || nichts gefunden
|-
| 6 ||0 || 5 || 5 || 2 || || rechter Randfall
|-
| || 3 || 5 || 2 || 4 || 4 || gefunden
|- bgcolor="#e0e0e0"
| 5 ||0 || 5 || 5 || 2 || || typischer Fall
|- bgcolor="#e0e0e0"
| ||3 || 5 || 2 || 4 || ||
|- bgcolor="#e0e0e0"
| || 3 || 4 || 1 || 3 || 3 || gefunden
|-
| 7 ||0 || 5 || 5 || 2 || || rechts außerhalb
|-
| || 3 || 5 || 2 || 4 || ||
|-
| ||5 || 5 || 0 || || -1 || nichts gefunden
|}
 

== Suchbäume ==

Effiziente Suchalgorithmen kann man elegent mit Hilfe von Binärbäumen realisieren. Eine kurze Einführung in Binärbäume findet man [http://de.wikipedia.org/wiki/Bin%C3%A4rbaum hier]. Die Skizze erläutert wichtige Begriffe:

[[Image:Baum.png|text-top|300x300px|Zur Illustration von Bäumen]]

Bäume sind zweidimensional verkettete Strukturen. Sie gehören zu den fundamentalen Datenstrukturen in der Informatik. Da man in Bäumen nicht nur Daten speichern kann, sondern auch relevante Beziehungen der Daten untereinander, festgelegt über eine Ordnung auf der vergleichenden Dateneigenschaft (''Schlüssel''), eignen sich Bäume also insbesondere, um gesuchte Daten schnell wieder auffinden zu können.

Ein ''Binärbaum'' wie oben skizziert besteht aus einer Menge von ''Knoten'', die untereinander durch ''Kanten'' verbunden sind. Jeder Knoten hat einen linken und einen rechten Unterbaum, der auch leer sein kann (in Python ließe sich dies mit ''None'' implementieren). Führt eine Kante von Knoten A zu Knoten B, so heißt A Vater von B und B Kind von A. Es gibt genau einen Knoten ohne Vater, den man ''Wurzel'' nennt. Knoten ohne Kinder heißen ''Blätter''.

Ein ''Suchbaum'' hat zusätzlich die Eigenschaft, dass die Schlüssel jedes Knotens sortiert sind:
;Suchbaumbedingung: Für jeden Knoten des Binärbaumes gilt: Alle Schlüssel im linken Unterbaum sind kleiner als der Schlüssel des gegebenen Knotens, alle Schlüssel im rechten Unterbaum sind größer. Wir wollen hierbei annehmen, dass jeder Schlüssel pro Datensatz nur einmal vorkommt, da sich sonst die >- oder <-Relation nicht mehr strikt erfüllen ließe.
Mit anderen Worten: der maximale Schlüssel des linken Unterbaums, der Schlüssel des gegebenen Knotens, sowie der minimale Schlüssel des rechten Unterbaums sind in dieser Reihenfolge sortiert, und dies muss für alle Knoten und deren Unterbäume (falls sie existieren) gelten.

Um die Verwendung eines Suchbaums zu motivieren, wollen wir von zwei Annahmen ausgehen:
# Einfügen und Suchen im Baum wechseln sich ab. (Wenn das Suchen erst beginnt, nachdem alle Einfügungen erfolgt sind, wäre ein dynamisches Array mit [[Suchen#Bin.C3.A4re_Suche|binärer Suche]] wesentlich einfacher.)
# Der Schlüssel, der die Anordnung bestimmt, kennt eine [http://de.wikipedia.org/wiki/Ordnungsrelation Ordnung] (<-Relation oder >-Relation).

Zunächst definieren wir eine Knotenklasse für den Suchbaum:

class Node:
def __init__(self, key):
self.key = key
self.left = self.right = None

=== Suche in einem Binärbaum ===

Wir nehmen nun an, dass der Baum durch eine Referenz auf den Wurzelknoten <tt>root</tt> gegeben ist. Dann kann man folgendermassen suchen:

root = ... # Wurzel des Suchbaums
nodeFound = treeSearch(root, key) # None, falls nichts gefunden

Hier verwenden wir die Konvention, dass der passende Knoten zurückgegeben wird, falls <tt>key</tt> gefunden wurde, oder <tt>None</tt> andernfalls. Die Suchfunktion wird rekursiv implementiert:

def treeSearch(node, key):
if node is None:
return None
elif node.key == key: # gefunden
return node # => Knoten zurückgeben
elif key < node.key: # gesuchter Schlüssel ist kleiner
return treeSearch(node.left, key) # => im linken Unterbaum weitersuchen
else: # andernfalls
return treeSearch(node.right, key) # => im rechten Unterbaum weitersuchen

=== Einfügen in einen Binärbaum ===

Bevor wir den Einfügealgorithmus implementieren, müssen wir festlegen, was passieren soll, wenn der einzufügende Schlüssel schon vorhanden ist. Mehrere Möglichkeiten bieten sich an:
* Fehler signalisieren (exception auslösen)
* nichts einfügen
* nichts einfügen, aber einen boolean zurückgeben (false wenn nichts eingefügt wurde, true wenn etwas einfügt wurde)
* nochmals einfügen (z.B. kann man die Klasse Node oben durch einen Zähler erweitern, der angibt, wie oft der betreffende Schlüssel bereits eingefügt wurde)

Die ersten 3 Punkte realisieren eine Mengensemantik, der letzte eine Multimenge. Wir entscheiden uns hier für Möglichkeit 2 (nichts einfügen). Das Prinzip des Einfügens besteht darin, im Baum dorthin abzusteigen, wo der Schlüssel sich befinden müsste (wie bei <tt>treeSearch</tt>), und dann an der betreffenden Stelle einen neuen Blattknoten zu erzeugen. Die Funktion gibt ein Knotenobjekt zurück, damit die Verkettungen im Elternknoten entsprechend angepasst werden können:

def treeInsert(node, key):
if node is None: # richtiger Platz gefunden
return Node(key) # => neuen Knoten einfügen
if node.key == key: # schon vorhanden
return node # => nichts tun
elif key < node.key:
node.left = treeInsert(node.left, key) # im linken Teilbaum einfügen
else:
node.right = treeInsert(node.right, key) # im rechten Teilbaum einfügen
return node

Ein Binärbaum wird aufgebaut, indem <tt>treeInsert</tt> für jeden Schlüssel aufgerufen wird. Wir verwenden hier ganze Zahlen als Schlüssel. Am Anfang ist der Baum leer:

root = None
root = treeInsert(root, 4)
root = treeInsert(root, 2)
root = treeInsert(root, 3)
root = treeInsert(root, 6)

=== Entfernen aus einem Binärbaum ===
Wir legen wiederum zuerst fest, was im Fehlerfall passieren soll, d.h. wenn der Schlüssel nicht vorhanden ist:
* Auslösen einer Exception (KeyError)
* nichts löschen
* nichts löschen, aber ein boolean zurückgeben, das dies signalisiert.

Wir entscheiden uns wieder für Möglichkeit 2. Beim Entfernen eines Knotens unterscheiden wir nun 3 Fälle:
# node, welcher <tt>key</tt> enthält, ist ein Blatt => kann einfach gelöscht werden
# node hat nur linken Unterbaum oder nur rechten Unterbaum => durch Unterbaum ersetzen
# node hat beide Unterbäume:
#* Suche Vorgänger: <math>\max_{k < key} (k \in keys)</math> => ersetze node durch seinen Vorgänger und entferne Vorgänger. (Dies führt zu einem effizienten Algorithmus, weil der Vorgänger immer zu Fall 1 oder Fall 2 gehört. Wenn er nämlich einen rechten Unterbaum hätte, könnte er nicht der Vorgänger sein.)

Die Funktion, die den Vorgänger sucht, muss den größten Knoten im lnken Unterbaum suchen. Da diese Funktion nur in Fall 3 aufgerufen wird, gibt es den linken Unterbaum immer.
def treePredecessor(node):
node = node.left
while node.right is not None:
node = node.right
return node

Die oben angegebenen Fälle werden durch folgende Funktion realisiert:

def treeRemove(node, key):
if node is None: # key nicht vorhanden
return node # => nichts tun
if key < node.key:
node.left = treeRemove(node.left, key)
elif key > node.key:
node.right = treeRemove(node.right, key)
else: # key gefunden
if node.left is None and node.right is None: # Fall 1
node = None
elif node.left is None: # Fall 2
node = node.right # +
elif node.right is None: # Fall 2
node = node.left
else: # Fall 3
pred = treePredecessor(node)
node.key = pred.key
node.left = treeRemove(node.left, pred.key)
return node

=== Komplexitätsanalyse ===

Um die Komplexität der Operationen auf einem Binärbaum zu bestimmen, müssen wir zunächst einige weitere Begriffe einführen:
;Pfad: Ein Pfad zwischen zwei Knoten node1 und node2 ist eine Folge von Knoten nodek1,...,nodekn, so dass:
:* nodek1 == node1
:* nodekn == node2
:* nodeki und nodeki+1 haben eine gemeinsame Kante.
[[Image:Baum_Pfad.png]]
Ein Baum ist definiert als ein Graph, in dem es zwischen beliebigen Knoten stets genau einen Pfad gibt.

;Länge eines Pfades: Anzahl der Kanten im Pfad (= Anzahl der Knoten - 1)
;Tiefe eines Knotens: Pfadlänge vom Knoten zur Wurzel des Baumes (die Wurzel hat also die Tiefe 0)
;Tiefe des Baumes: maximale Tiefe eines Knotens

Allen Baumoperationen ist gemeinsam, dass sie entlang genau eines Pfades im Baum absteigen (welcher Pfad dies ist ergibt sich aus der Ordnung der Schlüssel). Der Abstieg endet, wenn entweder der gesuchte Schlüssel gefunden wird, oder wenn erkannt wird, dass der Schlüssel nicht vorhanden ist (wenn das Kind, wo der Schlüssel sein müsste, den Wert <tt>None</tt> hat). Während des Abstiegs werden in jedem Knoten nur Anweisungen ausgeführt, die konstante Zeit benötigen (1 Vergleich, wenn die Suche in dem Knoten erfolglos beendet wird, 2 Vergleiche, wenn der Schlüssel gefunden wird, und 3 Vergleiche, wenn im rechten oder linken Teilbaun weiter abgestiegen werden muss). Daraus folgt, dass die Suche im ungünstigsten Fall die Komplexität <math>\mathcal{O}(T)</math> hat, wobei T die Tiefe des Baumes (= längster Pfad, der durchlaufen werden kann) ist.

==== Ungünstigster Fall für die Baumoperationen ====

Um den ungünstigsten Fall für die Baumoperationen zu finden, müssen wir offensichtlich herausfinden, wie groß die Tiefe maximal werden kann. Es ist leicht zu erkennen, dass die Tiefe maximiert wird, wenn man sortierte Daten in den Baum einfügt:
* Fügt man [1,2,3,4,5] in dieser Reihenfolge ein, muss man bei <tt>treeInsert</tt> stets in den rechten Teilbaum absteigen (weil der nächste Schlüssel immer größer als der größte bisherige Schlüssel ist) und dort ein rechtes Kind einfügen. Es ergibt sich folgender Baum: [[Image:Balance.png]]
: Dieser Baum hat die Tiefe 4. Die Funktion <tt>treeSerach</tt> verhält sich dann wie sequentielle Suche, man hat also durch die Verwendung des Suchbaums nichts gewonnen.
Allgemein gilt: Alle Operationen eine binären Suchbaums haben im ungünstigsten Fall die Komplexität <math>\mathcal{O}(N)</math>, wo N die Anzahl der Elemente im Baum bezeichnet. Eine offensichtliche Lösung der Problems besteht darin, die Elemente nicht in einer so ungünstigen Reihenfolge einzufügen (siehe Übungsaufgabe 5.1.c). Allerdings ist dies nicht immer möglich. Abhilfe schaffen dann selbst-balancierende Bäume.

==Selbst-balancierende Suchbäume==

=== Balance eines Suchbaumes ===

Um die Komplexität der Suchbaum-Operationen zu minimieren, müssen wir die Höhe des Baumes minimieren. Wir wollen also die Länge des längsten Pfades verkürzen, ohne dass ein anderer Pfad dadurch unnötig lang wird. Mit anderen Worten wollen wir erreichen, dass alle Pfade von der Wurzel zu den Blättern ungefährt die gleiche Länge haben. Diese Idee kann man formal durch den Begriff der ''Balance'' eines Suchbaums fassen. Um die Balance zu definieren, betrachten wir <tt>None</tt> als zusätzlichen Knoten, als sogenannten '''Sentinel''' (engl. für ''Wächter''). Der sentinel-Knoten wird als rechter oder linker Nachfolger verlinkt, wenn der entsprechende Nachfolger nicht durch einen echten Knoten belegt ist:

[[Image:sentinel.png|400px|right]]

Wir definieren nun:
;RS-Pfade: Pfad von ''root'' → ''sentinel''. In jedem Binärbaum gibt es mehrere RS-Pfade.
;Balance eines Baumes: Differenz zwischen der Länge des längsten und kürzesten RS-Pfads:
:::<math> B = \max_{P\in\{RS\}} |P| - \min_{P\in\{RS\}} |P|</math>
:wobei <math>\{RS\}</math> die Menge aller RS-Pfade bezeichnet, und |P| die Länge des Pfades P.
;vollständiger Baum: Balance <math>B=0</math>
:Daraus folgt, dass alle Knoten (außer den Blättern) 2 Kinder haben müssen.
;perfekt balancierter Baum: Balance <math>B \le 1</math>
::alternative Definition für perfekt balancierte Bäume: Für jeden Knoten gilt, dass der rechte und linke Unterbaum ebenfalls perfekt balancierte Bäume sind und ihre Höhe sich höchstens um '''1''' unterscheidet. Leere Unterbäume sind per Definition perfekt balanciert und haben die Höhe Null.

====Größe eines Baumes in Abhängigkeit von Balance und Tiefe====
[[Image:Baum_voll.png|400px|right]]
;vollständiger Baum:
Aus der Abbildung erkennt man, dass Ebene k eines vollständigen Baumes stets 2k Knoten enthält (der grüne Knoten gehört nicht zum vollständigen Baum). Hat der Baum die Tiefe d, dann enthält er

::N = 20 + 21.....+ 2d = 2d+1 - 1

Knoten (und damit ebensoviele Datenelemente).

;perfekt balancierter Baum:
Für eine gegebene Tiefe d kann kein Baum mehr Elemente enthalten als der entsprechende vollständige Baum. Also gilt für jeden perfekt balancierten Baum der Größe N:
:::<math> N \le 2^{d+1} - 1</math>
Der kleinste perfekt balancierte Baum der Tiefe d ist ein vollständiger Baum der Tiefe d-1 (mit <math>2^{(d-1)+1} - 1</math> Knoten), wo an einem einzigen Knoten noch ein weiteres Datenelement angehängt wurde (grüner Knoten in der Abbildung). Dieser Baum enthält
:::<math>N = \left(2^{(d-1)+1} - 1\right) + 1 = 2^d</math>
Datenelemente. Folglich gilt für perfekt balancierte Bäume die Ungleichung
:::<math>2^d \le N \le 2^{d+1} - 1</math>
und demzufolge auch
:::<math>\log_2(2^d) \le \log_2(N) \le \log_2(2^{d+1} - 1) < \log_2(2^{d+1})</math> 
:::<math>d \le \log_2(N) < d+1</math>

Da die Baumoperationen im ungünstigsten Fall die Komplexität <math>\mathcal{O}(d)</math> haben, gilt für perfekt balancierte Bäume, dass alle Operationen im schlechtesten Fall die Komplexität
:::<math>\mathcal{O}(\log(N))</math>
haben, das ist ''logarithmische Komplexität''. Ein perfekt balancierter Baum wird z.B. durch die Datenstruktur des [http://en.wikipedia.org/wiki/AVL_tree AVL-Baums] realisiert. Die Implementation eines AVL-Baums ist jedoch kompliziert, und es zeigt sich, dass die Eigenschaft der perfekten Balance gar nicht notwendig ist, um logarithmische Komplexität zu garantieren. Wir definieren:
;balancierter Baum: Für die Tiefe d(N) eines balancierten Baumes mit N Knoten gilt
:::<math>\forall N:d(N)\le c \cdot d_{PB}(N)</math> mit <math>1 \le c < \infty</math>
:wobei dPB(N) die Tiefe eines perfekt balancierten Baumes mit N Knoten ist. Für die Komplexität der Operationen in einem balancierten Baum gilt dann:
:::<math>f(N) \le c\cdot f_{PB}(N) = c\, \mathcal{O}(\log(N)) = \mathcal{O}(\log(N))</math>
d.h. die Komplexität ändert sich nicht. Balancierte Bäume sind fast genauso schnell wie perfekt balancierte Bäume (bis auf den Faktor c), aber ihr Aufbau ist algorithmisch einfacher.

===Idee selbst-balancierende Bäume===

Die grundlegende Idee der selbst-balancierenden Bäume besteht darin, nach jeder Einfügung die Balance des Baumes zu optimieren. Dies geschieht am zweckmäßigsten im aufsteigenden Zweig der Rekursion, also nach der Rückkehr von den rekursiven Aufrufen der Funktion <tt>treeInsert</tt>. Dies entspricht folgendem Pseudo-Code:

def insertTree(node,key):
if node is None:
return Node(key)
if node.key == key:
return node
if key < node.key:
node.left = insertTree(node.left, key)
else:
node.right = insertTree(node.right, key)
optimiere die Balance hier
return node

Dabei muss man beachten, dass bei den Optimierungen die Suchbaumbedingung (Definition siehe oben) erhalten bleibt. Dies ist garantiert, wenn alle Umstrukturierungen durch die elementare Operation der ''Rotation'' implementiert werden. Eine ''Rechtsrotation'' ersetzt die Wurzel <tt>n</tt> eines Teilbaumes durch sein linkes Kind, und fügt die alte Wurzel als rechtes Kind der neuen Wurzel ein. Die ''Linksrotation'' ist die Inverse dieser Operation. Die Abbildung verdeutlicht die Umstrukturierungen:

[[Image:Baum_Rotation.png]]

Die Rotationen werden wie folgt implementiert:

def rotateRight(node):
newRoot = node.left
node.left = newRoot.right
newRoot.right = node
return newRoot

def rotateLeft(node):
newRoot = node.right
node.right = newRoot.left
newRoot.left = node
return newRoot

Man erkennt leicht, dass die Suchbaumbedingung erhalten bleibt. Wir erläutern dies für die Rechtsrotation, bei der Linksrotation gilt die Erklärung entsprechend. Knoten ''n'' hat einen größeren Schlüssel als Knoten ''L'', denn ''L'' ist vor der Rechtsrotation das linke Kind von ''n''. Nach der Rotation ist ''n'' deshalb korrekterweise das rechte Kind von ''L''. Weiter gilt für den Teilbaum mit der Wurzel ''LR'', dass er größer als ''L'' ist (denn er ist das rechte Kind von ''L''), aber kleiner als ''n'' (denn er liegt im linken Teilbaum von ''n''). Nach der Rechtsrotation ist diese Bedingung immer noch erfüllt, denn ''LR'' ist jetzt linker Teilbaum von ''n'', welches wiederum rechter Teilbaum von ''L'' geworden ist. Alle anderen Teilbäume sind von der Rotation nicht betroffen.

Verschiedene Arten von selbst-balancierenden Bäumen unterscheiden sich im Wesentlichen dadurch, wann welche Rotation ausgeführt wird. Wichtige Beispiele sind
* [http://en.wikipedia.org/wiki/AVL_tree AVL-Bäume] (älteste Variante)
* [http://en.wikipedia.org/wiki/Red_black_tree Rot-Schwarz-Bäume] (verbreitetste Variante)
* [http://en.wikipedia.org/wiki/Treap Treaps] (flexibelste Variante, siehe Übung 6.1)
* [http://en.wikipedia.org/wiki/Splay_tree Splay trees]
* [http://en.wikipedia.org/wiki/AA_tree Andersson-Bäume] (einfachste Variante, siehe unten)

Daneben wird gern die [http://en.wikipedia.org/wiki/Skip_list Skip List] verwendet, die aber kein Binärbaum ist, sondern auf einem anderen Prinzip beruht.

===Andersson-Bäume===

Jeder selbst-balancierende Baum benötigt Zusatzinformationen, die die augenblickliche Balance beschreiben, so dass diese gegebenenfalls optimiert werden kann. Der Andersson-Baum fügt zu diesem Zweck in jedem Knoten ein neues Feld ''level'' ein, welches mit 1 initialisiert wird:

class AnderssonNode:
def__init__(self, key):
self.key = key
self.left = self.right = None
self.level = 1

Grob gesprochen kodiert das ''level''-Feld den Abstand des Knotens vom Sentinel. Genauer gelten folgende

====Regeln====

* Es gibt vertikale Kanten (parent.level == child.level + 1 ) und horizontale Kanten (parent.level == child.level).
* Die ''reduzierte Länge'' eines Pfades zwischen zwei Knoten wird berechnet, indem nur die vertikalen Kanten im Pfad gezählt werden.
* Das Sentinel hat ''level = 0''. Alle Kanten zum Sentinel sind vertikal.
* Die ''reduzierte Höhe'' eines Knotens entspricht der reduzierten Länge des Pfades von diesem Knoten zum Sentinel. Das ''level''-Feld jedes Knotens speichert die reduzierte Höhe dieses Knotens. Folglich gilt für alle Knoten, die direkt mit dem Sentinel verbunden sind, ''level = 1''. Insbesondere gilt dies auch für neu eingefügte Knoten (siehe obige Initialisierung).

Die nächsten zwei Regeln sichern die Balance:
* Alle RS-Pfade haben die gleiche reduzierte Länge. Dies ist äquivalent zu der Bedingung, dass die Wurzel des Andersson-Baumes über alle möglichen RS-Pfade auf dem gleichen Level erreicht wird.
* Kein Pfad hat 2 aufeinander folgende horizontale Kanten.

Die letzte Regel führt zu starken algorithmischen Vereinfachungen gegenüber den konzeptionell sehr ähnlichen Rot-Schwarz-Bäumen:
* Nur Kanten zum rechten Kind dürfen horizontal sein.

Das folgende Bild zeigt einen Andersson-Baum, bei dem allerdings nicht alle Verbindungen zum Sentinel eingezeichnet sind:

[[Image:Abild.png]]

Es gilt folgender
;Satz: Jeder Andersson-Baum ist balanciert. Beweis:
:1. Sei ''hr'' die reduzierte Höhe des Andersson-Baumes. Die Eigenschaft, dass alle RS-Pfade die reduzierte Länge ''hr'' (also die ''gleiche'' reduzierte Länge) haben, hat eine wichtige Folge: Hat der Andersson-Baum ''keine'' horizontalen Kanten, so muss er ein vollständiger Baum der Tiefe ''dv = hr - 1'' sein, denn nur ein vollständiger Baum hat die Eigenschaft, dass alle RS-Pfade die gleiche Länge besitzen. Gibt es hingegen horizontale Kanten, muss der Andersson-Baum ''mehr'' Elemente enthalten als der vollständige Baum der Tiefe ''dv''. Folglich gilt für die Anzahl der Knoten eines Andersson-Baumes:
:::<math>N \ge 2^{d_v+1} - 1 = 2^{h_r} - 1</math>
:2. Da niemals zwei aufeinenderfolgende Kanten horizontal sein dürfen, ist in jedem RS-Pfad höchstens die Hälfte aller Kanten horizontal. Daher gilt für die Tiefe ''d'' eines Andersson-Baumes
:::<math>d \le 2 h_r</math>
:3. Fasst man 1. und 2. zusammen, erhält man:
:::<math>N \ge 2^{h_r} - 1 \ge 2^{d/2} - 1</math> 
:::<math>N + 1 \ge 2^{d/2}</math> 
:::<math>\log_2(N + 1) \ge d/2</math> 
:::<math>d \le 2 \log_2(N + 1)</math>.
::Da die Komplexität der Baumoperationen <math>f(N) = \mathcal{O}(d)</math> ist, gilt für den Andersson-Baum:
:::<math>f(N) = \mathcal{O}(2 \log_2(N + 1)) = \mathcal{O}(\log(N))</math>
::q.e.d.

====Wie erreicht man die Balance?====

Der Baum ist nicht mehr balanciert, wenn obige Regeln verletzt sind. Dies kann durch Einfügen eines neuen Knotens oder durch Löschen eines Knotens passieren. Nach jeder Einfügung haben sowohl der neue Knoten als auch sein Vater das Level 1 (denn der Vater war vorher direkt mit dem Sentinel verbunden). Kanten zu neu eingefügten Knoten sind deshalb immer horizontal. Dies kann die Regeln verletzen, indem entweder
* eine horizontale Kante zum linken Kind enstanden ist (falls der neue Knoten ein linkes Kind ist), oder
* zwei aufeinander folgende horizontale Kanten zu rechten Kindern entstanden sind (falls der neue Knoten ein rechtes Kind ist, und sein Vater bereits ein horizontales rechtes Kind war).
Diese Fehler können durch Rotation leicht behoben werden:
* Linke horizontale Kanten werden durch Rechtsrotation in rechte horizontale Kanten verwandelt.
* Bei zwei aufeinander folgenden rechten horizontalen Kanten wird der mittlere Knoten um eine Ebene angehoben.
Dabei ist zu beachten, dass die erste Reparatur einen neuen Fehler erzeugen kann: Es können zwei aufeinanderfolgende rechte horizontale Kanten enstehen. Daher muss die zweite Operation stets nach der ersten ausgeführt werden. Das Anheben des Levels in der zweiten Operation kann wiederum dazu führen, dass auf der nächsthöheren Ebene verbotene horizontale Kanten entstehen. Deshalb müssen die Reparaturoperationen auf der nächsten Ebene rekursiv wiederholt werden. Dies führt uns zu folgender Implementation des Insert-Algorithmus

def anderssonTreeInsert(node,key):
if node is None:
return AnderssonNode(key)
if node.key == key:
return node
if key < node.key:
node.left = anderssonTreeInsert(node.left, key)
else:
node.right = anderssonTreeInsert(node.right, key)
if node.left is not None and node.level == node.left.level: # linke horizontale Kante
node = rotateRight(node) # wird zu rechter horizontaler Kante gemacht
if node.right is not None and node.right.right is not None and node.level==node.right.right.level: # aufeinanderfolgende horizontale Kanten
node = rotateLeft(node) # mache den mittleren Knoten zur Wurzel des Teilbaums
node.level += 1 # und hebe die Wurzel um ein level an
return node

Da die Reparaturoperationen auf dem Rückweg von der Rekursion ausgeführt werden, ist gewährleistet, dass sie auf der nächsten Ebene des Baumes ebenfalls ausgeführt werden, falls nötig. Die folgende Skizze verdeutlicht die Anwendung der Reparaturen, wenn Knoten ''c'' über eine linke horizontale Kante an Knoten ''b'' angefügt wurde. Im oberen Beispiel genügt die erste Operation zur Reparatur, beim unteren Beispiel muss hingegen auch noch die zweite Operation angewendet werden.

[[Image:rotate.jpg|text-top]]

Die folgende Illustration verdeutlicht das Verhalten des Andersson-Baumes, wenn die Schlüssel in der Folge [5,4,3,2,1] eingefügt werden. Beim einfachen Binärbaum sind solche vorsortierten Daten sehr ungünstig und führen zu entarteten Bäumen mit linearer Zugriffzeit. Die Umstrukturierungen beim Andersson-Baum stellen hingegen sicher, dass die Balance immer gewahrt bleibt. Wir stellen die Knoten hier als Paare <tt>(key, level)</tt> dar, Pfeile markieren die Richtung von horizontalen Kanten. Wie oben beschrieben, werden neue Knoten zunächst normal in den Baum eingefügt und ihr Level mit 1 initialisiert. Wenn dadurch Bedingungen verletzt werden, werden die notwendigen Umstrukturierungen durchgeführt.

Beim Einfügen des ersten Knotens (Schlüssel 5) gibt es noch keine Probleme:

(5,1)

Der zweite Knoten (Schlüssel 4) wird zum linken Kind des ersten. Da beide Knoten sich auf Level 1 befinden, ensteht dadurch eine verbotene horizontale Kante nach links, die durch eine Rechtsrotation (RR) in eine erlaubte horizontale Kante nach rechts umgewandelt wird. Danach ist Knoten 4 die neue Wurzel des Baumes:

(4,1) <-- (5,1) ==RR==> (4,1) --> (5,1)

Das Einfügen von Schlüssel 3 verursacht wieder eine horizontale linke Kante, die in eine rechte umgewandelt wird:

(3,1) <-- (4,1) --> (5,1) ==RR==> (3,1) --> (4,1) --> (5,1)

Nun gibt es aber zwei horizontale Kanten hintereinander. Wir führen deshalb eine Linksrotation (LR) durch und heben das Level des mittleren Knotens um 1 an:

(4,2)
/ \
(3,1) --> (4,1) --> (5,1) ==LR==> (3,1) <-- (4,1) --> (5,1) ==Lift==> (3,1) (5,1)

Damit ist der Baum wieder korrekt. Das Einfügen des Schlüssels 2 führt wieder zu einer verbotenen linken Kante, die durch Rechtsrotation beseitigt wird:

(4,2)
(4,2) / \
/ \ ==RR==> / \
(2,1) <-- (3,1) (5,1) / \
(2,1)-->(3,1) (5,1)

Nun fügen wir Schlüssel 1 ein, der ebenfalls zu einer verbotenen linken Kante führt, aber die Reparatur des Fehlers durch Rechstsrotation würde zwei aufeinanderfolgende horizontale Kanten erzeugen. Knoten 2 muss deshalb angehoben werden:

(4,2) (2,2) <-- (4,2)
/ \ / \ \
/ \ ===> / \ \
/ \ / \ \
(1,1) <-- (2,1)-->(3,1) (5,1) (1,1) (3,1) (5,1)

Jetzt ist aber bei Level 2 eine verbotene linke horizontale Kante entstanden, die wir wieder durch Rechtsrotation in eine erlaubte rechte horizontale Kante verwandeln, so dass Knoten 2 nun die Wurzel des Baumes bildet:

(2,2) <-- (4,2) (2,2) --> (4,2)
/ \ \ / / \
/ \ \ ===> / / \
/ \ \ / / \
(1,1) (3,1) (5,1) (1,1) (3,1) (5,1)

Jetzt sind alle Bedingungen erfüllt. Man erkennt, dass alle reduzierten RS-Pfade die gleiche Länge, nämlich 2, haben (dies entspricht gerade dem Level der Wurzel des Baumes). Die tatsächliche Tiefe des Baumes (längster Pfad von der Wurzel zu einem Blatt, wobei horizontale Kanten mitgezählt werden) beträgt 2. Für einen Binärbaum mit 5 Knoten ist die Tiefe 2 gerade der beste erreichbare Wert, der Andersson-Baum verhält sich hier also optimal.

Die Löschoperation <tt>anderssonTreeRemove</tt> benötigt in jedem Knoten bis zu 5 Rotationen. Wegen der Einzelheiten verweisen wir auf Anderssons [http://user.it.uu.se/~arnea/abs/simp.html Originalartikel].

==Beziehungen zwischen dem Suchproblem und dem Sortierproblem==

===Sortieren mit Hilfe eines selbst-balancierenden Suchbaums===

Mit Hilfe eines selbst-balancierenden Suchbaums kann ein effizienter Sortieralgorithmus implementiert werden, indem man zunächst die Daten in beliebiger Reihenfolge in einen Baum einfügt, und dann in der richtigen Sortierung wieder ausliest.

a = ... # unsortiertes Array
t = None # leerer Andersson-Baum
for e in a:
t = anderssonTreeInsert(t, e) # Baum erzeugen
r = [] # leeres dynamisches Array
treeSort(t, r)
# r enthält jetzt die Daten aus a in sortierter Reihenfolge

Die Funktion <tt>treeSort</tt> navigiert im Sinne eines sogenannten ''in-order traversals'' durch den Baum und fügt die Datenelemente in der richtigen Reihenfolge an des Array an:

def treeSort(node,array): # dynamisches Array als 2. Argument
if node is None: # <math>\mathcal{O}(1)</math>
return
treeSort(node.left, array) # rekursiv
array.append(node.key) # amortisiert <math>\mathcal{O}(1)</math>
treeSort(node.right, array) # rekursiv

;Komplexität:

* Jede Einfügeoperation in den Baum hat logarithmische Komplexität. Der Aufbau eines Baumes aus N Elementen hat daher Komplexität <math>\mathcal{O}(N \log(N))</math>.
* <tt>treeSort</tt> führt in jedem Knoten eine oder zwei Operationen mit Komplexität <math>\mathcal{O}(1)</math> sowie zwei rekursive Aufrufe aus. Die Auflösung der Rekursion ergibt
<math>
f(N)=\mathcal{O}(1)+f(N_\mathrm{left})+f(N_\mathrm{right})=\mathcal{O}(1)+\mathcal{O}(1)+f(N_\mathrm{left.left})+f(N_\mathrm{left.right})+\mathcal{O}(1)+f(N_\mathrm{right.left})
+f(N_\mathrm{left.right})=N\cdot\mathcal{O}(1)=\mathcal{O}(N)
</math>
* Insgesamt erhalten wir also Komplexität <math>\mathcal{O}(\max(N \log(N), N)) = \mathcal{O}(N \log(N))</math> wie bei Merge Sort. Allerdings sind der konstante Faktor sowie der Speicherverbrauch größer, so dass diese Sortiermethode in der Praxis kaum angewendet wird.

===Sortieren als Suchproblem===

Diesem Thema ist jetzt ein eigenes Kapitel [[Sortieren in linearer Zeit]] gewidmet.

[[Sortieren in linearer Zeit|Nächstes Thema]]

Suchen

2012-07-31T14:00:49Z

Ukoethe: /* Suchbäume */

Das Suchen ist eine grundlegende Operation in der Informatik. Viele Probleme in der Informatik können auf Suchaufgaben zurückgeführt werden.

Gemeint ist mit Suchen das Wiederauffinden eines Datensatzes aus einer Menge von früher gespeicherten Datensätzen, oder das Auffinden einer bestimmten Lösung in einem (potentiell großen) Suchraum möglicher Lösungen. Ein paar einleitende Worte zum Suchproblem findet man [http://de.wikipedia.org/wiki/Suche hier].

== Überblick über verschiedene Suchmethoden ==

Um sich der Vielseitigkeit des Suchproblems bewusst zu werden, ist es sinnvoll, sich einen Überblick über verschiedene Suchmethoden zu verschaffen.

Hier sei auch auf einen bereits existierenden Wikipedia-Artikel zu [http://de.wikipedia.org/wiki/Suchverfahren Suchverfahren] verwiesen.

Allen gemeinsam ist die grundlegende Aufgabe, ein Datenelement mit bestimmten Eigenschaften aus einer großen Menge von Datenelementen zu selektieren.
Dies kann, natürlich ohne jeden Anspruch auf Vollständigkeit, nach einer der jetzt diskutierten Methoden geschehen:

* '''Schlüsselsuche''': meint das Suchen von Elementen mit bestimmtem Schlüssel; ein klassisches Beispiel wäre das Suchen in einem Wörterbuch, die Schlüssel entsprechen hier den Wörtern, die Datensätze wären die zu den Wörtern gehörigen Eintragungen.

* '''Bereichssuche''': Im Allgemeinen meint die Bereichssuche in n-Dimensionen die Selektion von Elementen mit Eigenschaften aus einem bestimmten n-dimensionalen Volumen. Im eindimensionalen Fall will man alle Elemente finden, deren Eigenschaft(en) in einem bestimmten Intervall liegen. Die Verallgemeinerung auf n-Dimensionen ist offensichtlich. Ein Beispiel für die Bereichssuche in einer 3D-Kugel wäre ein Handy mit Geolokalisierung, welches alle Restaurants in einem Umkreis von 500m findet. Lineare Ungleichungen werden graphisch durch [http://de.wikipedia.org/wiki/Hyperebene Hyperebenen] repräsentiert. In 2D sind diese Hyperebenen Geraden. Die Ungleichungen können dann den Lösungsraum in irgendeiner Form begrenzen.

* '''Ähnlichkeitssuche''': Finde Elemente, die gegebenen Eigenschaften möglichst ähnlich sind. Ein prominentes Beispiel ist Google (=Ähnlichkeit zwischen Suchbegriffen und Dokumenten) oder das Suchen des nächstengelegenen Restaurants (Ähnlichkeit zwischen eigener Position und Position des Restaurants). Ein wichtiger Spezialfall ist die ''nächste-nachbar Suche''.

* '''Graphensuche''': Hier wäre beispielsweise das Problem optimaler Wege zu nennen (Navigationssuche). Dieser Punkt wird später im Verlauf der Vorlesung noch einmal aufgegriffen werden.

Im jetzt folgenden wird nur noch die ''Schlüsselsuche'' betrachtet werden.

==Sequentielle Suche==

Die ''sequentielle'' oder ''lineare'' Suche ist die einfachste Methode, einen Datensatz zu durchsuchen. Hierbei wird ein Array beispielsweise sequentiell von vorne nach hinten durchsucht. Ein prinzipieller Vorteil der Methode ist, dass auf der Eigenschaft der Datenelemente, nach denen das Array durchsucht wird, keine Ordnung im Sinne von > oder < definiert zu sein braucht, lediglich die Identität (==) muss feststellbar sein. Der folgende Python-Code zeigt, wie man sequentielle Suche einsetzen kann:

a = ... # array mit den zu durchsuchenden Elementen

foundIndex = sequentialSearch(a, key)
# foundIndex == -1 wenn nichts gefunden, 0 <math>\leq </math> foundIndex < len(a) wenn key gefunden (erster Eintrag mit diesem Wert)

Wir verwenden hier die Konvention, dass der zugehörige Arrayindex zurückgegeben wird, falls ein Element mit dem Schlüssel <tt>key</tt> gefunden wird (falls es mehrere solche Elemente gibt, wird das erste zurückgegeben). Das Ergebnis <tt>-1</tt> signalisiert hingegen, dass kein solches Element gefunden wurde. Die Funktion <tt>sequentialSearch</tt> kann folgendermaßen implementiert werden:

def sequentialSearch(a, key):
for i in range(len(a)):
if a[i] == key: # bzw. allgemeiner a[i].key == key
return i
return -1

Wir wollen jetzt die Komplexität dieses Algorithmus bestimmen, wobei die Problemgröße durch <tt>N = len(a)</tt> gegeben ist.

Dabei nimmt man an, dass der Vergleich in der inneren Schleife (<tt>a[i] == key</tt>) jeweils <math> \mathcal{O}(1)</math> ist (diese Annahme könnte verletzt sein, wenn der Vergleichsoperator eine komplizierte Berechnung mit höherer Komplexität ausführen muss). Bei einer erfolglosen Suche wird dieser Vergleich in der for-Schleife N-mal durchgeführt (<math> \mathcal{O}(N)</math>), bei einer erfolgreichen Suche im Mittel (N/2)-mal (ebenfalls <math> \mathcal{O}(N)</math>). Nach der Verschachtelungsregel erhält man also eine gesamte Komplexität von <math> \mathcal{O}(N)</math>.

Der Name ''lineare'' Suche rührt von diesem linearen Anwachsen der Komplexität mit der Arraygröße her.

==Binäre Suche==

Wie wir weiter unten zeigen werden, gestattet es diese Suchmethode, die Gesamtdauer der Suche in großen Datensätzen beträchtlich zu verringern. Die Methode beruht auf dem [http://de.wikipedia.org/wiki/Divide_and_Conquer Divide and Conquer-Prinzip], wobei die Suche in jedem Schritt rekursiv auf eine Hälfte des Datensatzes eingeschränkt wird. Weitere Details zur Methode sind [http://de.wikipedia.org/wiki/Bin%C3%A4re_Suche hier] zu finden.

Die Methode ist nur dann anwendbar beziehungsweise effektiv, wenn folgendes gilt:

# Auf der Eigenschaft der Daten, die zur Suche verwendet wird, ist eine Ordnung im Sinne von < oder > definiert.
# Wir wollen uns auf Datensätze beschränken, die schon fertig aufgebaut sind, in die also keine neuen Elemente mehr eingefügt werden, wenn man mit dem Suchen beginnt. Ist dies nicht der Fall, müsste nach jeder Einfügung das Array neu sortiert werden (unter diesen Umständen wäre die Verwendung eines [[Suchen#Suchb.C3.A4ume|Suchbaumes]] geschickter).

Im Unterschied zur sequenziellen Suche müssen wir jetzt das Array sortieren bevor die Suchfunktion aufgerufen werden kann:

a = [...,...] # array
a.sort() # sortiere über Ordnung des Schlüssels
foundIndex = binSearch(a, key, 0, len(a)) # (Array, Schlüssel, von wo bis wo suchen im Array)
# foundIndex == -1 wenn nichts gefunden, 0 <math>\leq</math> foundIndex < len(a) wenn key gefunden (erster Eintrag mit diesem Wert)

Der folgende Algorithmus zeigt eine beispielhafte Implementierung der Methode:

def binSearch(a, key, start, end): # start ist 1. Index, end ist letzter Index + 1
size = end - start # <math> \mathcal{O}(1)</math>
if size <= 0: # Bereich leer? <math> \mathcal{O}(1)</math>
return -1 # also nichts gefunden, <math> \mathcal{O}(1)</math>
center = (start + end)/2 # Integer Division (d.h. Ergebnis wird abgerundet, wichtig für ganzzahlige Indizes) <math> \mathcal{O}(1)</math>
if a[center] == key: # <math> \mathcal{O}(1)</math>
return center # Schlüssel gefunden, <math> \mathcal{O}(1)</math>
elif a[center] < key: <math> \mathcal{O}(1)</math>
return binSearch(a, key, center + 1, end) # Rekursion in die rechte Teilliste
else:
return binSearch(a, key, start, center) # Rekursion in die linke Teilliste

Zur Berechnung der Komplexität dieses Algorithmus vernachlässigen wir zunächst den Aufwand, den die Sortierung verursacht (wir diskutieren unten, wann dies nicht zulässig ist). Wir setzen <tt>N = len(a)</tt>.

Im obigen Code ist zu erkennen, dass fast alle Anweisungen des Algorithmus die Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel hat auch deren Hintereinanderausführung die Komplexität <math>\mathcal{O}(1)</math>. Es bleibt die Komplexität der Rekursion zu berechnen. Die gesamte Komplexität des Algorithmus (jetzt als Funktion f bezeichnet) setzt sich zusammen aus den oben erwähnten <math>\mathcal{O}(1)</math>-Anweisungen sowie der Rekursion auf einem Teilarray der halben Größe

<math>f(N) = \mathcal{O}(1) + f(N/2) = \mathcal{O}(1) + \mathcal{O}(1) + f(N/4) = ... = \underbrace{\mathcal{O}(1) + ... + \mathcal{O}(1) + \underbrace{f(0)}_{\mathcal{O}(1)\, \rightarrow \,\mathrm{size-Abfrage}}}_{n+1 \,\mathrm{Terme}} </math>

Zur Vereinfachung nehmen wir an <math> N = 2^n </math>, so dass gilt

<math> \rightarrow f(N) = \mathcal{O}(1) \cdot \mathcal{O}(n+1) = \mathcal{O}(n) = \mathcal{O}(\lg N) </math>

Für große Datenmengen ist die ''binäre Suche'' also weit effizienter als die ''lineare Suche''. Verdoppelt sich beispielsweise die zu durchsuchende Datenmenge, so verdoppelt sich der Aufwand für die ''sequentielle Suche'' - bei der ''binären Suche'' hingegen benötigt man lediglich eine zusätzliche Vergleichsoperation.

Für kleine Daten (<math> N = 4,\, 5 </math>) ist die ''sequentielle Suche'' jedoch schneller als die ''binäre Suche'', da hier die rekursiven Funktionsaufrufe teurer als das Mehr an Vergleichen sind. Ein anderer ungünstiger Fall ist gegeben, wenn nur sehr wenige Suchanfragen erfolgen (weniger als <math>\mathcal{O}(N)</math> viele). Dann wird der Aufwand durch das Sortieren des Arrays dominiert, ist also <math>\mathcal{O}(N \lg N) </math>. Auch dann ist sequentielle Suche vorzuziehen.

Eine relativ einfache Möglichkeit, die ''binäre Suche'' zu verbessern, ist die sogenannte ''Interpolationssuche''. Hierbei wird die neue Position für die Suche, also die Mitte des Arrays, durch eine Schätzung ersetzt, die angibt, wo sich der Schlüssel innerhalb des Arrays befinden könnte. Bei der Suche in einem Telefonbuch nach dem Namen Zebra würde man ja auch nicht in der Mitte anfangen. Näheres hierzu im Buch von ''Sedgewick''.

Um sich den Algorithmus der ''binären Suche'' klar zu machen, ist es instruktiv, sich die folgende Tabelle genauer anzusehen, die die sukzessive Belegung der Variablen bei verschiedenen Anfragen beschreibt. Die Testfälle wurden nach dem Prinzip des ''domain partitioning'' gewählt. Das zugehörige Array hat die Einträge

a = [2, 3, 4, 5, 6]

{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"
! gesuchter key !! start !! end !! size !! center !! return (-1 oder index) !! Kommentare
|- bgcolor="#e0e0e0"
| 4 ||0 || 5 || 5 || 2 || 2 || gefunden
|-
| 2 || 0 || 5 || 5 || 2 || || linker Randfall
|-
| ||0 || 2 || 2 || 1 || ||
|-
| || 0 || 1 || 1 || 0 || 0 || gefunden
|- bgcolor="#e0e0e0"
| 1 ||0 || 5 || 5 || 2 || || links außerhalb
|- bgcolor="#e0e0e0"
| ||0 || 2 || 2 || 1 || ||
|- bgcolor="#e0e0e0"
| ||0 || 1 || 1 || 0 || ||
|- bgcolor="#e0e0e0"
| ||0 || 0 || 0 || || -1 || nichts gefunden
|-
| 6 ||0 || 5 || 5 || 2 || || rechter Randfall
|-
| || 3 || 5 || 2 || 4 || 4 || gefunden
|- bgcolor="#e0e0e0"
| 5 ||0 || 5 || 5 || 2 || || typischer Fall
|- bgcolor="#e0e0e0"
| ||3 || 5 || 2 || 4 || ||
|- bgcolor="#e0e0e0"
| || 3 || 4 || 1 || 3 || 3 || gefunden
|-
| 7 ||0 || 5 || 5 || 2 || || rechts außerhalb
|-
| || 3 || 5 || 2 || 4 || ||
|-
| ||5 || 5 || 0 || || -1 || nichts gefunden
|}
 

== Suchbäume ==

Effiziente Suchalgorithmen kann man elegent mit Hilfe von Binärbäumen realisieren. Eine kurze Einführung in Binärbäume findet man [http://de.wikipedia.org/wiki/Bin%C3%A4rbaum hier]. Die Skizze erläutert wichtige Begriffe:

[[Image:Baum.png|text-top|300x300px|Zur Illustration von Bäumen]]

Bäume sind zweidimensional verkettete Strukturen. Sie gehören zu den fundamentalen Datenstrukturen in der Informatik. Da man in Bäumen nicht nur Daten speichern kann, sondern auch relevante Beziehungen der Daten untereinander, festgelegt über eine Ordnung auf der vergleichenden Dateneigenschaft (''Schlüssel''), eignen sich Bäume also insbesondere, um gesuchte Daten schnell wieder auffinden zu können.

Ein ''Binärbaum'' wie oben skizziert besteht aus einer Menge von ''Knoten'', die untereinander durch ''Kanten'' verbunden sind. Jeder Knoten hat einen linken und einen rechten Unterbaum, der auch leer sein kann (in Python ließe sich dies mit ''None'' implementieren). Führt eine Kante von Knoten A zu Knoten B, so heißt A Vater von B und B Kind von A. Es gibt genau einen Knoten ohne Vater, den man ''Wurzel'' nennt. Knoten ohne Kinder heißen ''Blätter''.

Ein ''Suchbaum'' hat zusätzlich die Eigenschaft, dass die Schlüssel jedes Knotens sortiert sind:
;Suchbaumbedingung: Für jeden Knoten des Binärbaumes gilt: Alle Schlüssel im linken Unterbaum sind kleiner als der Schlüssel des gegebenen Knotens, alle Schlüssel im rechten Unterbaum sind größer. Wir wollen hierbei annehmen, dass jeder Schlüssel pro Datensatz nur einmal vorkommt, da sich sonst die >- oder <-Relation nicht mehr strikt erfüllen ließe.
Mit anderen Worten: der maximale Schlüssel des linken Teilbaums, der Schlüssel des gegebenen Knotens, sowie der minimale Schlüssel des rechten Teilbaums sind in dieser Reihenfolge sortiert, und dies muss für alle Knoten und deren Teilbäume (falls sie existieren) gelten.

Um die Verwendung eines Suchbaums zu motivieren, wollen wir von zwei Annahmen ausgehen:
# Einfügen und Suchen im Baum wechseln sich ab. (Wenn das Suchen erst beginnt, nachdem alle Einfügungen erfolgt sind, wäre ein dynamisches Array mit [[Suchen#Bin.C3.A4re_Suche|binärer Suche]] wesentlich einfacher.)
# Der Schlüssel, der die Anordnung bestimmt, kennt eine [http://de.wikipedia.org/wiki/Ordnungsrelation Ordnung] (<-Relation oder >-Relation).

Zunächst definieren wir eine Knotenklasse für den Suchbaum:

class Node:
def __init__(self, key):
self.key = key
self.left = self.right = None

=== Suche in einem Binärbaum ===

Wir nehmen nun an, dass der Baum durch eine Referenz auf den Wurzelknoten <tt>root</tt> gegeben ist. Dann kann man folgendermassen suchen:

root = ... # Wurzel des Suchbaums
nodeFound = treeSearch(root, key) # None, falls nichts gefunden

Hier verwenden wir die Konvention, dass der passende Knoten zurückgegeben wird, falls <tt>key</tt> gefunden wurde, oder <tt>None</tt> andernfalls. Die Suchfunktion wird rekursiv implementiert:

def treeSearch(node, key):
if node is None:
return None
elif node.key == key: # gefunden
return node # => Knoten zurückgeben
elif key < node.key: # gesuchter Schlüssel ist kleiner
return treeSearch(node.left, key) # => im linken Unterbaum weitersuchen
else: # andernfalls
return treeSearch(node.right, key) # => im rechten Unterbaum weitersuchen

=== Einfügen in einen Binärbaum ===

Bevor wir den Einfügealgorithmus implementieren, müssen wir festlegen, was passieren soll, wenn der einzufügende Schlüssel schon vorhanden ist. Mehrere Möglichkeiten bieten sich an:
* Fehler signalisieren (exception auslösen)
* nichts einfügen
* nichts einfügen, aber einen boolean zurückgeben (false wenn nichts eingefügt wurde, true wenn etwas einfügt wurde)
* nochmals einfügen (z.B. kann man die Klasse Node oben durch einen Zähler erweitern, der angibt, wie oft der betreffende Schlüssel bereits eingefügt wurde)

Die ersten 3 Punkte realisieren eine Mengensemantik, der letzte eine Multimenge. Wir entscheiden uns hier für Möglichkeit 2 (nichts einfügen). Das Prinzip des Einfügens besteht darin, im Baum dorthin abzusteigen, wo der Schlüssel sich befinden müsste (wie bei <tt>treeSearch</tt>), und dann an der betreffenden Stelle einen neuen Blattknoten zu erzeugen. Die Funktion gibt ein Knotenobjekt zurück, damit die Verkettungen im Elternknoten entsprechend angepasst werden können:

def treeInsert(node, key):
if node is None: # richtiger Platz gefunden
return Node(key) # => neuen Knoten einfügen
if node.key == key: # schon vorhanden
return node # => nichts tun
elif key < node.key:
node.left = treeInsert(node.left, key) # im linken Teilbaum einfügen
else:
node.right = treeInsert(node.right, key) # im rechten Teilbaum einfügen
return node

Ein Binärbaum wird aufgebaut, indem <tt>treeInsert</tt> für jeden Schlüssel aufgerufen wird. Wir verwenden hier ganze Zahlen als Schlüssel. Am Anfang ist der Baum leer:

root = None
root = treeInsert(root, 4)
root = treeInsert(root, 2)
root = treeInsert(root, 3)
root = treeInsert(root, 6)

=== Entfernen aus einem Binärbaum ===
Wir legen wiederum zuerst fest, was im Fehlerfall passieren soll, d.h. wenn der Schlüssel nicht vorhanden ist:
* Auslösen einer Exception (KeyError)
* nichts löschen
* nichts löschen, aber ein boolean zurückgeben, das dies signalisiert.

Wir entscheiden uns wieder für Möglichkeit 2. Beim Entfernen eines Knotens unterscheiden wir nun 3 Fälle:
# node, welcher <tt>key</tt> enthält, ist ein Blatt => kann einfach gelöscht werden
# node hat nur linken Unterbaum oder nur rechten Unterbaum => durch Unterbaum ersetzen
# node hat beide Unterbäume:
#* Suche Vorgänger: <math>\max_{k < key} (k \in keys)</math> => ersetze node durch seinen Vorgänger und entferne Vorgänger. (Dies führt zu einem effizienten Algorithmus, weil der Vorgänger immer zu Fall 1 oder Fall 2 gehört. Wenn er nämlich einen rechten Unterbaum hätte, könnte er nicht der Vorgänger sein.)

Die Funktion, die den Vorgänger sucht, muss den größten Knoten im lnken Unterbaum suchen. Da diese Funktion nur in Fall 3 aufgerufen wird, gibt es den linken Unterbaum immer.
def treePredecessor(node):
node = node.left
while node.right is not None:
node = node.right
return node

Die oben angegebenen Fälle werden durch folgende Funktion realisiert:

def treeRemove(node, key):
if node is None: # key nicht vorhanden
return node # => nichts tun
if key < node.key:
node.left = treeRemove(node.left, key)
elif key > node.key:
node.right = treeRemove(node.right, key)
else: # key gefunden
if node.left is None and node.right is None: # Fall 1
node = None
elif node.left is None: # Fall 2
node = node.right # +
elif node.right is None: # Fall 2
node = node.left
else: # Fall 3
pred = treePredecessor(node)
node.key = pred.key
node.left = treeRemove(node.left, pred.key)
return node

=== Komplexitätsanalyse ===

Um die Komplexität der Operationen auf einem Binärbaum zu bestimmen, müssen wir zunächst einige weitere Begriffe einführen:
;Pfad: Ein Pfad zwischen zwei Knoten node1 und node2 ist eine Folge von Knoten nodek1,...,nodekn, so dass:
:* nodek1 == node1
:* nodekn == node2
:* nodeki und nodeki+1 haben eine gemeinsame Kante.
[[Image:Baum_Pfad.png]]
Ein Baum ist definiert als ein Graph, in dem es zwischen beliebigen Knoten stets genau einen Pfad gibt.

;Länge eines Pfades: Anzahl der Kanten im Pfad (= Anzahl der Knoten - 1)
;Tiefe eines Knotens: Pfadlänge vom Knoten zur Wurzel des Baumes (die Wurzel hat also die Tiefe 0)
;Tiefe des Baumes: maximale Tiefe eines Knotens

Allen Baumoperationen ist gemeinsam, dass sie entlang genau eines Pfades im Baum absteigen (welcher Pfad dies ist ergibt sich aus der Ordnung der Schlüssel). Der Abstieg endet, wenn entweder der gesuchte Schlüssel gefunden wird, oder wenn erkannt wird, dass der Schlüssel nicht vorhanden ist (wenn das Kind, wo der Schlüssel sein müsste, den Wert <tt>None</tt> hat). Während des Abstiegs werden in jedem Knoten nur Anweisungen ausgeführt, die konstante Zeit benötigen (1 Vergleich, wenn die Suche in dem Knoten erfolglos beendet wird, 2 Vergleiche, wenn der Schlüssel gefunden wird, und 3 Vergleiche, wenn im rechten oder linken Teilbaun weiter abgestiegen werden muss). Daraus folgt, dass die Suche im ungünstigsten Fall die Komplexität <math>\mathcal{O}(T)</math> hat, wobei T die Tiefe des Baumes (= längster Pfad, der durchlaufen werden kann) ist.

==== Ungünstigster Fall für die Baumoperationen ====

Um den ungünstigsten Fall für die Baumoperationen zu finden, müssen wir offensichtlich herausfinden, wie groß die Tiefe maximal werden kann. Es ist leicht zu erkennen, dass die Tiefe maximiert wird, wenn man sortierte Daten in den Baum einfügt:
* Fügt man [1,2,3,4,5] in dieser Reihenfolge ein, muss man bei <tt>treeInsert</tt> stets in den rechten Teilbaum absteigen (weil der nächste Schlüssel immer größer als der größte bisherige Schlüssel ist) und dort ein rechtes Kind einfügen. Es ergibt sich folgender Baum: [[Image:Balance.png]]
: Dieser Baum hat die Tiefe 4. Die Funktion <tt>treeSerach</tt> verhält sich dann wie sequentielle Suche, man hat also durch die Verwendung des Suchbaums nichts gewonnen.
Allgemein gilt: Alle Operationen eine binären Suchbaums haben im ungünstigsten Fall die Komplexität <math>\mathcal{O}(N)</math>, wo N die Anzahl der Elemente im Baum bezeichnet. Eine offensichtliche Lösung der Problems besteht darin, die Elemente nicht in einer so ungünstigen Reihenfolge einzufügen (siehe Übungsaufgabe 5.1.c). Allerdings ist dies nicht immer möglich. Abhilfe schaffen dann selbst-balancierende Bäume.

==Selbst-balancierende Suchbäume==

=== Balance eines Suchbaumes ===

Um die Komplexität der Suchbaum-Operationen zu minimieren, müssen wir die Höhe des Baumes minimieren. Wir wollen also die Länge des längsten Pfades verkürzen, ohne dass ein anderer Pfad dadurch unnötig lang wird. Mit anderen Worten wollen wir erreichen, dass alle Pfade von der Wurzel zu den Blättern ungefährt die gleiche Länge haben. Diese Idee kann man formal durch den Begriff der ''Balance'' eines Suchbaums fassen. Um die Balance zu definieren, betrachten wir <tt>None</tt> als zusätzlichen Knoten, als sogenannten '''Sentinel''' (engl. für ''Wächter''). Der sentinel-Knoten wird als rechter oder linker Nachfolger verlinkt, wenn der entsprechende Nachfolger nicht durch einen echten Knoten belegt ist:

[[Image:sentinel.png|400px|right]]

Wir definieren nun:
;RS-Pfade: Pfad von ''root'' → ''sentinel''. In jedem Binärbaum gibt es mehrere RS-Pfade.
;Balance eines Baumes: Differenz zwischen der Länge des längsten und kürzesten RS-Pfads:
:::<math> B = \max_{P\in\{RS\}} |P| - \min_{P\in\{RS\}} |P|</math>
:wobei <math>\{RS\}</math> die Menge aller RS-Pfade bezeichnet, und |P| die Länge des Pfades P.
;vollständiger Baum: Balance <math>B=0</math>
:Daraus folgt, dass alle Knoten (außer den Blättern) 2 Kinder haben müssen.
;perfekt balancierter Baum: Balance <math>B \le 1</math>
::alternative Definition für perfekt balancierte Bäume: Für jeden Knoten gilt, dass der rechte und linke Unterbaum ebenfalls perfekt balancierte Bäume sind und ihre Höhe sich höchstens um '''1''' unterscheidet. Leere Unterbäume sind per Definition perfekt balanciert und haben die Höhe Null.

====Größe eines Baumes in Abhängigkeit von Balance und Tiefe====
[[Image:Baum_voll.png|400px|right]]
;vollständiger Baum:
Aus der Abbildung erkennt man, dass Ebene k eines vollständigen Baumes stets 2k Knoten enthält (der grüne Knoten gehört nicht zum vollständigen Baum). Hat der Baum die Tiefe d, dann enthält er

::N = 20 + 21.....+ 2d = 2d+1 - 1

Knoten (und damit ebensoviele Datenelemente).

;perfekt balancierter Baum:
Für eine gegebene Tiefe d kann kein Baum mehr Elemente enthalten als der entsprechende vollständige Baum. Also gilt für jeden perfekt balancierten Baum der Größe N:
:::<math> N \le 2^{d+1} - 1</math>
Der kleinste perfekt balancierte Baum der Tiefe d ist ein vollständiger Baum der Tiefe d-1 (mit <math>2^{(d-1)+1} - 1</math> Knoten), wo an einem einzigen Knoten noch ein weiteres Datenelement angehängt wurde (grüner Knoten in der Abbildung). Dieser Baum enthält
:::<math>N = \left(2^{(d-1)+1} - 1\right) + 1 = 2^d</math>
Datenelemente. Folglich gilt für perfekt balancierte Bäume die Ungleichung
:::<math>2^d \le N \le 2^{d+1} - 1</math>
und demzufolge auch
:::<math>\log_2(2^d) \le \log_2(N) \le \log_2(2^{d+1} - 1) < \log_2(2^{d+1})</math> 
:::<math>d \le \log_2(N) < d+1</math>

Da die Baumoperationen im ungünstigsten Fall die Komplexität <math>\mathcal{O}(d)</math> haben, gilt für perfekt balancierte Bäume, dass alle Operationen im schlechtesten Fall die Komplexität
:::<math>\mathcal{O}(\log(N))</math>
haben, das ist ''logarithmische Komplexität''. Ein perfekt balancierter Baum wird z.B. durch die Datenstruktur des [http://en.wikipedia.org/wiki/AVL_tree AVL-Baums] realisiert. Die Implementation eines AVL-Baums ist jedoch kompliziert, und es zeigt sich, dass die Eigenschaft der perfekten Balance gar nicht notwendig ist, um logarithmische Komplexität zu garantieren. Wir definieren:
;balancierter Baum: Für die Tiefe d(N) eines balancierten Baumes mit N Knoten gilt
:::<math>\forall N:d(N)\le c \cdot d_{PB}(N)</math> mit <math>1 \le c < \infty</math>
:wobei dPB(N) die Tiefe eines perfekt balancierten Baumes mit N Knoten ist. Für die Komplexität der Operationen in einem balancierten Baum gilt dann:
:::<math>f(N) \le c\cdot f_{PB}(N) = c\, \mathcal{O}(\log(N)) = \mathcal{O}(\log(N))</math>
d.h. die Komplexität ändert sich nicht. Balancierte Bäume sind fast genauso schnell wie perfekt balancierte Bäume (bis auf den Faktor c), aber ihr Aufbau ist algorithmisch einfacher.

===Idee selbst-balancierende Bäume===

Die grundlegende Idee der selbst-balancierenden Bäume besteht darin, nach jeder Einfügung die Balance des Baumes zu optimieren. Dies geschieht am zweckmäßigsten im aufsteigenden Zweig der Rekursion, also nach der Rückkehr von den rekursiven Aufrufen der Funktion <tt>treeInsert</tt>. Dies entspricht folgendem Pseudo-Code:

def insertTree(node,key):
if node is None:
return Node(key)
if node.key == key:
return node
if key < node.key:
node.left = insertTree(node.left, key)
else:
node.right = insertTree(node.right, key)
optimiere die Balance hier
return node

Dabei muss man beachten, dass bei den Optimierungen die Suchbaumbedingung (Definition siehe oben) erhalten bleibt. Dies ist garantiert, wenn alle Umstrukturierungen durch die elementare Operation der ''Rotation'' implementiert werden. Eine ''Rechtsrotation'' ersetzt die Wurzel <tt>n</tt> eines Teilbaumes durch sein linkes Kind, und fügt die alte Wurzel als rechtes Kind der neuen Wurzel ein. Die ''Linksrotation'' ist die Inverse dieser Operation. Die Abbildung verdeutlicht die Umstrukturierungen:

[[Image:Baum_Rotation.png]]

Die Rotationen werden wie folgt implementiert:

def rotateRight(node):
newRoot = node.left
node.left = newRoot.right
newRoot.right = node
return newRoot

def rotateLeft(node):
newRoot = node.right
node.right = newRoot.left
newRoot.left = node
return newRoot

Man erkennt leicht, dass die Suchbaumbedingung erhalten bleibt. Wir erläutern dies für die Rechtsrotation, bei der Linksrotation gilt die Erklärung entsprechend. Knoten ''n'' hat einen größeren Schlüssel als Knoten ''L'', denn ''L'' ist vor der Rechtsrotation das linke Kind von ''n''. Nach der Rotation ist ''n'' deshalb korrekterweise das rechte Kind von ''L''. Weiter gilt für den Teilbaum mit der Wurzel ''LR'', dass er größer als ''L'' ist (denn er ist das rechte Kind von ''L''), aber kleiner als ''n'' (denn er liegt im linken Teilbaum von ''n''). Nach der Rechtsrotation ist diese Bedingung immer noch erfüllt, denn ''LR'' ist jetzt linker Teilbaum von ''n'', welches wiederum rechter Teilbaum von ''L'' geworden ist. Alle anderen Teilbäume sind von der Rotation nicht betroffen.

Verschiedene Arten von selbst-balancierenden Bäumen unterscheiden sich im Wesentlichen dadurch, wann welche Rotation ausgeführt wird. Wichtige Beispiele sind
* [http://en.wikipedia.org/wiki/AVL_tree AVL-Bäume] (älteste Variante)
* [http://en.wikipedia.org/wiki/Red_black_tree Rot-Schwarz-Bäume] (verbreitetste Variante)
* [http://en.wikipedia.org/wiki/Treap Treaps] (flexibelste Variante, siehe Übung 6.1)
* [http://en.wikipedia.org/wiki/Splay_tree Splay trees]
* [http://en.wikipedia.org/wiki/AA_tree Andersson-Bäume] (einfachste Variante, siehe unten)

Daneben wird gern die [http://en.wikipedia.org/wiki/Skip_list Skip List] verwendet, die aber kein Binärbaum ist, sondern auf einem anderen Prinzip beruht.

===Andersson-Bäume===

Jeder selbst-balancierende Baum benötigt Zusatzinformationen, die die augenblickliche Balance beschreiben, so dass diese gegebenenfalls optimiert werden kann. Der Andersson-Baum fügt zu diesem Zweck in jedem Knoten ein neues Feld ''level'' ein, welches mit 1 initialisiert wird:

class AnderssonNode:
def__init__(self, key):
self.key = key
self.left = self.right = None
self.level = 1

Grob gesprochen kodiert das ''level''-Feld den Abstand des Knotens vom Sentinel. Genauer gelten folgende

====Regeln====

* Es gibt vertikale Kanten (parent.level == child.level + 1 ) und horizontale Kanten (parent.level == child.level).
* Die ''reduzierte Länge'' eines Pfades zwischen zwei Knoten wird berechnet, indem nur die vertikalen Kanten im Pfad gezählt werden.
* Das Sentinel hat ''level = 0''. Alle Kanten zum Sentinel sind vertikal.
* Die ''reduzierte Höhe'' eines Knotens entspricht der reduzierten Länge des Pfades von diesem Knoten zum Sentinel. Das ''level''-Feld jedes Knotens speichert die reduzierte Höhe dieses Knotens. Folglich gilt für alle Knoten, die direkt mit dem Sentinel verbunden sind, ''level = 1''. Insbesondere gilt dies auch für neu eingefügte Knoten (siehe obige Initialisierung).

Die nächsten zwei Regeln sichern die Balance:
* Alle RS-Pfade haben die gleiche reduzierte Länge. Dies ist äquivalent zu der Bedingung, dass die Wurzel des Andersson-Baumes über alle möglichen RS-Pfade auf dem gleichen Level erreicht wird.
* Kein Pfad hat 2 aufeinander folgende horizontale Kanten.

Die letzte Regel führt zu starken algorithmischen Vereinfachungen gegenüber den konzeptionell sehr ähnlichen Rot-Schwarz-Bäumen:
* Nur Kanten zum rechten Kind dürfen horizontal sein.

Das folgende Bild zeigt einen Andersson-Baum, bei dem allerdings nicht alle Verbindungen zum Sentinel eingezeichnet sind:

[[Image:Abild.png]]

Es gilt folgender
;Satz: Jeder Andersson-Baum ist balanciert. Beweis:
:1. Sei ''hr'' die reduzierte Höhe des Andersson-Baumes. Die Eigenschaft, dass alle RS-Pfade die reduzierte Länge ''hr'' (also die ''gleiche'' reduzierte Länge) haben, hat eine wichtige Folge: Hat der Andersson-Baum ''keine'' horizontalen Kanten, so muss er ein vollständiger Baum der Tiefe ''dv = hr - 1'' sein, denn nur ein vollständiger Baum hat die Eigenschaft, dass alle RS-Pfade die gleiche Länge besitzen. Gibt es hingegen horizontale Kanten, muss der Andersson-Baum ''mehr'' Elemente enthalten als der vollständige Baum der Tiefe ''dv''. Folglich gilt für die Anzahl der Knoten eines Andersson-Baumes:
:::<math>N \ge 2^{d_v+1} - 1 = 2^{h_r} - 1</math>
:2. Da niemals zwei aufeinenderfolgende Kanten horizontal sein dürfen, ist in jedem RS-Pfad höchstens die Hälfte aller Kanten horizontal. Daher gilt für die Tiefe ''d'' eines Andersson-Baumes
:::<math>d \le 2 h_r</math>
:3. Fasst man 1. und 2. zusammen, erhält man:
:::<math>N \ge 2^{h_r} - 1 \ge 2^{d/2} - 1</math> 
:::<math>N + 1 \ge 2^{d/2}</math> 
:::<math>\log_2(N + 1) \ge d/2</math> 
:::<math>d \le 2 \log_2(N + 1)</math>.
::Da die Komplexität der Baumoperationen <math>f(N) = \mathcal{O}(d)</math> ist, gilt für den Andersson-Baum:
:::<math>f(N) = \mathcal{O}(2 \log_2(N + 1)) = \mathcal{O}(\log(N))</math>
::q.e.d.

====Wie erreicht man die Balance?====

Der Baum ist nicht mehr balanciert, wenn obige Regeln verletzt sind. Dies kann durch Einfügen eines neuen Knotens oder durch Löschen eines Knotens passieren. Nach jeder Einfügung haben sowohl der neue Knoten als auch sein Vater das Level 1 (denn der Vater war vorher direkt mit dem Sentinel verbunden). Kanten zu neu eingefügten Knoten sind deshalb immer horizontal. Dies kann die Regeln verletzen, indem entweder
* eine horizontale Kante zum linken Kind enstanden ist (falls der neue Knoten ein linkes Kind ist), oder
* zwei aufeinander folgende horizontale Kanten zu rechten Kindern entstanden sind (falls der neue Knoten ein rechtes Kind ist, und sein Vater bereits ein horizontales rechtes Kind war).
Diese Fehler können durch Rotation leicht behoben werden:
* Linke horizontale Kanten werden durch Rechtsrotation in rechte horizontale Kanten verwandelt.
* Bei zwei aufeinander folgenden rechten horizontalen Kanten wird der mittlere Knoten um eine Ebene angehoben.
Dabei ist zu beachten, dass die erste Reparatur einen neuen Fehler erzeugen kann: Es können zwei aufeinanderfolgende rechte horizontale Kanten enstehen. Daher muss die zweite Operation stets nach der ersten ausgeführt werden. Das Anheben des Levels in der zweiten Operation kann wiederum dazu führen, dass auf der nächsthöheren Ebene verbotene horizontale Kanten entstehen. Deshalb müssen die Reparaturoperationen auf der nächsten Ebene rekursiv wiederholt werden. Dies führt uns zu folgender Implementation des Insert-Algorithmus

def anderssonTreeInsert(node,key):
if node is None:
return AnderssonNode(key)
if node.key == key:
return node
if key < node.key:
node.left = anderssonTreeInsert(node.left, key)
else:
node.right = anderssonTreeInsert(node.right, key)
if node.left is not None and node.level == node.left.level: # linke horizontale Kante
node = rotateRight(node) # wird zu rechter horizontaler Kante gemacht
if node.right is not None and node.right.right is not None and node.level==node.right.right.level: # aufeinanderfolgende horizontale Kanten
node = rotateLeft(node) # mache den mittleren Knoten zur Wurzel des Teilbaums
node.level += 1 # und hebe die Wurzel um ein level an
return node

Da die Reparaturoperationen auf dem Rückweg von der Rekursion ausgeführt werden, ist gewährleistet, dass sie auf der nächsten Ebene des Baumes ebenfalls ausgeführt werden, falls nötig. Die folgende Skizze verdeutlicht die Anwendung der Reparaturen, wenn Knoten ''c'' über eine linke horizontale Kante an Knoten ''b'' angefügt wurde. Im oberen Beispiel genügt die erste Operation zur Reparatur, beim unteren Beispiel muss hingegen auch noch die zweite Operation angewendet werden.

[[Image:rotate.jpg|text-top]]

Die folgende Illustration verdeutlicht das Verhalten des Andersson-Baumes, wenn die Schlüssel in der Folge [5,4,3,2,1] eingefügt werden. Beim einfachen Binärbaum sind solche vorsortierten Daten sehr ungünstig und führen zu entarteten Bäumen mit linearer Zugriffzeit. Die Umstrukturierungen beim Andersson-Baum stellen hingegen sicher, dass die Balance immer gewahrt bleibt. Wir stellen die Knoten hier als Paare <tt>(key, level)</tt> dar, Pfeile markieren die Richtung von horizontalen Kanten. Wie oben beschrieben, werden neue Knoten zunächst normal in den Baum eingefügt und ihr Level mit 1 initialisiert. Wenn dadurch Bedingungen verletzt werden, werden die notwendigen Umstrukturierungen durchgeführt.

Beim Einfügen des ersten Knotens (Schlüssel 5) gibt es noch keine Probleme:

(5,1)

Der zweite Knoten (Schlüssel 4) wird zum linken Kind des ersten. Da beide Knoten sich auf Level 1 befinden, ensteht dadurch eine verbotene horizontale Kante nach links, die durch eine Rechtsrotation (RR) in eine erlaubte horizontale Kante nach rechts umgewandelt wird. Danach ist Knoten 4 die neue Wurzel des Baumes:

(4,1) <-- (5,1) ==RR==> (4,1) --> (5,1)

Das Einfügen von Schlüssel 3 verursacht wieder eine horizontale linke Kante, die in eine rechte umgewandelt wird:

(3,1) <-- (4,1) --> (5,1) ==RR==> (3,1) --> (4,1) --> (5,1)

Nun gibt es aber zwei horizontale Kanten hintereinander. Wir führen deshalb eine Linksrotation (LR) durch und heben das Level des mittleren Knotens um 1 an:

(4,2)
/ \
(3,1) --> (4,1) --> (5,1) ==LR==> (3,1) <-- (4,1) --> (5,1) ==Lift==> (3,1) (5,1)

Damit ist der Baum wieder korrekt. Das Einfügen des Schlüssels 2 führt wieder zu einer verbotenen linken Kante, die durch Rechtsrotation beseitigt wird:

(4,2)
(4,2) / \
/ \ ==RR==> / \
(2,1) <-- (3,1) (5,1) / \
(2,1)-->(3,1) (5,1)

Nun fügen wir Schlüssel 1 ein, der ebenfalls zu einer verbotenen linken Kante führt, aber die Reparatur des Fehlers durch Rechstsrotation würde zwei aufeinanderfolgende horizontale Kanten erzeugen. Knoten 2 muss deshalb angehoben werden:

(4,2) (2,2) <-- (4,2)
/ \ / \ \
/ \ ===> / \ \
/ \ / \ \
(1,1) <-- (2,1)-->(3,1) (5,1) (1,1) (3,1) (5,1)

Jetzt ist aber bei Level 2 eine verbotene linke horizontale Kante entstanden, die wir wieder durch Rechtsrotation in eine erlaubte rechte horizontale Kante verwandeln, so dass Knoten 2 nun die Wurzel des Baumes bildet:

(2,2) <-- (4,2) (2,2) --> (4,2)
/ \ \ / / \
/ \ \ ===> / / \
/ \ \ / / \
(1,1) (3,1) (5,1) (1,1) (3,1) (5,1)

Jetzt sind alle Bedingungen erfüllt. Man erkennt, dass alle reduzierten RS-Pfade die gleiche Länge, nämlich 2, haben (dies entspricht gerade dem Level der Wurzel des Baumes). Die tatsächliche Tiefe des Baumes (längster Pfad von der Wurzel zu einem Blatt, wobei horizontale Kanten mitgezählt werden) beträgt 2. Für einen Binärbaum mit 5 Knoten ist die Tiefe 2 gerade der beste erreichbare Wert, der Andersson-Baum verhält sich hier also optimal.

Die Löschoperation <tt>anderssonTreeRemove</tt> benötigt in jedem Knoten bis zu 5 Rotationen. Wegen der Einzelheiten verweisen wir auf Anderssons [http://user.it.uu.se/~arnea/abs/simp.html Originalartikel].

==Beziehungen zwischen dem Suchproblem und dem Sortierproblem==

===Sortieren mit Hilfe eines selbst-balancierenden Suchbaums===

Mit Hilfe eines selbst-balancierenden Suchbaums kann ein effizienter Sortieralgorithmus implementiert werden, indem man zunächst die Daten in beliebiger Reihenfolge in einen Baum einfügt, und dann in der richtigen Sortierung wieder ausliest.

a = ... # unsortiertes Array
t = None # leerer Andersson-Baum
for e in a:
t = anderssonTreeInsert(t, e) # Baum erzeugen
r = [] # leeres dynamisches Array
treeSort(t, r)
# r enthält jetzt die Daten aus a in sortierter Reihenfolge

Die Funktion <tt>treeSort</tt> navigiert im Sinne eines sogenannten ''in-order traversals'' durch den Baum und fügt die Datenelemente in der richtigen Reihenfolge an des Array an:

def treeSort(node,array): # dynamisches Array als 2. Argument
if node is None: # <math>\mathcal{O}(1)</math>
return
treeSort(node.left, array) # rekursiv
array.append(node.key) # amortisiert <math>\mathcal{O}(1)</math>
treeSort(node.right, array) # rekursiv

;Komplexität:

* Jede Einfügeoperation in den Baum hat logarithmische Komplexität. Der Aufbau eines Baumes aus N Elementen hat daher Komplexität <math>\mathcal{O}(N \log(N))</math>.
* <tt>treeSort</tt> führt in jedem Knoten eine oder zwei Operationen mit Komplexität <math>\mathcal{O}(1)</math> sowie zwei rekursive Aufrufe aus. Die Auflösung der Rekursion ergibt
<math>
f(N)=\mathcal{O}(1)+f(N_\mathrm{left})+f(N_\mathrm{right})=\mathcal{O}(1)+\mathcal{O}(1)+f(N_\mathrm{left.left})+f(N_\mathrm{left.right})+\mathcal{O}(1)+f(N_\mathrm{right.left})
+f(N_\mathrm{left.right})=N\cdot\mathcal{O}(1)=\mathcal{O}(N)
</math>
* Insgesamt erhalten wir also Komplexität <math>\mathcal{O}(\max(N \log(N), N)) = \mathcal{O}(N \log(N))</math> wie bei Merge Sort. Allerdings sind der konstante Faktor sowie der Speicherverbrauch größer, so dass diese Sortiermethode in der Praxis kaum angewendet wird.

===Sortieren als Suchproblem===

Diesem Thema ist jetzt ein eigenes Kapitel [[Sortieren in linearer Zeit]] gewidmet.

[[Sortieren in linearer Zeit|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-30T11:56:17Z

Ukoethe: /* 2. RANSAC-ALGORITHMUS (Random Sample Consensus) */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

== Anwendung: Lösen des K-SAT-Problems ==

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

===Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk===

Um die Random Walk Analyse zu verstehen, betrachten wir folgendes Spiel:

geg.: eine Stuhlreihe mit N Stühlen. Wir nummerieren die Stühle so, dass links der Stuhl 0 und rechts der Stuhl N steht.

* Eine Person setzt sich zufällig auf einen der Stühle.
* Eine zweite Person wirft eine Münze.

Wenn die Münze auf Zahl fällt, rückt die erste Person einen Stuhl nach links, andernfalls nach rechts.
<--- Zahl Kopf --->

* Frage: Wie oft muss man die Münze im Durchschnitt werfen, bis Person 1 zum ersten Mal auf Stuhl N sitzt?

Da die erste Person sich anfangs zufällig hinsetzt, haben wir eine Chance von 1/N, dass sie gleich auf dem richtigen Stuhl landet und wir 0 Schritte benötigen. Mit der gleichen Wahrscheinlichkeit von 1/N setzt sie sich anfangs auf Stuhl Nummer (N-1), und wir haben eine fifty-fifty-Chance, mit nur einem Wurf durchzukommen. Wir können aber auch Pech haben und landen auf Stuhl Nummer (N-2). Das ist das Gleiche, als wenn Person 1 von Anfang an auf diesem Stuhl gesessen hätte, nur dass wir jetzt bereits einen Wurf verbraucht haben. Man sieht, dass man die Zahl der Restwürfe immer in dieser Art ausdrücken kann: Sitzt Person 1 auf Stuhl <tt>i</tt>, kann sie entweder nach rechts rücken und benötigt dann noch soviele Würfe, wie man typischerweise für Stuhl <tt>i+1</tt> benötigt, plus den Wurf von <tt>i => i+1</tt>. Oder sie kann nach links rücken und benötigt dann die typische Wurfzahl für Stuhl <tt>i-1</tt> plus den Wurf <tt>i => i-1</tt>. Beide Möglichkeiten haben die Wahrscheinlichkeit 1/2. Mathematisch kann man dies elegant als Rekursionsformel schreiben, die die erwartete Wurfzahl für Stuhl <tt>i</tt> als Funktion der entsprechenden Wurfzahlen für die Stühle <tt>i-1</tt> und <tt>i+1</tt> ausdrückt:

* Wenn wir uns auf Stuhl N befinden, werfen wir gar nicht: <math>W\left(N\right)=0</math>
* Von Stuhl 0 gehen wir immer zu Stuhl 1: <math>W\left(0\right)=1 + W\left(1\right)</math>
* Allgemeiner Fall: <math>W\left(i\right)=\frac 1 2 \left(1 + W\left(i+1\right)\right) + \frac 1 2 \left(1 + W\left(i-1\right)\right) = \frac 1 2 W\left(i+1\right) + \frac 1 2 W\left(i-1\right) +1 </math>
Diese Rekursion wird durch die explizite Formel
::<math>W\left(i\right)= N^2 - i^2</math>
gelöst, wie man durch Einsetzen leicht nachprüft:
::<math>
\begin{align}
W\left(N\right) & = N^2-N^2=0 \\

W\left(0\right) &= W\left(1\right)+1 \\

&= N^2-1^2+1 \\

&= N^2 - 0^2\\

W\left(i\right) &= \frac 1 2 \left(N^2-\left(i-1\right)^2\right) + \frac 1 2 \left(N^2-\left(i+1\right)^2\right)+1 \\

&= \frac 1 2 N^2-\frac 1 2 \left( i^2-2i+1\right) + \frac 1 2 N^2-\frac 1 2 \left(i^2+2i+1\right) + 1 \\

&= N^2-i^2
\end{align}</math>
Insbesondere braucht man im ungünstigen Fall (Start auf Stuhl 0) im Durchschnitt <math>N^2</math> Würfe, im typischen Fall (Start in der Mitte, also bei <math>i = N/2</math>) im Durchschnitt
:<math>N^2 - (N/2)^2=\frac 3 4 N^2\in O(N^2)</math>
Würfe. Die '''Beziehung zum randomisiertem 2-SAT-Algorithmus''' ist jetzt leicht zu erkennen. Sitzt die Person auf Stuhl <tt>i</tt>, interpretieren wir das als:

"Stuhl <math>i</math>": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

Wählt der Algorithmus eine Klausel, die nicht erfüllt ist, gibt es zwei Möglichkeiten:
# Beide Literale in der Klausel haben den falschen Wert: Die Lösung wird auf jeden Fall besser, egal welche der beiden wir umdrehen. Wir gehen also von Zustand <tt>i</tt> zu Zustand <tt>i+1</tt>.
# Nur eins der Literale hat den falschen Wert: Beim Umdrehen haben wir eine fifty-fifty-Chance, das richtige Literal zu wählen und in den Zustand <tt>i+1</tt> zu gelangen. Mit der selben Wahrscheinlichkeit wählen wir das falsche Literal und landen im Zustand <tt>i-1</tt>.
Falls 2 ist der ungünstigere und entspricht unserem Spiel, dessen Analyse wir deshalb einfach auf das 2-SAT-Problem übertragen können: Ziel des Algorithmus ist es, in den Zustand N zu gelangen, und deshalb gilt genau wie beim Spiel der
;Satz: Der randomisierte 2-SAT-Algorithmus findet im Durchschnitt nach <math>O(N^2)</math> Versuchen eine Lösung, wenn das Problem erfüllbar ist.
Damit ist der randomisierte Algorithmus für dieses Problem effizient, was Sie in Übung 12 experimentell nachprüfen sollen.

== RANSAC-Algorithmus (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-30T11:55:43Z

Ukoethe: /* Las Vegas vs. Monte Carlo */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

== Anwendung: Lösen des K-SAT-Problems ==

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

===Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk===

Um die Random Walk Analyse zu verstehen, betrachten wir folgendes Spiel:

geg.: eine Stuhlreihe mit N Stühlen. Wir nummerieren die Stühle so, dass links der Stuhl 0 und rechts der Stuhl N steht.

* Eine Person setzt sich zufällig auf einen der Stühle.
* Eine zweite Person wirft eine Münze.

Wenn die Münze auf Zahl fällt, rückt die erste Person einen Stuhl nach links, andernfalls nach rechts.
<--- Zahl Kopf --->

* Frage: Wie oft muss man die Münze im Durchschnitt werfen, bis Person 1 zum ersten Mal auf Stuhl N sitzt?

Da die erste Person sich anfangs zufällig hinsetzt, haben wir eine Chance von 1/N, dass sie gleich auf dem richtigen Stuhl landet und wir 0 Schritte benötigen. Mit der gleichen Wahrscheinlichkeit von 1/N setzt sie sich anfangs auf Stuhl Nummer (N-1), und wir haben eine fifty-fifty-Chance, mit nur einem Wurf durchzukommen. Wir können aber auch Pech haben und landen auf Stuhl Nummer (N-2). Das ist das Gleiche, als wenn Person 1 von Anfang an auf diesem Stuhl gesessen hätte, nur dass wir jetzt bereits einen Wurf verbraucht haben. Man sieht, dass man die Zahl der Restwürfe immer in dieser Art ausdrücken kann: Sitzt Person 1 auf Stuhl <tt>i</tt>, kann sie entweder nach rechts rücken und benötigt dann noch soviele Würfe, wie man typischerweise für Stuhl <tt>i+1</tt> benötigt, plus den Wurf von <tt>i => i+1</tt>. Oder sie kann nach links rücken und benötigt dann die typische Wurfzahl für Stuhl <tt>i-1</tt> plus den Wurf <tt>i => i-1</tt>. Beide Möglichkeiten haben die Wahrscheinlichkeit 1/2. Mathematisch kann man dies elegant als Rekursionsformel schreiben, die die erwartete Wurfzahl für Stuhl <tt>i</tt> als Funktion der entsprechenden Wurfzahlen für die Stühle <tt>i-1</tt> und <tt>i+1</tt> ausdrückt:

* Wenn wir uns auf Stuhl N befinden, werfen wir gar nicht: <math>W\left(N\right)=0</math>
* Von Stuhl 0 gehen wir immer zu Stuhl 1: <math>W\left(0\right)=1 + W\left(1\right)</math>
* Allgemeiner Fall: <math>W\left(i\right)=\frac 1 2 \left(1 + W\left(i+1\right)\right) + \frac 1 2 \left(1 + W\left(i-1\right)\right) = \frac 1 2 W\left(i+1\right) + \frac 1 2 W\left(i-1\right) +1 </math>
Diese Rekursion wird durch die explizite Formel
::<math>W\left(i\right)= N^2 - i^2</math>
gelöst, wie man durch Einsetzen leicht nachprüft:
::<math>
\begin{align}
W\left(N\right) & = N^2-N^2=0 \\

W\left(0\right) &= W\left(1\right)+1 \\

&= N^2-1^2+1 \\

&= N^2 - 0^2\\

W\left(i\right) &= \frac 1 2 \left(N^2-\left(i-1\right)^2\right) + \frac 1 2 \left(N^2-\left(i+1\right)^2\right)+1 \\

&= \frac 1 2 N^2-\frac 1 2 \left( i^2-2i+1\right) + \frac 1 2 N^2-\frac 1 2 \left(i^2+2i+1\right) + 1 \\

&= N^2-i^2
\end{align}</math>
Insbesondere braucht man im ungünstigen Fall (Start auf Stuhl 0) im Durchschnitt <math>N^2</math> Würfe, im typischen Fall (Start in der Mitte, also bei <math>i = N/2</math>) im Durchschnitt
:<math>N^2 - (N/2)^2=\frac 3 4 N^2\in O(N^2)</math>
Würfe. Die '''Beziehung zum randomisiertem 2-SAT-Algorithmus''' ist jetzt leicht zu erkennen. Sitzt die Person auf Stuhl <tt>i</tt>, interpretieren wir das als:

"Stuhl <math>i</math>": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

Wählt der Algorithmus eine Klausel, die nicht erfüllt ist, gibt es zwei Möglichkeiten:
# Beide Literale in der Klausel haben den falschen Wert: Die Lösung wird auf jeden Fall besser, egal welche der beiden wir umdrehen. Wir gehen also von Zustand <tt>i</tt> zu Zustand <tt>i+1</tt>.
# Nur eins der Literale hat den falschen Wert: Beim Umdrehen haben wir eine fifty-fifty-Chance, das richtige Literal zu wählen und in den Zustand <tt>i+1</tt> zu gelangen. Mit der selben Wahrscheinlichkeit wählen wir das falsche Literal und landen im Zustand <tt>i-1</tt>.
Falls 2 ist der ungünstigere und entspricht unserem Spiel, dessen Analyse wir deshalb einfach auf das 2-SAT-Problem übertragen können: Ziel des Algorithmus ist es, in den Zustand N zu gelangen, und deshalb gilt genau wie beim Spiel der
;Satz: Der randomisierte 2-SAT-Algorithmus findet im Durchschnitt nach <math>O(N^2)</math> Versuchen eine Lösung, wenn das Problem erfüllbar ist.
Damit ist der randomisierte Algorithmus für dieses Problem effizient, was Sie in Übung 12 experimentell nachprüfen sollen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-30T11:55:15Z

Ukoethe: /* Anwendung: Lösen des K-SAT-Problems */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

== Anwendung: Lösen des K-SAT-Problems ==

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

===Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk===

Um die Random Walk Analyse zu verstehen, betrachten wir folgendes Spiel:

geg.: eine Stuhlreihe mit N Stühlen. Wir nummerieren die Stühle so, dass links der Stuhl 0 und rechts der Stuhl N steht.

* Eine Person setzt sich zufällig auf einen der Stühle.
* Eine zweite Person wirft eine Münze.

Wenn die Münze auf Zahl fällt, rückt die erste Person einen Stuhl nach links, andernfalls nach rechts.
<--- Zahl Kopf --->

* Frage: Wie oft muss man die Münze im Durchschnitt werfen, bis Person 1 zum ersten Mal auf Stuhl N sitzt?

Da die erste Person sich anfangs zufällig hinsetzt, haben wir eine Chance von 1/N, dass sie gleich auf dem richtigen Stuhl landet und wir 0 Schritte benötigen. Mit der gleichen Wahrscheinlichkeit von 1/N setzt sie sich anfangs auf Stuhl Nummer (N-1), und wir haben eine fifty-fifty-Chance, mit nur einem Wurf durchzukommen. Wir können aber auch Pech haben und landen auf Stuhl Nummer (N-2). Das ist das Gleiche, als wenn Person 1 von Anfang an auf diesem Stuhl gesessen hätte, nur dass wir jetzt bereits einen Wurf verbraucht haben. Man sieht, dass man die Zahl der Restwürfe immer in dieser Art ausdrücken kann: Sitzt Person 1 auf Stuhl <tt>i</tt>, kann sie entweder nach rechts rücken und benötigt dann noch soviele Würfe, wie man typischerweise für Stuhl <tt>i+1</tt> benötigt, plus den Wurf von <tt>i => i+1</tt>. Oder sie kann nach links rücken und benötigt dann die typische Wurfzahl für Stuhl <tt>i-1</tt> plus den Wurf <tt>i => i-1</tt>. Beide Möglichkeiten haben die Wahrscheinlichkeit 1/2. Mathematisch kann man dies elegant als Rekursionsformel schreiben, die die erwartete Wurfzahl für Stuhl <tt>i</tt> als Funktion der entsprechenden Wurfzahlen für die Stühle <tt>i-1</tt> und <tt>i+1</tt> ausdrückt:

* Wenn wir uns auf Stuhl N befinden, werfen wir gar nicht: <math>W\left(N\right)=0</math>
* Von Stuhl 0 gehen wir immer zu Stuhl 1: <math>W\left(0\right)=1 + W\left(1\right)</math>
* Allgemeiner Fall: <math>W\left(i\right)=\frac 1 2 \left(1 + W\left(i+1\right)\right) + \frac 1 2 \left(1 + W\left(i-1\right)\right) = \frac 1 2 W\left(i+1\right) + \frac 1 2 W\left(i-1\right) +1 </math>
Diese Rekursion wird durch die explizite Formel
::<math>W\left(i\right)= N^2 - i^2</math>
gelöst, wie man durch Einsetzen leicht nachprüft:
::<math>
\begin{align}
W\left(N\right) & = N^2-N^2=0 \\

W\left(0\right) &= W\left(1\right)+1 \\

&= N^2-1^2+1 \\

&= N^2 - 0^2\\

W\left(i\right) &= \frac 1 2 \left(N^2-\left(i-1\right)^2\right) + \frac 1 2 \left(N^2-\left(i+1\right)^2\right)+1 \\

&= \frac 1 2 N^2-\frac 1 2 \left( i^2-2i+1\right) + \frac 1 2 N^2-\frac 1 2 \left(i^2+2i+1\right) + 1 \\

&= N^2-i^2
\end{align}</math>
Insbesondere braucht man im ungünstigen Fall (Start auf Stuhl 0) im Durchschnitt <math>N^2</math> Würfe, im typischen Fall (Start in der Mitte, also bei <math>i = N/2</math>) im Durchschnitt
:<math>N^2 - (N/2)^2=\frac 3 4 N^2\in O(N^2)</math>
Würfe. Die '''Beziehung zum randomisiertem 2-SAT-Algorithmus''' ist jetzt leicht zu erkennen. Sitzt die Person auf Stuhl <tt>i</tt>, interpretieren wir das als:

"Stuhl <math>i</math>": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

Wählt der Algorithmus eine Klausel, die nicht erfüllt ist, gibt es zwei Möglichkeiten:
# Beide Literale in der Klausel haben den falschen Wert: Die Lösung wird auf jeden Fall besser, egal welche der beiden wir umdrehen. Wir gehen also von Zustand <tt>i</tt> zu Zustand <tt>i+1</tt>.
# Nur eins der Literale hat den falschen Wert: Beim Umdrehen haben wir eine fifty-fifty-Chance, das richtige Literal zu wählen und in den Zustand <tt>i+1</tt> zu gelangen. Mit der selben Wahrscheinlichkeit wählen wir das falsche Literal und landen im Zustand <tt>i-1</tt>.
Falls 2 ist der ungünstigere und entspricht unserem Spiel, dessen Analyse wir deshalb einfach auf das 2-SAT-Problem übertragen können: Ziel des Algorithmus ist es, in den Zustand N zu gelangen, und deshalb gilt genau wie beim Spiel der
;Satz: Der randomisierte 2-SAT-Algorithmus findet im Durchschnitt nach <math>O(N^2)</math> Versuchen eine Lösung, wenn das Problem erfüllbar ist.
Damit ist der randomisierte Algorithmus für dieses Problem effizient, was Sie in Übung 12 experimentell nachprüfen sollen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-30T11:54:03Z

Ukoethe: /* 2. RANSAC-ALGORITHMUS (Random Sample Consensus) */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

====Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk====

Um die Random Walk Analyse zu verstehen, betrachten wir folgendes Spiel:

geg.: eine Stuhlreihe mit N Stühlen. Wir nummerieren die Stühle so, dass links der Stuhl 0 und rechts der Stuhl N steht.

* Eine Person setzt sich zufällig auf einen der Stühle.
* Eine zweite Person wirft eine Münze.

Wenn die Münze auf Zahl fällt, rückt die erste Person einen Stuhl nach links, andernfalls nach rechts.
<--- Zahl Kopf --->

* Frage: Wie oft muss man die Münze im Durchschnitt werfen, bis Person 1 zum ersten Mal auf Stuhl N sitzt?

Da die erste Person sich anfangs zufällig hinsetzt, haben wir eine Chance von 1/N, dass sie gleich auf dem richtigen Stuhl landet und wir 0 Schritte benötigen. Mit der gleichen Wahrscheinlichkeit von 1/N setzt sie sich anfangs auf Stuhl Nummer (N-1), und wir haben eine fifty-fifty-Chance, mit nur einem Wurf durchzukommen. Wir können aber auch Pech haben und landen auf Stuhl Nummer (N-2). Das ist das Gleiche, als wenn Person 1 von Anfang an auf diesem Stuhl gesessen hätte, nur dass wir jetzt bereits einen Wurf verbraucht haben. Man sieht, dass man die Zahl der Restwürfe immer in dieser Art ausdrücken kann: Sitzt Person 1 auf Stuhl <tt>i</tt>, kann sie entweder nach rechts rücken und benötigt dann noch soviele Würfe, wie man typischerweise für Stuhl <tt>i+1</tt> benötigt, plus den Wurf von <tt>i => i+1</tt>. Oder sie kann nach links rücken und benötigt dann die typische Wurfzahl für Stuhl <tt>i-1</tt> plus den Wurf <tt>i => i-1</tt>. Beide Möglichkeiten haben die Wahrscheinlichkeit 1/2. Mathematisch kann man dies elegant als Rekursionsformel schreiben, die die erwartete Wurfzahl für Stuhl <tt>i</tt> als Funktion der entsprechenden Wurfzahlen für die Stühle <tt>i-1</tt> und <tt>i+1</tt> ausdrückt:

* Wenn wir uns auf Stuhl N befinden, werfen wir gar nicht: <math>W\left(N\right)=0</math>
* Von Stuhl 0 gehen wir immer zu Stuhl 1: <math>W\left(0\right)=1 + W\left(1\right)</math>
* Allgemeiner Fall: <math>W\left(i\right)=\frac 1 2 \left(1 + W\left(i+1\right)\right) + \frac 1 2 \left(1 + W\left(i-1\right)\right) = \frac 1 2 W\left(i+1\right) + \frac 1 2 W\left(i-1\right) +1 </math>
Diese Rekursion wird durch die explizite Formel
::<math>W\left(i\right)= N^2 - i^2</math>
gelöst, wie man durch Einsetzen leicht nachprüft:
::<math>
\begin{align}
W\left(N\right) & = N^2-N^2=0 \\

W\left(0\right) &= W\left(1\right)+1 \\

&= N^2-1^2+1 \\

&= N^2 - 0^2\\

W\left(i\right) &= \frac 1 2 \left(N^2-\left(i-1\right)^2\right) + \frac 1 2 \left(N^2-\left(i+1\right)^2\right)+1 \\

&= \frac 1 2 N^2-\frac 1 2 \left( i^2-2i+1\right) + \frac 1 2 N^2-\frac 1 2 \left(i^2+2i+1\right) + 1 \\

&= N^2-i^2
\end{align}</math>
Insbesondere braucht man im ungünstigen Fall (Start auf Stuhl 0) im Durchschnitt <math>N^2</math> Würfe, im typischen Fall (Start in der Mitte, also bei <math>i = N/2</math>) im Durchschnitt
:<math>N^2 - (N/2)^2=\frac 3 4 N^2\in O(N^2)</math>
Würfe. Die '''Beziehung zum randomisiertem 2-SAT-Algorithmus''' ist jetzt leicht zu erkennen. Sitzt die Person auf Stuhl <tt>i</tt>, interpretieren wir das als:

"Stuhl <math>i</math>": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

Wählt der Algorithmus eine Klausel, die nicht erfüllt ist, gibt es zwei Möglichkeiten:
# Beide Literale in der Klausel haben den falschen Wert: Die Lösung wird auf jeden Fall besser, egal welche der beiden wir umdrehen. Wir gehen also von Zustand <tt>i</tt> zu Zustand <tt>i+1</tt>.
# Nur eins der Literale hat den falschen Wert: Beim Umdrehen haben wir eine fifty-fifty-Chance, das richtige Literal zu wählen und in den Zustand <tt>i+1</tt> zu gelangen. Mit der selben Wahrscheinlichkeit wählen wir das falsche Literal und landen im Zustand <tt>i-1</tt>.
Falls 2 ist der ungünstigere und entspricht unserem Spiel, dessen Analyse wir deshalb einfach auf das 2-SAT-Problem übertragen können: Ziel des Algorithmus ist es, in den Zustand N zu gelangen, und deshalb gilt genau wie beim Spiel der
;Satz: Der randomisierte 2-SAT-Algorithmus findet im Durchschnitt nach <math>O(N^2)</math> Versuchen eine Lösung, wenn das Problem erfüllbar ist.
Damit ist der randomisierte Algorithmus für dieses Problem effizient, was Sie in Übung 12 experimentell nachprüfen sollen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-30T11:52:01Z

Ukoethe: /* Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

====Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk====

Um die Random Walk Analyse zu verstehen, betrachten wir folgendes Spiel:

geg.: eine Stuhlreihe mit N Stühlen. Wir nummerieren die Stühle so, dass links der Stuhl 0 und rechts der Stuhl N steht.

* Eine Person setzt sich zufällig auf einen der Stühle.
* Eine zweite Person wirft eine Münze.

Wenn die Münze auf Zahl fällt, rückt die erste Person einen Stuhl nach links, andernfalls nach rechts.
<--- Zahl Kopf --->

* Frage: Wie oft muss man die Münze im Durchschnitt werfen, bis Person 1 zum ersten Mal auf Stuhl N sitzt?

Da die erste Person sich anfangs zufällig hinsetzt, haben wir eine Chance von 1/N, dass sie gleich auf dem richtigen Stuhl landet und wir 0 Schritte benötigen. Mit der gleichen Wahrscheinlichkeit von 1/N setzt sie sich anfangs auf Stuhl Nummer (N-1), und wir haben eine fifty-fifty-Chance, mit nur einem Wurf durchzukommen. Wir können aber auch Pech haben und landen auf Stuhl Nummer (N-2). Das ist das Gleiche, als wenn Person 1 von Anfang an auf diesem Stuhl gesessen hätte, nur dass wir jetzt bereits einen Wurf verbraucht haben. Man sieht, dass man die Zahl der Restwürfe immer in dieser Art ausdrücken kann: Sitzt Person 1 auf Stuhl <tt>i</tt>, kann sie entweder nach rechts rücken und benötigt dann noch soviele Würfe, wie man typischerweise für Stuhl <tt>i+1</tt> benötigt, plus den Wurf von <tt>i => i+1</tt>. Oder sie kann nach links rücken und benötigt dann die typische Wurfzahl für Stuhl <tt>i-1</tt> plus den Wurf <tt>i => i-1</tt>. Beide Möglichkeiten haben die Wahrscheinlichkeit 1/2. Mathematisch kann man dies elegant als Rekursionsformel schreiben, die die erwartete Wurfzahl für Stuhl <tt>i</tt> als Funktion der entsprechenden Wurfzahlen für die Stühle <tt>i-1</tt> und <tt>i+1</tt> ausdrückt:

* Wenn wir uns auf Stuhl N befinden, werfen wir gar nicht: <math>W\left(N\right)=0</math>
* Von Stuhl 0 gehen wir immer zu Stuhl 1: <math>W\left(0\right)=1 + W\left(1\right)</math>
* Allgemeiner Fall: <math>W\left(i\right)=\frac 1 2 \left(1 + W\left(i+1\right)\right) + \frac 1 2 \left(1 + W\left(i-1\right)\right) = \frac 1 2 W\left(i+1\right) + \frac 1 2 W\left(i-1\right) +1 </math>
Diese Rekursion wird durch die explizite Formel
::<math>W\left(i\right)= N^2 - i^2</math>
gelöst, wie man durch Einsetzen leicht nachprüft:
::<math>
\begin{align}
W\left(N\right) & = N^2-N^2=0 \\

W\left(0\right) &= W\left(1\right)+1 \\

&= N^2-1^2+1 \\

&= N^2 - 0^2\\

W\left(i\right) &= \frac 1 2 \left(N^2-\left(i-1\right)^2\right) + \frac 1 2 \left(N^2-\left(i+1\right)^2\right)+1 \\

&= \frac 1 2 N^2-\frac 1 2 \left( i^2-2i+1\right) + \frac 1 2 N^2-\frac 1 2 \left(i^2+2i+1\right) + 1 \\

&= N^2-i^2
\end{align}</math>
Insbesondere braucht man im ungünstigen Fall (Start auf Stuhl 0) im Durchschnitt <math>N^2</math> Würfe, im typischen Fall (Start in der Mitte, also bei <math>i = N/2</math>) im Durchschnitt
:<math>N^2 - (N/2)^2=\frac 3 4 N^2\in O(N^2)</math>
Würfe. Die '''Beziehung zum randomisiertem 2-SAT-Algorithmus''' ist jetzt leicht zu erkennen. Sitzt die Person auf Stuhl <tt>i</tt>, interpretieren wir das als:

"Stuhl <math>i</math>": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

Wählt der Algorithmus eine Klausel, die nicht erfüllt ist, gibt es zwei Möglichkeiten:
# Beide Literale in der Klausel haben den falschen Wert: Die Lösung wird auf jeden Fall besser, egal welche der beiden wir umdrehen. Wir gehen also von Zustand <tt>i</tt> zu Zustand <tt>i+1</tt>.
# Nur eins der Literale hat den falschen Wert: Beim Umdrehen haben wir eine fifty-fifty-Chance, das richtige Literal zu wählen und in den Zustand <tt>i+1</tt> zu gelangen. Mit der selben Wahrscheinlichkeit wählen wir das falsche Literal und landen im Zustand <tt>i-1</tt>.
Falls 2 ist der ungünstigere und entspricht unserem Spiel, dessen Analyse wir deshalb einfach auf das 2-SAT-Problem übertragen können: Ziel des Algorithmus ist es, in den Zustand N zu gelangen, und deshalb gilt genau wie beim Spiel der
;Satz: Der randomisierte 2-SAT-Algorithmus findet im Durchschnitt nach <math>O(N^2)</math> Versuchen eine Lösung, wenn das Problem erfüllbar ist.
Damit ist der randomisierte Algorithmus für dieses Problem effizient, was Sie in Übung 12 experimentell nachprüfen sollen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-30T11:50:40Z

Ukoethe: /* Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

====Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk====

Um die Random Walk Analyse zu verstehen, betrachten wir folgendes Spiel:

geg.: eine Stuhlreihe mit N Stühlen. Wir nummerieren die Stühle so, dass links der Stuhl 0 und rechts der Stuhl N steht.

* Eine Person setzt sich zufällig auf einen der Stühle.
* Eine zweite Person wirft eine Münze.

Wenn die Münze auf Zahl fällt, rückt die erste Person einen Stuhl nach links, andernfalls nach rechts.
<--- Zahl Kopf --->

* Frage: Wie oft muss man die Münze im Durchschnitt werfen, bis Person 1 zum ersten Mal auf Stuhl N sitzt?

Da die erste Person sich anfangs zufällig hinsetzt, haben wir eine Chance von 1/N, dass sie gleich auf dem richtigen Stuhl landet und wir 0 Schritte benötigen. Mit der gleichen Wahrscheinlichkeit von 1/N setzt sie sich anfangs auf Stuhl Nummer (N-1), und wir haben eine fifty-fifty-Chance, mit nur einem Wurf durchzukommen. Wir können aber auch Pech haben und landen auf Stuhl Nummer (N-2). Das ist das Gleiche, als wenn Person 1 von Anfang an auf diesem Stuhl gesessen hätte, nur dass wir jetzt bereits einen Wurf verbraucht haben. Man sieht, dass man die Zahl der Restwürfe immer in dieser Art ausdrücken kann: Sitzt Person 1 auf Stuhl <tt>i</tt>, kann sie entweder nach rechts rücken und benötigt dann noch soviele Würfe, wie man typischerweise für Stuhl <tt>i+1</tt> benötigt, plus den Wurf von <tt>i => i+1</tt>. Oder sie kann nach links rücken und benötigt dann die typische Wurfzahl für Stuhl <tt>i-1</tt> plus den Wurf <tt>i => i-1</tt>. Beide Möglichkeiten haben die Wahrscheinlichkeit 1/2. Mathematisch kann man dies elegant als Rekursionsformel schreiben, die die erwartete Wurfzahl für Stuhl <tt>i</tt> als Funktion der entsprechenden Wurfzahlen für die Stühle <tt>i-1</tt> und <tt>i+1</tt> ausdrückt:

* Wenn wir uns auf Stuhl Nr.1 befinden, werfen wir gar nicht: <math>W\left(N\right)=0</math>
* Von Stuhl 0 gehen wir immer zu Stuhl 1: <math>W\left(0\right)=1 + W\left(1\right)</math>
* Allgemeiner Fall: <math>W\left(i\right)=\frac 1 2 \left(1 + W\left(i+1\right)\right) + \frac 1 2 \left(1 + W\left(i-1\right)\right) = \frac 1 2 W\left(i+1\right) + \frac 1 2 W\left(i-1\right) +1 </math>
Diese Rekursion wird durch die explizite Formel
::<math>W\left(i\right)= N^2 - i^2</math>
gelöst, wie man durch Einsetzen leicht nachprüft:
::<math>
\begin{align}
W\left(N\right) & = N^2-N^2=0 \\

W\left(0\right) &= W\left(1\right)+1 \\

&= N^2-1^2+1 \\

&= N^2 - 0^2\\

W\left(i\right) &= \frac 1 2 \left(N^2-\left(i-1\right)^2\right) + \frac 1 2 \left(N^2-\left(i+1\right)^2\right)+1 \\

&= \frac 1 2 N^2-\frac 1 2 \left( i^2-2i+1\right) + \frac 1 2 N^2-\frac 1 2 \left(i^2+2i+1\right) + 1 \\

&= N^2-i^2
\end{align}</math>
Insbesondere braucht man im ungünstigen Fall (Start auf Stuhl 0) im Durchschnitt <math>N^2</math> Würfe, im typischen Fall (Start in der Mitte, also bei <math>i = N/2</math>) im Durchschnitt
:<math>N^2 - (N/2)^2=\frac 3 4 N^2\in O(N^2)</math>
Würfe. Die '''Beziehung zum randomisiertem 2-SAT-Algorithmus''' ist jetzt leicht zu erkennen. Sitzt die Person auf Stuhl <tt>i</tt>, interpretieren wir das als:

"Stuhl <math>i</math>": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

Wählt der Algorithmus eine Klausel, die nicht erfüllt ist, gibt es zwei Möglichkeiten:
# Beide Literale in der Klausel haben den falschen Wert: Die Lösung wird auf jeden Fall besser, egal welche der beiden wir umdrehen. Wir gehen also von Zustand <tt>i</tt> zu Zustand <tt>i+1</tt>.
# Nur eins der Literale hat den falschen Wert: Beim Umdrehen haben wir eine fifty-fifty-Chance, das richtige Literal zu wählen und in den Zustand <tt>i+1</tt> zu gelangen. Mit der selben Wahrscheinlichkeit wählen wir das falsche Literal und landen im Zustand <tt>i-1</tt>.
Falls 2 ist der ungünstigere und entspricht unserem Spiel, dessen Analyse wir deshalb einfach auf das 2-SAT-Problem übertragen können: Ziel des Algorithmus ist es, in den Zustand N zu gelangen, und deshalb gilt genau wie beim Spiel der
;Satz: Der randomisierte 2-SAT-Algorithmus findet im Durchschnitt nach <math>O(N^2)</math> Versuchen eine Lösung, wenn das Problem erfüllbar ist.
Damit ist der randomisierte Algorithmus für dieses Problem effizient, was Sie in Übung 12 experimentell nachprüfen sollen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-30T11:50:30Z

Ukoethe: /* Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

====Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk====

Um die Random Walk Analyse zu verstehen, betrachten wir folgendes Spiel:

geg.: eine Stuhlreihe mit N Stühlen. Wir nummerieren die Stühle so, dass links der Stuhl 0 und rechts der Stuhl N steht.

* Eine Person setzt sich zufällig auf einen der Stühle.
* Eine zweite Person wirft eine Münze.

Wenn die Münze auf Zahl fällt, rückt die erste Person einen Stuhl nach links, andernfalls nach rechts.
<--- Zahl Kopf --->

* Frage: Wie oft muss man die Münze im Durchschnitt werfen, bis Person 1 zum ersten Mal auf Stuhl N sitzt?

Da die erste Person sich anfangs zufällig hinsetzt, haben wir eine Chance von 1/N, dass sie gleich auf dem richtigen Stuhl landet und wir 0 Schritte benötigen. Mit der gleichen Wahrscheinlichkeit von 1/N setzt sie sich anfangs auf Stuhl Nummer (N-1), und wir haben eine fifty-fifty-Chance, mit nur einem Wurf durchzukommen. Wir können aber auch Pech haben und landen auf Stuhl Nummer (N-2). Das ist das Gleiche, als wenn Person 1 von Anfang an auf diesem Stuhl gesessen hätte, nur dass wir jetzt bereits einen Wurf verbraucht haben. Man sieht, dass man die Zahl der Restwürfe immer in dieser Art ausdrücken kann: Sitzt Person 1 auf Stuhl <tt>i</tt>, kann sie entweder nach rechts rücken und benötigt dann noch soviele Würfe, wie man typischerweise für Stuhl <tt>i+1</tt> benötigt, plus den Wurf von <tt>i => i+1</tt>. Oder sie kann nach links rücken und benötigt dann die typische Wurfzahl für Stuhl <tt>i-1</tt> plus den Wurf <tt>i => i-1</tt>. Beide Möglichkeiten haben die Wahrscheinlichkeit 1/2. Mathematisch kann man dies elegant als Rekursionsformel schreiben, die die erwartete Wurfzahl für Stuhl <tt>i</tt> als Funktion der entsprechenden Wurfzahlen für die Stühle <tt>i-1</tt> und <tt>i+1</tt> ausdrückt:

* Wenn wir uns auf Stuhl Nr.1 befinden, werfen wir gar nicht: <math>W\left(N\right)=0</math>
* Von Stuhl 0 gehen wir immer zu Stuhl 1: <math>W\left(0\right)=1 + W\left(1\right)</math>
* Allgemeiner Fall: <math>W\left(i\right)=\frac 1 2 \left(1 + W\left(i+1\right)\right) + \frac 1 2 \left(1 + W\left(i-1\right)\right) = \frac 1 2 W\left(i+1\right) + \frac 1 2 W\left(i-1\right) +1 </math>
Diese Rekursion wird durch die explizite Formel
::<math>W\left(i\right)= N^2 - i^2</math>
gelöst, wie man durch Einsetzen leicht nachprüft:
::<math>
\begin{align}
W\left(N\right) & = N^2-N^2=0 \\

W\left(0\right) &= W\left(1\right)+1 \\

&= N^2-1^2+1 \\

&= N^2 - 0^2\\

W\left(i\right) &= \frac 1 2 \left(N^2-\left(i-1\right)^2\right) + \frac 1 2 \left(N^2-\left(i+1\right)^2\right)+1 \\

&= \frac 1 2 N^2-\frac 1 2 \left( i^2-2i+1\right) + \frac 1 2 N^2-\frac 1 2 \left(i^2+2i+1\right) + 1 \\

&= N^2-i^2
\end{align}</math>
Insbesondere braucht man im ungünstigen Fall (Start auf Stuhl 0) im Durchschnitt <math>N^2</math> Würfe, im typischen Fall (Start in der Mitte, also bei <math>i = N/2</math>) im Durchschnitt
:<math>N^2 - (N/2)^2=\frac 3 4 N^2\in O(N^2)</math>
Würfe. Die '''Beziehung zum randomisiertem 2-SAT-Algorithmus''' ist jetzt leicht zu erkennen. Sitzt die Person auf Stuhl <tt>i</tt>, interpretieren wir das als:

"Stuhl <math>i</math>": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

Wählt der Algorithmus eine Klausel, die nicht erfüllt ist, gibt es zwei Möglichkeiten:
# Beide Literale in der Klausel haben den falschen Wert: Die Lösung wird auf jeden Fall besser, egal welche der beiden wir umdrehen. Wir gehen also von Zustand <tt>i</tt> zu Zustand <tt>i+1</tt>.
# Nur eins der Literale hat den falschen Wert: Beim Umdrehen haben wir eine fifty-fifty-Chance, das richtige Literal zu wählen und in den Zustand <tt>i+1</tt> zu gelangen. Mit der selben Wahrscheinlichkeit wählen wir das falsche Literal und landen im Zustand <tt>i-1</tt>.
Falls 2 ist der ungünstigere und entspricht unserem Spiel, dessen Analyse wir deshalb einfach auf das 2-SAT-Problem übertragen können: Ziel des Algorithmus ist es, in den Zustand N zu gelangen, und deshalb gilt genau wie beim Spiel der
;Satz: Der randomisierte 2-SAT-Algorithmus findet im Durchschnitt nach <math>O(N^2)</math> Versuchen eine Lösung, wenn das Problem erfüllbar ist.
Damit ist der randomisierte Algorithmus für dieses Problem effizient, was Sie in Übung 12 experimentell nachprüfen sollen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-30T11:49:29Z

Ukoethe: /* Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

====Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk====

Um die Random Walk Analyse zu verstehen, betrachten wir folgendes Spiel:

geg.: eine Stuhlreihe mit N Stühlen. Wir nummerieren die Stühle so, dass links der Stuhl 0 und rechts der Stuhl N steht.

* Eine Person setzt sich zufällig auf einen der Stühle.
* Eine zweite Person wirft eine Münze.

Wenn die Münze auf Zahl fällt, rückt die erste Person einen Stuhl nach links, andernfalls nach rechts.
<--- Zahl Kopf --->

* Frage: Wie oft muss man die Münze im Durchschnitt werfen, bis Person 1 zum ersten Mal auf Stuhl N sitzt?

Da die erste Person sich anfangs zufällig hinsetzt, haben wir eine Chance von 1/N, dass sie gleich auf dem richtigen Stuhl landet und wir 0 Schritte benötigen. Mit der gleichen Wahrscheinlichkeit von 1/N setzt sie sich anfangs auf Stuhl Nummer (N-1), und wir haben eine fifty-fifty-Chance, mit nur einem Wurf durchzukommen. Wir können aber auch Pech haben und landen auf Stuhl Nummer (N-2). Das ist das Gleiche, als wenn Person 1 von Anfang an auf diesem Stuhl gesessen hätte, nur dass wir jetzt bereits einen Wurf verbraucht haben. Man sieht, dass man die Zahl der Restwürfe immer in dieser Art ausdrücken kann: Sitzt Person 1 auf Stuhl <tt>i</tt>, kann sie entweder nach rechts rücken und benötigt dann noch soviele Würfe, wie man typischerweise für Stuhl <tt>i+1</tt> benötigt, plus den Wurf von <tt>i => i+1</tt>. Oder sie kann nach links rücken und benötigt dann die typische Wurfzahl für Stuhl <tt>i-1</tt> plus den Wurf <tt>i => i-1</tt>. Beide Möglichkeiten haben die Wahrscheinlichkeit 1/2. Mathematisch kann man dies elegant als Rekursionsformel schreiben, die die erwartete Wurfzahl für Stuhl <tt>i</tt> als Funktion der entsprechenden Wurfzahlen für die Stühle <tt>i-1</tt> und <tt>i+1</tt> ausdrückt:

* Wenn wir uns auf Stuhl Nr.1 befinden, werfen wir gar nicht: <math>W\left(N\right)=0</math>
* Von Stuhl 0 gehen wir immer zu Stuhl 1: <math>W\left(0\right)=1 + W\left(1\right)</math>
* Allgemeiner Fall: <math>W\left(i\right)=\frac 1 2 \left(1 + W\left(i+1\right)\right) + \frac 1 2 \left(1 + W\left(i-1\right)\right) = \frac 1 2 W\left(i+1\right) + \frac 1 2 W\left(i-1\right) +1 </math>
Diese Rekursion wird durch die explizite Formel
::<math>W\left(i\right)= N^2 - i^2</math>
gelöst, wie man durch Einsetzen leicht nachprüft:
::<math>
\begin{align}
W\left(N\right) & = N^2-N^2=0 \\

W\left(0\right) &= W\left(1\right)+1 \\

&= N^2-1^2+1 \\

&= N^2 - 0^2\\

W\left(i\right) &= \frac 1 2 \left(N^2-\left(i-1\right)^2\right) + \frac 1 2 \left(N^2-\left(i+1\right)^2\right)+1 \\

&= \frac 1 2 N^2-\frac 1 2 \left( i^2-2i+1\right) + \frac 1 2 N^2-\frac 1 2 \left(i^2+2i+1\right) + 1 \\

&= N^2-i^2
\end{align}</math>
Insbesondere braucht man im ungünstigen Fall (Start auf Stuhl 0) im Durchschnitt <math>N^2</math> Würfe, im typischen Fall (start in der Mitte, also bei <math>i = N/2</math>) im Durchschnitt
:<math>N^2 - (N/2)^2=\frac 3 4 N^2\in O(N^2)</math>
Würfe. Die '''Beziehung zum randomisiertem 2-SAT-Algorithmus''' ist jetzt leicht zu erkennen. Sitzt die Person auf Stuhl <tt>i</tt>, interpretieren wir das als:

"Stuhl <math>i</math>": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

Wählt der Algorithmus eine Klausel, die nicht erfüllt ist, gibt es zwei Möglichkeiten:
# Beide Literale in der Klausel haben den falschen Wert: Die Lösung wird auf jeden Fall besser, egal welche der beiden wir umdrehen. Wir gehen also von Zustand <tt>i</tt> zu Zustand <tt>i+1</tt>.
# Nur eins der Literale hat den falschen Wert: Beim Umdrehen haben wir eine fifty-fifty-Chance, das richtige Literal zu wählen und in den Zustand <tt>i+1</tt> zu gelangen. Mit der selben Wahrscheinlichkeit wählen wir das falsche Literal und landen im Zustand <tt>i-1</tt>.
Falls 2 ist der ungünstigere und entspricht unserem Spiel, dessen Analyse wir deshalb einfach auf das 2-SAT-Problem übertragen können: Ziel des Algorithmus ist es, in den Zustand N zu gelangen, und deshalb gilt genau wie beim Spiel der
;Satz: Der randomisierte 2-SAT-Algorithmus findet im Durchschnitt nach <math>O(N^2)</math> Versuchen eine Lösung, wenn das Problem erfüllbar ist.
Damit ist der randomisierte Algorithmus für dieses Problem effizient, was Sie in Übung 12 experimentell nachprüfen sollen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-27T18:53:28Z

Ukoethe: /* Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

====Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk====

Um die Random Walk Analyse zu verstehen, betrachten wir folgendes Spiel:

geg.: eine Stuhlreihe mit N Stühlen. Wir nummerieren die Stühle so, dass links der Stuhl 0 und rechts der Stuhl N steht.

* Eine Person setzt sich zufällig auf einen der Stühle.
* Eine zweite Person wirft eine Münze.

Wenn die Münze auf Zahl fällt, rückt die erste Person einen Stuhl nach links, andernfalls nach rechts.
<--- Zahl Kopf --->

* Frage: Wie oft muss man die Münze im Durchschnitt werfen, bis Person 1 zum ersten Mal auf Stuhl N sitzt?

Da die erste Person sich anfangs zufällig hinsetzt, haben wir eine Chance von 1/N, dass sie gleich auf dem richtigen Stuhl landet und wir 0 Schritte benötigen. Mit der gleichen Wahrscheinlichkeit von 1/N setzt sie sich anfangs auf Stuhl Nummer (N-1), und wir haben eine fifty-fifty-Chance, mit nur einem Wurf durchzukommen. Wir können aber auch Pech haben und landen auf Stuhl Nummer (N-2). Das ist das Gleiche, als wenn Person 1 von Anfang an auf diesem Stuhl gesessen hätte, nur dass wir jetzt bereits einen Wurf verbraucht haben. Man sieht, dass man die Zahl der Restwürfe immer in dieser Art ausdrücken kann: Sitzt Person 1 auf Stuhl <tt>i</tt>, kann sie entweder nach rechts rücken und benötigt dann noch soviele Würfe, wie man typischerweise für Stuhl <tt>i+1</tt> benötigt, plus den Wurf von <tt>i => i+1</tt>. Oder sie kann nach links rücken und benötigt dann die typische Wurfzahl für Stuhl <tt>i-1</tt> plus den Wurf <tt>i => i-1</tt>. Beide Möglichkeiten haben die Wahrscheinlichkeit 1/2. Mathematisch kann man dies elegant als Rekursionsformel schreiben, die die erwartete Wurfzahl für Stuhl <tt>i</tt> als Funktion der entsprechenden Wurfzahlen für die Stühle <tt>i-1</tt> und <tt>i+1</tt> ausdrückt:

* Wenn wir uns auf Stuhl Nr.1 befinden, werfen wir gar nicht: <math>W\left(N\right)=0</math>
* Von Stuhl 0 gehen wir immer zu Stuhl 1: <math>W\left(0\right)=1 + W\left(1\right)</math>
* Allgemeiner Fall: <math>W\left(i\right)=\frac 1 2 \left(1 + W\left(i+1\right)\right) + \frac 1 2 \left(1 + W\left(i-1\right)\right) = \frac 1 2 W\left(i+1\right) + \frac 1 2 W\left(i-1\right) +1 </math>
Diese Rekursion wird durch die explizite Formel
::<math>W\left(i\right)= N^2 - i^2</math>
gelöst, wie man durch Einsetzen leicht nachprüft:
::<math>
\begin{align}
W\left(N\right) & = N^2-N^2=0 \\

W\left(0\right) &= N^2-0^2 \\

&= W\left(1\right)+1 \\

&= N^2-1^2+1 \\

&= N^2 \\

W\left(i\right) &= \frac 1 2 \left(N^2-\left(i-1\right)^2\right) + \frac 1 2 \left(N^2-\left(i+1\right)^2\right)+1 \\

&= \frac 1 2 N^2-\frac 1 2 \left( i^2-2i+1\right) + \frac 1 2 N^2-\frac 1 2 \left(i^2+2i+1\right) + 1 \\

&= N^2-i^2
\end{align}</math>
Insbesondere braucht man im ungünstigen Fall (Start auf Stuhl 0) im Durchschnitt <math>N^2</math> Würfe, im typischen Fall (start in der Mitte, also bei <math>i = N/2</math>) im Durchschnitt
:<math>N^2 - (N/2)^2=\frac 3 4 N^2\in O(N^2)</math>
Würfe. Die '''Beziehung zum randomisiertem 2-SAT-Algorithmus''' ist jetzt leicht zu erkennen. Sitzt die Person auf Stuhl <tt>i</tt>, interpretieren wir das als:

"Stuhl <math>i</math>": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

Wählt der Algorithmus eine Klausel, die nicht erfüllt ist, gibt es zwei Möglichkeiten:
# Beide Literale in der Klausel haben den falschen Wert: Die Lösung wird auf jeden Fall besser, egal welche der beiden wir umdrehen. Wir gehen also von Zustand <tt>i</tt> zu Zustand <tt>i+1</tt>.
# Nur eins der Literale hat den falschen Wert: Beim Umdrehen haben wir eine fifty-fifty-Chance, das richtige Literal zu wählen und in den Zustand <tt>i+1</tt> zu gelangen. Mit der selben Wahrscheinlichkeit wählen wir das falsche Literal und landen im Zustand <tt>i-1</tt>.
Falls 2 ist der ungünstigere und entspricht unserem Spiel. Ziel des Algorithmus ist es, in den Zustand N zu gelangen, und deshalb gilt genau wie beim Spiel der
;Satz: Der randomisierte 2-SAT-Algorithmus findet im Durchschnitt nach O(N^2) Versuchen eine Lösung, wenn das Problem erfüllbar ist.
Damit ist der randomisierte Algorithmus für dieses Problem effizient, was Sie in Übung 12 experimentell nachprüfen sollen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-27T18:50:29Z

Ukoethe: /* Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

====Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk====

Um die Random Walk Analyse zu verstehen, betrachten wir folgendes Spiel:

geg.: eine Stuhlreihe mit N Stühlen. Wir nummerieren die Stühle so, dass links der Stuhl 0 und rechts der Stuhl N steht.

* Eine Person setzt sich zufällig auf einen der Stühle.
* Eine zweite Person wirft eine Münze.

Wenn die Münze auf Zahl fällt, rückt die erste Person einen Stuhl nach links, andernfalls nach rechts.
<--- Zahl Kopf --->

* Frage: Wie oft muss man die Münze im Durchschnitt werfen, bis Person 1 zum ersten Mal auf Stuhl N sitzt?

Da die erste Person sich anfangs zufällig hinsetzt, haben wir eine Chance von 1/N, dass sie gleich auf dem richtigen Stuhl landet und wir 0 Schritte benötigen. Mit der gleichen Wahrscheinlichkeit von 1/N setzt sie sich anfangs auf Stuhl Nummer (N-1), und wir haben eine fifty-fifty-Chance, mit nur einem Wurf durchzukommen. Wir können aber auch Pech haben und landen auf Stuhl Nummer (N-2). Das ist das Gleiche, als wenn Person 1 von Anfang an auf diesem Stuhl gesessen hätte, nur dass wir jetzt bereits einen Wurf verbraucht haben. Man sieht, dass man die Zahl der Restwürfe immer in dieser Art ausdrücken kann: Sitzt Person 1 auf Stuhl <tt>i</tt>, kann sie entweder nach rechts rücken und benötigt dann noch soviele Würfe, wie man typischerweise für Stuhl <tt>i+1</tt> benötigt, plus den Wurf von <tt>i => i+1</tt>. Oder sie kann nach links rücken und benötigt dann die typische Wurfzahl für Stuhl <tt>i-1</tt> plus den Wurf <tt>i => i-1</tt>. Beide Möglichkeiten haben die Wahrscheinlichkeit 1/2. Mathematisch kann man dies elegant als Rekursionsformel schreiben, die die erwartete Wurfzahl für Stuhl <tt>i</tt> als Funktion der entsprechenden Wurfzahlen für die Stühle <tt>i-1</tt> und <tt>i+1</tt> ausdrückt:

* Wenn wir uns auf Stuhl Nr.1 befinden, werfen wir gar nicht: <math>W\left(N\right)=0</math>
* Von Stuhl 0 gehen wir immer zu Stuhl 1: <math>W\left(0\right)=1 + W\left(1\right)</math>
* Allgemeiner Fall: <math>W\left(i\right)=\frac 1 2 \left(1 + W\left(i+1\right)\right) + \frac 1 2 \left(1 + W\left(i-1\right)\right) = \frac 1 2 W\left(i+1\right) + \frac 1 2 W\left(i-1\right) +1 </math>
Diese Rekursion wird durch die explizite Formel
::<math>W\left(i\right)= N^2 - i^2</math>
gelöst, wie man durch Einsetzen leicht nachprüft:
::<math>
\begin{align}
W\left(N\right) & = N^2-N^2=0 \\

W\left(0\right) &= N^2-0^2 \\

&= W\left(1\right)+1 \\

&= N^2-1^2+1 \\

&= N^2 \\

W\left(i\right) &= \frac 1 2 \left(N^2-\left(i-1\right)^2\right) + \frac 1 2 \left(N^2-\left(i+1\right)^2\right)+1 \\

&= \frac 1 2 N^2-\frac 1 2 \left( i^2-2i+1\right) + \frac 1 2 N^2-\frac 1 2 \left(i^2+2i+1\right) + 1 \\

&= N^2-i^2
\end{align}</math>
Insbesondere braucht man im ungünstigen Fall (Start auf Stuhl 0) im Durchschnitt <math>N^2</math> Würfe, im typischen Fall (start in der Mitte, also bei <math>i = N/2</math> im Durchschnitt :<math>N^2 - (N/2)^2=\frac 3 4 N^2\in O(N^2)</math> Würfe.

Die '''Beziehung zum randomisiertem 2-SAT-Algorithmus''' ist jetzt leicht zu erkennen. Sitzt die Person auf Stuhl <tt>i</tt>, interpretieren wir das als:

"Stuhl <math>i</math>": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

Wählt der Algorithmus eine Klausel, die nicht erfüllt ist, gibt es zwei Möglichkeiten:
# Beide Literale in der Klausel haben den falschen Wert: Die Lösung wird auf jeden Fall besser, egal welche der beiden wir umdrehen. Wir gehen also von Zustand <tt>i</tt> zu Zustand <tt>i+1</tt>.
# Nur eins der Literale hat den falschen Wert: Beim Umdrehen haben wir eine fifty-fifty-Chance, das richtige Literal zu wählen und in den Zustand <tt>i+1</tt> zu gelangen. Mit der selben Wahrscheinlichkeit wählen wir das falsche Literal und landen im Zustand <tt>i-1</tt>.
Falls 2 ist der ungünstigere und entspricht unserem Spiel. Deshalb gilt genau wie beim Spiel der
;Satz: Der randomisierte 2-SAT-Algorithmus findet im Durchschnitt nach O(N^2) Versuchen eine Lösung, wenn das Problem erfüllbar ist.
Damit ist der randomisierte Algorithmus für dieses Problem effizient, was Sie in Übung 12 experimentell nachprüfen sollen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-27T18:49:57Z

Ukoethe: /* Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

====Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk====

Um die Random Walk Analyse zu verstehen, betrachten wir folgendes Spiel:

geg.: eine Stuhlreihe mit N Stühlen. Wir nummerieren die Stühle so, dass links der Stuhl 0 und rechts der Stuhl N steht.

* Eine Person setzt sich zufällig auf einen der Stühle.
* Eine zweite Person wirft eine Münze.

Wenn die Münze auf Zahl fällt, rückt die erste Person einen Stuhl nach links, andernfalls nach rechts.
<--- Zahl Kopf --->

* Frage: Wie oft muss man die Münze im Durchschnitt werfen, bis Person 1 zum ersten Mal auf Stuhl N sitzt?

Da die erste Person sich anfangs zufällig hinsetzt, haben wir eine Chance von 1/N, dass sie gleich auf dem richtigen Stuhl landet und wir 0 Schritte benötigen. Mit der gleichen Wahrscheinlichkeit von 1/N setzt sie sich anfangs auf Stuhl Nummer (N-1), und wir haben eine fifty-fifty-Chance, mit nur einem Wurf durchzukommen. Wir können aber auch Pech haben und landen auf Stuhl Nummer (N-2). Das ist das Gleiche, als wenn Person 1 von Anfang an auf diesem Stuhl gesessen hätte, nur dass wir jetzt bereits einen Wurf verbraucht haben. Man sieht, dass man die Zahl der Restwürfe immer in dieser Art ausdrücken kann: Sitzt Person 1 auf Stuhl <tt>i</tt>, kann sie entweder nach rechts rücken und benötigt dann noch soviele Würfe, wie man typischerweise für Stuhl <tt>i+1</tt> benötigt, plus den Wurf von <tt>i => i+1</tt>. Oder sie kann nach links rücken und benötigt dann die typische Wurfzahl für Stuhl <tt>i-1</tt> plus den Wurf <tt>i => i-1</tt>. Beide Möglichkeiten haben die Wahrscheinlichkeit 1/2. Mathematisch kann man dies elegant als Rekursionsformel schreiben, die die erwartete Wurfzahl für Stuhl <tt>i</tt> als Funktion der entsprechenden Wurfzahlen für die Stühle <tt>i-1</tt> und <tt>i+1</tt> ausdrückt:

* Wenn wir uns auf Stuhl Nr.1 befinden, werfen wir gar nicht: <math>W\left(N\right)=0</math>
* Von Stuhl 0 gehen wir immer zu Stuhl 1: <math>W\left(0\right)=1 + W\left(1\right)</math>
* Allgemeiner Fall: <math>W\left(i\right)=\frac 1 2 \left(1 + W\left(i+1\right)\right) + \frac 1 2 \left(1 + W\left(i-1\right)\right) = \frac 1 2 W\left(i+1\right) + \frac 1 2 W\left(i-1\right) +1 </math>
Diese Rekursion wird durch die explizite Formel
::<math>W\left(i\right)= N^2 - i^2</math>
gelöst, wie man durch Einsetzen leicht nachprüft:
::<math>
\begin{align}
W\left(N\right) & = N^2-N^2=0 \\

W\left(0\right) &= N^2-0^2 \\

&= W\left(1\right)+1 \\

&= N^2-1^2+1 \\

&= N^2 \\

W\left(i\right) &= \frac 1 2 \left(N^2-\left(i-1\right)^2\right) + \frac 1 2 \left(N^2-\left(i+1\right)^2\right)+1 \\

&= \frac 1 2 N^2-\frac 1 2 \left( i^2-2i+1\right) + \frac 1 2 N^2-\frac 1 2 \left(i^2+2i+1\right) + 1 \\

&= N^2-i^2
\end{align}</math>
Insbesondere braucht man im ungünstigen Fall (Start auf Stuhl 0) im Durchschnitt <math>N^2</math> Würfe, im typischen Fall (start in der Mitte, also bei <math>i = N/2</math> im Durchschnitt :<math>N^2 - (N/2)^2=\frac 3 4 N^2\in O(N^2)</math> Würfe.

Die '''Beziehung zum randomisiertem 2-SAT-Algorithmus''' ist jetzt leicht zu erkennen. Sitz die Person auf Stuhl <tt>i</tt> sitzt, interpretieren wir das als:

"Stuhl <math>i</math>": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

Wählt der Algorithmus eine Klausel, die nicht erfüllt ist, gibt es zwei Möglichkeiten:
# Beide Literale in der Klausel haben den falschen Wert: Die Lösung wird auf jeden Fall besser, egal welche der beiden wir umdrehen. Wir gehen also von Zustand <tt>i</tt> zu Zustand <tt>i+1</tt>.
# Nur eins der Literale hat den falschen Wert: Beim Umdrehen haben wir eine fifty-fifty-Chance, das richtige Literal zu wählen und in den Zustand <tt>i+1</tt> zu gelangen. Mit der selben Wahrscheinlichkeit wählen wir das falsche Literal und landen im Zustand <tt>i-1</tt>.
Falls 2 ist der ungünstigere und entspricht unserem Spiel. Deshalb gilt genau wie beim Spiel der
;Satz: Der randomisierte 2-SAT-Algorithmus findet im Durchschnitt nach O(N^2) Versuchen eine Lösung, wenn das Problem erfüllbar ist.
Damit ist der randomisierte Algorithmus für dieses Problem effizient, was Sie in Übung 12 experimentell nachprüfen sollen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-27T17:13:11Z

Ukoethe: /* Anwendung: Lösen des K-SAT-Problems */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

====Laufzeitanalyse der randomisierten 2-SAT-Algorithmus mittels Random Walk====

'''-Zufallsbelegung hat <math>t\leq n</math> richtige Variablen (im Mittel <math>t\approx \frac {n} 2</math>)'''

Negieren einer Variable ändert t um 1,
u.Z. <math>t\rightarrow t+1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac 1 k</math>)
::::::::::<math>t\rightarrow t-1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac {k-1} k</math>)

'''-Wieviele Schritte braucht man im Mittel, um zu einer Lösung mit t Richtigen zu kommen?'''

<math>S\left(t\right)=\frac 1 2 S\left(t-1\right) + \frac 1 2 S\left(t+1\right) +1</math>

<math>S\left(n\right)=0</math> #Abbruchbedingung der Schleife

<math>S\left(0\right) = S\left( 1\right) + 1 \Rightarrow S\left(t\right) = n^2-t^2</math>

'''Probe:'''

<math>
\begin{align}
S\left(n\right) & = n^2-n^2=0 \\

S\left(0\right) &= n^2-0^2 \\

&= S\left(1\right)+1 \\

&= n^2-1^2+1 \\

&= n^2 \\

S\left(t\right) &= \frac 1 2 \left(n^2-\left(t-1\right)^2\right) + \frac 1 2 \left(n^2-\left(t+1\right)^2\right)+1 \\

&= \frac 1 2 n^2-\frac 1 2 \left( t^2-2t+1\right) + \frac 1 2 n^2-\frac 1 2 \left(t^2+2t+1\right) + 1 \\

&= n^2-t^2
\end{align}</math>

'''Das ist das Random Walk Problem'''

Im ungünstigsten Fall (t=0) werden im Mittel <math>n^2</math> Schritte benötigt, um durch random walk nach t=n zu gelangen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-27T17:08:10Z

Ukoethe: /* Anwendung: Lösen des K-SAT-Problems */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Für <math>k \ge 3</math> gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

----

'''-Zufallsbelegung hat <math>t\leq n</math> richtige Variablen (im Mittel <math>t\approx \frac {n} 2</math>)'''

Negieren einer Variable ändert t um 1,
u.Z. <math>t\rightarrow t+1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac 1 k</math>)
::::::::::<math>t\rightarrow t-1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac {k-1} k</math>)

'''-Wieviele Schritte braucht man im Mittel, um zu einer Lösung mit t Richtigen zu kommen?'''

<math>S\left(t\right)=\frac 1 2 S\left(t-1\right) + \frac 1 2 S\left(t+1\right) +1</math>

<math>S\left(n\right)=0</math> #Abbruchbedingung der Schleife

<math>S\left(0\right) = S\left( 1\right) + 1 \Rightarrow S\left(t\right) = n^2-t^2</math>

'''Probe:'''

<math>
\begin{align}
S\left(n\right) & = n^2-n^2=0 \\

S\left(0\right) &= n^2-0^2 \\

&= S\left(1\right)+1 \\

&= n^2-1^2+1 \\

&= n^2 \\

S\left(t\right) &= \frac 1 2 \left(n^2-\left(t-1\right)^2\right) + \frac 1 2 \left(n^2-\left(t+1\right)^2\right)+1 \\

&= \frac 1 2 n^2-\frac 1 2 \left( t^2-2t+1\right) + \frac 1 2 n^2-\frac 1 2 \left(t^2+2t+1\right) + 1 \\

&= n^2-t^2
\end{align}</math>

'''Das ist das Random Walk Problem'''

Im ungünstigsten Fall (t=0) werden im Mittel <math>n^2</math> Schritte benötigt, um durch random walk nach t=n zu gelangen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-27T17:07:25Z

Ukoethe: /* Anwendung: Lösen des K-SAT-Problems */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Es gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

----

'''-Zufallsbelegung hat <math>t\leq n</math> richtige Variablen (im Mittel <math>t\approx \frac {n} 2</math>)'''

Negieren einer Variable ändert t um 1,
u.Z. <math>t\rightarrow t+1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac 1 k</math>)
::::::::::<math>t\rightarrow t-1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac {k-1} k</math>)

'''-Wieviele Schritte braucht man im Mittel, um zu einer Lösung mit t Richtigen zu kommen?'''

<math>S\left(t\right)=\frac 1 2 S\left(t-1\right) + \frac 1 2 S\left(t+1\right) +1</math>

<math>S\left(n\right)=0</math> #Abbruchbedingung der Schleife

<math>S\left(0\right) = S\left( 1\right) + 1 \Rightarrow S\left(t\right) = n^2-t^2</math>

'''Probe:'''

<math>
\begin{align}
S\left(n\right) & = n^2-n^2=0 \\

S\left(0\right) &= n^2-0^2 \\

&= S\left(1\right)+1 \\

&= n^2-1^2+1 \\

&= n^2 \\

S\left(t\right) &= \frac 1 2 \left(n^2-\left(t-1\right)^2\right) + \frac 1 2 \left(n^2-\left(t+1\right)^2\right)+1 \\

&= \frac 1 2 n^2-\frac 1 2 \left( t^2-2t+1\right) + \frac 1 2 n^2-\frac 1 2 \left(t^2+2t+1\right) + 1 \\

&= n^2-t^2
\end{align}</math>

'''Das ist das Random Walk Problem'''

Im ungünstigsten Fall (t=0) werden im Mittel <math>n^2</math> Schritte benötigt, um durch random walk nach t=n zu gelangen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-27T17:06:16Z

Ukoethe: /* Anwendung: Lösen des K-SAT-Problems */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel den Wert True annehmen, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
# Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>:
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
# wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Es gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

----

'''-Zufallsbelegung hat <math>t\leq n</math> richtige Variablen (im Mittel <math>t\approx \frac {n} 2</math>)'''

Negieren einer Variable ändert t um 1,
u.Z. <math>t\rightarrow t+1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac 1 k</math>)
::::::::::<math>t\rightarrow t-1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac {k-1} k</math>)

'''-Wieviele Schritte braucht man im Mittel, um zu einer Lösung mit t Richtigen zu kommen?'''

<math>S\left(t\right)=\frac 1 2 S\left(t-1\right) + \frac 1 2 S\left(t+1\right) +1</math>

<math>S\left(n\right)=0</math> #Abbruchbedingung der Schleife

<math>S\left(0\right) = S\left( 1\right) + 1 \Rightarrow S\left(t\right) = n^2-t^2</math>

'''Probe:'''

<math>
\begin{align}
S\left(n\right) & = n^2-n^2=0 \\

S\left(0\right) &= n^2-0^2 \\

&= S\left(1\right)+1 \\

&= n^2-1^2+1 \\

&= n^2 \\

S\left(t\right) &= \frac 1 2 \left(n^2-\left(t-1\right)^2\right) + \frac 1 2 \left(n^2-\left(t+1\right)^2\right)+1 \\

&= \frac 1 2 n^2-\frac 1 2 \left( t^2-2t+1\right) + \frac 1 2 n^2-\frac 1 2 \left(t^2+2t+1\right) + 1 \\

&= n^2-t^2
\end{align}</math>

'''Das ist das Random Walk Problem'''

Im ungünstigsten Fall (t=0) werden im Mittel <math>n^2</math> Schritte benötigt, um durch random walk nach t=n zu gelangen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-27T17:05:37Z

Ukoethe: /* Anwendung: Lösen des K-SAT-Problems */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur dann False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel True sein, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
# Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>:
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
# wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Es gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

----

'''-Zufallsbelegung hat <math>t\leq n</math> richtige Variablen (im Mittel <math>t\approx \frac {n} 2</math>)'''

Negieren einer Variable ändert t um 1,
u.Z. <math>t\rightarrow t+1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac 1 k</math>)
::::::::::<math>t\rightarrow t-1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac {k-1} k</math>)

'''-Wieviele Schritte braucht man im Mittel, um zu einer Lösung mit t Richtigen zu kommen?'''

<math>S\left(t\right)=\frac 1 2 S\left(t-1\right) + \frac 1 2 S\left(t+1\right) +1</math>

<math>S\left(n\right)=0</math> #Abbruchbedingung der Schleife

<math>S\left(0\right) = S\left( 1\right) + 1 \Rightarrow S\left(t\right) = n^2-t^2</math>

'''Probe:'''

<math>
\begin{align}
S\left(n\right) & = n^2-n^2=0 \\

S\left(0\right) &= n^2-0^2 \\

&= S\left(1\right)+1 \\

&= n^2-1^2+1 \\

&= n^2 \\

S\left(t\right) &= \frac 1 2 \left(n^2-\left(t-1\right)^2\right) + \frac 1 2 \left(n^2-\left(t+1\right)^2\right)+1 \\

&= \frac 1 2 n^2-\frac 1 2 \left( t^2-2t+1\right) + \frac 1 2 n^2-\frac 1 2 \left(t^2+2t+1\right) + 1 \\

&= n^2-t^2
\end{align}</math>

'''Das ist das Random Walk Problem'''

Im ungünstigsten Fall (t=0) werden im Mittel <math>n^2</math> Schritte benötigt, um durch random walk nach t=n zu gelangen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-27T17:05:04Z

Ukoethe: /* Anwendung: Lösen des K-SAT-Problems */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===

Der Algorithmus von Schöning löst das [[Graphen_und_Graphenalgorithmen#Normalformen für logische Ausdrücke|k-SAT-Problem]] durch Raten: Wenn ein Ausdruck in k-CNF den Wert False hat, gibt es mindestens eine Klausel, die den Wert False hat. Alle Literale in dieser Klausel haben ebenfalls den Wert False, denn jede Klausel ist eine ODER-Verknüpfung, die nur so False werden kann. Um den Ausdruck zu erfüllen, muss jede Klausel True sein, also müssen wir den Wert von mindestens einem Literal umdrehen. Wenn der Ausruck tatsächlich erfüllbar ist, gibt es immer ein geeignetes Literal, wir wissen nur nicht, welches. Deshalb drehen wir ein unter den k Literalen der betreffenden Klausel zufällig gewähltes. Liegen wir mit unserer Wahl richtig, sind wir der Lösung näher gekommen - im besten Fall sind jetzt alle Klauseln erfüllt. Wählen wir jedoch die falsche Variable, ist die aktuelle Klausel zwar jetzt True, aber dafür werden andere Klauseln zu False, die bisher True waren, und wir entfernen uns somit von der Lösung.

geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Literale} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>
Der Algorithmus von Schöning lautet in Pseudocode:
for i in range (trials): #Anzahl der Versuche
# Bestimme eine Zufallsbelegung der Variablen <math>\{ x_i \}</math>:
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln:
return <math>\{ x_i \}</math>
# wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
# (die Klausel ist jetzt erfüllt)
return None # keine Lösung gefunden

Findet der Algorithmus eine Lösung, wissen wir, dass der Ausdruck erfüllbar ist. Andernfalls könnte der Ausdruck unerfüllbar sein, oder wir haben nur Pech gehabt. Je mehr erfolglose Versuche wir machen, desto höher ist die Wahrscheinlichkeit, dass das erste zutrifft.

Es ist sinnvoll, <tt>steps = k*n</tt> zu wählen. Dann gilt der
;Satz: Wenn ein Ausdruck in k-CNF mit <math>k \ge 3</math> erfüllbar ist, muss man im Mittel <tt>trials</tt><math>\in O\left(\left(\frac{2(k-1)}{k}\right)^n \right)</math> Versuche machen, um eine Lösung zu finden.

Es gilt stets <math>\frac{2(k-1)}{k} > 1</math>, man benötigt also eine in n exponentielle Anzahl von Versuchen. Bei <math>k=3</math> gilt z.B. <tt>trials</tt><math> \in O\left(\left(\frac{4}{3}\right)^n\right)</math>. Dies ist zwar im Mittel effizienter also die erschöpfende Suche, die <math>O(2^n)</math> Schritte benötigt, aber immer noch sehr langsam.

Der Fall <math>k=2</math> ist jedoch ein Sonderfall: Hier kann man leicht beweisen, dass eine Lösung im Mittel bereits nach <math>O\left(n^2\right)</math> Schritten gefunden wird. Wenn man schon weiss, dass der Ausdruck erfüllbar ist (was mit [[Graphen_und_Graphenalgorithmen#Lösung des 2-SAT-Problems mit Implikationgraphen|Implikationgraphen]] leicht geprüft werden kann), lässt man den randomisierten Algorithmus einfach so lange laufen, bis er eine Lösung findet. Man setzt also <tt>step = infinity</tt> und <tt>trials = 1</tt> und verlässt sich darauf, dass das <tt>return</tt> mit einer gültigen Lösung früher oder später ausgeführt wird. Dass man darauf im Mittel nur <math>n^2</math> Schritte warten muss, zeigen wir jetzt mit Hilfe eines random walk.

----

'''-Zufallsbelegung hat <math>t\leq n</math> richtige Variablen (im Mittel <math>t\approx \frac {n} 2</math>)'''

Negieren einer Variable ändert t um 1,
u.Z. <math>t\rightarrow t+1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac 1 k</math>)
::::::::::<math>t\rightarrow t-1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac {k-1} k</math>)

'''-Wieviele Schritte braucht man im Mittel, um zu einer Lösung mit t Richtigen zu kommen?'''

<math>S\left(t\right)=\frac 1 2 S\left(t-1\right) + \frac 1 2 S\left(t+1\right) +1</math>

<math>S\left(n\right)=0</math> #Abbruchbedingung der Schleife

<math>S\left(0\right) = S\left( 1\right) + 1 \Rightarrow S\left(t\right) = n^2-t^2</math>

'''Probe:'''

<math>
\begin{align}
S\left(n\right) & = n^2-n^2=0 \\

S\left(0\right) &= n^2-0^2 \\

&= S\left(1\right)+1 \\

&= n^2-1^2+1 \\

&= n^2 \\

S\left(t\right) &= \frac 1 2 \left(n^2-\left(t-1\right)^2\right) + \frac 1 2 \left(n^2-\left(t+1\right)^2\right)+1 \\

&= \frac 1 2 n^2-\frac 1 2 \left( t^2-2t+1\right) + \frac 1 2 n^2-\frac 1 2 \left(t^2+2t+1\right) + 1 \\

&= n^2-t^2
\end{align}</math>

'''Das ist das Random Walk Problem'''

Im ungünstigsten Fall (t=0) werden im Mittel <math>n^2</math> Schritte benötigt, um durch random walk nach t=n zu gelangen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Randomisierte Algorithmen

2012-07-27T16:16:54Z

Ukoethe: /* Randomisierte Algorithmen */

== Randomisierte Algorithmen ==

;Definition: Randomisierte Algorithmen sind Algorithmen, die bei Entscheidungen über ihr weiteres Vorgehen oder bei der Wahl ihrer Parameter Zufallszahlen benutzen.

Anschaulich gesprochen, wersucht man bei randomisierten Algorithmen, einen Teil der Lösung zu raten. Auf den ersten Blick würde man vermuten, dass dabei nicht viel Sinnvolles herauskommen kann. Diese Kapitel wird jedoch zeigen, dass man durch geschicktes Raten tatsächlich zu sehr eleganten Algorithmen gelangen kann.

Grundsätzlich unterscheidet man zwei Arten von randomisierten Algorithmen:
;Las Vegas - Algorithmen: Das Ergebnis des Algorithmus ist immer korrekt, und die Berechnung erfolgt mit hoher Wahrscheinlichkeit effizient.
;Monte Carlo - Algorithmen: Die Berechnung ist immer effizient, und das Ergebnis ist mit hoher Wahrscheinlichkeit korrekt.
Las Vegas-Algorithmen verwendet man, wenn der Algorithmus im ungünstigen Fall eine schlechte Laufzeit hat, und der ungünstige Fall kann durch die Randomisierung sehr unwahrscheinlich gemacht werden. Wir haben in der Vorlesung schon mehrere Las Vegas-Algorithmen kennen gelernt:
* Quick Sort mit zufälliger Wahl des Pivot-Elements: Die Randomisierung verhindert, dass das Array immer wieder in Subarrays von sehr unterschiedlicher Größe aufgeteilt wird.
* Treap mit zufälligen Prioritäten: Die Randomisierung verhindert, dass der Baum schlecht balanciert ist.
* Universelles Hashing: Die zufällige Wahl der Hashfunktion verhindert, dass ein Angreifer eine Schlüsselmenge mit sehr vielen Kollisionen konstruieren kann.
* Erzeugung einer perfekten Hashfunktion: Durch die Randomisierung entsteht mit nach wenigen Versuchen ein zyklenfreier Graph, der zur Definition der Hashfunktion geeignet ist.
Monte Carlo-Algorithmen verwendet man dagegen, wenn kein effizienter deterministischer Algorithmus für ein Problem bekannt ist. Man gibt sich dann damit zufrieden, dass der randomisierte Algorithmus die korrekte Lösung nur mit hoher Wahrscheinlichkeit findet, wenn dies dafür sehr effizient geschieht. Bei manchen Problemen ist auch dies unerreichbar - man muss dann bereits zufrieden sein, wenn der Algorithmus mit hoher Wahrscheinlichkeit eine sehr gute Näherungslösung findet. Beliebte Anwendungsgebiete für Monte Carlo-Algorithmen sind beispielsweise
* Randomisierte Primzahl-Tests: Moderne Verschlüsselungsverfahren benötigen zahlreiche Primzahlen, aber exakte Primzahltests sind teuer. Der [http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test Miller-Rabin-Test] findet effizient Zahlen, die mit sehr hoher Wahrscheinlichkeit tatsächlich Primzahlen sind.
* Randomisiertes Testen: Wie jeder Test kann auch eine randomisierter Test nicht die Abwesenheit von Programmierfehlern garantieren, aber man kann durch die Randomisierung viel mehr Testfälle generieren und erhöht so die Erfolgswarscheinlichkeit. Wir haben als Beispiel dafür den [[Korrektheit#Beispiel_f.C3.BCr_das_Testen:_Freivalds_Algorithmus|Algorithmus von Freivald]] behandelt.
* Lösung schwieriger Optimierungsprobleme: Wir zeigen unten, dass ein randomisierter Algorithmus effizient eine Lösung für das 2-SAT-Problem aus dem vorherigen Kapitel findet (für k-SAT mit <math>k \ge 3</math> liefert der Algorithmus immer noch mit einer gewissen Wahrscheinlichkeit das richtige Ergebnis, ist aber nicht mehr effizient). Einen effizienten Approximationsalgorithmus für des Problem des Handelsreisenden behandlen wir im Kapitel [[NP-Vollständigkeit]]. Weitere wichtige Beispiele für diesen Bereich sind [http://en.wikipedia.org/wiki/Simulated_annealing simulated annealing] und das [http://de.wikipedia.org/wiki/MCMC-Verfahren Markov-Chain-Monte-Carlo-Verfahren].
* Robuste Statistik: Eine Grundaufgabe der Statistik ist das Anpassen (Fitten) von Modellen an gemessene Werte. Wenn die Messungen jedoch "Ausreißer" (einige völlig falsche Werte) enthalten, geht die Anpassung schief. Wir beschreiben unten den RANSAC-Algorithmus, der die Ausreißer identifizieren und beim Modellfitten ignorieren kann.

Obwohl randomisierte Algorithmen oft einfach und elegant sind, ist ihre theoretische Analyse (also das Führen von Korrektheits- und Komplexitätsbeweisen) häufig sehr schwierig. Man muss fortgeschrittene Methoden der Wahrscheinlichkeitsrechnung und Statistik beherrschen, um die Wahrscheinlichkeit für das Versagen des Algorithmus zu berechnen und um zu zeigen, wie man den Algorithmus benutzt, damit diese Wahrscheinlichkeit unter einer akzeptablen Schranke bleibt. Die Algorithmen, die wir für diese Vorlesung ausgewählt haben, zeichnen sich dadurch aus, dass die Beweise hier einfach zu erbringen sind.

=== Anwendung: Lösen des K-SAT-Problems ===
geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Variablen} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>

for i in range (trials): #Anzahl der Versuche
#Bestimme eine Zufallsbelegung des <math>\{ x_i \}</math>:
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln: return <math>\{ x_i \}</math>
#wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
(die Klausel ist jetzt erfüllt)
return None

Eigenschaft: falls <math>k>2</math> : steps *trials <math>\in O\left(\Alpha^n \right) \Alpha >1</math>

z.B. <math>k=3</math> steps=3*n, trials=<math>\left(\frac{4}3\right)^n</math>

aber: bei <math>k=2</math> sind im Mittel nur steps=<math>O\left(n^2\right)</math> nötig, trials=<math>O\left(1\right)</math>

----

'''-Zufallsbelegung hat <math>t\leq n</math> richtige Variablen (im Mittel <math>t\approx \frac {n} 2</math>)'''

Negieren einer Variable ändert t um 1,
u.Z. <math>t\rightarrow t+1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac 1 k</math>)
::::::::::<math>t\rightarrow t-1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac {k-1} k</math>)

'''-Wieviele Schritte braucht man im Mittel, um zu einer Lösung mit t Richtigen zu kommen?'''

<math>S\left(t\right)=\frac 1 2 S\left(t-1\right) + \frac 1 2 S\left(t+1\right) +1</math>

<math>S\left(n\right)=0</math> #Abbruchbedingung der Schleife

<math>S\left(0\right) = S\left( 1\right) + 1 \Rightarrow S\left(t\right) = n^2-t^2</math>

'''Probe:'''

<math>
\begin{align}
S\left(n\right) & = n^2-n^2=0 \\

S\left(0\right) &= n^2-0^2 \\

&= S\left(1\right)+1 \\

&= n^2-1^2+1 \\

&= n^2 \\

S\left(t\right) &= \frac 1 2 \left(n^2-\left(t-1\right)^2\right) + \frac 1 2 \left(n^2-\left(t+1\right)^2\right)+1 \\

&= \frac 1 2 n^2-\frac 1 2 \left( t^2-2t+1\right) + \frac 1 2 n^2-\frac 1 2 \left(t^2+2t+1\right) + 1 \\

&= n^2-t^2
\end{align}</math>

'''Das ist das Random Walk Problem'''

Im ungünstigsten Fall (t=0) werden im Mittel <math>n^2</math> Schritte benötigt, um durch random walk nach t=n zu gelangen.

== 2. RANSAC-ALGORITHMUS (Random Sample Consensus)==

''Aufgabe:'' gegeben: Datenpunkte
::gesucht: Modell, das die Datenpunkte erklärt

[[Image:Rubto.png|thumb|250px|none]]

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

<math>\min_{a,b} \sum_{i} \left(a x_i + b + y_i\right)^2</math>

Schulmathematik: <math>Minimum\stackrel{\wedge}{=}Ableitung=0</math>

'''Lineares Gleichungssystem'''

<math>\frac{d}{da}\sum{i} \left(ax_i+b-y_i\right)^2=\sum{i} \frac{d}{da} \left[ax_i+b-y_i\right)^2</math>

::::<math>f\left(g\left(x\right)\right)</math>

::::<math>f\left(x\right)=x^2</math>

::::<math>y\left(a\right)=ax_i+b-y_i</math>

<math>=\sum_{i}2\left(ax_i+b-y_i\right)\frac{d}{da} \underbrace {ax_i+b-y_i}_{x_i}</math>

<math>\underline {=2\sum_{i}\left(ax_i+b-y_i\right)x_i\stackrel{!}{=}0}</math>

::::::<math>a\sum_{i}{x_i}^2+b\sum_{i}x_i=\sum_{i}x_iy_i</math>

::::::<math>a\sum_{i}x_i+b\sum_{i}1=\sum_{i}y_i</math>

<math>\frac{d}{db}\sum_{i}\left(ax_i+b-y_i\right)^2=2\sum_{i}\left(ax_i+b-y_i\right)*1</math>

----

:Problem: <math>\epsilon %</math> der Datenpunkte sind Outlier

:<math>\Longrightarrow</math> Einfaches Anpassen des Modells an die Datenpunkte funktioniert nicht

:Seien mindestens k Datenpunkte notwendig, um das Programm anpassen zu können

RANSAC-Algorithmus

for l in range (trials):
wähle zufällig k Punkte aus
passe das Modell an die k Punkte an
zähle, wieviele Punkte in der Nähe des Modells liegen (d.h. <math>d_i < d_max</math> muss geschickt gewählt werden)
#Bsp. Geradenfinden:-wähle a,b aus zwei Punkten
-berechne: <math>|ax_i+b-y_i|=d_i</math>
-zähle Punkt i als Inlier, falls <math>d_i<d_ma</math>
return: Modell mit höchster Zahl der Inlier

<math>trials= \frac{log\left(1-p\right)}{log\left(1-\left(1-\epsilon\right)^k\right)}</math> mit k=Anzahl der Datenpunkte und p=Erfolgswahrscheinlichkeit, <math>\epsilon</math>=Outlier-Anteil

'''Erfolgswahrscheinlichkeit: p=99%'''

<math>\begin{array}{|c||c|c|c|c|c|}
Beispiel & k & \epsilon=10% & 20% & 50% & 70%\\
\hline
Linie\;in\;2D & 2 & 3 &5 & 17 & 49\\
Kreis\;in\;2D & 3 & 4 & 7 & 35 & 169\\
Ebene\;in\;3D & 8 & 9 & 26 & 1172 & 70188\\
\end{array}</math>

'''Ein Spiel: Wie viel Schritte braucht man im Mittel zum Ziel?'''

geg.: 5 Plätze, 2 Personen: eine Person rückt vom einem Platz zu dem enderen Platz;
die zweite Person wirft die Münze.
Wenn die Münze auf Kopf landet, rücke nach rechts und wenn die Münze auf Zahl landet, rücke nach links.
<--- Zahl Kopf-->
Kopf: /////
Zahl: ///

:: => mit 8 Schritten bis zum Ziel
:im Mittel: bei N Plätzen braucht man N2 Schritte

: all: mit N2 Schritten um N Plätze rücken
: Wie viel Schritte braucht man im Mittel zum Ziel?

<math>S\left(N\right)=0</math> #wenn wir uns im Stuhl Nr.1 befinden

<math>S\left(i\right)=\frac 1 2 S\left(1 + S\left(i+1\right)\right) + \frac 1 2 S\left(1 + S\left(i-1\right)\right) = \frac 1 2 S\left(i+1\right) + \frac 1 2 S\left(i-1\right) +1 </math>

<math>S\left(0\right)=1 + S\left(1\right)</math> #bei 0.Platz

:::*Lösung:

<math>S\left(i\right)= N^2 - i^2</math>

:::*speziell:

<math>S\left(i\right)= N^2</math> #wenn man am ungünstigsten Platz startet

----

'''Beziehung zu randomisiertem 2-SAT'''

"Platz <math>i</math> ": <math>i</math> Variablen haben den richtigen Wert, <math>\left(N-i\right)</math> sind falsch gesetzt

<math>S\left(\frac N 2\right)=N^2 - \left(\frac N 2\right)^2 = N^2 - \frac N 4 ^2 = \frac 3 4 N^2 </math>
<math>S\left(\frac N 2\right)</math> # Anfangszustand
----
== '''Las Vegas vs. Monte Carlo'''==

* ''Las Vegas - Algorithmen''
- Ergebnis ist immer korrekt.
- Berechnung ist mit hoher Wahrscheinlichkeit effizient (d.h. Randomisierung macht den ungünstigsten Fall unwahrscheinlich).

* ''Monte Carlo - Algorithmen''
- Berechnung immer effizient.
- Ergebnis mit hoher Wahrscheinlichkeit korrekt (falls kein effizienter Algorithmus bekannt, der immer die richtige Lösung liefert).

{| border = "1" cellspacing="0" cellpadding="5" align="center"
|-
! Las Vegas
! Monte Carlo
|-
| - Erzeugen einer perfekten Hashfuktion
| - Algorithmus von Freiwald(Matrizenmultiplikation)
|-
| - universelles Hashing
| - RANSAC
|-
| - Quick Sort mit zufälliger Wahl des Pivot-Elements
| - randomisierte K-SAT(k>=3)(Alg. von Schöning)
|-
| - Treep mit zufälligen Prioritäten
| -
|}

== ''' Zufallszahlen ''' ==

:- kann man nicht mit deterministischen Computern erzeugen
:- aber man kann Pseudo-Zufallszahlen erzeugen, die viele Eigenschaften von echten Zufallszahlen haben
::: * sehr ähnlich zum Hash

''"linear Conguential Random number generator"''
<math>I_{i+1}= \left(a*I_i + c\right)\textrm{mod\ } m</math>
<math>\begin{array}{ll}
\mathrm{=> } & I_i \in [0, m-1]\\

\end{array}</math>

:-sorgfältige Wahl von a, c, m notwendig
::'''Bsp.''' m = 232
::: a = 1664525, c = 1013904223
::: ''"quick and dirty generator"''

==='''Nachteile'''===

* nicht zufällig genug für viele Anwendungen
::'''Bsp.''' wähle Punkt in R3

::<math>\begin{array}{ll}
\mathrm{ } & p = (rand(), rand(), rand())\\

\end{array}</math>

::gibt Zahl u, v, w so, dass

::<math>\begin{array}{ll}
\mathrm{ } & u * p[0] + v * p[1] + w * p[3]\\

\end{array}</math>

::stark geclustert ist.

* Periodenlänge ist zu kurz:
:: spätestens nach m Schritten wiederholt sich die Folge

::'''allgemein''': falls der interne Zustand des Zufallsgenerators ''k'' bits hat, ist Periodenlänge:

::<math>\begin{array}{ll}
\mathrm{ } & Periode < 2^k\\

\end{array}</math>

* ''lowbits'' sind weniger zufällig als die ''highbits''
----
=== ''Mersenne Twister''===

'''bester zur Zeit bekannter Zufallszahlengenerator (ZZG)'''
* innere Zustand: <math>\begin{array}{ll}
\mathrm{ } & 624*32 bit\ Integers => 19968 bits\\
\end{array}</math>

* Periodenlänge: <math>2^ {19937} \approx 4 * 10^{6000}</math>

* Punkte aus aufeinanderfolgende Zufallszahlen in <math>\mathbb{R}^n</math> sind gleich verteilt bis <math>\begin{array}{ll}
\mathrm{ } & n = 623\\
\end{array}</math>

* alle Bits sind unabhängig voneinander zufällig ("Twister")

* schnell

class MersenneTwister:

def __init__(self, seed):
self.N = 624 # Größe des inneren Zustands festlegen
self.i = 0 # zählt mit in welchem Zustand wir uns gerade aufhalten

self.state = [0]*self.N # Speicher für den inneren Zustand reservieren

self.state[0] = seed # initiale Zufallszahl vom Benutzer
# den Rest des inneren Zustands mit einfachem Zufallszahlengenerator initialisieren
for i in xrange(1, self.N):
self.state[i] = (1812433253 * (self.state[i-1] ^ (self.state[i-1] >> 30)) + i) % 4294967296

def __call__(self):
"""gibt die nächste Zufallszahl im Bereich [0, 232-1] aus"""
N, M = self.N, 397

# Zustand aktualisieren (neue Zufallszahl ausrechnen)
i = self.i
r = ((self.state[i] & 0x80000000) | (self.state[(i+1)%N] & 0x7FFFFFFF)) >> 1
if self.state[(i+1)%N] & 1:
r ^= 0x9908B0DF
self.state[i] = self.state[(i+M)%N] ^ r

# aktuelle Zufallszahl auslesen und ihre Zufälligkeit durch verwürfeln der Bits verbessern
y = self.state[i]
y ^= (y >> 11)
y ^= ((y << 7) & 0x9D2C5680)
y ^= ((y << 15) & 0xEFC60000)
y ^= (y >> 18)

# Zustand weitersetzen und endgültige Zufallszahl ausgeben
self.i = (self.i + 1) % N
return y

'''geg.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, \overbrace{2^{32}-1}^{m-1}]\\
\end{array}</math>

'''ges.:''' Zufallszahl
<math>\begin{array}{ll}
\mathrm{ } & [0, k - 1]\\
\end{array}</math>

'''naive Lösung:''' <math>\begin{array}{ll}
\mathrm{ } & rand()%k\\
\end{array}</math> ist schlecht.

'''Bsp.'''
<math>\begin{array}{ll}
\mathrm{ } & \qquad m = 16\qquad k = 11\\
\end{array}</math>

{| border="1" cellspacing="0" cellpadding="5"
! rand() || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! rand()%k
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 0 || 1 || 2 || 3 || 4
|-

|}

=> 0,...,4 kommt doppelt so häufig wie 5,...,10 "nicht zufällig"

'''Lösung:''' Zurückweisen des Rests der Zahlen (''rejektion sampling'')

<math>\begin{array}{ll}
\mathrm{ } & remainder = (m - 1 - (k - 1))% k = (m - k)%k\\
\mathrm{ } & last\ Good\ Value = m-1-remainder\\
\end{array}</math>

r = rand()
while r > last.GoodValue:
r = rand()
return r%k

[[Greedy-Algorithmen und Dynamische Programmierung|Nächstes Thema]]

Effizienz

2012-07-27T16:04:44Z

Ukoethe: /* Effiziente Lösung durch Verdoppeln der Kapazität */

Bei der Diskussion von Effizienz müssen wir zwischen der Laufzeit eines Algorithmus auf einem bestimmten System und seiner prinzipiellen Leistungsfähigkeit (Algorithmenkomplexität) unterscheiden. Der Benutzer ist natürlich vor allem an der Laufzeit interessiert, denn diese bestimmt letztendlich seine Arbeitsproduktivität. Ein Softwaredesigner hingegen muss eine Implementation wählen, die auf verschiedenen Systemen und in verschiedenen Anwendungen schnell ist. Für ihn sind daher auch Aussagen zur Algorithmenkomplexität sehr wichtig, um den am besten geeigneten Algorithmus auszuwählen.

== Laufzeit ==

Aus Anwendersicht ist ein Algorithmus effizient, wenn er die in der Spezifikation verlangten Laufzeitgrenzen einhält. Ein Algorithmus muss also nicht immer so schnell wie möglich sein, sondern so schnell wie nötig. Dies führt in verschiedenen Anwendungen zu ganz unterschiedliche Laufzeitanforderungen:

* Berechnen des nächsten Steuerkommandos für eine Maschine: ca. 1/1000s
* Berechnen des nächsten Bildes für eine Videopräsentation (z.B. Dekompression von MPEG-kodierten Bildern): ca. 1/25s
: Geringere Bildraten führen zu ruckeligen Filmen.
* Sichtbare Antwort auf ein interaktives Kommando (z.B. Mausklick): ca. 1/2s
: Wird diese Antwortzeit überschritten, vermuten viele Benutzer, dass der Mausklick nicht funktioniert hat, und klicken nochmals, mit eventuell fatalen Folgen. Wenn ein Algorithmus notwendigerweise länger dauert als 1/2s, sollte ein Fortschrittsbalken angezeigt werden.
* Wettervorhersage: muss spätestens am Vorabend des vorhergesagten Tages beendet sein

===Laufzeitvergleich===

Da die Laufzeit für den Benutzer ein so wichtiges Kriterium ist, werden häufig Laufzeitvergleiche durchgeführt. Deren Ergebnisse hängen allerdings von vielen Faktoren ab, die möglicherweise nicht kontrollierbar sind:
* Geschwindigkeit und Anzahl der Prozessoren
* Auslastung des Systems
* Größe des Hauptspeichers und Cache, Geschwindigkeit des Datenbus
* Qualität des Compilers/Optimierers (ist der Compiler für die spezielle Prozessor-Architektur optimiert?)
* Geschick des Programmierers
* Daten (Beispiel Quicksort: Best case und worst case [vorsortierter Input] stark unterschiedlich)
All diese Faktoren sind untereinander abhängig. Laufzeitvergleiche sind daher mit Vorsicht zu interpretieren.
Generell sollten bei Vergleichen möglichst wenige Parameter verändert werden, z.B.
* gleiches Programm (gleiche Kompilierung), gleiche Daten, andere Prozessoren
oder
* gleiche CPU, Daten, andere Programme (Vergleich von Algorithmen)
Zur Verbesserung der Vergleichbarkeit gibt es standardisierte [http://en.wikipedia.org/wiki/Benchmark_(computing) Benchmarks], die bestimmte Aspekte eines Systems unter möglichst realitätsnahen Bedingungen testen. Generell gilt aber: Durch Laufzeitmessung ist schwer festzustellen, ob ein Algorithmus ''prinzipiell'' besser ist als ein anderer. Dafür ist die Analyse der [[Effizienz#Algorithmen-Komplexität|Algorithmenkomplexität]] notwendig.

===Optimierung der Laufzeit===

Wenn sich herausstellt, dass ein bereits implementierter Algorithmus zu langsam läuft, geht man wie folgt vor:

# Man verwendet einen [http://en.wikipedia.org/wiki/Performance_analysis Profiler], um zunächst den Flaschenhals zu bestimmen. Ein Profiler ist ein Hilfsprogramm, das während der Ausführung eines Programms misst, wieviel Zeit in jeder Funktion und Unterfunktion verbraucht wird. Dadurch kann man herausfinden, welcher Teil des Algorithmus überhaupt Probleme bereitet. Donald Knuth gibt z.B. als Erfahrungswert an, dass Programme während des größten Teils ihrer Laufzeit nur 3% des Quellcodes (natürlich mehrmals wiederholt) ausführen [http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf]. Es ist sehr wichtig, diese 3% experimentell zu bestimmen, weil die Erfahrung zeigt, dass man beim Erraten der kritischen Programmteile oft falsch liegt. Man spricht dann von "[http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize premature optimization]", also von voreiliger Optimierung ohne experimentelle Untersuchung der wirklichen Laufzeiten, was laut Knuth "the root of all evil" ist. Der Python-Profiler wird in [http://docs.python.org/lib/profile.html Kapitel 25] der Python-Dokumentation beschrieben.
# Man kann dann versuchen, die kritischen Programmteile zu optimieren.
# Falls der Laufzeitgewinn durch Optimierung zu gering ist, muss man einen prinzipiell schnelleren Algorithmus verwenden, falls es einen gibt.

Einige wichtige Techniken der Programmoptimierung sollen hier erwähnt werden. Wenn man einen optimierenden Compiler verwendet, werden einige Optimierungen automatisch ausgeführt [http://en.wikipedia.org/wiki/Compiler_optimization]. In Python trifft dies jedoch nicht zu. Um den Sinn einiger Optimierungen zu verstehen, benötigt man Grundkenntnisse der Computerarchitektur.

;Elimination von redundantem Code: Es ist offensichtlich überflüssig, dasselbe Ergebnis mehrmals zu berechnen, wenn es auch zwischengespeichert werden könnte. Diese Optimierung wird von vielen automatischen Optimierern unterstützt und kommt im wesentlichen in zwei Ausprägungen vor:
:; common subexpression elimination: In mathematischen Ausdrücken wird ein Teilergebnis häufig mehrmals benötigt. Man betrachte z.B. die Lösung der quadratischen Gleichung <math>x^2+p\,x+q = 0</math>:
x1 = - p / 2.0 + sqrt(p*p/4.0 - q)
x2 = - p / 2.0 - sqrt(p*p/4.0 - q)
::Die mehrmalige Berechnung von Teilausdrücken wird vermieden, wenn man stattdessen schreibt:
p2 = - p / 2.0
r = sqrt(p2*p2 - q)
x1 = p2 + r
x2 = p2 - r
:; loop invariant elimination: Wenn ein Teilausdruck sich in einer Schleife nicht ändert, muss man ihn nicht bei jedem Schleifendurchlauf neu berechnen, sondern kann dies einmal vor Beginn der Schleife tun. Ein typisches Beispiel hierfür ist die Adressierung von Matrizen, die als 1-dimensionales Array gespeichert sind. Angenommen, wir speichern eine NxN Matrix <tt>m</tt> in einem Array <tt>a</tt> der Größe N2, so dass das Matrixelement <tt>mij</tt> durch <tt>a[i + j*N]</tt> indexiert wird. Wir betrachten die Aufgabe, eine Einheitsmatrix zu initialisieren. Ein nicht optimierter Algorithmus dafür lautet:
for j in range(N):
for i in range(N):
if i == j:
a[i + j*N] = 1.0
else:
a[i + j*N] = 0.0
::Der Ausdruck <tt>j*N</tt> wird hier in jedem Schleifendurchlauf erneut berechnet, obwohl sich <tt>j</tt> in der inneren Schleife gar nicht verändert. Man kann deshalb optimieren zu:
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
;Vereinfachung der inneren Schleife: Generell sollte man sich bei der Optimierung auf die innere Schleife eines Algorithmus konzentrieren, weil dieser Code am häufigsten ausgeführt wird. Insbesondere sollte man die Anzahl der Befehle in der inneren Schleife so gering wie möglich halten und teure Befehle vermeiden. Früher waren vor allem Floating-Point Befehle teuer, die man oft durch die schnellere Integer-Arithmetik ersetzt hat, falls dies algorithmisch möglich war (diesen Rat findet man noch oft in der Literatur). Heute hat sich die Hardware so verbessert, dass im Allgemeinen nur noch die Floating-Point Division deutlich langsamer ist als die anderen Operatoren. Im obigen Beispiel der quadratischen Gleichung ist es daher sinnvoll, den Ausdruck
p2 = -p / 2.0
:durch
p2 = -0.5 * p
:zu ersetzen. Dadurch ersetzt man eine Division durch eine Multiplikation und spart außerdem das Negieren von <tt>p</tt>, da der Compiler direkt mit <tt>-0.5</tt> multipliziert.
;Ausnutzung der Prozessor-Pipeline: Moderne Prozessoren führen mehrere Befehle parallel aus. Dies ist möglich, weil jeder Befehl in mehrere Teilschritte zerlegt werden kann. Eine generische Unterteilung in vier Teilschritte ist z.B.:
:# Dekodieren des nächsten Befehls
:# Beschaffen der Daten, die der Befehl verwendet (aus Prozessorregistern, dem Cache, oder dem Hauptspeicher)
:# Ausführen des Befehls
:# Schreiben der Ergebnisse
:Man bezeichnet dies als die "[http://en.wikipedia.org/wiki/Instruction_pipeline instruction pipeline]" des Prozessors (heutige Prozessoren verwenden wesentlich feinere Unterteilungen). Prozessoren werden nun so gebaut, dass mehrere Befehle parallel, auf verschiedenen Ausführungsstufen ausgeführt werden. Wenn Befehl 1 also beim Schreiben der Ergebnisse angelangt ist, kann Befehl 2 die Hardware zum Ausführen des Befehls benutzen, während Befehl 3 seine Daten holt, und Befehl 4 soeben dekodiert wird. Unter bestimmten Bedingungen funktioniert diese Parallelverarbeitung jedoch nicht. Dies gibt Anlass zu Optimierungen:
:;Vermeiden unnötiger Typkonvertierungen: Der Prozessor verarbeitet Interger- und Floating-Point-Befehle in verschiedenen Pipelines, weil die Hardwareanforderungen sehr verschieden sind. Wird jetzt ein Ergebnis von Integer nach Floating-Point umgewandelt oder umgekehrt, muss die jeweils andere Pipeline warten, bis die erste Pipeline ihre Berechnung beendet. Es kann dann besser sein, Berechnungen in Floating-Point zu Ende zu führen, auch wenn sie semantisch eigentlich Integer-Berechnungen sind.
:;Reduzierung der Anzahl von Verzweigungen: Wenn der Code verzweigt (z.B. durch eine <tt>if</tt>- oder <tt>while</tt>-Anweisung), ist nicht klar, welcher Befehl nach der Verzweigung ausgeführt werden soll, bevor Stufe 3 der Pipeline die Verzweigungsbedingung ausgewertet hat. Bis dahin wären die ersten beiden Stufen der Pipeline unbenutzt. Moderne Prozessoren benutzen zwar ausgefeilte Heuristiken, um das Ergebnis der Bedingung vorherzusagen, und führen den hoffentlich richtigen Zweig des Codes spekulativ aus, aber dies funktioniert nicht immer. Man sollte deshalb generell die Anzahl der Verzweigungen minimieren. Als Nebeneffekt führt dies meist auch zu besser lesbarem, verständlicherem Code. Im Matrixbeispiel kann man
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
::durch
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
ersetzen. Die Diagonalelemente <tt>a[j + jN]</tt> werden jetzt zwar zweimal initialisiert (in der Schleife auf Null, dann auf Eins), aber durch Elimination der <tt>if</tt>-Abfrage wird dies wahrscheinlich mehr als ausgeglichen, zumal dadurch die innere Schleife wesentlich vereinfacht wurde.
;Ausnutzen des Prozessor-Cache: Zugriffe auf den Hauptspeicher sind sehr langsam. Deshalb werden stets ganze Speicherseiten auf einmal in den [http://en.wikipedia.org/wiki/Cache Cache] des Prozessors geladen. Wenn unmittelbar nacheinander benutzte Daten auch im Speicher nahe beieinander liegen (sogenannte "[http://en.wikipedia.org/wiki/Locality_of_reference locality of reference]"), ist die Wahrscheinlichkeit groß, dass die als nächstes benötigten Daten bereits im Cache sind und damit schnell gelesen werden können. Bei vielen Algorithmen kann man die Implementation so umordnen, dass die locality of reference verbessert wird, was zu einer drastischen Beschleunigung führt. Im Matrix-Beispiel ist z.B. die Reihenfolge der Schleifen wichtig. Für konstanten Index <tt>j</tt> liegen die Indizes <tt>i</tt> im Speicher hintereinander. Deshalb ist es günstig, in der inneren Schleife über <tt>i</tt> zu iterieren:
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
:Die umgekehrte Reihenfolge der Schleifen ist hingegen ungünstig
for i in range(N):
for j in range(N):
a[i + j*N] = 0.0
a[i + i*N] = 1.0
:Jetzt werden in der inneren Schleife stets N Datenelemente übersprungen. Besonders bei großem N muss man daher häufig den Cache neu füllen, was bei der ersten Implementation nicht notwendig war. (Außerdem verliert man hier die Optimierung <tt>jN = j*N</tt>, die jetzt nicht mehr möglich ist.)

Als Faustregel kann man durch Optimierung eine Verdoppelung der Geschwindigkeit erreichen (in Ausnahmefällen auch mehr). Benötigt man stärkere Verbesserungen, muss man wohl oder übel einen besseren Algorithmus oder einen schnelleren Computer verwenden.

== Algorithmen-Komplexität ==

Komplexitätsbetrachtungen ermöglichen den Vergleich der prinzipiellen Eigenschaften von Algorithmen unabhängig von einer Implementation, Umgebung etc.

Eine einfache Möglichkeit ist das Zählen der Aufrufe einer Schlüsseloperation. Beispiel Sortieren:
* Anzahl der Vergleiche
* Anzahl der Vertauschungen

=== Beispiel: Selection Sort ===

for i in range(len(a)-1):
max = i
for j in range(i+1, len(a)):
if a[j] < a[max]:
max = j
a[max], a[i] = a[i], a[max] # swap

*Anzahl der Vergleiche: Ein Vergleich in jedem Durchlauf der inneren Schleife. Es ergibt sich folgende Komplexität:
*:Ingesamt <math>\sum_{i=0}^{N-2} \sum_{j=i+1}^{N-1}1 = \frac{N}{2} (N-1) \!</math> Vergleiche.

*Anzahl der Vertauschungen (swaps): Eine Vertauschung pro Durchlauf der äußeren Schleife:
*:Insgesamt <math>N-1 \!</math> Vertauschungen

Die Komplexität wird durch die Operationen bestimmt, die am häufigsten ausgeführt werden, hier also die Anzahl der Vergleiche. Die Anzahl der Vertauschungen ist hingegen kein geeignetes Kriterium für die Komplexität von selection sort, weil der Aufwand in der inneren Schleife ignoriert würde.

=== Fallunterscheidung: Worst und Average Case ===

Die Komplexität ist in der Regel eine Funktion der Eingabegröße (Anzahl der Eingabebits, Anzahl der Eingabeelemente). Sie kann aber auch von der Art der Daten abhängen, nicht nur von der Menge, z.B. vorsortierte Daten bei Quicksort. Um von der Art der Daten unabhängig zu werden, kann man zwei Fälle der Komplexität unterscheiden:

* Komplexität im ungünstigsten Fall
*: Der ungünstigste Fall ist die Eingabe gegebener Länge, für die der Algorithmus am langsamsten ist. Der Nachteil dieser Methode besteht darin, dass dieser ungünstige Fall in der Praxis vielleicht gar nicht oder nur selten vorkommt, so dass sich der Algorithmus in Wirklichkeit besser verhält als man nach dieser Analyse erwarten würde. Beim Quicksort-Algorithmus mit zufälliger Wahl des Pivot-Elements müsste z.B. stets das kleinste oder größte Element des aktuellen Intervalls als Pivot-Element gewählt werden, was äußerst unwahrscheinlich ist.
* Komplexität im durchschnittlichen/typischen Fall
*: Der typische Fall ist die mittlere Komplexität des Algorithmus über alle möglichen Eingaben. Dazu muss man die Wahrscheinlichkeit jeder möglichen Eingabe kennen, und berechnet dann die mittlere Laufzeit über dieser Wahrscheinlichkeitsverteilung. Leider ist die Wahrscheinlichkeit der Eingaben oft nicht bekannt, so dass man geeignete Annahmen treffen muss. Bei Sortieralgorithmen können z.B. alle möglichen Permutationen des Eingabearrays als gleich wahrscheinlich angenommen werden, und der typische Fall ist dann die mittlere Komplexität über alle diese Eingaben. Oft hat man jedoch in der Praxis andere Wahrscheinlichkeitsverteilungen, z.B. sind die Daten oft "fast sortiert" (nur wenige Elemente sind an der falschen Stelle). Dann verhält sich der Algorithmus ebenfalls anders als vorhergesagt.

Wir beschränken uns in dieser Vorlesung auf die Komplexität im ungünstigseten Fall. '''Exakte''' Formeln für Komplexität sind aber auch dann schwer zu gewinnen, wie das folgende Beispiel zeigt:

=== Beispiele aus den Übungen (Gemessene Laufzeiten für Mergesort/Selectionsort) ===

* Mergesort: <math>\frac{0,977N\log N}{\log 2} + 0,267N-4.39 \!</math>
*: andere Lösung: <math>1140 N\log(N) - 1819N + 6413 \!</math>
* Selectionsort: <math>\frac{1}{2}N^2 - \frac{1}{2N} - 10^{-12} \!</math>
*: andere Lösung: <math>1275N^2 - 116003^N + 11111144 \!</math>

Aus diesen Formeln wird nicht offensichtlich, welcher Algorithmus besser ist.
Näherung: Betrachte nur '''sehr große Eingaben''' (meist sind alle Algorithmen schnell genug für kleine Eingaben). Dieses Vorgehen wird als '''Asymptotische Komplexität''' bezeichnet (N gegen unendlich).

=== Asymptotische Komplexität am Beispiel Polynom ===

Polynom: <math>a\,x^2+b\,x+c=p\!</math>

<math>x \!</math> sei die Eingabegröße, und wir betrachten die Entwicklung von <math>p \!</math> in Abhängigkeit von <math>x \!</math>.

* <math>x=0 \!</math>
*: <math>p=c \!</math>
* <math>x=1 \!</math>
*: <math>p=a+b+c \!</math>
* <math>x=1000 \!</math>
*: <math>p=1000000a+1000b+c \approx 1000000a\!</math>
* <math>x \to \infty \!</math>
*: <math>p \approx x^2a\!</math>

Für sehr große Eingaben verlieren also ''b'' und ''c'' immer mehr an Bedeutung, so dass am Ende nur noch ''a'' für die Komplexitätsbetrachtung wichtig ist.

== Landau-Symbole ==

Um die asymptotische Komplexität verschiedener Algorithmen miteinander vergleichen zu können, verwendet man die sogenannten [http://de.wikipedia.org/wiki/Landau-Symbole Landau-Symbole]. Das wichtigste Landau-Symbol ist <math>\mathcal{O}</math>, mit dem man eine ''obere Schranke'' <math>f \in \mathcal{O}(g)</math> für die Komplexität angeben kann.

Schreibt man <math>f \in \Omega(g)</math>, so stellt dies eine asymptotische ''untere Schranke'' für die Funktion f dar.

Schließlich bedeutet <math>f \in \Theta(g)</math>, dass die Funktion f genauso schnell wie die Funktion g wächst, das heißt man hat eine asymptotisch ''scharfe Schranke'' für f. Hierzu muss sowohl <math>f\in\mathcal{O}(g)</math> als auch <math>f \in \Omega(g)</math> erfüllt sein.

Im nun folgenden soll auf die verschiedenen Landau-Symbole noch näher eingegeangen werden.

===O-Notation===

Intuitiv gilt: Für große N dominieren die am schnellsten wachsenden Terme einer Funktion. Die Notation <math>f \in \mathcal{O}(g)</math> (sprich "f ist in O von g" oder "f ist von derselben Größenordnung wie g") formalisiert eine solche Abschätzung der asymptotischen Komplexität der Funktion f von oben.
; Asymptotische Komplexität: Für zwei Funktionen f(x) und g(x) gilt
::<math>f(x) \in \mathcal{O}(g(x))</math>
: genau dann wenn es eine Konstante <math>c>0</math> und ein Argument <math>x_0</math> gibt, so dass
::<math>\forall x \ge x_0:\quad f(x) \le c\,g(x)</math>.
:Die Menge <math>\mathcal{O}(g(x))</math> aller durch g(x) abschätzbaren Funktionen ist also formal definiert durch
::<math>\mathcal{O}(g(x)) = \{ f(x)\ |\ \exists c>0: \forall x \ge x_0: 0 \le f(x) \le c\,g(x)\}</math>

Die Idee hinter dieser Definition ist, dass g(x) eine wesentlich einfachere Funktion ist als f(x), die sich aber nach geeigneter Skalierung (Multiplikation mit c) und für große Argumente x im wesentlichen genauso wie f(x) verhält. Man kann deshalb in der Algorithmenanalyse f(x) durch g(x) ersetzen. <math>f(x) \in \mathcal{O}(g(x))</math> spielt für Funktionen eine ähnliche Rolle wie der Operator ≤ für Zahlen: Falls a ≤ b gilt, kann bei einer Abschätzung von oben ebenfalls a durch b ersetzt werden.

==== Ein einfaches Beispiel ====

[[Image:Sqsqrt.png]]

Rot = <math>x^2 \!</math>
Blau = <math>\sqrt{x} \!</math>

<math>\sqrt{x} \in \mathcal{O}(x^2)\!</math> weil <math>\sqrt{x} \le c\,x^2\!</math> für alle <math>x \ge x_0 = 1 \!</math> und <math>c = 1\!</math>, oder auch für <math>x \ge x_0 = 4 \!</math> und <math>c = 1/16</math> (die Wahl von c und x0 in der Definition von O(.) ist beliebig, solange die Bedingungen erfüllt sind).

==== Komplexität bei kleinen Eingaben ====

Algorithmus 1: <math>\mathcal{O}(N^2) \!</math> 
Algorithmus 2: <math>\mathcal{O}(N\log{N}) \!</math>

Algorithmus 2 ist schneller (von geringerer Komplexität) für große Eingaben, aber bei kleinen Eingaben (insbesondere, wenn der Algorithmus in einer Schleife immer wieder mit kleinen Eingaben aufgerufen wird) könnte Algorithmus 1 schneller sein, falls der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor ''c'' bei Algorithmus 2 einen wesentlich größeren Wert hat als bei Algorithmus 1.

==== Eigenschaften der O-Notation (Rechenregeln) ====

# Transitiv:
#: <math>f(x) \in \mathcal{O}(g(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) \in \mathcal{O}(h(x)) \!</math>
# Additiv:
#: <math>f(x) \in \mathcal{O}(h(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) + g(x) \in \mathcal{O}(h(x)) \!</math>
# Für Monome gilt:
#: <math>x^k \in \mathcal{O}(x^k)</math> und
#: <math>x^k \in \mathcal{O}(x^{k+j}), \forall j \ge 0 \!</math>
# Multiplikation mit einer Konstanten:
#: <math>f(x) \in \mathcal{O}(g(x)) \to c\,f(x) \in \mathcal{O}(g(x))\!</math>
#: andere Schreibweise:
#: <math>f(x) = c\,g(x) \to f(x) \in \mathcal{O}(g(x))\!</math>
# Folgerung aus 3. und 4. für Polynome:
#: <math>a_0+a_1\,x + ... + a_n\,x^n \in \mathcal{O}(x^n)\!</math>
#: Beispiel: <math>a\,x^2+b\,x+c \in \mathcal{O}(x^2)\!</math>
# Logarithmus:
#: <math>a, b > 1\!</math>
#: <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>
#: Die Basis des Logarithmus spielt also keine Rolle.
#: Beweis hierfür:
#:: <math>\log_{a}{x} = \frac{\log_{b}{x}}{\log_{b}{a}}\!</math>
#:: Mit <math>c = 1 / \log_{b}{a}\,</math> gilt: <math>\log_{a}{x} = c\,\log_{b}{x}\!</math>.
#:: Wird hier die (zweite) Regel für Multiplikation mit einer Konstanten angewendet, fällt der konstante Faktor weg, also <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>.
#: Insbesondere gilt auch <math>\log_{a}{x} \in \mathcal{O}(\log_{2}{x})\!</math>, es kann also immer der 2er Logarithmus verwendet werden.

==== O-Kalkül ====

Das O-Kalkül definiert wichtige Vereinfachungsregeln for Ausdrücke in O-Notation (Beweise: siehe Übungsaufgabe):

# <math>f(x) \in \mathcal{O}(f(x))\!</math>
# <math>\mathcal{O}(\mathcal{O}(f(x))) \in \mathcal{O}(f(x))\!</math>
# <math>c\,\mathcal{O}(f(x)) \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# <math>\mathcal{O}(f(x))+c \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# Sequenzregel:
#: Wenn zwei nacheinander ausgeführte Programmteile die Komplexität <math>\mathcal{O}(f(x))</math> bzw. <math>\mathcal{O}(g(x))</math> haben, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(f(x))</math> falls <math>g(x) < \mathcal{O}(f(x))</math> bzw.
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(g(x))\!</math> falls <math>f(x) < \mathcal{O}(g(x))</math>.
#: Informell schreibt man auch: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(max(f(x), g(x)))\!</math>.
# Schachtelungsregel bzw. Aufrufregel:
#: Wenn in einer geschachtelten Schleife die äußere Schleife die Komplexität <math>\mathcal{O}(f(x))</math> hat, und die innere <math>\mathcal{O}(g(x))</math>, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) * \mathcal{O}(g(x)) \in \mathcal{O}(f(x) * g(x))\!</math>.
#: Gleiches gilt wenn eine Funktion <math>\mathcal{O}(f(x))</math>-mal aufgerufen wird, und die Komplexität der Funktion selbst <math>\mathcal{O}(g(x))</math> ist.

;Beispiel für 5.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Dies gilt auch für ihre Hintereinanderausführung:
for i in range(N):
a[i] = i
for i in range(N):
print a[i]
;Beispiele für 6.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Ihre Verschachtelung hat daher die Komplexität <math>\mathcal{O}(N^2)</math>.
for i in range(N):
for j in range(N):
a[i*N + j] = i+j
: Dies gilt ebenso, wenn statt der inneren Schleife eine Funktion mit Komplexität <math>\mathcal{O}(N)</math> ausgeführt wird:
for i in range(N):
a[i] = foo(i, N) # <math>\mathrm{foo}(i, N) \in \mathcal{O}(N)</math>

==== O-Kalkül auf das Beispiel des Selectionsort angewandt ====

Selectionsort: Wir hatten gezeigt dass <math>f(N) = \frac{N^2}{2} - \frac{N}{2}</math>. Nach der Regel für Polynome vereinfacht sich dies zu <math>f(N) \in \mathcal{O}\left(\frac{N^2}{2}\right) = \mathcal{O}(N^2)\!</math>.

Alternativ via Schachtelungsregel:
: Die äußere Schleife wird (''N''-1)-mal durchlaufen: <math>N-1 \in \mathcal{O}(N)</math>
: Die innere Schleife wird (''N-i''-1)-mal durchlaufen. Das sind im Mittel ''N''/2 Durchläufe: <math>N/2 \in \mathcal{O}(N)</math>
: Zusammen: <math>\mathcal{O}(N)*\mathcal{O}(N) \in \mathcal{O}(N^2)</math>

Nach beiden Vorgehensweisen kommen wir zur Schlussfolgerung, dass der Selectionsort die asymptotische Komplexität <math>\mathcal{O}(N^2)\!</math> besitzt.

==== Zusammenhang zwischen Komplexität und Laufzeit ====

Wenn eine Operation 1ms dauert, erreichen Algorithmen verschiedener Komplexität folgende Leistungen (wobei angenommen wird, dass der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor immer etwa gleich 1 ist):

{| class="wikitable" style="text-align:left" cellpadding="7"
|+
|-
! Komplexität !! Operationen in 1s !! Operationen in 1min !! Operationen in 1h
|-
! <math>\mathcal{O}(N)</math>
| 1000 || 60.000 || 3.600.000
|-
! <math>\mathcal{O}(N\log_2{N})</math>
| 140 || 4895 || 204094
|-
! <math>\mathcal{O}(N^2)</math>
| 32 || 245 || 1898
|-
! <math>\mathcal{O}(N^3)</math>
| 10 || 39 || 153
|-
! <math>\mathcal{O}(2^N)</math>
| 10 || 16 || 21
|}

==== Exponentielle Komplexität ====
Der letzte Fall <math>\mathcal{O}(2^N)</math> ist von exponentieller Komplexität. Das bedeutet, dass eine Verdopplung des Aufwands nur bewirkt, dass die maximale Problemgröße um eine Konstante wächst. Algorithmen mit exponentieller (oder noch höherer) Komplexität werden deshalb als '''ineffizient''' bezeichnet. Algorithmen mit höchstens polynomieller Komplexität gelten hingegen als effizient.

In der Praxis sind allerdings auch polynomielle Algorithmen mit hohem Exponenten meist zu langsam. Als Faustregel kann man eine praktische Grenze von <math>\mathcal{O}(N^3)</math> ansehen. Bei einer Komplexität von <math>\mathcal{O}(N^3)</math> bewirkt ein verdoppelter Aufwand immer noch eine Steigerung der maximalen Problemgröße um den Faktor <math>\sqrt[3]{2}</math> (also eine ''multiplikative'' Vergrößerung um ca. 25%, statt nur einer additiven Vergrößerung wie bei exponentieller Komplexität).

===<math>\Omega</math>- Notation===

Genauso wie <math>f \in \mathcal{O}(g)</math> eine Art <math>\le</math>-Operator für Funktionen ist, definiert <math>f \in \Omega(g) </math> eine Abschätzung von unten, analog zum <math>\ge</math>-Operator für Zahlen. Formal kann man <math>f(N) \in \Omega(g(N)) </math> genau dann schreiben, falls es eine Konstante <math> c > 0 </math> gibt, so dass

<math> f(N) \ge c \cdot g(N) </math> für <math> N \ge N_0 </math>

gilt.
Man verwendet diese Notation also um abzuschätzen, wie groß der Aufwand (die Komplexität) für einen bestimmten Algorithmus ''mindestens'' ist und nicht ''höchstens'', was man mit der <math>\mathcal{O}</math> - Notation ausdrücken würde.

Ein praktisches Beispiel für eine Anwendung der <math>\Omega</math>- Notation wäre die Fragestellung, ob es ''prinzipiell'' einen besseren Algorithmus für ein bestimmtes Problem gibt. Wie später im Abschnitt [[Suchen#Sortieren_als_Suchproblem|Sortieren als Suchproblem]] gezeigt wird, ist das Sortieren eines Arrays durch paarweise Vergleiche von Elementen immer mindestens von der Komplexität <math> \Omega(N\cdot \ln N) </math>, was konkret bedeutet, dass kein Sortieralgorithmus, der nach diesem Prinzip arbeitet, jemals eine geringere Komplexität als beispielsweise Merge-Sort haben wird. Natürlich kann man den entsprechenden Sortieralgorithmus, also Merge-Sort zum Beispiel, unter Umständen noch optimieren, aber die Komplexität wird erhalten bleiben. Mit diesem Wissen kann man sich viel (vergebliche) Arbeit sparen.

===<math>\Theta</math>- Notation===

<math>f(N) \in \Theta(g(N))</math> ist eine scharfe Abschätzung der asymptotischen Komplexität einer Funktion f.

Damit dies gilt, muss <math>f(N) \in \mathcal{O}(g(N))</math> und ''gleichzeitig'' <math>f(N) \in \Omega(g(N))</math> erfüllt sein.

Dies ist natürlich auch die beste Abschätzung der asymptotischen Komplexität einer Funktion f. Formal bedeutet <math>f(N) \in \Theta(g(N))</math> dass es zwei Konstanten <math> c_1 </math> und <math> c_2 </math>, beide größer als Null, gibt, so dass für alle <math> N \geq N_0 </math> gilt:

<math> c_1 \cdot g(N) \leq f(N) \leq c_2 \cdot g(N) </math>.

In der Praxis wird manchmal statt der <math>\Theta</math>-Notation auch dann die <math>\mathcal{O}</math>-Notation benutzt, wenn eine scharfe Schranke ausgedrückt werden soll. Dies ist zwar formal nicht korrekt, aber man kann die intendierte Bedeutung meist aus dem Kontext erschließen.

== Komplexitätsvergleich zweier Algorithmen ==

In diesem Abschnitt wollen wir der Frage nachgehen, wie ein formaler Beweis für die Behauptung <math> f(N) \in \mathcal{O}(g(N))</math> geschehen kann. Hierbei werden zwei Beweismethoden vorgestellt werden, und zwar der '''Beweis über die Definition der Komplexität''' sowie der '''Beweis durch Dividieren'''.

===Beweis über die Definition der asymptotischen Komplexität===

Die Definition der asymptotischen Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> war:

Es gibt eine Konstante <math> c > 0 </math>, so dass <math> f(N) \le c \cdot g(N) </math> für <math> N \ge N_0 </math> erfüllt ist.

Um also die die asymptotische Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> zu beweisen, muss man die oben erwähnten Konstanten c und <math> N_0 </math> finden, so dass

<math> f(N) \leq c \cdot g(N) </math> für alle <math> N \ge N_0 </math> erfüllt ist.

Dies geschieht zweckmäßigerweise mit dem Beweisprinzip der ''vollständigen Induktion''. Hierbei ist zu zeigen, dass
# <math> f(N_0) \leq g(N_0) </math> für die eine zu bestimmende Konstante <math> N_0 </math> gilt (''Induktionsanfang'') und
# falls <math> f(N) \leq g(N) </math>, dann auch <math> f(N+1) \leq g(N+1) </math> (''Induktionsschritt'') gilt.

===Beweis durch Dividieren===

Hierbei wählt man eine Konstante c und zeigt, dass <math> \lim_{N \rightarrow \infty} \frac{f(N)}{c \cdot g(N)} \leq 1 </math> gilt (für die O-Notation, bei Ω-Notation gilt entsprechend <math>\geq 1 </math>). Man kann dies auch als alternative Definition der Komplexität verwenden.

Als Beispiel betrachten wir die beiden Funktionen <math> f(N) = N \,\lg N </math> und <math> g(N) = N^2 </math> und wollen zeigen, dass <math>f(N) \in \mathcal{O}(g(N))</math> gilt.

Als Konstante c wählen wir <math> c = 1 </math>

<math> \lim_{N \rightarrow \infty} \frac{f(N)}{g(N)} = \lim_{N \rightarrow \infty} \frac{\lg N}{N} = \frac{\infty}{\infty} </math>

Unbestimmte Ausdrücke der Form
<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} </math>,
in denen sowohl <math> f(x) </math> als auch <math> g(x) </math> mit <math> x \rightarrow x_0 </math> gegen Null oder gegen Unendlich streben, kann man manchmal mit den Regeln von [http://de.wikipedia.org/wiki/L%27Hospital%27sche_Regel ''l'Hospital''] berechnen. Danach darf man die Funktionen f und g zur Berechnung des unbestimmten Ausdrucks durch ihre k-ten Ableitungen ersetzen:

<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} = \lim_{x \rightarrow x_0} \frac{f^{(k)}(x)}{g^{(k)}(x)} </math>

In unserem Fall verwenden wir die erste Ableitung und erhalten:
<math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)} = \lim_{N \rightarrow \infty} \frac{1/N}{1} \rightarrow 0 </math>

Damit wurde <math>f(N) \in \mathcal{O}(g(N))</math>, also <math>N \lg N \in \mathcal{O}(N^2)</math> gezeigt.

Man beachte hierbei, dass <math>N \lg N \in \mathcal{O}(N^2)</math> keine enge Grenze für die Komplexität von <math>N \,\lg N</math> darstellt, da der Grenzwert <math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)}\, </math> gegen 0 und nicht gegen eine von Null verschiedene Konstante strebt. In diesem Fall haben wir die Komplexität von <math>N \cdot \lg N </math> also nur nach oben abschätzen können.

===Beispiel für den Komplexitätsvergleich: Gleitender Mittelwert (Running Average)===

Wir berechnen für ein gegebenes Array <tt>a</tt> einen gleitenden Mittelwert über <tt>k</tt> Elemente: 
::<math>r_i = \frac{1}{k} \sum_{j=i-k+1}^i a_j</math> 
Das heisst, für jedes <tt>i</tt> mitteln wir die letzten <tt>k</tt> Elemente von <tt>a</tt> und schreiben das Ergebnis in <tt>r[i]</tt>. Diese Operation ist z.B. bei Börsenkursen wichtig: Neben dem aktuellen Kurs für jeden Tag wird dort meist auch der gleitende Mittelwert der letzten 30 Tage sowie der letzten 200 Tage angegeben. In diesen Mittelwerten erkennt man besser die langfristige Tendenz, weil die täglichen Schwankungen herausgemittelt werden. Wir nehmen außerdem an, dass
* Array-Zugriff hat eine Komplexität von O(1)
* <math>k \ll N</math>, d.h. <math>N-k\approx N</math>.

Die beiden folgenden Algorithmen berechnen die Mittelwerte auf unterschiedliche Art. Der linke folgt der obigen Definition durch eine Summe, während der rechte inkrementell arbeitet: Man kann den Bereich der <tt>k</tt> letzten Werte als Fenster betrachten, das über das Array <tt>a</tt> geschoben wird. Schiebt man das Fenster ein Element weiter, fällt links ein Element heraus, und rechts kommt eins hinzu. Man muss also nicht jedes Mal die Summe neu berechnen, sondern kann den vorigen Wert aktualisieren. Wir werden sehen, dass dies Folgen für die Komplexität des Algorithmus hat.

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1: O(N * k)
! Komplexität
! Version 2: O(N)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|
<tt>for i in range(k):</tt>
|
'''<center>O(k)</center>'''
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|
:: <tt>r[k-1] += a[i]</tt>
|
'''<center>O(1)</center>'''
|-
|
6.
|
:::: <tt>r[j] += a[i]</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(k, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|
:: <tt>r[j] = (a[j] - a[j-k] + r[j-1])</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(len(a)):</tt>
|
'''<center>O(N)</center>'''
|-
|
9.
|

|

|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
10.
|

|

|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Wir zeigen unten dass Version 2 eine geringere Komplexität besitzt, obwohl sie mehr Zeilen benötigt.

Wir haben in der Tabelle die Komplexität jeder Zeile für sich angegeben. Einfache Anweisungen (Berechnungen, Lese- und Schreibzugriffe auf das Array, Zuweiseungen) haben konstante Komplexität, die Komplexität des Schleifenkopfes allein (also der <tt>for</tt>-Anweisung ohne den eingerückten Schleifenkörper) entspricht der Anzahl der Durchläufe. Wir müssen jetzt noch die Verschachtelung der Schleifen und die Nacheinanderausführung von Anweisungen berücksichtigen.

====Berechnung der Komplexität von Version 1====

(Wiederholung der Rechenregeln: siehe Abschnitt [[Effizienz#O-Notation|O-Notation]])

Wir betrachten zunächst die innere Schleife (Zeilen 5 und 6 von Version 1):

Der Schleifenkopf (Zeile 5) hat die Komplexität <math>\mathcal{O}(k)</math>, weil die Schleife k-mal durchlaufen wird. Der Schleifenkörper (Zeile 6) hat die Komplexität <math>\mathcal{O}(1)</math>. Nach der Verschachtelungsregel müssen wir die beiden Komplexitäten multiplizieren, und es ergibt sich:

::<math>\mathcal{O}(k)\cdot\mathcal{O}(1) = \mathcal{O}(k\cdot 1)=\mathcal{O}(k)</math>

Wir betrachten nun die äußere Schleife. Der Schleifenkopf (Zeile 4) wird (N-k)-mal durchlaufen und hat somit eine Komplexität von <math>\mathcal{O}(N)</math>. Der Schleifenkörper (Zeilen 5 bis 7) besteht aus der inneren Schleife (Zeilen 5 und 6) mit der gerade berechneten Komplexität <math>\mathcal{O}(k)</math> sowie einer einfachen Anweisung (Zeile 7) mit Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel wird die Komplexität des Schleifenkörpers durch Addition berechnet:

::<math>\mathcal{O}(k)+\mathcal{O}(1) = \mathcal{O}(\max(k,1)) = \mathcal{O}(k)</math>

Die Komplexität der gesamten äußeren Schleife erhalten wir nach der Verschachtelungsregel wieder durch multiplizieren:

::<math>\mathcal{O}(N)\cdot\mathcal{O}(k) = \mathcal{O}(N\cdot k)</math>

Die übrigen Schritte des Algorithmus werden einfach nacheinander ausgeführt, so dass sie ebenfalls nach der Sequenzregel behandelt werden. Wir erhalten

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(N\cdot k)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,N\cdot k,1)) = \mathcal{O}(N\cdot k)</math>

Der gesamte Algorithmus hat also die Komplexität <math>\mathcal{O}(N\cdot k)</math>.

====Berechnung der Komplexität von Version 2====

Hier gibt es nur einfache Schleifen ohne Verschachtelung. Da der Schleifenkörper jeder Schleife nur einfache Anweisungen der Komplexität <math>\mathcal{O}(1)</math> enthält, ergibt sich die Komplexität der Schleifen nach der Verschachtelungsregel als

::<math>\mathcal{O}(X)\cdot\mathcal{O}(1) = \mathcal{O}(X\cdot 1)=\mathcal{O}(X)</math>

wobei <math>\mathcal{O}(X)</math> die Komplexität des jeweiligen Schleifenkopfes ist. Wir erhalten also für Zeilen 4 und 5: <math>\mathcal{O}(k)</math>, Zeilen 6 und 7: <math>\mathcal{O}(N)</math>, Zeilen 8 und 9: <math>\mathcal{O}(N)</math>. Die Hintereinanderausführung wird nach der Sequenzregel behandelt:

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(k)+\mathcal{O}(N)+\mathcal{O}(N)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,k,N,N,1)) = \mathcal{O}(N)</math>

Dieser Algorithmus hat also nur die Komplexität <math>\mathcal{O}(N)</math>.

====Fazit====

Obwohl Version 2 mehr Schritte benötigt hat sie eine geringere Komplexität, da die for-Schleifen nicht wie bei Version 1 verschachtelt/untergeordnet sind. Bei verschachtelten for-Schleifen muss die Multiplikationsregel angewendet werden → höhere Komplexität.

Die gerade berechnete Komplexität gilt aber nur unter der Annahme, dass Array-Zugriffe konstante Komplexität <math>\mathcal{O}(1)</math> besitzen. Wenn dies nicht der Fall ist, kann sich die Komplexität des Algorithmus drastisch verschlechtern.

{| border="1" cellspacing="0" cellpadding="5"
|Allgemein gilt: 
Algorithmen-Analysen beruhen auf der Annahme, dass Zugriffe auf die Daten optimal schnell sind, dass heißt, dass die für den jeweiligen Algorithmus am besten geeignete Datenstruktur verwendetet wird. → Ansonsten: Komplexitätsverschlechterung!
|}
 

====Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur====

Wir verwende im Mittelwert-Algorithmus eine verkettete Liste anstelle des Eingabe-Arrays <tt>a</tt>. Wir benötigen dazu eine Funktion, die das j-te Element der Liste zurückgibt. Wie üblich ist die Liste mit Hilfe einer Knotenklasse implementiert:
class Node:
def __init__(self, data):
self.data = data
self.next = None

Die Listenklasse selbst hat ein Feld <tt>head</tt>, das eine Referenz auf den ersten Knoten speichert, und jeder Knoten speichert im Feld <tt>next</tt> eine Referenz auf seinen Nachfolger. Um zum j-ten Element zu gelangen, muss man die Liste sequenziell durchlaufen
def get_jth(list, j):
r = list.head
while j > 0:
r = r.head
j -= 1
return r.data
Die Komplexität dieser Funktion ist offensichtlich <math>\mathcal{O}(j)</math> (Komplexitätsberechnung wie oben). Wir setzen jetzt bei Version 1 des Mittelwert-Algorithmus diese Funktion in Zeile 6 anstelle des Indexzugriffs <tt>a[i]</tt> ein (nur in dieser Zeile wird auf die Elemente des Arrays zugegriffen). Wir erhalten folgende Implementation (die Änderungen sind rot markiert):

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1 mit Liste: O(N * k)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|-
|
6.
|
:::: <tt>r[j] += get_jth(a, i)</tt>
|
'''<center>O(i)</center>'''
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Der Aufruf der Funktion <tt>get_jth</tt> ist jetzt gleichbedeutend mit einer dreifach verschachtelten Schleife (weil <tt>get_jth</tt> ja eine zusatzliche Schleife enthält). Die Anzahl der Operationen in Zeile 4 bis 6 ist jetzt

::<math>f(N,k)=\sum_{j=k-1}^{N-1}\,\sum_{i=j-k+1}^j\,\mathcal{O}(i)</math>

wobei das <math>\mathcal{O}(i)</math> die neue Schleife durch Verwendung der Liste repräsentiert. Mit Mathematica-Hilfe [http://www.wolfram.com/] lässt sich diese Summe exakt ausrechnen

::<math>f(N,k)=\frac{1}{2}(k N^2-k^2 N+k^2-k)\in \mathcal{O}(k N^2)</math>

Die Komplexitätsberechnung erfolgte dabei nach der Regel für Polynome unter Beachtung von <math>k \ll N</math>.

====Fazit:====

Die Komplexität von Version 1 mit einer verketteten Liste wäre O(N2 * k)
'''→ Die richtige Datenstruktur ist wichtig, da es sonst zu einer Komplexitätsverschlechterung kommen kann!'''

Auf Version 2 unseres Running Average-Beispiels hätte eine verkettete Liste allerdings keine Auswirkungen, da die inkrementelle Berechnung der Summen in Zeile 7 weiterhin möglich ist (bei geschickter Implementation!) und somit Version 2 immer noch eine Komplexität von O(N) hätte.

==Amortisierte Komplexität==

Bis jetzt wurde die Komplexität nur im schlechtesten Fall (Worst Case) betrachtet. Bei einigen Operationen schwankt die Komplexität jedoch sehr stark, wenn man sie mehrmals hintereinander ausführt, und der schlechteste Fall kommt nur selten vor. Dann ist es sinnvoll, die amortisierte Komplexität zu betrachten, die sich mit der durchschnittlichen Komplexität über viele Aufrufe der selben Operation beschäftigt.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse Wikipedia: Amortisierte Laufzeitanalyse]]

===Beispiel: Inkrementieren von Binärzahlen===

Frage: Angenommen, das Umdrehen eines Bits einer Binärzahl verursacht Kosten von 1 Einheit. Wir erzeugen die Folge der natürlichen Zahlen in Binärdarstellung durch sukzessives Inkrementieren, von Null beginnend. Bei jeder Inkrementierung werden einige Bits verändert, aber diese Zahl (und damit die Kosten der Inkrementierungen) ''schwanken'' sehr stark. Wir fragen jetzt, was eine Inkrementierung im Durchschnitt kostet?

Um diese Durchschnittskosten zu berechnen, bezahlen wir bei jeder Inkrementierung 2 Einheiten. Wenn davon nach Abzug der Kosten der jeweiligen Operation noch etwas übrig bleibt, wird der Rest dem Guthaben zugeschrieben. Umgekehrt wird ein eventueller Fehlbetrag (wenn eine Inkrementierung mehr als 2 Bits umdreht) aus dem Guthaben gedeckt. Dadurch werden die ansonsten großen Schwankungen der Kosten ausgeglichen:
:: Kosten < Einzahlung → es wird gespart
:: Kosten = Einzahlung → Guthaben bleibt unverändert
:: Kosten > Einzahlung → Guthaben wird für die Kosten verbraucht

{| border="1" cellspacing="0" cellpadding="5"
!Schritte
!Zahlen
!Kosten 
(Anzahl der geänderten Bits)
! Einzahlung
!Guthaben = 
altes Guthaben + Einzahlung - Kosten
|-
|1.
|00001
|1
|'''2'''
|'''1'''
|-
|2.
|00010
|2
|'''2'''
|'''1'''
|-
|3.
|00011
|1
|'''2'''
|'''2'''
|-
|4.
|00100
|3
|'''2'''
|'''1'''
|-
|5.
|00101
|1
|'''2'''
|'''2'''
|-
|6.
|00110
|2
|'''2'''
|'''2'''
|-
|7.
|00111
|1
|'''2'''
|'''3'''
|-
|8.
|01000
|4
|'''2'''
|'''1'''
|-
|}

Die Kosten ergeben sich aus der Anzahl der Ziffern die von 1 nach 0, bzw. von 0 nach 1 verändert werden

Rechnung:

1. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

2. Schritt: Kosten: 2 = Einzahlung: 2 
:: → es wird nicht gespart 
:: → Guthaben bleibt so wie es ist 

3. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

4. Schritt: Kosten: 3 > Einzahlung: 2 
:: → es wird eine 1 vom Guthaben genommen um die Kosten zu zahlen 

usw.

Man erkennt, dass vor teuren Operation (Wechsel von 3 auf 4 bzw. von 7 auf 8) genügend Guthaben angespart wurde, um die Kosten zu decken. Das Guthaben geht bei diesen Operationen immer wieder auf 1 zurück, aber es wird nie vollständig verbraucht (Dies kann natürlich auch mathematisch exakt bewiesen werden, wie wir es unten am Beispiel des dynamische Arrays zeigen). Wir schließen daraus, dass die durchschnittlichen oder '''amortisierten Kosten''' einer Inkrementierungsoperation gleich 2 sind.

Zum Weiterlesen: [[http://de.wikipedia.org/wiki/Account-Methode Wikipedia Account-Methode]]

====Fazit====
Die amortisierte Komplexität beschäftigt sich mit dem Durchschnitt aller Operation im ungünstigsten Fall. Operationen mit hohen Kosten, die aber nur selten ausgeführt werden, fallen bei der amortisierten Komplexität nicht so ins Gewicht. Bei Algorithmen, die gelegentlich eine "teure" Operation benutzen, ansonsten jedoch "billige" Operationen aufrufen, kann die amortisierte Komplexität niedriger sein als die Komplexität im schlechtesten (Einzel-)Fall.

In unserem Beispiel fallen die teuren Einzelschritte (z.B. 4. und 8. Schritt) bei den amortisierten Kosten nicht so ins Gewicht, da wir die Kosten aus unserem Guthaben mitbezahlen können. Das Guthaben ist immer groß genug, weil jeder zweite Aufruf eine billige Operation ist, die nur ein Bit umdreht und somit das Ansparen ermöglicht. Diese Betrachtung zeigt, dass die amortisierte (d.h. durchschnittliche) Komplexität des Algoithmus niedriger (nämlich konstant) ist als die Komplexität im schlechtesten Fall.

===Anwendung: Dynamisches Array===

Ein dynamisches Array hat die Eigenschaft, dass man effizient am Ende des Arrays neue Elemente anfügen kann, indem man die Länge des Arrays entsprechend vergrößert (siehe Übung 1). Die Analyse der amortisierten Komplexität der Anfüge-Operation zeigt uns, wie man das Vergrößern des Arrays richtig implementiert, damit die Operation wirklich effizient abläuft.

==== Ineffiziente naive Lösung ====

Wenn wir an ein Array ein Element anhängen wollen, müssen wir neuen Speicher allokieren, der die gewünschte Länge hat. Die Werte aus dem alten Array müssen dann in den neuen Speicher umkopiert werden. Danach kann das neue Element hinten angefügt werden, weil wir im neuen Array bereits Speicher für dieses Element reserviert haben. Bei der naiven Implementation des dynamischen Arrays wiederholt man dies bei jeder Anfügeoperation. Für die Analyse nehmen wir an, dass das Kopieren eines Elements konstante Zeit O(1) erfordert, ebenso das Einfügen eines neuen Elements auf in eine noch unbenutzte Speicherposition.

Naives Anhängen eines weiteren Elements an ein Array:

{| border="1" cellspacing="0" cellpadding="5" align="right"
!Schritte
|'''Array'''
(wie es nach jedem Schritt aussieht)
!Komplexität
|-
|<center>altes Array (N=4)</center>
|<center>[0,1,2,3]</center>
|<center>-</center>
|-
|1. neuer Speicher für    (N+1) Elemente
|<center>[None,None,None,None,None]</center>
|<center>O(N+1) = '''O(N)'''</center>(wenn der Speicher initialisiert wird (hier auf <tt>None</tt>), sonst O(1))
|-
|2. Kopieren
|<center>[0,1,2,3,None]</center>
|<center>'''O(N)'''</center>
|-
|3. append von "x"
|<center>[0,1,2,3,'x']</center>
|<center>'''O(1)'''</center>
|-
|}

altesArray = [0,1,2,3] 
altesArray.append('x')

1. Es wird ein neues Array der Größe N+1 erzeugt 
2. Die N Datenelemente aus dem alten Array werden in das neue Array kopiert 
Das sind N Operationen der Komplexität O(1), also ein Gesamtaufwand von O(N). 
3. 'x' wird mit Aufwand O(1) an die letzte Stelle des neuen Arrays geschrieben

Additionsregel: 
O(N) + O(1) ∈ O(N)

Folgerung:

Bei der naiven Methode erfordert jede Anfügung einen Aufwand O(N) (wobei N die derzeitige Arraygröße ist). Das ist nicht effizient.

====Effiziente Lösung durch Verdoppeln der Kapazität====

Offensichtlich kommt man nicht darum herum, den Inhalt des alten Arrays zu kopieren, wenn der allokierte Speicher voll ist. Der Trick für die effiziente Implementation der Anfügeoperation besteht darin, das Kopieren so selten wie möglich durchzuführen, also nicht wie in der naiven Lösung bei jeder Anfügeoperation. Hier kommt die amortisierte Komplexität ins Spiel: Ab und zu gibt es eine teure Anfügeoperation (wenn nämlich kopiert werden muss), aber wenn man den durchschnittlichen Aufwand über viele Anfügungen betrachtet, ist die Operation effizient. Der teure Fall wird sozusagen "herausgemittelt".

Um nur selten kopieren zu müssen, werden beim dynamischen Array mehr Speicherelemente reserviert als zur Zeit benötigt werden (in der naiven Lösung wurde dagegen immer nur Speicher für ein einziges neues Element reserviert). Wir unterscheiden deshalb

:<tt>capacity</tt> = Anzahl der allokierten Speicherzellen, d.h. der möglichen Elemente, die in das Array passen 
:<tt>size</tt> = Anzahl der Elemente, die im Array zur Zeit gespeichert sind 

Die Daten selbst werden in einem statischen Array gespeichert:
:<tt>data</tt> = statisches Array der Größe <tt>capacity</tt> 

Die folgende intuitive Abschätzung zeigt, dass es sinnvoll ist, die Größe des allokierten Speichers jeweils zu verdoppeln. Wir starten bei einem Array der Größe <tt>size = capacity</tt> = N. Da der verfügbare Speicher voll ist, müssen wir bei der nächsten Anfügung die N vorhandenen Elemente in ein neues Array der Länge <tt>new_capacity</tt> kopieren (Aufwand <math>N\cdot O(1)</math>). Danach können wir K Elemente billig einfügen (Aufwand <math>K\cdot O(1)</math>), wobei
:K = <tt>new_capacity - capacity</tt>
die Anzahl der nach dem Kopieren noch unbenutzen Speicherzellen ist. Der durchschnittliche Aufwand für diese K Einfügungen ist somit
:<math>\bar T = \frac{N \cdot O(1) + K \cdot O(1)}{K}=\frac{N+K}{K}\cdot O(1)</math>
Damit die mittlere Zeit in O(1) sein kann, muss der Quotient <math>(N+K)/K</math> eine Konstante sein. Wir setzen <math>K = a N</math> und erhalten:
:<math>\bar T = \frac{(a+1)N}{a N}\cdot O(1)=\frac{a+1}{a}\cdot O(1)</math>
Der amortisierte Aufwand über K Einfügungen ist also konstant, wenn <math>a</math> eine (kleine) von N unabhängige Zahl ist. Typischerweise wählt man
:<math>a = 1</math>
und mit <math>K = 1\cdot N</math> ergibt sich
:<tt>new_capacity = capacity</tt> + N = <tt>2 * capacity</tt>

Die Vorgehensweise beim Zufügen eines neuen Elements im Fall <tt>size == capacity</tt> ist also
* capacity wird verdoppelt 
: <tt>neue capacity = 2 * alte capacity</tt>
: (allgemein genügt es auch, wenn capacity um einen bestimmten Prozentsatz vergrößert wird,
:: <tt>neue capacity = alte capacity * c</tt>
: mit c > 1, z.B. c = 1.2, das entspricht oben der Wahl <math>a = 0.2</math>)
* ein neues statisches Array der Größe 'neue capacity' wird erzeugt
* das alte Array wird ins neue kopiert und danach freigegeben
* das anzufügende Element wird ins neue Array eingefügt
Umgekehrt geht man beim Entfernen des ''letzten'' Array-Elements vor. Normalerweise überschreibt man einfach das letzte Element mit <tt>None</tt> und dekrementiert <tt>size</tt>. Wird dadurch das Array zu klein (üblicherweise <tt>size < capacity / 4</tt>), wird die Kapazität halbiert, genauer:
* ein neues Array mit 
: <tt>neue capacity = alte capacity / 2 </tt>
: wird angelegt (bzw. mit
:: <tt>neue capacity = alte capacity / c </tt>
: wenn ein anderer Vergrößerungsfaktor verwendet wird)
* das alte Array wird ins neue kopiert und danach freigegeben

'''Folge:''' Die Kosten für das Vergrößern/Verkleinern der Kapazität werden amortisiert über viele Einfügungen, die kein Vergrößern erfordern. Die Operation <tt>append</tt> besitzt amortisierte Komplexität O(1). Im folgenden Abschnitt zeigen wir dies mathematisch exakt mit der Potentialmethode.

====Komplexitätsanalyse des dynamischen Arrays mit Potentialmethode====

Durchschnitt der Gesamtkosten für N-maliges append = <math>\frac{1}{N} \sum_{i = 1}^N Kosten(i)</math>. Zur Analyse der amortisierten Komplexität wird ein Potential 
::Φi = 2*sizei - capacityi 
eingeführt, wobei das Array nach dem i-ten Einfüge-Schritt die Größe sizei und die Kapizität capacityi hat. Wir nehmen vereinfachend an, dass es keine Löschoperationen gibt. Dann gilt nach dem i-ten Schritt jeweils
::Φi = 2*i - capacityi 

Fall 1: Array ist nicht voll 
Es wird kein Umkopieren benötigt, da das Array noch nicht voll ist 
→ sizei-1 < capacityi-1 
→ capacityi == capacityi-1

Kosten: 1 (für Einfügen des neuen Elements) 
Potenzial vor append: Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append: Φi = 2i - capacityi-1 

amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = 1 + (2i - capacityi-1) - [2(i - 1) - capacityi-1]
::::: = 1 + 2i - capacityi-1 - 2i + 2 + capacityi-1
::::: = 1 + <del>2i</del> - <del>capacityi-1</del> - <del>2i</del> + 2 + <del>capacityi-1</del>
::::: = 1 + 2
::::: = 3 = O(1) → konstant

Fall 2: Array ist voll 
Vor dem i-ten append muss umkopiert werden 
→ sizei-1 == capacityi-1 == i-1 
→ Allokieren eines neuen statischen Arrays mit verdoppelter Kapazität notwendig, also capacityi == 2*capacityi-1

Kosten: (i-1) + 1 (für Umkopieren und Einfügen des neuen Elements) 
Potenzial vor append = Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append = Φi = 2i - 2 capacityi-1 
amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = ((i - 1) + 1) + 2i - 2 capacityi-1 - [2(i-1) - capacityi-1]
::::: = i + <del>2i</del> - 2 capacityi-1 - <del>2i</del> + 2 - capacityi-1
::::: = i + 2 - capacityi-1
::::: = i + 2 - (i - 1) (da capacityi-1 = i-1)
::::: = 3 = O(1) → konstant

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine amortisierte Komplexität von 3 Einheiten hat, also <tt>append</tt> ∈ O(1)'''. Diese Operation kann deshalb gefahrlos in der inneren Schleife eines Algorithmus benutzt werden.

==== Beispiel für 9 Einfügeoperationen ====

{| border="1" cellspacing="0" cellpadding="5"
!Array 
(wie es aussehen könnte)
!size
!capacity
!Kosten für append (einschließlich Umkopieren)
!Summe Kosten
!Durchschnittskosten
!Φi = 2 * size - capacity 
(i = size)
!Potenzialdifferenz 
Δ Φi = Φi - Φi-1
!amortisierte Kosteni 
= Kosteni + Δ Φi
|-
| <center>[None]</center>
| <center>0</center>
| <center>1</center>
| <center>-</center>
| <center>-</center>
| <center>-</center>
| <center>-1</center>
| <center>-</center>
| <center>-</center>
|-
| <center>[a]</center><center>Array ist voll!</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b]</center><center>Array ist voll!</center>
| <center>2</center>
| <center>2</center>
| <center>1 + 1</center>
| <center>3</center>
| <center>3/2</center>
| <center>2</center>
| <center>1</center>
| <center>3</center>
|-
| <center>[a,b,c,None]</center>
| <center>3</center>
| <center>4</center>
| <center>2 + 1</center>
| <center>6</center>
| <center>6/3</center>
| <center>2</center>
| <center>0</center>
| <center>3</center>
|-
| <center>[a,b,c,d]</center><center>Array ist voll!</center>
| <center>4</center>
| <center>4</center>
| <center>1</center>
| <center>7</center>
| <center>7/4</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,None,None,None]</center>
| <center>5</center>
| <center>8</center>
| <center>4 + 1</center>
| <center>12</center>
| <center>12/5</center>
| <center>2</center>
| <center>-2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,None,None]</center>
| <center>6</center>
| <center>8</center>
| <center>1</center>
| <center>13</center>
| <center>13/6</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,None]</center>
| <center>7</center>
| <center>8</center>
| <center>1</center>
| <center>14</center>
| <center>14/7</center>
| <center>6</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h]</center><center>Array ist voll!</center>
| <center>8</center>
| <center>8</center>
| <center>1</center>
| <center>15</center>
| <center>15/8</center>
| <center>8</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h,j,None,None,None, 
None,None,None,None]</center>
| <center>9</center>
| <center>16</center>
| <center>8 + 1</center>
| <center>24</center>
| <center>24/9</center>
| <center>2</center>
| <center>-6</center>
| <center>3</center>
|-
|}

Die durchschnittlichen Kosten betragen stets etwa 2 Einheiten, schwanken allerdings so, dass nicht unmittelbar ersichtlich ist, ob dies für sämtliche Einfügeoperationen gilt. Die amortisierte Komplexität, die mit Hilfe des Potentials berechnet wird, ist hingegen konstant 3, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

[[Suchen|Nächstes Thema]]

Effizienz

2012-07-27T16:04:27Z

Ukoethe: /* Ineffiziente naive Lösung */

Bei der Diskussion von Effizienz müssen wir zwischen der Laufzeit eines Algorithmus auf einem bestimmten System und seiner prinzipiellen Leistungsfähigkeit (Algorithmenkomplexität) unterscheiden. Der Benutzer ist natürlich vor allem an der Laufzeit interessiert, denn diese bestimmt letztendlich seine Arbeitsproduktivität. Ein Softwaredesigner hingegen muss eine Implementation wählen, die auf verschiedenen Systemen und in verschiedenen Anwendungen schnell ist. Für ihn sind daher auch Aussagen zur Algorithmenkomplexität sehr wichtig, um den am besten geeigneten Algorithmus auszuwählen.

== Laufzeit ==

Aus Anwendersicht ist ein Algorithmus effizient, wenn er die in der Spezifikation verlangten Laufzeitgrenzen einhält. Ein Algorithmus muss also nicht immer so schnell wie möglich sein, sondern so schnell wie nötig. Dies führt in verschiedenen Anwendungen zu ganz unterschiedliche Laufzeitanforderungen:

* Berechnen des nächsten Steuerkommandos für eine Maschine: ca. 1/1000s
* Berechnen des nächsten Bildes für eine Videopräsentation (z.B. Dekompression von MPEG-kodierten Bildern): ca. 1/25s
: Geringere Bildraten führen zu ruckeligen Filmen.
* Sichtbare Antwort auf ein interaktives Kommando (z.B. Mausklick): ca. 1/2s
: Wird diese Antwortzeit überschritten, vermuten viele Benutzer, dass der Mausklick nicht funktioniert hat, und klicken nochmals, mit eventuell fatalen Folgen. Wenn ein Algorithmus notwendigerweise länger dauert als 1/2s, sollte ein Fortschrittsbalken angezeigt werden.
* Wettervorhersage: muss spätestens am Vorabend des vorhergesagten Tages beendet sein

===Laufzeitvergleich===

Da die Laufzeit für den Benutzer ein so wichtiges Kriterium ist, werden häufig Laufzeitvergleiche durchgeführt. Deren Ergebnisse hängen allerdings von vielen Faktoren ab, die möglicherweise nicht kontrollierbar sind:
* Geschwindigkeit und Anzahl der Prozessoren
* Auslastung des Systems
* Größe des Hauptspeichers und Cache, Geschwindigkeit des Datenbus
* Qualität des Compilers/Optimierers (ist der Compiler für die spezielle Prozessor-Architektur optimiert?)
* Geschick des Programmierers
* Daten (Beispiel Quicksort: Best case und worst case [vorsortierter Input] stark unterschiedlich)
All diese Faktoren sind untereinander abhängig. Laufzeitvergleiche sind daher mit Vorsicht zu interpretieren.
Generell sollten bei Vergleichen möglichst wenige Parameter verändert werden, z.B.
* gleiches Programm (gleiche Kompilierung), gleiche Daten, andere Prozessoren
oder
* gleiche CPU, Daten, andere Programme (Vergleich von Algorithmen)
Zur Verbesserung der Vergleichbarkeit gibt es standardisierte [http://en.wikipedia.org/wiki/Benchmark_(computing) Benchmarks], die bestimmte Aspekte eines Systems unter möglichst realitätsnahen Bedingungen testen. Generell gilt aber: Durch Laufzeitmessung ist schwer festzustellen, ob ein Algorithmus ''prinzipiell'' besser ist als ein anderer. Dafür ist die Analyse der [[Effizienz#Algorithmen-Komplexität|Algorithmenkomplexität]] notwendig.

===Optimierung der Laufzeit===

Wenn sich herausstellt, dass ein bereits implementierter Algorithmus zu langsam läuft, geht man wie folgt vor:

# Man verwendet einen [http://en.wikipedia.org/wiki/Performance_analysis Profiler], um zunächst den Flaschenhals zu bestimmen. Ein Profiler ist ein Hilfsprogramm, das während der Ausführung eines Programms misst, wieviel Zeit in jeder Funktion und Unterfunktion verbraucht wird. Dadurch kann man herausfinden, welcher Teil des Algorithmus überhaupt Probleme bereitet. Donald Knuth gibt z.B. als Erfahrungswert an, dass Programme während des größten Teils ihrer Laufzeit nur 3% des Quellcodes (natürlich mehrmals wiederholt) ausführen [http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf]. Es ist sehr wichtig, diese 3% experimentell zu bestimmen, weil die Erfahrung zeigt, dass man beim Erraten der kritischen Programmteile oft falsch liegt. Man spricht dann von "[http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize premature optimization]", also von voreiliger Optimierung ohne experimentelle Untersuchung der wirklichen Laufzeiten, was laut Knuth "the root of all evil" ist. Der Python-Profiler wird in [http://docs.python.org/lib/profile.html Kapitel 25] der Python-Dokumentation beschrieben.
# Man kann dann versuchen, die kritischen Programmteile zu optimieren.
# Falls der Laufzeitgewinn durch Optimierung zu gering ist, muss man einen prinzipiell schnelleren Algorithmus verwenden, falls es einen gibt.

Einige wichtige Techniken der Programmoptimierung sollen hier erwähnt werden. Wenn man einen optimierenden Compiler verwendet, werden einige Optimierungen automatisch ausgeführt [http://en.wikipedia.org/wiki/Compiler_optimization]. In Python trifft dies jedoch nicht zu. Um den Sinn einiger Optimierungen zu verstehen, benötigt man Grundkenntnisse der Computerarchitektur.

;Elimination von redundantem Code: Es ist offensichtlich überflüssig, dasselbe Ergebnis mehrmals zu berechnen, wenn es auch zwischengespeichert werden könnte. Diese Optimierung wird von vielen automatischen Optimierern unterstützt und kommt im wesentlichen in zwei Ausprägungen vor:
:; common subexpression elimination: In mathematischen Ausdrücken wird ein Teilergebnis häufig mehrmals benötigt. Man betrachte z.B. die Lösung der quadratischen Gleichung <math>x^2+p\,x+q = 0</math>:
x1 = - p / 2.0 + sqrt(p*p/4.0 - q)
x2 = - p / 2.0 - sqrt(p*p/4.0 - q)
::Die mehrmalige Berechnung von Teilausdrücken wird vermieden, wenn man stattdessen schreibt:
p2 = - p / 2.0
r = sqrt(p2*p2 - q)
x1 = p2 + r
x2 = p2 - r
:; loop invariant elimination: Wenn ein Teilausdruck sich in einer Schleife nicht ändert, muss man ihn nicht bei jedem Schleifendurchlauf neu berechnen, sondern kann dies einmal vor Beginn der Schleife tun. Ein typisches Beispiel hierfür ist die Adressierung von Matrizen, die als 1-dimensionales Array gespeichert sind. Angenommen, wir speichern eine NxN Matrix <tt>m</tt> in einem Array <tt>a</tt> der Größe N2, so dass das Matrixelement <tt>mij</tt> durch <tt>a[i + j*N]</tt> indexiert wird. Wir betrachten die Aufgabe, eine Einheitsmatrix zu initialisieren. Ein nicht optimierter Algorithmus dafür lautet:
for j in range(N):
for i in range(N):
if i == j:
a[i + j*N] = 1.0
else:
a[i + j*N] = 0.0
::Der Ausdruck <tt>j*N</tt> wird hier in jedem Schleifendurchlauf erneut berechnet, obwohl sich <tt>j</tt> in der inneren Schleife gar nicht verändert. Man kann deshalb optimieren zu:
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
;Vereinfachung der inneren Schleife: Generell sollte man sich bei der Optimierung auf die innere Schleife eines Algorithmus konzentrieren, weil dieser Code am häufigsten ausgeführt wird. Insbesondere sollte man die Anzahl der Befehle in der inneren Schleife so gering wie möglich halten und teure Befehle vermeiden. Früher waren vor allem Floating-Point Befehle teuer, die man oft durch die schnellere Integer-Arithmetik ersetzt hat, falls dies algorithmisch möglich war (diesen Rat findet man noch oft in der Literatur). Heute hat sich die Hardware so verbessert, dass im Allgemeinen nur noch die Floating-Point Division deutlich langsamer ist als die anderen Operatoren. Im obigen Beispiel der quadratischen Gleichung ist es daher sinnvoll, den Ausdruck
p2 = -p / 2.0
:durch
p2 = -0.5 * p
:zu ersetzen. Dadurch ersetzt man eine Division durch eine Multiplikation und spart außerdem das Negieren von <tt>p</tt>, da der Compiler direkt mit <tt>-0.5</tt> multipliziert.
;Ausnutzung der Prozessor-Pipeline: Moderne Prozessoren führen mehrere Befehle parallel aus. Dies ist möglich, weil jeder Befehl in mehrere Teilschritte zerlegt werden kann. Eine generische Unterteilung in vier Teilschritte ist z.B.:
:# Dekodieren des nächsten Befehls
:# Beschaffen der Daten, die der Befehl verwendet (aus Prozessorregistern, dem Cache, oder dem Hauptspeicher)
:# Ausführen des Befehls
:# Schreiben der Ergebnisse
:Man bezeichnet dies als die "[http://en.wikipedia.org/wiki/Instruction_pipeline instruction pipeline]" des Prozessors (heutige Prozessoren verwenden wesentlich feinere Unterteilungen). Prozessoren werden nun so gebaut, dass mehrere Befehle parallel, auf verschiedenen Ausführungsstufen ausgeführt werden. Wenn Befehl 1 also beim Schreiben der Ergebnisse angelangt ist, kann Befehl 2 die Hardware zum Ausführen des Befehls benutzen, während Befehl 3 seine Daten holt, und Befehl 4 soeben dekodiert wird. Unter bestimmten Bedingungen funktioniert diese Parallelverarbeitung jedoch nicht. Dies gibt Anlass zu Optimierungen:
:;Vermeiden unnötiger Typkonvertierungen: Der Prozessor verarbeitet Interger- und Floating-Point-Befehle in verschiedenen Pipelines, weil die Hardwareanforderungen sehr verschieden sind. Wird jetzt ein Ergebnis von Integer nach Floating-Point umgewandelt oder umgekehrt, muss die jeweils andere Pipeline warten, bis die erste Pipeline ihre Berechnung beendet. Es kann dann besser sein, Berechnungen in Floating-Point zu Ende zu führen, auch wenn sie semantisch eigentlich Integer-Berechnungen sind.
:;Reduzierung der Anzahl von Verzweigungen: Wenn der Code verzweigt (z.B. durch eine <tt>if</tt>- oder <tt>while</tt>-Anweisung), ist nicht klar, welcher Befehl nach der Verzweigung ausgeführt werden soll, bevor Stufe 3 der Pipeline die Verzweigungsbedingung ausgewertet hat. Bis dahin wären die ersten beiden Stufen der Pipeline unbenutzt. Moderne Prozessoren benutzen zwar ausgefeilte Heuristiken, um das Ergebnis der Bedingung vorherzusagen, und führen den hoffentlich richtigen Zweig des Codes spekulativ aus, aber dies funktioniert nicht immer. Man sollte deshalb generell die Anzahl der Verzweigungen minimieren. Als Nebeneffekt führt dies meist auch zu besser lesbarem, verständlicherem Code. Im Matrixbeispiel kann man
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
::durch
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
ersetzen. Die Diagonalelemente <tt>a[j + jN]</tt> werden jetzt zwar zweimal initialisiert (in der Schleife auf Null, dann auf Eins), aber durch Elimination der <tt>if</tt>-Abfrage wird dies wahrscheinlich mehr als ausgeglichen, zumal dadurch die innere Schleife wesentlich vereinfacht wurde.
;Ausnutzen des Prozessor-Cache: Zugriffe auf den Hauptspeicher sind sehr langsam. Deshalb werden stets ganze Speicherseiten auf einmal in den [http://en.wikipedia.org/wiki/Cache Cache] des Prozessors geladen. Wenn unmittelbar nacheinander benutzte Daten auch im Speicher nahe beieinander liegen (sogenannte "[http://en.wikipedia.org/wiki/Locality_of_reference locality of reference]"), ist die Wahrscheinlichkeit groß, dass die als nächstes benötigten Daten bereits im Cache sind und damit schnell gelesen werden können. Bei vielen Algorithmen kann man die Implementation so umordnen, dass die locality of reference verbessert wird, was zu einer drastischen Beschleunigung führt. Im Matrix-Beispiel ist z.B. die Reihenfolge der Schleifen wichtig. Für konstanten Index <tt>j</tt> liegen die Indizes <tt>i</tt> im Speicher hintereinander. Deshalb ist es günstig, in der inneren Schleife über <tt>i</tt> zu iterieren:
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
:Die umgekehrte Reihenfolge der Schleifen ist hingegen ungünstig
for i in range(N):
for j in range(N):
a[i + j*N] = 0.0
a[i + i*N] = 1.0
:Jetzt werden in der inneren Schleife stets N Datenelemente übersprungen. Besonders bei großem N muss man daher häufig den Cache neu füllen, was bei der ersten Implementation nicht notwendig war. (Außerdem verliert man hier die Optimierung <tt>jN = j*N</tt>, die jetzt nicht mehr möglich ist.)

Als Faustregel kann man durch Optimierung eine Verdoppelung der Geschwindigkeit erreichen (in Ausnahmefällen auch mehr). Benötigt man stärkere Verbesserungen, muss man wohl oder übel einen besseren Algorithmus oder einen schnelleren Computer verwenden.

== Algorithmen-Komplexität ==

Komplexitätsbetrachtungen ermöglichen den Vergleich der prinzipiellen Eigenschaften von Algorithmen unabhängig von einer Implementation, Umgebung etc.

Eine einfache Möglichkeit ist das Zählen der Aufrufe einer Schlüsseloperation. Beispiel Sortieren:
* Anzahl der Vergleiche
* Anzahl der Vertauschungen

=== Beispiel: Selection Sort ===

for i in range(len(a)-1):
max = i
for j in range(i+1, len(a)):
if a[j] < a[max]:
max = j
a[max], a[i] = a[i], a[max] # swap

*Anzahl der Vergleiche: Ein Vergleich in jedem Durchlauf der inneren Schleife. Es ergibt sich folgende Komplexität:
*:Ingesamt <math>\sum_{i=0}^{N-2} \sum_{j=i+1}^{N-1}1 = \frac{N}{2} (N-1) \!</math> Vergleiche.

*Anzahl der Vertauschungen (swaps): Eine Vertauschung pro Durchlauf der äußeren Schleife:
*:Insgesamt <math>N-1 \!</math> Vertauschungen

Die Komplexität wird durch die Operationen bestimmt, die am häufigsten ausgeführt werden, hier also die Anzahl der Vergleiche. Die Anzahl der Vertauschungen ist hingegen kein geeignetes Kriterium für die Komplexität von selection sort, weil der Aufwand in der inneren Schleife ignoriert würde.

=== Fallunterscheidung: Worst und Average Case ===

Die Komplexität ist in der Regel eine Funktion der Eingabegröße (Anzahl der Eingabebits, Anzahl der Eingabeelemente). Sie kann aber auch von der Art der Daten abhängen, nicht nur von der Menge, z.B. vorsortierte Daten bei Quicksort. Um von der Art der Daten unabhängig zu werden, kann man zwei Fälle der Komplexität unterscheiden:

* Komplexität im ungünstigsten Fall
*: Der ungünstigste Fall ist die Eingabe gegebener Länge, für die der Algorithmus am langsamsten ist. Der Nachteil dieser Methode besteht darin, dass dieser ungünstige Fall in der Praxis vielleicht gar nicht oder nur selten vorkommt, so dass sich der Algorithmus in Wirklichkeit besser verhält als man nach dieser Analyse erwarten würde. Beim Quicksort-Algorithmus mit zufälliger Wahl des Pivot-Elements müsste z.B. stets das kleinste oder größte Element des aktuellen Intervalls als Pivot-Element gewählt werden, was äußerst unwahrscheinlich ist.
* Komplexität im durchschnittlichen/typischen Fall
*: Der typische Fall ist die mittlere Komplexität des Algorithmus über alle möglichen Eingaben. Dazu muss man die Wahrscheinlichkeit jeder möglichen Eingabe kennen, und berechnet dann die mittlere Laufzeit über dieser Wahrscheinlichkeitsverteilung. Leider ist die Wahrscheinlichkeit der Eingaben oft nicht bekannt, so dass man geeignete Annahmen treffen muss. Bei Sortieralgorithmen können z.B. alle möglichen Permutationen des Eingabearrays als gleich wahrscheinlich angenommen werden, und der typische Fall ist dann die mittlere Komplexität über alle diese Eingaben. Oft hat man jedoch in der Praxis andere Wahrscheinlichkeitsverteilungen, z.B. sind die Daten oft "fast sortiert" (nur wenige Elemente sind an der falschen Stelle). Dann verhält sich der Algorithmus ebenfalls anders als vorhergesagt.

Wir beschränken uns in dieser Vorlesung auf die Komplexität im ungünstigseten Fall. '''Exakte''' Formeln für Komplexität sind aber auch dann schwer zu gewinnen, wie das folgende Beispiel zeigt:

=== Beispiele aus den Übungen (Gemessene Laufzeiten für Mergesort/Selectionsort) ===

* Mergesort: <math>\frac{0,977N\log N}{\log 2} + 0,267N-4.39 \!</math>
*: andere Lösung: <math>1140 N\log(N) - 1819N + 6413 \!</math>
* Selectionsort: <math>\frac{1}{2}N^2 - \frac{1}{2N} - 10^{-12} \!</math>
*: andere Lösung: <math>1275N^2 - 116003^N + 11111144 \!</math>

Aus diesen Formeln wird nicht offensichtlich, welcher Algorithmus besser ist.
Näherung: Betrachte nur '''sehr große Eingaben''' (meist sind alle Algorithmen schnell genug für kleine Eingaben). Dieses Vorgehen wird als '''Asymptotische Komplexität''' bezeichnet (N gegen unendlich).

=== Asymptotische Komplexität am Beispiel Polynom ===

Polynom: <math>a\,x^2+b\,x+c=p\!</math>

<math>x \!</math> sei die Eingabegröße, und wir betrachten die Entwicklung von <math>p \!</math> in Abhängigkeit von <math>x \!</math>.

* <math>x=0 \!</math>
*: <math>p=c \!</math>
* <math>x=1 \!</math>
*: <math>p=a+b+c \!</math>
* <math>x=1000 \!</math>
*: <math>p=1000000a+1000b+c \approx 1000000a\!</math>
* <math>x \to \infty \!</math>
*: <math>p \approx x^2a\!</math>

Für sehr große Eingaben verlieren also ''b'' und ''c'' immer mehr an Bedeutung, so dass am Ende nur noch ''a'' für die Komplexitätsbetrachtung wichtig ist.

== Landau-Symbole ==

Um die asymptotische Komplexität verschiedener Algorithmen miteinander vergleichen zu können, verwendet man die sogenannten [http://de.wikipedia.org/wiki/Landau-Symbole Landau-Symbole]. Das wichtigste Landau-Symbol ist <math>\mathcal{O}</math>, mit dem man eine ''obere Schranke'' <math>f \in \mathcal{O}(g)</math> für die Komplexität angeben kann.

Schreibt man <math>f \in \Omega(g)</math>, so stellt dies eine asymptotische ''untere Schranke'' für die Funktion f dar.

Schließlich bedeutet <math>f \in \Theta(g)</math>, dass die Funktion f genauso schnell wie die Funktion g wächst, das heißt man hat eine asymptotisch ''scharfe Schranke'' für f. Hierzu muss sowohl <math>f\in\mathcal{O}(g)</math> als auch <math>f \in \Omega(g)</math> erfüllt sein.

Im nun folgenden soll auf die verschiedenen Landau-Symbole noch näher eingegeangen werden.

===O-Notation===

Intuitiv gilt: Für große N dominieren die am schnellsten wachsenden Terme einer Funktion. Die Notation <math>f \in \mathcal{O}(g)</math> (sprich "f ist in O von g" oder "f ist von derselben Größenordnung wie g") formalisiert eine solche Abschätzung der asymptotischen Komplexität der Funktion f von oben.
; Asymptotische Komplexität: Für zwei Funktionen f(x) und g(x) gilt
::<math>f(x) \in \mathcal{O}(g(x))</math>
: genau dann wenn es eine Konstante <math>c>0</math> und ein Argument <math>x_0</math> gibt, so dass
::<math>\forall x \ge x_0:\quad f(x) \le c\,g(x)</math>.
:Die Menge <math>\mathcal{O}(g(x))</math> aller durch g(x) abschätzbaren Funktionen ist also formal definiert durch
::<math>\mathcal{O}(g(x)) = \{ f(x)\ |\ \exists c>0: \forall x \ge x_0: 0 \le f(x) \le c\,g(x)\}</math>

Die Idee hinter dieser Definition ist, dass g(x) eine wesentlich einfachere Funktion ist als f(x), die sich aber nach geeigneter Skalierung (Multiplikation mit c) und für große Argumente x im wesentlichen genauso wie f(x) verhält. Man kann deshalb in der Algorithmenanalyse f(x) durch g(x) ersetzen. <math>f(x) \in \mathcal{O}(g(x))</math> spielt für Funktionen eine ähnliche Rolle wie der Operator ≤ für Zahlen: Falls a ≤ b gilt, kann bei einer Abschätzung von oben ebenfalls a durch b ersetzt werden.

==== Ein einfaches Beispiel ====

[[Image:Sqsqrt.png]]

Rot = <math>x^2 \!</math>
Blau = <math>\sqrt{x} \!</math>

<math>\sqrt{x} \in \mathcal{O}(x^2)\!</math> weil <math>\sqrt{x} \le c\,x^2\!</math> für alle <math>x \ge x_0 = 1 \!</math> und <math>c = 1\!</math>, oder auch für <math>x \ge x_0 = 4 \!</math> und <math>c = 1/16</math> (die Wahl von c und x0 in der Definition von O(.) ist beliebig, solange die Bedingungen erfüllt sind).

==== Komplexität bei kleinen Eingaben ====

Algorithmus 1: <math>\mathcal{O}(N^2) \!</math> 
Algorithmus 2: <math>\mathcal{O}(N\log{N}) \!</math>

Algorithmus 2 ist schneller (von geringerer Komplexität) für große Eingaben, aber bei kleinen Eingaben (insbesondere, wenn der Algorithmus in einer Schleife immer wieder mit kleinen Eingaben aufgerufen wird) könnte Algorithmus 1 schneller sein, falls der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor ''c'' bei Algorithmus 2 einen wesentlich größeren Wert hat als bei Algorithmus 1.

==== Eigenschaften der O-Notation (Rechenregeln) ====

# Transitiv:
#: <math>f(x) \in \mathcal{O}(g(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) \in \mathcal{O}(h(x)) \!</math>
# Additiv:
#: <math>f(x) \in \mathcal{O}(h(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) + g(x) \in \mathcal{O}(h(x)) \!</math>
# Für Monome gilt:
#: <math>x^k \in \mathcal{O}(x^k)</math> und
#: <math>x^k \in \mathcal{O}(x^{k+j}), \forall j \ge 0 \!</math>
# Multiplikation mit einer Konstanten:
#: <math>f(x) \in \mathcal{O}(g(x)) \to c\,f(x) \in \mathcal{O}(g(x))\!</math>
#: andere Schreibweise:
#: <math>f(x) = c\,g(x) \to f(x) \in \mathcal{O}(g(x))\!</math>
# Folgerung aus 3. und 4. für Polynome:
#: <math>a_0+a_1\,x + ... + a_n\,x^n \in \mathcal{O}(x^n)\!</math>
#: Beispiel: <math>a\,x^2+b\,x+c \in \mathcal{O}(x^2)\!</math>
# Logarithmus:
#: <math>a, b > 1\!</math>
#: <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>
#: Die Basis des Logarithmus spielt also keine Rolle.
#: Beweis hierfür:
#:: <math>\log_{a}{x} = \frac{\log_{b}{x}}{\log_{b}{a}}\!</math>
#:: Mit <math>c = 1 / \log_{b}{a}\,</math> gilt: <math>\log_{a}{x} = c\,\log_{b}{x}\!</math>.
#:: Wird hier die (zweite) Regel für Multiplikation mit einer Konstanten angewendet, fällt der konstante Faktor weg, also <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>.
#: Insbesondere gilt auch <math>\log_{a}{x} \in \mathcal{O}(\log_{2}{x})\!</math>, es kann also immer der 2er Logarithmus verwendet werden.

==== O-Kalkül ====

Das O-Kalkül definiert wichtige Vereinfachungsregeln for Ausdrücke in O-Notation (Beweise: siehe Übungsaufgabe):

# <math>f(x) \in \mathcal{O}(f(x))\!</math>
# <math>\mathcal{O}(\mathcal{O}(f(x))) \in \mathcal{O}(f(x))\!</math>
# <math>c\,\mathcal{O}(f(x)) \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# <math>\mathcal{O}(f(x))+c \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# Sequenzregel:
#: Wenn zwei nacheinander ausgeführte Programmteile die Komplexität <math>\mathcal{O}(f(x))</math> bzw. <math>\mathcal{O}(g(x))</math> haben, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(f(x))</math> falls <math>g(x) < \mathcal{O}(f(x))</math> bzw.
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(g(x))\!</math> falls <math>f(x) < \mathcal{O}(g(x))</math>.
#: Informell schreibt man auch: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(max(f(x), g(x)))\!</math>.
# Schachtelungsregel bzw. Aufrufregel:
#: Wenn in einer geschachtelten Schleife die äußere Schleife die Komplexität <math>\mathcal{O}(f(x))</math> hat, und die innere <math>\mathcal{O}(g(x))</math>, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) * \mathcal{O}(g(x)) \in \mathcal{O}(f(x) * g(x))\!</math>.
#: Gleiches gilt wenn eine Funktion <math>\mathcal{O}(f(x))</math>-mal aufgerufen wird, und die Komplexität der Funktion selbst <math>\mathcal{O}(g(x))</math> ist.

;Beispiel für 5.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Dies gilt auch für ihre Hintereinanderausführung:
for i in range(N):
a[i] = i
for i in range(N):
print a[i]
;Beispiele für 6.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Ihre Verschachtelung hat daher die Komplexität <math>\mathcal{O}(N^2)</math>.
for i in range(N):
for j in range(N):
a[i*N + j] = i+j
: Dies gilt ebenso, wenn statt der inneren Schleife eine Funktion mit Komplexität <math>\mathcal{O}(N)</math> ausgeführt wird:
for i in range(N):
a[i] = foo(i, N) # <math>\mathrm{foo}(i, N) \in \mathcal{O}(N)</math>

==== O-Kalkül auf das Beispiel des Selectionsort angewandt ====

Selectionsort: Wir hatten gezeigt dass <math>f(N) = \frac{N^2}{2} - \frac{N}{2}</math>. Nach der Regel für Polynome vereinfacht sich dies zu <math>f(N) \in \mathcal{O}\left(\frac{N^2}{2}\right) = \mathcal{O}(N^2)\!</math>.

Alternativ via Schachtelungsregel:
: Die äußere Schleife wird (''N''-1)-mal durchlaufen: <math>N-1 \in \mathcal{O}(N)</math>
: Die innere Schleife wird (''N-i''-1)-mal durchlaufen. Das sind im Mittel ''N''/2 Durchläufe: <math>N/2 \in \mathcal{O}(N)</math>
: Zusammen: <math>\mathcal{O}(N)*\mathcal{O}(N) \in \mathcal{O}(N^2)</math>

Nach beiden Vorgehensweisen kommen wir zur Schlussfolgerung, dass der Selectionsort die asymptotische Komplexität <math>\mathcal{O}(N^2)\!</math> besitzt.

==== Zusammenhang zwischen Komplexität und Laufzeit ====

Wenn eine Operation 1ms dauert, erreichen Algorithmen verschiedener Komplexität folgende Leistungen (wobei angenommen wird, dass der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor immer etwa gleich 1 ist):

{| class="wikitable" style="text-align:left" cellpadding="7"
|+
|-
! Komplexität !! Operationen in 1s !! Operationen in 1min !! Operationen in 1h
|-
! <math>\mathcal{O}(N)</math>
| 1000 || 60.000 || 3.600.000
|-
! <math>\mathcal{O}(N\log_2{N})</math>
| 140 || 4895 || 204094
|-
! <math>\mathcal{O}(N^2)</math>
| 32 || 245 || 1898
|-
! <math>\mathcal{O}(N^3)</math>
| 10 || 39 || 153
|-
! <math>\mathcal{O}(2^N)</math>
| 10 || 16 || 21
|}

==== Exponentielle Komplexität ====
Der letzte Fall <math>\mathcal{O}(2^N)</math> ist von exponentieller Komplexität. Das bedeutet, dass eine Verdopplung des Aufwands nur bewirkt, dass die maximale Problemgröße um eine Konstante wächst. Algorithmen mit exponentieller (oder noch höherer) Komplexität werden deshalb als '''ineffizient''' bezeichnet. Algorithmen mit höchstens polynomieller Komplexität gelten hingegen als effizient.

In der Praxis sind allerdings auch polynomielle Algorithmen mit hohem Exponenten meist zu langsam. Als Faustregel kann man eine praktische Grenze von <math>\mathcal{O}(N^3)</math> ansehen. Bei einer Komplexität von <math>\mathcal{O}(N^3)</math> bewirkt ein verdoppelter Aufwand immer noch eine Steigerung der maximalen Problemgröße um den Faktor <math>\sqrt[3]{2}</math> (also eine ''multiplikative'' Vergrößerung um ca. 25%, statt nur einer additiven Vergrößerung wie bei exponentieller Komplexität).

===<math>\Omega</math>- Notation===

Genauso wie <math>f \in \mathcal{O}(g)</math> eine Art <math>\le</math>-Operator für Funktionen ist, definiert <math>f \in \Omega(g) </math> eine Abschätzung von unten, analog zum <math>\ge</math>-Operator für Zahlen. Formal kann man <math>f(N) \in \Omega(g(N)) </math> genau dann schreiben, falls es eine Konstante <math> c > 0 </math> gibt, so dass

<math> f(N) \ge c \cdot g(N) </math> für <math> N \ge N_0 </math>

gilt.
Man verwendet diese Notation also um abzuschätzen, wie groß der Aufwand (die Komplexität) für einen bestimmten Algorithmus ''mindestens'' ist und nicht ''höchstens'', was man mit der <math>\mathcal{O}</math> - Notation ausdrücken würde.

Ein praktisches Beispiel für eine Anwendung der <math>\Omega</math>- Notation wäre die Fragestellung, ob es ''prinzipiell'' einen besseren Algorithmus für ein bestimmtes Problem gibt. Wie später im Abschnitt [[Suchen#Sortieren_als_Suchproblem|Sortieren als Suchproblem]] gezeigt wird, ist das Sortieren eines Arrays durch paarweise Vergleiche von Elementen immer mindestens von der Komplexität <math> \Omega(N\cdot \ln N) </math>, was konkret bedeutet, dass kein Sortieralgorithmus, der nach diesem Prinzip arbeitet, jemals eine geringere Komplexität als beispielsweise Merge-Sort haben wird. Natürlich kann man den entsprechenden Sortieralgorithmus, also Merge-Sort zum Beispiel, unter Umständen noch optimieren, aber die Komplexität wird erhalten bleiben. Mit diesem Wissen kann man sich viel (vergebliche) Arbeit sparen.

===<math>\Theta</math>- Notation===

<math>f(N) \in \Theta(g(N))</math> ist eine scharfe Abschätzung der asymptotischen Komplexität einer Funktion f.

Damit dies gilt, muss <math>f(N) \in \mathcal{O}(g(N))</math> und ''gleichzeitig'' <math>f(N) \in \Omega(g(N))</math> erfüllt sein.

Dies ist natürlich auch die beste Abschätzung der asymptotischen Komplexität einer Funktion f. Formal bedeutet <math>f(N) \in \Theta(g(N))</math> dass es zwei Konstanten <math> c_1 </math> und <math> c_2 </math>, beide größer als Null, gibt, so dass für alle <math> N \geq N_0 </math> gilt:

<math> c_1 \cdot g(N) \leq f(N) \leq c_2 \cdot g(N) </math>.

In der Praxis wird manchmal statt der <math>\Theta</math>-Notation auch dann die <math>\mathcal{O}</math>-Notation benutzt, wenn eine scharfe Schranke ausgedrückt werden soll. Dies ist zwar formal nicht korrekt, aber man kann die intendierte Bedeutung meist aus dem Kontext erschließen.

== Komplexitätsvergleich zweier Algorithmen ==

In diesem Abschnitt wollen wir der Frage nachgehen, wie ein formaler Beweis für die Behauptung <math> f(N) \in \mathcal{O}(g(N))</math> geschehen kann. Hierbei werden zwei Beweismethoden vorgestellt werden, und zwar der '''Beweis über die Definition der Komplexität''' sowie der '''Beweis durch Dividieren'''.

===Beweis über die Definition der asymptotischen Komplexität===

Die Definition der asymptotischen Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> war:

Es gibt eine Konstante <math> c > 0 </math>, so dass <math> f(N) \le c \cdot g(N) </math> für <math> N \ge N_0 </math> erfüllt ist.

Um also die die asymptotische Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> zu beweisen, muss man die oben erwähnten Konstanten c und <math> N_0 </math> finden, so dass

<math> f(N) \leq c \cdot g(N) </math> für alle <math> N \ge N_0 </math> erfüllt ist.

Dies geschieht zweckmäßigerweise mit dem Beweisprinzip der ''vollständigen Induktion''. Hierbei ist zu zeigen, dass
# <math> f(N_0) \leq g(N_0) </math> für die eine zu bestimmende Konstante <math> N_0 </math> gilt (''Induktionsanfang'') und
# falls <math> f(N) \leq g(N) </math>, dann auch <math> f(N+1) \leq g(N+1) </math> (''Induktionsschritt'') gilt.

===Beweis durch Dividieren===

Hierbei wählt man eine Konstante c und zeigt, dass <math> \lim_{N \rightarrow \infty} \frac{f(N)}{c \cdot g(N)} \leq 1 </math> gilt (für die O-Notation, bei Ω-Notation gilt entsprechend <math>\geq 1 </math>). Man kann dies auch als alternative Definition der Komplexität verwenden.

Als Beispiel betrachten wir die beiden Funktionen <math> f(N) = N \,\lg N </math> und <math> g(N) = N^2 </math> und wollen zeigen, dass <math>f(N) \in \mathcal{O}(g(N))</math> gilt.

Als Konstante c wählen wir <math> c = 1 </math>

<math> \lim_{N \rightarrow \infty} \frac{f(N)}{g(N)} = \lim_{N \rightarrow \infty} \frac{\lg N}{N} = \frac{\infty}{\infty} </math>

Unbestimmte Ausdrücke der Form
<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} </math>,
in denen sowohl <math> f(x) </math> als auch <math> g(x) </math> mit <math> x \rightarrow x_0 </math> gegen Null oder gegen Unendlich streben, kann man manchmal mit den Regeln von [http://de.wikipedia.org/wiki/L%27Hospital%27sche_Regel ''l'Hospital''] berechnen. Danach darf man die Funktionen f und g zur Berechnung des unbestimmten Ausdrucks durch ihre k-ten Ableitungen ersetzen:

<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} = \lim_{x \rightarrow x_0} \frac{f^{(k)}(x)}{g^{(k)}(x)} </math>

In unserem Fall verwenden wir die erste Ableitung und erhalten:
<math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)} = \lim_{N \rightarrow \infty} \frac{1/N}{1} \rightarrow 0 </math>

Damit wurde <math>f(N) \in \mathcal{O}(g(N))</math>, also <math>N \lg N \in \mathcal{O}(N^2)</math> gezeigt.

Man beachte hierbei, dass <math>N \lg N \in \mathcal{O}(N^2)</math> keine enge Grenze für die Komplexität von <math>N \,\lg N</math> darstellt, da der Grenzwert <math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)}\, </math> gegen 0 und nicht gegen eine von Null verschiedene Konstante strebt. In diesem Fall haben wir die Komplexität von <math>N \cdot \lg N </math> also nur nach oben abschätzen können.

===Beispiel für den Komplexitätsvergleich: Gleitender Mittelwert (Running Average)===

Wir berechnen für ein gegebenes Array <tt>a</tt> einen gleitenden Mittelwert über <tt>k</tt> Elemente: 
::<math>r_i = \frac{1}{k} \sum_{j=i-k+1}^i a_j</math> 
Das heisst, für jedes <tt>i</tt> mitteln wir die letzten <tt>k</tt> Elemente von <tt>a</tt> und schreiben das Ergebnis in <tt>r[i]</tt>. Diese Operation ist z.B. bei Börsenkursen wichtig: Neben dem aktuellen Kurs für jeden Tag wird dort meist auch der gleitende Mittelwert der letzten 30 Tage sowie der letzten 200 Tage angegeben. In diesen Mittelwerten erkennt man besser die langfristige Tendenz, weil die täglichen Schwankungen herausgemittelt werden. Wir nehmen außerdem an, dass
* Array-Zugriff hat eine Komplexität von O(1)
* <math>k \ll N</math>, d.h. <math>N-k\approx N</math>.

Die beiden folgenden Algorithmen berechnen die Mittelwerte auf unterschiedliche Art. Der linke folgt der obigen Definition durch eine Summe, während der rechte inkrementell arbeitet: Man kann den Bereich der <tt>k</tt> letzten Werte als Fenster betrachten, das über das Array <tt>a</tt> geschoben wird. Schiebt man das Fenster ein Element weiter, fällt links ein Element heraus, und rechts kommt eins hinzu. Man muss also nicht jedes Mal die Summe neu berechnen, sondern kann den vorigen Wert aktualisieren. Wir werden sehen, dass dies Folgen für die Komplexität des Algorithmus hat.

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1: O(N * k)
! Komplexität
! Version 2: O(N)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|
<tt>for i in range(k):</tt>
|
'''<center>O(k)</center>'''
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|
:: <tt>r[k-1] += a[i]</tt>
|
'''<center>O(1)</center>'''
|-
|
6.
|
:::: <tt>r[j] += a[i]</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(k, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|
:: <tt>r[j] = (a[j] - a[j-k] + r[j-1])</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(len(a)):</tt>
|
'''<center>O(N)</center>'''
|-
|
9.
|

|

|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
10.
|

|

|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Wir zeigen unten dass Version 2 eine geringere Komplexität besitzt, obwohl sie mehr Zeilen benötigt.

Wir haben in der Tabelle die Komplexität jeder Zeile für sich angegeben. Einfache Anweisungen (Berechnungen, Lese- und Schreibzugriffe auf das Array, Zuweiseungen) haben konstante Komplexität, die Komplexität des Schleifenkopfes allein (also der <tt>for</tt>-Anweisung ohne den eingerückten Schleifenkörper) entspricht der Anzahl der Durchläufe. Wir müssen jetzt noch die Verschachtelung der Schleifen und die Nacheinanderausführung von Anweisungen berücksichtigen.

====Berechnung der Komplexität von Version 1====

(Wiederholung der Rechenregeln: siehe Abschnitt [[Effizienz#O-Notation|O-Notation]])

Wir betrachten zunächst die innere Schleife (Zeilen 5 und 6 von Version 1):

Der Schleifenkopf (Zeile 5) hat die Komplexität <math>\mathcal{O}(k)</math>, weil die Schleife k-mal durchlaufen wird. Der Schleifenkörper (Zeile 6) hat die Komplexität <math>\mathcal{O}(1)</math>. Nach der Verschachtelungsregel müssen wir die beiden Komplexitäten multiplizieren, und es ergibt sich:

::<math>\mathcal{O}(k)\cdot\mathcal{O}(1) = \mathcal{O}(k\cdot 1)=\mathcal{O}(k)</math>

Wir betrachten nun die äußere Schleife. Der Schleifenkopf (Zeile 4) wird (N-k)-mal durchlaufen und hat somit eine Komplexität von <math>\mathcal{O}(N)</math>. Der Schleifenkörper (Zeilen 5 bis 7) besteht aus der inneren Schleife (Zeilen 5 und 6) mit der gerade berechneten Komplexität <math>\mathcal{O}(k)</math> sowie einer einfachen Anweisung (Zeile 7) mit Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel wird die Komplexität des Schleifenkörpers durch Addition berechnet:

::<math>\mathcal{O}(k)+\mathcal{O}(1) = \mathcal{O}(\max(k,1)) = \mathcal{O}(k)</math>

Die Komplexität der gesamten äußeren Schleife erhalten wir nach der Verschachtelungsregel wieder durch multiplizieren:

::<math>\mathcal{O}(N)\cdot\mathcal{O}(k) = \mathcal{O}(N\cdot k)</math>

Die übrigen Schritte des Algorithmus werden einfach nacheinander ausgeführt, so dass sie ebenfalls nach der Sequenzregel behandelt werden. Wir erhalten

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(N\cdot k)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,N\cdot k,1)) = \mathcal{O}(N\cdot k)</math>

Der gesamte Algorithmus hat also die Komplexität <math>\mathcal{O}(N\cdot k)</math>.

====Berechnung der Komplexität von Version 2====

Hier gibt es nur einfache Schleifen ohne Verschachtelung. Da der Schleifenkörper jeder Schleife nur einfache Anweisungen der Komplexität <math>\mathcal{O}(1)</math> enthält, ergibt sich die Komplexität der Schleifen nach der Verschachtelungsregel als

::<math>\mathcal{O}(X)\cdot\mathcal{O}(1) = \mathcal{O}(X\cdot 1)=\mathcal{O}(X)</math>

wobei <math>\mathcal{O}(X)</math> die Komplexität des jeweiligen Schleifenkopfes ist. Wir erhalten also für Zeilen 4 und 5: <math>\mathcal{O}(k)</math>, Zeilen 6 und 7: <math>\mathcal{O}(N)</math>, Zeilen 8 und 9: <math>\mathcal{O}(N)</math>. Die Hintereinanderausführung wird nach der Sequenzregel behandelt:

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(k)+\mathcal{O}(N)+\mathcal{O}(N)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,k,N,N,1)) = \mathcal{O}(N)</math>

Dieser Algorithmus hat also nur die Komplexität <math>\mathcal{O}(N)</math>.

====Fazit====

Obwohl Version 2 mehr Schritte benötigt hat sie eine geringere Komplexität, da die for-Schleifen nicht wie bei Version 1 verschachtelt/untergeordnet sind. Bei verschachtelten for-Schleifen muss die Multiplikationsregel angewendet werden → höhere Komplexität.

Die gerade berechnete Komplexität gilt aber nur unter der Annahme, dass Array-Zugriffe konstante Komplexität <math>\mathcal{O}(1)</math> besitzen. Wenn dies nicht der Fall ist, kann sich die Komplexität des Algorithmus drastisch verschlechtern.

{| border="1" cellspacing="0" cellpadding="5"
|Allgemein gilt: 
Algorithmen-Analysen beruhen auf der Annahme, dass Zugriffe auf die Daten optimal schnell sind, dass heißt, dass die für den jeweiligen Algorithmus am besten geeignete Datenstruktur verwendetet wird. → Ansonsten: Komplexitätsverschlechterung!
|}
 

====Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur====

Wir verwende im Mittelwert-Algorithmus eine verkettete Liste anstelle des Eingabe-Arrays <tt>a</tt>. Wir benötigen dazu eine Funktion, die das j-te Element der Liste zurückgibt. Wie üblich ist die Liste mit Hilfe einer Knotenklasse implementiert:
class Node:
def __init__(self, data):
self.data = data
self.next = None

Die Listenklasse selbst hat ein Feld <tt>head</tt>, das eine Referenz auf den ersten Knoten speichert, und jeder Knoten speichert im Feld <tt>next</tt> eine Referenz auf seinen Nachfolger. Um zum j-ten Element zu gelangen, muss man die Liste sequenziell durchlaufen
def get_jth(list, j):
r = list.head
while j > 0:
r = r.head
j -= 1
return r.data
Die Komplexität dieser Funktion ist offensichtlich <math>\mathcal{O}(j)</math> (Komplexitätsberechnung wie oben). Wir setzen jetzt bei Version 1 des Mittelwert-Algorithmus diese Funktion in Zeile 6 anstelle des Indexzugriffs <tt>a[i]</tt> ein (nur in dieser Zeile wird auf die Elemente des Arrays zugegriffen). Wir erhalten folgende Implementation (die Änderungen sind rot markiert):

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1 mit Liste: O(N * k)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|-
|
6.
|
:::: <tt>r[j] += get_jth(a, i)</tt>
|
'''<center>O(i)</center>'''
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Der Aufruf der Funktion <tt>get_jth</tt> ist jetzt gleichbedeutend mit einer dreifach verschachtelten Schleife (weil <tt>get_jth</tt> ja eine zusatzliche Schleife enthält). Die Anzahl der Operationen in Zeile 4 bis 6 ist jetzt

::<math>f(N,k)=\sum_{j=k-1}^{N-1}\,\sum_{i=j-k+1}^j\,\mathcal{O}(i)</math>

wobei das <math>\mathcal{O}(i)</math> die neue Schleife durch Verwendung der Liste repräsentiert. Mit Mathematica-Hilfe [http://www.wolfram.com/] lässt sich diese Summe exakt ausrechnen

::<math>f(N,k)=\frac{1}{2}(k N^2-k^2 N+k^2-k)\in \mathcal{O}(k N^2)</math>

Die Komplexitätsberechnung erfolgte dabei nach der Regel für Polynome unter Beachtung von <math>k \ll N</math>.

====Fazit:====

Die Komplexität von Version 1 mit einer verketteten Liste wäre O(N2 * k)
'''→ Die richtige Datenstruktur ist wichtig, da es sonst zu einer Komplexitätsverschlechterung kommen kann!'''

Auf Version 2 unseres Running Average-Beispiels hätte eine verkettete Liste allerdings keine Auswirkungen, da die inkrementelle Berechnung der Summen in Zeile 7 weiterhin möglich ist (bei geschickter Implementation!) und somit Version 2 immer noch eine Komplexität von O(N) hätte.

==Amortisierte Komplexität==

Bis jetzt wurde die Komplexität nur im schlechtesten Fall (Worst Case) betrachtet. Bei einigen Operationen schwankt die Komplexität jedoch sehr stark, wenn man sie mehrmals hintereinander ausführt, und der schlechteste Fall kommt nur selten vor. Dann ist es sinnvoll, die amortisierte Komplexität zu betrachten, die sich mit der durchschnittlichen Komplexität über viele Aufrufe der selben Operation beschäftigt.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse Wikipedia: Amortisierte Laufzeitanalyse]]

===Beispiel: Inkrementieren von Binärzahlen===

Frage: Angenommen, das Umdrehen eines Bits einer Binärzahl verursacht Kosten von 1 Einheit. Wir erzeugen die Folge der natürlichen Zahlen in Binärdarstellung durch sukzessives Inkrementieren, von Null beginnend. Bei jeder Inkrementierung werden einige Bits verändert, aber diese Zahl (und damit die Kosten der Inkrementierungen) ''schwanken'' sehr stark. Wir fragen jetzt, was eine Inkrementierung im Durchschnitt kostet?

Um diese Durchschnittskosten zu berechnen, bezahlen wir bei jeder Inkrementierung 2 Einheiten. Wenn davon nach Abzug der Kosten der jeweiligen Operation noch etwas übrig bleibt, wird der Rest dem Guthaben zugeschrieben. Umgekehrt wird ein eventueller Fehlbetrag (wenn eine Inkrementierung mehr als 2 Bits umdreht) aus dem Guthaben gedeckt. Dadurch werden die ansonsten großen Schwankungen der Kosten ausgeglichen:
:: Kosten < Einzahlung → es wird gespart
:: Kosten = Einzahlung → Guthaben bleibt unverändert
:: Kosten > Einzahlung → Guthaben wird für die Kosten verbraucht

{| border="1" cellspacing="0" cellpadding="5"
!Schritte
!Zahlen
!Kosten 
(Anzahl der geänderten Bits)
! Einzahlung
!Guthaben = 
altes Guthaben + Einzahlung - Kosten
|-
|1.
|00001
|1
|'''2'''
|'''1'''
|-
|2.
|00010
|2
|'''2'''
|'''1'''
|-
|3.
|00011
|1
|'''2'''
|'''2'''
|-
|4.
|00100
|3
|'''2'''
|'''1'''
|-
|5.
|00101
|1
|'''2'''
|'''2'''
|-
|6.
|00110
|2
|'''2'''
|'''2'''
|-
|7.
|00111
|1
|'''2'''
|'''3'''
|-
|8.
|01000
|4
|'''2'''
|'''1'''
|-
|}

Die Kosten ergeben sich aus der Anzahl der Ziffern die von 1 nach 0, bzw. von 0 nach 1 verändert werden

Rechnung:

1. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

2. Schritt: Kosten: 2 = Einzahlung: 2 
:: → es wird nicht gespart 
:: → Guthaben bleibt so wie es ist 

3. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

4. Schritt: Kosten: 3 > Einzahlung: 2 
:: → es wird eine 1 vom Guthaben genommen um die Kosten zu zahlen 

usw.

Man erkennt, dass vor teuren Operation (Wechsel von 3 auf 4 bzw. von 7 auf 8) genügend Guthaben angespart wurde, um die Kosten zu decken. Das Guthaben geht bei diesen Operationen immer wieder auf 1 zurück, aber es wird nie vollständig verbraucht (Dies kann natürlich auch mathematisch exakt bewiesen werden, wie wir es unten am Beispiel des dynamische Arrays zeigen). Wir schließen daraus, dass die durchschnittlichen oder '''amortisierten Kosten''' einer Inkrementierungsoperation gleich 2 sind.

Zum Weiterlesen: [[http://de.wikipedia.org/wiki/Account-Methode Wikipedia Account-Methode]]

====Fazit====
Die amortisierte Komplexität beschäftigt sich mit dem Durchschnitt aller Operation im ungünstigsten Fall. Operationen mit hohen Kosten, die aber nur selten ausgeführt werden, fallen bei der amortisierten Komplexität nicht so ins Gewicht. Bei Algorithmen, die gelegentlich eine "teure" Operation benutzen, ansonsten jedoch "billige" Operationen aufrufen, kann die amortisierte Komplexität niedriger sein als die Komplexität im schlechtesten (Einzel-)Fall.

In unserem Beispiel fallen die teuren Einzelschritte (z.B. 4. und 8. Schritt) bei den amortisierten Kosten nicht so ins Gewicht, da wir die Kosten aus unserem Guthaben mitbezahlen können. Das Guthaben ist immer groß genug, weil jeder zweite Aufruf eine billige Operation ist, die nur ein Bit umdreht und somit das Ansparen ermöglicht. Diese Betrachtung zeigt, dass die amortisierte (d.h. durchschnittliche) Komplexität des Algoithmus niedriger (nämlich konstant) ist als die Komplexität im schlechtesten Fall.

===Anwendung: Dynamisches Array===

Ein dynamisches Array hat die Eigenschaft, dass man effizient am Ende des Arrays neue Elemente anfügen kann, indem man die Länge des Arrays entsprechend vergrößert (siehe Übung 1). Die Analyse der amortisierten Komplexität der Anfüge-Operation zeigt uns, wie man das Vergrößern des Arrays richtig implementiert, damit die Operation wirklich effizient abläuft.

==== Ineffiziente naive Lösung ====

Wenn wir an ein Array ein Element anhängen wollen, müssen wir neuen Speicher allokieren, der die gewünschte Länge hat. Die Werte aus dem alten Array müssen dann in den neuen Speicher umkopiert werden. Danach kann das neue Element hinten angefügt werden, weil wir im neuen Array bereits Speicher für dieses Element reserviert haben. Bei der naiven Implementation des dynamischen Arrays wiederholt man dies bei jeder Anfügeoperation. Für die Analyse nehmen wir an, dass das Kopieren eines Elements konstante Zeit O(1) erfordert, ebenso das Einfügen eines neuen Elements auf in eine noch unbenutzte Speicherposition.

Naives Anhängen eines weiteren Elements an ein Array:

{| border="1" cellspacing="0" cellpadding="5" align="right"
!Schritte
|'''Array'''
(wie es nach jedem Schritt aussieht)
!Komplexität
|-
|<center>altes Array (N=4)</center>
|<center>[0,1,2,3]</center>
|<center>-</center>
|-
|1. neuer Speicher für    (N+1) Elemente
|<center>[None,None,None,None,None]</center>
|<center>O(N+1) = '''O(N)'''</center>(wenn der Speicher initialisiert wird (hier auf <tt>None</tt>), sonst O(1))
|-
|2. Kopieren
|<center>[0,1,2,3,None]</center>
|<center>'''O(N)'''</center>
|-
|3. append von "x"
|<center>[0,1,2,3,'x']</center>
|<center>'''O(1)'''</center>
|-
|}

altesArray = [0,1,2,3] 
altesArray.append('x')

1. Es wird ein neues Array der Größe N+1 erzeugt 
2. Die N Datenelemente aus dem alten Array werden in das neue Array kopiert 
Das sind N Operationen der Komplexität O(1), also ein Gesamtaufwand von O(N). 
3. 'x' wird mit Aufwand O(1) an die letzte Stelle des neuen Arrays geschrieben

Additionsregel: 
O(N) + O(1) ∈ O(N)

Folgerung:

Bei der naiven Methode erfordert jede Anfügung einen Aufwand O(N) (wobei N die derzeitige Arraygröße ist). Das ist nicht effizient.

====Effiziente Lösung durch Verdoppeln der Kapazität====

Offensichtlich kommt man nicht darum heraum, den Inhalt des alten Arrays zu kopieren, wenn der allokierte Speicher voll ist. Der Trick für die effiziente Implementation der Anfügeoperation besteht darin, das Kopieren so selten wie möglich durchzuführen, also nicht wie in der naiven Lösung bei jeder Anfügeoperation. Hier kommt die amortisierte Komplexität ins Spiel: Ab und zu gibt es eine teure Anfügeoperation (wenn nämlich kopiert werden muss), aber wenn man den durchschnittlichen Aufwand über viele Anfügungen betrachtet, ist die Operation effizient. Der teure Fall wird sozusagen "herausgemittelt".

Um nur selten kopieren zu müssen, werden beim dynamischen Array mehr Speicherelemente reserviert als zur Zeit benötigt werden (in der naiven Lösung wurde dagegen immer nur Speicher für ein einziges neues Element reserviert). Wir unterscheiden deshalb

:<tt>capacity</tt> = Anzahl der allokierten Speicherzellen, d.h. der möglichen Elemente, die in das Array passen 
:<tt>size</tt> = Anzahl der Elemente, die im Array zur Zeit gespeichert sind 

Die Daten selbst werden in einem statischen Array gespeichert:
:<tt>data</tt> = statisches Array der Größe <tt>capacity</tt> 

Die folgende intuitive Abschätzung zeigt, dass es sinnvoll ist, die Größe des allokierten Speichers jeweils zu verdoppeln. Wir starten bei einem Array der Größe <tt>size = capacity</tt> = N. Da der verfügbare Speicher voll ist, müssen wir bei der nächsten Anfügung die N vorhandenen Elemente in ein neues Array der Länge <tt>new_capacity</tt> kopieren (Aufwand <math>N\cdot O(1)</math>). Danach können wir K Elemente billig einfügen (Aufwand <math>K\cdot O(1)</math>), wobei
:K = <tt>new_capacity - capacity</tt>
die Anzahl der nach dem Kopieren noch unbenutzen Speicherzellen ist. Der durchschnittliche Aufwand für diese K Einfügungen ist somit
:<math>\bar T = \frac{N \cdot O(1) + K \cdot O(1)}{K}=\frac{N+K}{K}\cdot O(1)</math>
Damit die mittlere Zeit in O(1) sein kann, muss der Quotient <math>(N+K)/K</math> eine Konstante sein. Wir setzen <math>K = a N</math> und erhalten:
:<math>\bar T = \frac{(a+1)N}{a N}\cdot O(1)=\frac{a+1}{a}\cdot O(1)</math>
Der amortisierte Aufwand über K Einfügungen ist also konstant, wenn <math>a</math> eine (kleine) von N unabhängige Zahl ist. Typischerweise wählt man
:<math>a = 1</math>
und mit <math>K = 1\cdot N</math> ergibt sich
:<tt>new_capacity = capacity</tt> + N = <tt>2 * capacity</tt>

Die Vorgehensweise beim Zufügen eines neuen Elements im Fall <tt>size == capacity</tt> ist also
* capacity wird verdoppelt 
: <tt>neue capacity = 2 * alte capacity</tt>
: (allgemein genügt es auch, wenn capacity um einen bestimmten Prozentsatz vergrößert wird,
:: <tt>neue capacity = alte capacity * c</tt>
: mit c > 1, z.B. c = 1.2, das entspricht oben der Wahl <math>a = 0.2</math>)
* ein neues statisches Array der Größe 'neue capacity' wird erzeugt
* das alte Array wird ins neue kopiert und danach freigegeben
* das anzufügende Element wird ins neue Array eingefügt
Umgekehrt geht man beim Entfernen des ''letzten'' Array-Elements vor. Normalerweise überschreibt man einfach das letzte Element mit <tt>None</tt> und dekrementiert <tt>size</tt>. Wird dadurch das Array zu klein (üblicherweise <tt>size < capacity / 4</tt>), wird die Kapazität halbiert, genauer:
* ein neues Array mit 
: <tt>neue capacity = alte capacity / 2 </tt>
: wird angelegt (bzw. mit
:: <tt>neue capacity = alte capacity / c </tt>
: wenn ein anderer Vergrößerungsfaktor verwendet wird)
* das alte Array wird ins neue kopiert und danach freigegeben

'''Folge:''' Die Kosten für das Vergrößern/Verkleinern der Kapazität werden amortisiert über viele Einfügungen, die kein Vergrößern erfordern. Die Operation <tt>append</tt> besitzt amortisierte Komplexität O(1). Im folgenden Abschnitt zeigen wir dies mathematisch exakt mit der Potentialmethode.

====Komplexitätsanalyse des dynamischen Arrays mit Potentialmethode====

Durchschnitt der Gesamtkosten für N-maliges append = <math>\frac{1}{N} \sum_{i = 1}^N Kosten(i)</math>. Zur Analyse der amortisierten Komplexität wird ein Potential 
::Φi = 2*sizei - capacityi 
eingeführt, wobei das Array nach dem i-ten Einfüge-Schritt die Größe sizei und die Kapizität capacityi hat. Wir nehmen vereinfachend an, dass es keine Löschoperationen gibt. Dann gilt nach dem i-ten Schritt jeweils
::Φi = 2*i - capacityi 

Fall 1: Array ist nicht voll 
Es wird kein Umkopieren benötigt, da das Array noch nicht voll ist 
→ sizei-1 < capacityi-1 
→ capacityi == capacityi-1

Kosten: 1 (für Einfügen des neuen Elements) 
Potenzial vor append: Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append: Φi = 2i - capacityi-1 

amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = 1 + (2i - capacityi-1) - [2(i - 1) - capacityi-1]
::::: = 1 + 2i - capacityi-1 - 2i + 2 + capacityi-1
::::: = 1 + <del>2i</del> - <del>capacityi-1</del> - <del>2i</del> + 2 + <del>capacityi-1</del>
::::: = 1 + 2
::::: = 3 = O(1) → konstant

Fall 2: Array ist voll 
Vor dem i-ten append muss umkopiert werden 
→ sizei-1 == capacityi-1 == i-1 
→ Allokieren eines neuen statischen Arrays mit verdoppelter Kapazität notwendig, also capacityi == 2*capacityi-1

Kosten: (i-1) + 1 (für Umkopieren und Einfügen des neuen Elements) 
Potenzial vor append = Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append = Φi = 2i - 2 capacityi-1 
amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = ((i - 1) + 1) + 2i - 2 capacityi-1 - [2(i-1) - capacityi-1]
::::: = i + <del>2i</del> - 2 capacityi-1 - <del>2i</del> + 2 - capacityi-1
::::: = i + 2 - capacityi-1
::::: = i + 2 - (i - 1) (da capacityi-1 = i-1)
::::: = 3 = O(1) → konstant

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine amortisierte Komplexität von 3 Einheiten hat, also <tt>append</tt> ∈ O(1)'''. Diese Operation kann deshalb gefahrlos in der inneren Schleife eines Algorithmus benutzt werden.

==== Beispiel für 9 Einfügeoperationen ====

{| border="1" cellspacing="0" cellpadding="5"
!Array 
(wie es aussehen könnte)
!size
!capacity
!Kosten für append (einschließlich Umkopieren)
!Summe Kosten
!Durchschnittskosten
!Φi = 2 * size - capacity 
(i = size)
!Potenzialdifferenz 
Δ Φi = Φi - Φi-1
!amortisierte Kosteni 
= Kosteni + Δ Φi
|-
| <center>[None]</center>
| <center>0</center>
| <center>1</center>
| <center>-</center>
| <center>-</center>
| <center>-</center>
| <center>-1</center>
| <center>-</center>
| <center>-</center>
|-
| <center>[a]</center><center>Array ist voll!</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b]</center><center>Array ist voll!</center>
| <center>2</center>
| <center>2</center>
| <center>1 + 1</center>
| <center>3</center>
| <center>3/2</center>
| <center>2</center>
| <center>1</center>
| <center>3</center>
|-
| <center>[a,b,c,None]</center>
| <center>3</center>
| <center>4</center>
| <center>2 + 1</center>
| <center>6</center>
| <center>6/3</center>
| <center>2</center>
| <center>0</center>
| <center>3</center>
|-
| <center>[a,b,c,d]</center><center>Array ist voll!</center>
| <center>4</center>
| <center>4</center>
| <center>1</center>
| <center>7</center>
| <center>7/4</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,None,None,None]</center>
| <center>5</center>
| <center>8</center>
| <center>4 + 1</center>
| <center>12</center>
| <center>12/5</center>
| <center>2</center>
| <center>-2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,None,None]</center>
| <center>6</center>
| <center>8</center>
| <center>1</center>
| <center>13</center>
| <center>13/6</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,None]</center>
| <center>7</center>
| <center>8</center>
| <center>1</center>
| <center>14</center>
| <center>14/7</center>
| <center>6</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h]</center><center>Array ist voll!</center>
| <center>8</center>
| <center>8</center>
| <center>1</center>
| <center>15</center>
| <center>15/8</center>
| <center>8</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h,j,None,None,None, 
None,None,None,None]</center>
| <center>9</center>
| <center>16</center>
| <center>8 + 1</center>
| <center>24</center>
| <center>24/9</center>
| <center>2</center>
| <center>-6</center>
| <center>3</center>
|-
|}

Die durchschnittlichen Kosten betragen stets etwa 2 Einheiten, schwanken allerdings so, dass nicht unmittelbar ersichtlich ist, ob dies für sämtliche Einfügeoperationen gilt. Die amortisierte Komplexität, die mit Hilfe des Potentials berechnet wird, ist hingegen konstant 3, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

[[Suchen|Nächstes Thema]]

Effizienz

2012-07-27T16:03:52Z

Ukoethe: /* Beispiel: Inkrementieren von Binärzahlen */

Bei der Diskussion von Effizienz müssen wir zwischen der Laufzeit eines Algorithmus auf einem bestimmten System und seiner prinzipiellen Leistungsfähigkeit (Algorithmenkomplexität) unterscheiden. Der Benutzer ist natürlich vor allem an der Laufzeit interessiert, denn diese bestimmt letztendlich seine Arbeitsproduktivität. Ein Softwaredesigner hingegen muss eine Implementation wählen, die auf verschiedenen Systemen und in verschiedenen Anwendungen schnell ist. Für ihn sind daher auch Aussagen zur Algorithmenkomplexität sehr wichtig, um den am besten geeigneten Algorithmus auszuwählen.

== Laufzeit ==

Aus Anwendersicht ist ein Algorithmus effizient, wenn er die in der Spezifikation verlangten Laufzeitgrenzen einhält. Ein Algorithmus muss also nicht immer so schnell wie möglich sein, sondern so schnell wie nötig. Dies führt in verschiedenen Anwendungen zu ganz unterschiedliche Laufzeitanforderungen:

* Berechnen des nächsten Steuerkommandos für eine Maschine: ca. 1/1000s
* Berechnen des nächsten Bildes für eine Videopräsentation (z.B. Dekompression von MPEG-kodierten Bildern): ca. 1/25s
: Geringere Bildraten führen zu ruckeligen Filmen.
* Sichtbare Antwort auf ein interaktives Kommando (z.B. Mausklick): ca. 1/2s
: Wird diese Antwortzeit überschritten, vermuten viele Benutzer, dass der Mausklick nicht funktioniert hat, und klicken nochmals, mit eventuell fatalen Folgen. Wenn ein Algorithmus notwendigerweise länger dauert als 1/2s, sollte ein Fortschrittsbalken angezeigt werden.
* Wettervorhersage: muss spätestens am Vorabend des vorhergesagten Tages beendet sein

===Laufzeitvergleich===

Da die Laufzeit für den Benutzer ein so wichtiges Kriterium ist, werden häufig Laufzeitvergleiche durchgeführt. Deren Ergebnisse hängen allerdings von vielen Faktoren ab, die möglicherweise nicht kontrollierbar sind:
* Geschwindigkeit und Anzahl der Prozessoren
* Auslastung des Systems
* Größe des Hauptspeichers und Cache, Geschwindigkeit des Datenbus
* Qualität des Compilers/Optimierers (ist der Compiler für die spezielle Prozessor-Architektur optimiert?)
* Geschick des Programmierers
* Daten (Beispiel Quicksort: Best case und worst case [vorsortierter Input] stark unterschiedlich)
All diese Faktoren sind untereinander abhängig. Laufzeitvergleiche sind daher mit Vorsicht zu interpretieren.
Generell sollten bei Vergleichen möglichst wenige Parameter verändert werden, z.B.
* gleiches Programm (gleiche Kompilierung), gleiche Daten, andere Prozessoren
oder
* gleiche CPU, Daten, andere Programme (Vergleich von Algorithmen)
Zur Verbesserung der Vergleichbarkeit gibt es standardisierte [http://en.wikipedia.org/wiki/Benchmark_(computing) Benchmarks], die bestimmte Aspekte eines Systems unter möglichst realitätsnahen Bedingungen testen. Generell gilt aber: Durch Laufzeitmessung ist schwer festzustellen, ob ein Algorithmus ''prinzipiell'' besser ist als ein anderer. Dafür ist die Analyse der [[Effizienz#Algorithmen-Komplexität|Algorithmenkomplexität]] notwendig.

===Optimierung der Laufzeit===

Wenn sich herausstellt, dass ein bereits implementierter Algorithmus zu langsam läuft, geht man wie folgt vor:

# Man verwendet einen [http://en.wikipedia.org/wiki/Performance_analysis Profiler], um zunächst den Flaschenhals zu bestimmen. Ein Profiler ist ein Hilfsprogramm, das während der Ausführung eines Programms misst, wieviel Zeit in jeder Funktion und Unterfunktion verbraucht wird. Dadurch kann man herausfinden, welcher Teil des Algorithmus überhaupt Probleme bereitet. Donald Knuth gibt z.B. als Erfahrungswert an, dass Programme während des größten Teils ihrer Laufzeit nur 3% des Quellcodes (natürlich mehrmals wiederholt) ausführen [http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf]. Es ist sehr wichtig, diese 3% experimentell zu bestimmen, weil die Erfahrung zeigt, dass man beim Erraten der kritischen Programmteile oft falsch liegt. Man spricht dann von "[http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize premature optimization]", also von voreiliger Optimierung ohne experimentelle Untersuchung der wirklichen Laufzeiten, was laut Knuth "the root of all evil" ist. Der Python-Profiler wird in [http://docs.python.org/lib/profile.html Kapitel 25] der Python-Dokumentation beschrieben.
# Man kann dann versuchen, die kritischen Programmteile zu optimieren.
# Falls der Laufzeitgewinn durch Optimierung zu gering ist, muss man einen prinzipiell schnelleren Algorithmus verwenden, falls es einen gibt.

Einige wichtige Techniken der Programmoptimierung sollen hier erwähnt werden. Wenn man einen optimierenden Compiler verwendet, werden einige Optimierungen automatisch ausgeführt [http://en.wikipedia.org/wiki/Compiler_optimization]. In Python trifft dies jedoch nicht zu. Um den Sinn einiger Optimierungen zu verstehen, benötigt man Grundkenntnisse der Computerarchitektur.

;Elimination von redundantem Code: Es ist offensichtlich überflüssig, dasselbe Ergebnis mehrmals zu berechnen, wenn es auch zwischengespeichert werden könnte. Diese Optimierung wird von vielen automatischen Optimierern unterstützt und kommt im wesentlichen in zwei Ausprägungen vor:
:; common subexpression elimination: In mathematischen Ausdrücken wird ein Teilergebnis häufig mehrmals benötigt. Man betrachte z.B. die Lösung der quadratischen Gleichung <math>x^2+p\,x+q = 0</math>:
x1 = - p / 2.0 + sqrt(p*p/4.0 - q)
x2 = - p / 2.0 - sqrt(p*p/4.0 - q)
::Die mehrmalige Berechnung von Teilausdrücken wird vermieden, wenn man stattdessen schreibt:
p2 = - p / 2.0
r = sqrt(p2*p2 - q)
x1 = p2 + r
x2 = p2 - r
:; loop invariant elimination: Wenn ein Teilausdruck sich in einer Schleife nicht ändert, muss man ihn nicht bei jedem Schleifendurchlauf neu berechnen, sondern kann dies einmal vor Beginn der Schleife tun. Ein typisches Beispiel hierfür ist die Adressierung von Matrizen, die als 1-dimensionales Array gespeichert sind. Angenommen, wir speichern eine NxN Matrix <tt>m</tt> in einem Array <tt>a</tt> der Größe N2, so dass das Matrixelement <tt>mij</tt> durch <tt>a[i + j*N]</tt> indexiert wird. Wir betrachten die Aufgabe, eine Einheitsmatrix zu initialisieren. Ein nicht optimierter Algorithmus dafür lautet:
for j in range(N):
for i in range(N):
if i == j:
a[i + j*N] = 1.0
else:
a[i + j*N] = 0.0
::Der Ausdruck <tt>j*N</tt> wird hier in jedem Schleifendurchlauf erneut berechnet, obwohl sich <tt>j</tt> in der inneren Schleife gar nicht verändert. Man kann deshalb optimieren zu:
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
;Vereinfachung der inneren Schleife: Generell sollte man sich bei der Optimierung auf die innere Schleife eines Algorithmus konzentrieren, weil dieser Code am häufigsten ausgeführt wird. Insbesondere sollte man die Anzahl der Befehle in der inneren Schleife so gering wie möglich halten und teure Befehle vermeiden. Früher waren vor allem Floating-Point Befehle teuer, die man oft durch die schnellere Integer-Arithmetik ersetzt hat, falls dies algorithmisch möglich war (diesen Rat findet man noch oft in der Literatur). Heute hat sich die Hardware so verbessert, dass im Allgemeinen nur noch die Floating-Point Division deutlich langsamer ist als die anderen Operatoren. Im obigen Beispiel der quadratischen Gleichung ist es daher sinnvoll, den Ausdruck
p2 = -p / 2.0
:durch
p2 = -0.5 * p
:zu ersetzen. Dadurch ersetzt man eine Division durch eine Multiplikation und spart außerdem das Negieren von <tt>p</tt>, da der Compiler direkt mit <tt>-0.5</tt> multipliziert.
;Ausnutzung der Prozessor-Pipeline: Moderne Prozessoren führen mehrere Befehle parallel aus. Dies ist möglich, weil jeder Befehl in mehrere Teilschritte zerlegt werden kann. Eine generische Unterteilung in vier Teilschritte ist z.B.:
:# Dekodieren des nächsten Befehls
:# Beschaffen der Daten, die der Befehl verwendet (aus Prozessorregistern, dem Cache, oder dem Hauptspeicher)
:# Ausführen des Befehls
:# Schreiben der Ergebnisse
:Man bezeichnet dies als die "[http://en.wikipedia.org/wiki/Instruction_pipeline instruction pipeline]" des Prozessors (heutige Prozessoren verwenden wesentlich feinere Unterteilungen). Prozessoren werden nun so gebaut, dass mehrere Befehle parallel, auf verschiedenen Ausführungsstufen ausgeführt werden. Wenn Befehl 1 also beim Schreiben der Ergebnisse angelangt ist, kann Befehl 2 die Hardware zum Ausführen des Befehls benutzen, während Befehl 3 seine Daten holt, und Befehl 4 soeben dekodiert wird. Unter bestimmten Bedingungen funktioniert diese Parallelverarbeitung jedoch nicht. Dies gibt Anlass zu Optimierungen:
:;Vermeiden unnötiger Typkonvertierungen: Der Prozessor verarbeitet Interger- und Floating-Point-Befehle in verschiedenen Pipelines, weil die Hardwareanforderungen sehr verschieden sind. Wird jetzt ein Ergebnis von Integer nach Floating-Point umgewandelt oder umgekehrt, muss die jeweils andere Pipeline warten, bis die erste Pipeline ihre Berechnung beendet. Es kann dann besser sein, Berechnungen in Floating-Point zu Ende zu führen, auch wenn sie semantisch eigentlich Integer-Berechnungen sind.
:;Reduzierung der Anzahl von Verzweigungen: Wenn der Code verzweigt (z.B. durch eine <tt>if</tt>- oder <tt>while</tt>-Anweisung), ist nicht klar, welcher Befehl nach der Verzweigung ausgeführt werden soll, bevor Stufe 3 der Pipeline die Verzweigungsbedingung ausgewertet hat. Bis dahin wären die ersten beiden Stufen der Pipeline unbenutzt. Moderne Prozessoren benutzen zwar ausgefeilte Heuristiken, um das Ergebnis der Bedingung vorherzusagen, und führen den hoffentlich richtigen Zweig des Codes spekulativ aus, aber dies funktioniert nicht immer. Man sollte deshalb generell die Anzahl der Verzweigungen minimieren. Als Nebeneffekt führt dies meist auch zu besser lesbarem, verständlicherem Code. Im Matrixbeispiel kann man
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
::durch
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
ersetzen. Die Diagonalelemente <tt>a[j + jN]</tt> werden jetzt zwar zweimal initialisiert (in der Schleife auf Null, dann auf Eins), aber durch Elimination der <tt>if</tt>-Abfrage wird dies wahrscheinlich mehr als ausgeglichen, zumal dadurch die innere Schleife wesentlich vereinfacht wurde.
;Ausnutzen des Prozessor-Cache: Zugriffe auf den Hauptspeicher sind sehr langsam. Deshalb werden stets ganze Speicherseiten auf einmal in den [http://en.wikipedia.org/wiki/Cache Cache] des Prozessors geladen. Wenn unmittelbar nacheinander benutzte Daten auch im Speicher nahe beieinander liegen (sogenannte "[http://en.wikipedia.org/wiki/Locality_of_reference locality of reference]"), ist die Wahrscheinlichkeit groß, dass die als nächstes benötigten Daten bereits im Cache sind und damit schnell gelesen werden können. Bei vielen Algorithmen kann man die Implementation so umordnen, dass die locality of reference verbessert wird, was zu einer drastischen Beschleunigung führt. Im Matrix-Beispiel ist z.B. die Reihenfolge der Schleifen wichtig. Für konstanten Index <tt>j</tt> liegen die Indizes <tt>i</tt> im Speicher hintereinander. Deshalb ist es günstig, in der inneren Schleife über <tt>i</tt> zu iterieren:
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
:Die umgekehrte Reihenfolge der Schleifen ist hingegen ungünstig
for i in range(N):
for j in range(N):
a[i + j*N] = 0.0
a[i + i*N] = 1.0
:Jetzt werden in der inneren Schleife stets N Datenelemente übersprungen. Besonders bei großem N muss man daher häufig den Cache neu füllen, was bei der ersten Implementation nicht notwendig war. (Außerdem verliert man hier die Optimierung <tt>jN = j*N</tt>, die jetzt nicht mehr möglich ist.)

Als Faustregel kann man durch Optimierung eine Verdoppelung der Geschwindigkeit erreichen (in Ausnahmefällen auch mehr). Benötigt man stärkere Verbesserungen, muss man wohl oder übel einen besseren Algorithmus oder einen schnelleren Computer verwenden.

== Algorithmen-Komplexität ==

Komplexitätsbetrachtungen ermöglichen den Vergleich der prinzipiellen Eigenschaften von Algorithmen unabhängig von einer Implementation, Umgebung etc.

Eine einfache Möglichkeit ist das Zählen der Aufrufe einer Schlüsseloperation. Beispiel Sortieren:
* Anzahl der Vergleiche
* Anzahl der Vertauschungen

=== Beispiel: Selection Sort ===

for i in range(len(a)-1):
max = i
for j in range(i+1, len(a)):
if a[j] < a[max]:
max = j
a[max], a[i] = a[i], a[max] # swap

*Anzahl der Vergleiche: Ein Vergleich in jedem Durchlauf der inneren Schleife. Es ergibt sich folgende Komplexität:
*:Ingesamt <math>\sum_{i=0}^{N-2} \sum_{j=i+1}^{N-1}1 = \frac{N}{2} (N-1) \!</math> Vergleiche.

*Anzahl der Vertauschungen (swaps): Eine Vertauschung pro Durchlauf der äußeren Schleife:
*:Insgesamt <math>N-1 \!</math> Vertauschungen

Die Komplexität wird durch die Operationen bestimmt, die am häufigsten ausgeführt werden, hier also die Anzahl der Vergleiche. Die Anzahl der Vertauschungen ist hingegen kein geeignetes Kriterium für die Komplexität von selection sort, weil der Aufwand in der inneren Schleife ignoriert würde.

=== Fallunterscheidung: Worst und Average Case ===

Die Komplexität ist in der Regel eine Funktion der Eingabegröße (Anzahl der Eingabebits, Anzahl der Eingabeelemente). Sie kann aber auch von der Art der Daten abhängen, nicht nur von der Menge, z.B. vorsortierte Daten bei Quicksort. Um von der Art der Daten unabhängig zu werden, kann man zwei Fälle der Komplexität unterscheiden:

* Komplexität im ungünstigsten Fall
*: Der ungünstigste Fall ist die Eingabe gegebener Länge, für die der Algorithmus am langsamsten ist. Der Nachteil dieser Methode besteht darin, dass dieser ungünstige Fall in der Praxis vielleicht gar nicht oder nur selten vorkommt, so dass sich der Algorithmus in Wirklichkeit besser verhält als man nach dieser Analyse erwarten würde. Beim Quicksort-Algorithmus mit zufälliger Wahl des Pivot-Elements müsste z.B. stets das kleinste oder größte Element des aktuellen Intervalls als Pivot-Element gewählt werden, was äußerst unwahrscheinlich ist.
* Komplexität im durchschnittlichen/typischen Fall
*: Der typische Fall ist die mittlere Komplexität des Algorithmus über alle möglichen Eingaben. Dazu muss man die Wahrscheinlichkeit jeder möglichen Eingabe kennen, und berechnet dann die mittlere Laufzeit über dieser Wahrscheinlichkeitsverteilung. Leider ist die Wahrscheinlichkeit der Eingaben oft nicht bekannt, so dass man geeignete Annahmen treffen muss. Bei Sortieralgorithmen können z.B. alle möglichen Permutationen des Eingabearrays als gleich wahrscheinlich angenommen werden, und der typische Fall ist dann die mittlere Komplexität über alle diese Eingaben. Oft hat man jedoch in der Praxis andere Wahrscheinlichkeitsverteilungen, z.B. sind die Daten oft "fast sortiert" (nur wenige Elemente sind an der falschen Stelle). Dann verhält sich der Algorithmus ebenfalls anders als vorhergesagt.

Wir beschränken uns in dieser Vorlesung auf die Komplexität im ungünstigseten Fall. '''Exakte''' Formeln für Komplexität sind aber auch dann schwer zu gewinnen, wie das folgende Beispiel zeigt:

=== Beispiele aus den Übungen (Gemessene Laufzeiten für Mergesort/Selectionsort) ===

* Mergesort: <math>\frac{0,977N\log N}{\log 2} + 0,267N-4.39 \!</math>
*: andere Lösung: <math>1140 N\log(N) - 1819N + 6413 \!</math>
* Selectionsort: <math>\frac{1}{2}N^2 - \frac{1}{2N} - 10^{-12} \!</math>
*: andere Lösung: <math>1275N^2 - 116003^N + 11111144 \!</math>

Aus diesen Formeln wird nicht offensichtlich, welcher Algorithmus besser ist.
Näherung: Betrachte nur '''sehr große Eingaben''' (meist sind alle Algorithmen schnell genug für kleine Eingaben). Dieses Vorgehen wird als '''Asymptotische Komplexität''' bezeichnet (N gegen unendlich).

=== Asymptotische Komplexität am Beispiel Polynom ===

Polynom: <math>a\,x^2+b\,x+c=p\!</math>

<math>x \!</math> sei die Eingabegröße, und wir betrachten die Entwicklung von <math>p \!</math> in Abhängigkeit von <math>x \!</math>.

* <math>x=0 \!</math>
*: <math>p=c \!</math>
* <math>x=1 \!</math>
*: <math>p=a+b+c \!</math>
* <math>x=1000 \!</math>
*: <math>p=1000000a+1000b+c \approx 1000000a\!</math>
* <math>x \to \infty \!</math>
*: <math>p \approx x^2a\!</math>

Für sehr große Eingaben verlieren also ''b'' und ''c'' immer mehr an Bedeutung, so dass am Ende nur noch ''a'' für die Komplexitätsbetrachtung wichtig ist.

== Landau-Symbole ==

Um die asymptotische Komplexität verschiedener Algorithmen miteinander vergleichen zu können, verwendet man die sogenannten [http://de.wikipedia.org/wiki/Landau-Symbole Landau-Symbole]. Das wichtigste Landau-Symbol ist <math>\mathcal{O}</math>, mit dem man eine ''obere Schranke'' <math>f \in \mathcal{O}(g)</math> für die Komplexität angeben kann.

Schreibt man <math>f \in \Omega(g)</math>, so stellt dies eine asymptotische ''untere Schranke'' für die Funktion f dar.

Schließlich bedeutet <math>f \in \Theta(g)</math>, dass die Funktion f genauso schnell wie die Funktion g wächst, das heißt man hat eine asymptotisch ''scharfe Schranke'' für f. Hierzu muss sowohl <math>f\in\mathcal{O}(g)</math> als auch <math>f \in \Omega(g)</math> erfüllt sein.

Im nun folgenden soll auf die verschiedenen Landau-Symbole noch näher eingegeangen werden.

===O-Notation===

Intuitiv gilt: Für große N dominieren die am schnellsten wachsenden Terme einer Funktion. Die Notation <math>f \in \mathcal{O}(g)</math> (sprich "f ist in O von g" oder "f ist von derselben Größenordnung wie g") formalisiert eine solche Abschätzung der asymptotischen Komplexität der Funktion f von oben.
; Asymptotische Komplexität: Für zwei Funktionen f(x) und g(x) gilt
::<math>f(x) \in \mathcal{O}(g(x))</math>
: genau dann wenn es eine Konstante <math>c>0</math> und ein Argument <math>x_0</math> gibt, so dass
::<math>\forall x \ge x_0:\quad f(x) \le c\,g(x)</math>.
:Die Menge <math>\mathcal{O}(g(x))</math> aller durch g(x) abschätzbaren Funktionen ist also formal definiert durch
::<math>\mathcal{O}(g(x)) = \{ f(x)\ |\ \exists c>0: \forall x \ge x_0: 0 \le f(x) \le c\,g(x)\}</math>

Die Idee hinter dieser Definition ist, dass g(x) eine wesentlich einfachere Funktion ist als f(x), die sich aber nach geeigneter Skalierung (Multiplikation mit c) und für große Argumente x im wesentlichen genauso wie f(x) verhält. Man kann deshalb in der Algorithmenanalyse f(x) durch g(x) ersetzen. <math>f(x) \in \mathcal{O}(g(x))</math> spielt für Funktionen eine ähnliche Rolle wie der Operator ≤ für Zahlen: Falls a ≤ b gilt, kann bei einer Abschätzung von oben ebenfalls a durch b ersetzt werden.

==== Ein einfaches Beispiel ====

[[Image:Sqsqrt.png]]

Rot = <math>x^2 \!</math>
Blau = <math>\sqrt{x} \!</math>

<math>\sqrt{x} \in \mathcal{O}(x^2)\!</math> weil <math>\sqrt{x} \le c\,x^2\!</math> für alle <math>x \ge x_0 = 1 \!</math> und <math>c = 1\!</math>, oder auch für <math>x \ge x_0 = 4 \!</math> und <math>c = 1/16</math> (die Wahl von c und x0 in der Definition von O(.) ist beliebig, solange die Bedingungen erfüllt sind).

==== Komplexität bei kleinen Eingaben ====

Algorithmus 1: <math>\mathcal{O}(N^2) \!</math> 
Algorithmus 2: <math>\mathcal{O}(N\log{N}) \!</math>

Algorithmus 2 ist schneller (von geringerer Komplexität) für große Eingaben, aber bei kleinen Eingaben (insbesondere, wenn der Algorithmus in einer Schleife immer wieder mit kleinen Eingaben aufgerufen wird) könnte Algorithmus 1 schneller sein, falls der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor ''c'' bei Algorithmus 2 einen wesentlich größeren Wert hat als bei Algorithmus 1.

==== Eigenschaften der O-Notation (Rechenregeln) ====

# Transitiv:
#: <math>f(x) \in \mathcal{O}(g(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) \in \mathcal{O}(h(x)) \!</math>
# Additiv:
#: <math>f(x) \in \mathcal{O}(h(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) + g(x) \in \mathcal{O}(h(x)) \!</math>
# Für Monome gilt:
#: <math>x^k \in \mathcal{O}(x^k)</math> und
#: <math>x^k \in \mathcal{O}(x^{k+j}), \forall j \ge 0 \!</math>
# Multiplikation mit einer Konstanten:
#: <math>f(x) \in \mathcal{O}(g(x)) \to c\,f(x) \in \mathcal{O}(g(x))\!</math>
#: andere Schreibweise:
#: <math>f(x) = c\,g(x) \to f(x) \in \mathcal{O}(g(x))\!</math>
# Folgerung aus 3. und 4. für Polynome:
#: <math>a_0+a_1\,x + ... + a_n\,x^n \in \mathcal{O}(x^n)\!</math>
#: Beispiel: <math>a\,x^2+b\,x+c \in \mathcal{O}(x^2)\!</math>
# Logarithmus:
#: <math>a, b > 1\!</math>
#: <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>
#: Die Basis des Logarithmus spielt also keine Rolle.
#: Beweis hierfür:
#:: <math>\log_{a}{x} = \frac{\log_{b}{x}}{\log_{b}{a}}\!</math>
#:: Mit <math>c = 1 / \log_{b}{a}\,</math> gilt: <math>\log_{a}{x} = c\,\log_{b}{x}\!</math>.
#:: Wird hier die (zweite) Regel für Multiplikation mit einer Konstanten angewendet, fällt der konstante Faktor weg, also <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>.
#: Insbesondere gilt auch <math>\log_{a}{x} \in \mathcal{O}(\log_{2}{x})\!</math>, es kann also immer der 2er Logarithmus verwendet werden.

==== O-Kalkül ====

Das O-Kalkül definiert wichtige Vereinfachungsregeln for Ausdrücke in O-Notation (Beweise: siehe Übungsaufgabe):

# <math>f(x) \in \mathcal{O}(f(x))\!</math>
# <math>\mathcal{O}(\mathcal{O}(f(x))) \in \mathcal{O}(f(x))\!</math>
# <math>c\,\mathcal{O}(f(x)) \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# <math>\mathcal{O}(f(x))+c \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# Sequenzregel:
#: Wenn zwei nacheinander ausgeführte Programmteile die Komplexität <math>\mathcal{O}(f(x))</math> bzw. <math>\mathcal{O}(g(x))</math> haben, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(f(x))</math> falls <math>g(x) < \mathcal{O}(f(x))</math> bzw.
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(g(x))\!</math> falls <math>f(x) < \mathcal{O}(g(x))</math>.
#: Informell schreibt man auch: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(max(f(x), g(x)))\!</math>.
# Schachtelungsregel bzw. Aufrufregel:
#: Wenn in einer geschachtelten Schleife die äußere Schleife die Komplexität <math>\mathcal{O}(f(x))</math> hat, und die innere <math>\mathcal{O}(g(x))</math>, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) * \mathcal{O}(g(x)) \in \mathcal{O}(f(x) * g(x))\!</math>.
#: Gleiches gilt wenn eine Funktion <math>\mathcal{O}(f(x))</math>-mal aufgerufen wird, und die Komplexität der Funktion selbst <math>\mathcal{O}(g(x))</math> ist.

;Beispiel für 5.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Dies gilt auch für ihre Hintereinanderausführung:
for i in range(N):
a[i] = i
for i in range(N):
print a[i]
;Beispiele für 6.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Ihre Verschachtelung hat daher die Komplexität <math>\mathcal{O}(N^2)</math>.
for i in range(N):
for j in range(N):
a[i*N + j] = i+j
: Dies gilt ebenso, wenn statt der inneren Schleife eine Funktion mit Komplexität <math>\mathcal{O}(N)</math> ausgeführt wird:
for i in range(N):
a[i] = foo(i, N) # <math>\mathrm{foo}(i, N) \in \mathcal{O}(N)</math>

==== O-Kalkül auf das Beispiel des Selectionsort angewandt ====

Selectionsort: Wir hatten gezeigt dass <math>f(N) = \frac{N^2}{2} - \frac{N}{2}</math>. Nach der Regel für Polynome vereinfacht sich dies zu <math>f(N) \in \mathcal{O}\left(\frac{N^2}{2}\right) = \mathcal{O}(N^2)\!</math>.

Alternativ via Schachtelungsregel:
: Die äußere Schleife wird (''N''-1)-mal durchlaufen: <math>N-1 \in \mathcal{O}(N)</math>
: Die innere Schleife wird (''N-i''-1)-mal durchlaufen. Das sind im Mittel ''N''/2 Durchläufe: <math>N/2 \in \mathcal{O}(N)</math>
: Zusammen: <math>\mathcal{O}(N)*\mathcal{O}(N) \in \mathcal{O}(N^2)</math>

Nach beiden Vorgehensweisen kommen wir zur Schlussfolgerung, dass der Selectionsort die asymptotische Komplexität <math>\mathcal{O}(N^2)\!</math> besitzt.

==== Zusammenhang zwischen Komplexität und Laufzeit ====

Wenn eine Operation 1ms dauert, erreichen Algorithmen verschiedener Komplexität folgende Leistungen (wobei angenommen wird, dass der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor immer etwa gleich 1 ist):

{| class="wikitable" style="text-align:left" cellpadding="7"
|+
|-
! Komplexität !! Operationen in 1s !! Operationen in 1min !! Operationen in 1h
|-
! <math>\mathcal{O}(N)</math>
| 1000 || 60.000 || 3.600.000
|-
! <math>\mathcal{O}(N\log_2{N})</math>
| 140 || 4895 || 204094
|-
! <math>\mathcal{O}(N^2)</math>
| 32 || 245 || 1898
|-
! <math>\mathcal{O}(N^3)</math>
| 10 || 39 || 153
|-
! <math>\mathcal{O}(2^N)</math>
| 10 || 16 || 21
|}

==== Exponentielle Komplexität ====
Der letzte Fall <math>\mathcal{O}(2^N)</math> ist von exponentieller Komplexität. Das bedeutet, dass eine Verdopplung des Aufwands nur bewirkt, dass die maximale Problemgröße um eine Konstante wächst. Algorithmen mit exponentieller (oder noch höherer) Komplexität werden deshalb als '''ineffizient''' bezeichnet. Algorithmen mit höchstens polynomieller Komplexität gelten hingegen als effizient.

In der Praxis sind allerdings auch polynomielle Algorithmen mit hohem Exponenten meist zu langsam. Als Faustregel kann man eine praktische Grenze von <math>\mathcal{O}(N^3)</math> ansehen. Bei einer Komplexität von <math>\mathcal{O}(N^3)</math> bewirkt ein verdoppelter Aufwand immer noch eine Steigerung der maximalen Problemgröße um den Faktor <math>\sqrt[3]{2}</math> (also eine ''multiplikative'' Vergrößerung um ca. 25%, statt nur einer additiven Vergrößerung wie bei exponentieller Komplexität).

===<math>\Omega</math>- Notation===

Genauso wie <math>f \in \mathcal{O}(g)</math> eine Art <math>\le</math>-Operator für Funktionen ist, definiert <math>f \in \Omega(g) </math> eine Abschätzung von unten, analog zum <math>\ge</math>-Operator für Zahlen. Formal kann man <math>f(N) \in \Omega(g(N)) </math> genau dann schreiben, falls es eine Konstante <math> c > 0 </math> gibt, so dass

<math> f(N) \ge c \cdot g(N) </math> für <math> N \ge N_0 </math>

gilt.
Man verwendet diese Notation also um abzuschätzen, wie groß der Aufwand (die Komplexität) für einen bestimmten Algorithmus ''mindestens'' ist und nicht ''höchstens'', was man mit der <math>\mathcal{O}</math> - Notation ausdrücken würde.

Ein praktisches Beispiel für eine Anwendung der <math>\Omega</math>- Notation wäre die Fragestellung, ob es ''prinzipiell'' einen besseren Algorithmus für ein bestimmtes Problem gibt. Wie später im Abschnitt [[Suchen#Sortieren_als_Suchproblem|Sortieren als Suchproblem]] gezeigt wird, ist das Sortieren eines Arrays durch paarweise Vergleiche von Elementen immer mindestens von der Komplexität <math> \Omega(N\cdot \ln N) </math>, was konkret bedeutet, dass kein Sortieralgorithmus, der nach diesem Prinzip arbeitet, jemals eine geringere Komplexität als beispielsweise Merge-Sort haben wird. Natürlich kann man den entsprechenden Sortieralgorithmus, also Merge-Sort zum Beispiel, unter Umständen noch optimieren, aber die Komplexität wird erhalten bleiben. Mit diesem Wissen kann man sich viel (vergebliche) Arbeit sparen.

===<math>\Theta</math>- Notation===

<math>f(N) \in \Theta(g(N))</math> ist eine scharfe Abschätzung der asymptotischen Komplexität einer Funktion f.

Damit dies gilt, muss <math>f(N) \in \mathcal{O}(g(N))</math> und ''gleichzeitig'' <math>f(N) \in \Omega(g(N))</math> erfüllt sein.

Dies ist natürlich auch die beste Abschätzung der asymptotischen Komplexität einer Funktion f. Formal bedeutet <math>f(N) \in \Theta(g(N))</math> dass es zwei Konstanten <math> c_1 </math> und <math> c_2 </math>, beide größer als Null, gibt, so dass für alle <math> N \geq N_0 </math> gilt:

<math> c_1 \cdot g(N) \leq f(N) \leq c_2 \cdot g(N) </math>.

In der Praxis wird manchmal statt der <math>\Theta</math>-Notation auch dann die <math>\mathcal{O}</math>-Notation benutzt, wenn eine scharfe Schranke ausgedrückt werden soll. Dies ist zwar formal nicht korrekt, aber man kann die intendierte Bedeutung meist aus dem Kontext erschließen.

== Komplexitätsvergleich zweier Algorithmen ==

In diesem Abschnitt wollen wir der Frage nachgehen, wie ein formaler Beweis für die Behauptung <math> f(N) \in \mathcal{O}(g(N))</math> geschehen kann. Hierbei werden zwei Beweismethoden vorgestellt werden, und zwar der '''Beweis über die Definition der Komplexität''' sowie der '''Beweis durch Dividieren'''.

===Beweis über die Definition der asymptotischen Komplexität===

Die Definition der asymptotischen Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> war:

Es gibt eine Konstante <math> c > 0 </math>, so dass <math> f(N) \le c \cdot g(N) </math> für <math> N \ge N_0 </math> erfüllt ist.

Um also die die asymptotische Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> zu beweisen, muss man die oben erwähnten Konstanten c und <math> N_0 </math> finden, so dass

<math> f(N) \leq c \cdot g(N) </math> für alle <math> N \ge N_0 </math> erfüllt ist.

Dies geschieht zweckmäßigerweise mit dem Beweisprinzip der ''vollständigen Induktion''. Hierbei ist zu zeigen, dass
# <math> f(N_0) \leq g(N_0) </math> für die eine zu bestimmende Konstante <math> N_0 </math> gilt (''Induktionsanfang'') und
# falls <math> f(N) \leq g(N) </math>, dann auch <math> f(N+1) \leq g(N+1) </math> (''Induktionsschritt'') gilt.

===Beweis durch Dividieren===

Hierbei wählt man eine Konstante c und zeigt, dass <math> \lim_{N \rightarrow \infty} \frac{f(N)}{c \cdot g(N)} \leq 1 </math> gilt (für die O-Notation, bei Ω-Notation gilt entsprechend <math>\geq 1 </math>). Man kann dies auch als alternative Definition der Komplexität verwenden.

Als Beispiel betrachten wir die beiden Funktionen <math> f(N) = N \,\lg N </math> und <math> g(N) = N^2 </math> und wollen zeigen, dass <math>f(N) \in \mathcal{O}(g(N))</math> gilt.

Als Konstante c wählen wir <math> c = 1 </math>

<math> \lim_{N \rightarrow \infty} \frac{f(N)}{g(N)} = \lim_{N \rightarrow \infty} \frac{\lg N}{N} = \frac{\infty}{\infty} </math>

Unbestimmte Ausdrücke der Form
<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} </math>,
in denen sowohl <math> f(x) </math> als auch <math> g(x) </math> mit <math> x \rightarrow x_0 </math> gegen Null oder gegen Unendlich streben, kann man manchmal mit den Regeln von [http://de.wikipedia.org/wiki/L%27Hospital%27sche_Regel ''l'Hospital''] berechnen. Danach darf man die Funktionen f und g zur Berechnung des unbestimmten Ausdrucks durch ihre k-ten Ableitungen ersetzen:

<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} = \lim_{x \rightarrow x_0} \frac{f^{(k)}(x)}{g^{(k)}(x)} </math>

In unserem Fall verwenden wir die erste Ableitung und erhalten:
<math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)} = \lim_{N \rightarrow \infty} \frac{1/N}{1} \rightarrow 0 </math>

Damit wurde <math>f(N) \in \mathcal{O}(g(N))</math>, also <math>N \lg N \in \mathcal{O}(N^2)</math> gezeigt.

Man beachte hierbei, dass <math>N \lg N \in \mathcal{O}(N^2)</math> keine enge Grenze für die Komplexität von <math>N \,\lg N</math> darstellt, da der Grenzwert <math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)}\, </math> gegen 0 und nicht gegen eine von Null verschiedene Konstante strebt. In diesem Fall haben wir die Komplexität von <math>N \cdot \lg N </math> also nur nach oben abschätzen können.

===Beispiel für den Komplexitätsvergleich: Gleitender Mittelwert (Running Average)===

Wir berechnen für ein gegebenes Array <tt>a</tt> einen gleitenden Mittelwert über <tt>k</tt> Elemente: 
::<math>r_i = \frac{1}{k} \sum_{j=i-k+1}^i a_j</math> 
Das heisst, für jedes <tt>i</tt> mitteln wir die letzten <tt>k</tt> Elemente von <tt>a</tt> und schreiben das Ergebnis in <tt>r[i]</tt>. Diese Operation ist z.B. bei Börsenkursen wichtig: Neben dem aktuellen Kurs für jeden Tag wird dort meist auch der gleitende Mittelwert der letzten 30 Tage sowie der letzten 200 Tage angegeben. In diesen Mittelwerten erkennt man besser die langfristige Tendenz, weil die täglichen Schwankungen herausgemittelt werden. Wir nehmen außerdem an, dass
* Array-Zugriff hat eine Komplexität von O(1)
* <math>k \ll N</math>, d.h. <math>N-k\approx N</math>.

Die beiden folgenden Algorithmen berechnen die Mittelwerte auf unterschiedliche Art. Der linke folgt der obigen Definition durch eine Summe, während der rechte inkrementell arbeitet: Man kann den Bereich der <tt>k</tt> letzten Werte als Fenster betrachten, das über das Array <tt>a</tt> geschoben wird. Schiebt man das Fenster ein Element weiter, fällt links ein Element heraus, und rechts kommt eins hinzu. Man muss also nicht jedes Mal die Summe neu berechnen, sondern kann den vorigen Wert aktualisieren. Wir werden sehen, dass dies Folgen für die Komplexität des Algorithmus hat.

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1: O(N * k)
! Komplexität
! Version 2: O(N)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|
<tt>for i in range(k):</tt>
|
'''<center>O(k)</center>'''
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|
:: <tt>r[k-1] += a[i]</tt>
|
'''<center>O(1)</center>'''
|-
|
6.
|
:::: <tt>r[j] += a[i]</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(k, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|
:: <tt>r[j] = (a[j] - a[j-k] + r[j-1])</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(len(a)):</tt>
|
'''<center>O(N)</center>'''
|-
|
9.
|

|

|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
10.
|

|

|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Wir zeigen unten dass Version 2 eine geringere Komplexität besitzt, obwohl sie mehr Zeilen benötigt.

Wir haben in der Tabelle die Komplexität jeder Zeile für sich angegeben. Einfache Anweisungen (Berechnungen, Lese- und Schreibzugriffe auf das Array, Zuweiseungen) haben konstante Komplexität, die Komplexität des Schleifenkopfes allein (also der <tt>for</tt>-Anweisung ohne den eingerückten Schleifenkörper) entspricht der Anzahl der Durchläufe. Wir müssen jetzt noch die Verschachtelung der Schleifen und die Nacheinanderausführung von Anweisungen berücksichtigen.

====Berechnung der Komplexität von Version 1====

(Wiederholung der Rechenregeln: siehe Abschnitt [[Effizienz#O-Notation|O-Notation]])

Wir betrachten zunächst die innere Schleife (Zeilen 5 und 6 von Version 1):

Der Schleifenkopf (Zeile 5) hat die Komplexität <math>\mathcal{O}(k)</math>, weil die Schleife k-mal durchlaufen wird. Der Schleifenkörper (Zeile 6) hat die Komplexität <math>\mathcal{O}(1)</math>. Nach der Verschachtelungsregel müssen wir die beiden Komplexitäten multiplizieren, und es ergibt sich:

::<math>\mathcal{O}(k)\cdot\mathcal{O}(1) = \mathcal{O}(k\cdot 1)=\mathcal{O}(k)</math>

Wir betrachten nun die äußere Schleife. Der Schleifenkopf (Zeile 4) wird (N-k)-mal durchlaufen und hat somit eine Komplexität von <math>\mathcal{O}(N)</math>. Der Schleifenkörper (Zeilen 5 bis 7) besteht aus der inneren Schleife (Zeilen 5 und 6) mit der gerade berechneten Komplexität <math>\mathcal{O}(k)</math> sowie einer einfachen Anweisung (Zeile 7) mit Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel wird die Komplexität des Schleifenkörpers durch Addition berechnet:

::<math>\mathcal{O}(k)+\mathcal{O}(1) = \mathcal{O}(\max(k,1)) = \mathcal{O}(k)</math>

Die Komplexität der gesamten äußeren Schleife erhalten wir nach der Verschachtelungsregel wieder durch multiplizieren:

::<math>\mathcal{O}(N)\cdot\mathcal{O}(k) = \mathcal{O}(N\cdot k)</math>

Die übrigen Schritte des Algorithmus werden einfach nacheinander ausgeführt, so dass sie ebenfalls nach der Sequenzregel behandelt werden. Wir erhalten

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(N\cdot k)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,N\cdot k,1)) = \mathcal{O}(N\cdot k)</math>

Der gesamte Algorithmus hat also die Komplexität <math>\mathcal{O}(N\cdot k)</math>.

====Berechnung der Komplexität von Version 2====

Hier gibt es nur einfache Schleifen ohne Verschachtelung. Da der Schleifenkörper jeder Schleife nur einfache Anweisungen der Komplexität <math>\mathcal{O}(1)</math> enthält, ergibt sich die Komplexität der Schleifen nach der Verschachtelungsregel als

::<math>\mathcal{O}(X)\cdot\mathcal{O}(1) = \mathcal{O}(X\cdot 1)=\mathcal{O}(X)</math>

wobei <math>\mathcal{O}(X)</math> die Komplexität des jeweiligen Schleifenkopfes ist. Wir erhalten also für Zeilen 4 und 5: <math>\mathcal{O}(k)</math>, Zeilen 6 und 7: <math>\mathcal{O}(N)</math>, Zeilen 8 und 9: <math>\mathcal{O}(N)</math>. Die Hintereinanderausführung wird nach der Sequenzregel behandelt:

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(k)+\mathcal{O}(N)+\mathcal{O}(N)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,k,N,N,1)) = \mathcal{O}(N)</math>

Dieser Algorithmus hat also nur die Komplexität <math>\mathcal{O}(N)</math>.

====Fazit====

Obwohl Version 2 mehr Schritte benötigt hat sie eine geringere Komplexität, da die for-Schleifen nicht wie bei Version 1 verschachtelt/untergeordnet sind. Bei verschachtelten for-Schleifen muss die Multiplikationsregel angewendet werden → höhere Komplexität.

Die gerade berechnete Komplexität gilt aber nur unter der Annahme, dass Array-Zugriffe konstante Komplexität <math>\mathcal{O}(1)</math> besitzen. Wenn dies nicht der Fall ist, kann sich die Komplexität des Algorithmus drastisch verschlechtern.

{| border="1" cellspacing="0" cellpadding="5"
|Allgemein gilt: 
Algorithmen-Analysen beruhen auf der Annahme, dass Zugriffe auf die Daten optimal schnell sind, dass heißt, dass die für den jeweiligen Algorithmus am besten geeignete Datenstruktur verwendetet wird. → Ansonsten: Komplexitätsverschlechterung!
|}
 

====Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur====

Wir verwende im Mittelwert-Algorithmus eine verkettete Liste anstelle des Eingabe-Arrays <tt>a</tt>. Wir benötigen dazu eine Funktion, die das j-te Element der Liste zurückgibt. Wie üblich ist die Liste mit Hilfe einer Knotenklasse implementiert:
class Node:
def __init__(self, data):
self.data = data
self.next = None

Die Listenklasse selbst hat ein Feld <tt>head</tt>, das eine Referenz auf den ersten Knoten speichert, und jeder Knoten speichert im Feld <tt>next</tt> eine Referenz auf seinen Nachfolger. Um zum j-ten Element zu gelangen, muss man die Liste sequenziell durchlaufen
def get_jth(list, j):
r = list.head
while j > 0:
r = r.head
j -= 1
return r.data
Die Komplexität dieser Funktion ist offensichtlich <math>\mathcal{O}(j)</math> (Komplexitätsberechnung wie oben). Wir setzen jetzt bei Version 1 des Mittelwert-Algorithmus diese Funktion in Zeile 6 anstelle des Indexzugriffs <tt>a[i]</tt> ein (nur in dieser Zeile wird auf die Elemente des Arrays zugegriffen). Wir erhalten folgende Implementation (die Änderungen sind rot markiert):

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1 mit Liste: O(N * k)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|-
|
6.
|
:::: <tt>r[j] += get_jth(a, i)</tt>
|
'''<center>O(i)</center>'''
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Der Aufruf der Funktion <tt>get_jth</tt> ist jetzt gleichbedeutend mit einer dreifach verschachtelten Schleife (weil <tt>get_jth</tt> ja eine zusatzliche Schleife enthält). Die Anzahl der Operationen in Zeile 4 bis 6 ist jetzt

::<math>f(N,k)=\sum_{j=k-1}^{N-1}\,\sum_{i=j-k+1}^j\,\mathcal{O}(i)</math>

wobei das <math>\mathcal{O}(i)</math> die neue Schleife durch Verwendung der Liste repräsentiert. Mit Mathematica-Hilfe [http://www.wolfram.com/] lässt sich diese Summe exakt ausrechnen

::<math>f(N,k)=\frac{1}{2}(k N^2-k^2 N+k^2-k)\in \mathcal{O}(k N^2)</math>

Die Komplexitätsberechnung erfolgte dabei nach der Regel für Polynome unter Beachtung von <math>k \ll N</math>.

====Fazit:====

Die Komplexität von Version 1 mit einer verketteten Liste wäre O(N2 * k)
'''→ Die richtige Datenstruktur ist wichtig, da es sonst zu einer Komplexitätsverschlechterung kommen kann!'''

Auf Version 2 unseres Running Average-Beispiels hätte eine verkettete Liste allerdings keine Auswirkungen, da die inkrementelle Berechnung der Summen in Zeile 7 weiterhin möglich ist (bei geschickter Implementation!) und somit Version 2 immer noch eine Komplexität von O(N) hätte.

==Amortisierte Komplexität==

Bis jetzt wurde die Komplexität nur im schlechtesten Fall (Worst Case) betrachtet. Bei einigen Operationen schwankt die Komplexität jedoch sehr stark, wenn man sie mehrmals hintereinander ausführt, und der schlechteste Fall kommt nur selten vor. Dann ist es sinnvoll, die amortisierte Komplexität zu betrachten, die sich mit der durchschnittlichen Komplexität über viele Aufrufe der selben Operation beschäftigt.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse Wikipedia: Amortisierte Laufzeitanalyse]]

===Beispiel: Inkrementieren von Binärzahlen===

Frage: Angenommen, das Umdrehen eines Bits einer Binärzahl verursacht Kosten von 1 Einheit. Wir erzeugen die Folge der natürlichen Zahlen in Binärdarstellung durch sukzessives Inkrementieren, von Null beginnend. Bei jeder Inkrementierung werden einige Bits verändert, aber diese Zahl (und damit die Kosten der Inkrementierungen) ''schwanken'' sehr stark. Wir fragen jetzt, was eine Inkrementierung im Durchschnitt kostet?

Um diese Durchschnittskosten zu berechnen, bezahlen wir bei jeder Inkrementierung 2 Einheiten. Wenn davon nach Abzug der Kosten der jeweiligen Operation noch etwas übrig bleibt, wird der Rest dem Guthaben zugeschrieben. Umgekehrt wird ein eventueller Fehlbetrag (wenn eine Inkrementierung mehr als 2 Bits umdreht) aus dem Guthaben gedeckt. Dadurch werden die ansonsten großen Schwankungen der Kosten ausgeglichen:
:: Kosten < Einzahlung → es wird gespart
:: Kosten = Einzahlung → Guthaben bleibt unverändert
:: Kosten > Einzahlung → Guthaben wird für die Kosten verbraucht

{| border="1" cellspacing="0" cellpadding="5"
!Schritte
!Zahlen
!Kosten 
(Anzahl der geänderten Bits)
! Einzahlung
!Guthaben = 
altes Guthaben + Einzahlung - Kosten
|-
|1.
|00001
|1
|'''2'''
|'''1'''
|-
|2.
|00010
|2
|'''2'''
|'''1'''
|-
|3.
|00011
|1
|'''2'''
|'''2'''
|-
|4.
|00100
|3
|'''2'''
|'''1'''
|-
|5.
|00101
|1
|'''2'''
|'''2'''
|-
|6.
|00110
|2
|'''2'''
|'''2'''
|-
|7.
|00111
|1
|'''2'''
|'''3'''
|-
|8.
|01000
|4
|'''2'''
|'''1'''
|-
|}

Die Kosten ergeben sich aus der Anzahl der Ziffern die von 1 nach 0, bzw. von 0 nach 1 verändert werden

Rechnung:

1. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

2. Schritt: Kosten: 2 = Einzahlung: 2 
:: → es wird nicht gespart 
:: → Guthaben bleibt so wie es ist 

3. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

4. Schritt: Kosten: 3 > Einzahlung: 2 
:: → es wird eine 1 vom Guthaben genommen um die Kosten zu zahlen 

usw.

Man erkennt, dass vor teuren Operation (Wechsel von 3 auf 4 bzw. von 7 auf 8) genügend Guthaben angespart wurde, um die Kosten zu decken. Das Guthaben geht bei diesen Operationen immer wieder auf 1 zurück, aber es wird nie vollständig verbraucht (Dies kann natürlich auch mathematisch exakt bewiesen werden, wie wir es unten am Beispiel des dynamische Arrays zeigen). Wir schließen daraus, dass die durchschnittlichen oder '''amortisierten Kosten''' einer Inkrementierungsoperation gleich 2 sind.

Zum Weiterlesen: [[http://de.wikipedia.org/wiki/Account-Methode Wikipedia Account-Methode]]

====Fazit====
Die amortisierte Komplexität beschäftigt sich mit dem Durchschnitt aller Operation im ungünstigsten Fall. Operationen mit hohen Kosten, die aber nur selten ausgeführt werden, fallen bei der amortisierten Komplexität nicht so ins Gewicht. Bei Algorithmen, die gelegentlich eine "teure" Operation benutzen, ansonsten jedoch "billige" Operationen aufrufen, kann die amortisierte Komplexität niedriger sein als die Komplexität im schlechtesten (Einzel-)Fall.

In unserem Beispiel fallen die teuren Einzelschritte (z.B. 4. und 8. Schritt) bei den amortisierten Kosten nicht so ins Gewicht, da wir die Kosten aus unserem Guthaben mitbezahlen können. Das Guthaben ist immer groß genug, weil jeder zweite Aufruf eine billige Operation ist, die nur ein Bit umdreht und somit das Ansparen ermöglicht. Diese Betrachtung zeigt, dass die amortisierte (d.h. durchschnittliche) Komplexität des Algoithmus niedriger (nämlich konstant) ist als die Komplexität im schlechtesten Fall.

===Anwendung: Dynamisches Array===

Ein dynamisches Array hat die Eigenschaft, dass man effizient am Ende des Arrays neue Elemente anfügen kann, indem man die Länge des Arrays entsprechend vergrößert (siehe Übung 1). Die Analyse der amortisierten Komplexität der Anfüge-Operation zeigt uns, wie man das Vergrößern des Arrays richtig implementiert, damit die Operation wirklich effizient abläuft.

==== Ineffiziente naive Lösung ====

Wenn wir an ein Array ein Element anhängen wollen, müssen wir neuen Speicher allokieren, der die gewünschte Länge hat. Die Werte aus dem alten Array müssen dann in den neuen Speicher umkopiert werden. Danach kann das neue Element hinten angefügt werden, weil wir im neuen Array bereits Speicher für dieses Element reserviert haben. Bei der naiven Implementation des dynamischen Arrays wiederholt man dies bei jeder Anfügeoperation. Für die Analyse nehmen wir an, dass das Kopieren eines Elements konstante Zeit O(1) erfordert, ebenso das Einfügen eines neuen Elements auf in eine noch unbenutzte Speicherposition.

Naives Anhängen eines weiteren Elements an ein Array:

{| border="1" cellspacing="0" cellpadding="5" align="right"
!Schritte
|'''Array'''
(wie es nach jedem Schritt aussieht)
!Komplexität
|-
|<center>altes Array (N=4)</center>
|<center>[0,1,2,3]</center>
|<center>-</center>
|-
|1. neuer Speicher für    (N+1) Elemente
|<center>[None,None,None,None,None]</center>
|<center>O(N+1) = '''O(N)'''</center>(wenn der Speicher initialisiert wird (hier auf <tt>None</tt>), sonst O(1))
|-
|2. Kopieren
|<center>[0,1,2,3,None]</center>
|<center>'''O(N)'''</center>
|-
|3. append von "x"
|<center>[0,1,2,3,'x']</center>
|<center>'''O(1)'''</center>
|-
|}

altesArray = [0,1,2,3] 
altesArray.append('x')

1. Es wird ein neues Array der Größe N+1 erzeugt 
2. Die N Datenelemente aus dem alten Array werden in das neue Array kopiert 
Das sind N Operationen der Komplexität O(1), also ein Gesamtaufwand von O(N). 
3. 'x' wird mit Aufwand O(1) an die letzte Stelle des neuen Arrays geschrieben

Additionsregel: 
O(N) + O(1) ∈ O(N)

Folgerung:

Bei der naiven Methode erfordert jede Anfügung einen Aufwand O(N) (wobei N die derzeitige Arraygröße ist). Dies ist nicht effizient.

====Effiziente Lösung durch Verdoppeln der Kapazität====

Offensichtlich kommt man nicht darum heraum, den Inhalt des alten Arrays zu kopieren, wenn der allokierte Speicher voll ist. Der Trick für die effiziente Implementation der Anfügeoperation besteht darin, das Kopieren so selten wie möglich durchzuführen, also nicht wie in der naiven Lösung bei jeder Anfügeoperation. Hier kommt die amortisierte Komplexität ins Spiel: Ab und zu gibt es eine teure Anfügeoperation (wenn nämlich kopiert werden muss), aber wenn man den durchschnittlichen Aufwand über viele Anfügungen betrachtet, ist die Operation effizient. Der teure Fall wird sozusagen "herausgemittelt".

Um nur selten kopieren zu müssen, werden beim dynamischen Array mehr Speicherelemente reserviert als zur Zeit benötigt werden (in der naiven Lösung wurde dagegen immer nur Speicher für ein einziges neues Element reserviert). Wir unterscheiden deshalb

:<tt>capacity</tt> = Anzahl der allokierten Speicherzellen, d.h. der möglichen Elemente, die in das Array passen 
:<tt>size</tt> = Anzahl der Elemente, die im Array zur Zeit gespeichert sind 

Die Daten selbst werden in einem statischen Array gespeichert:
:<tt>data</tt> = statisches Array der Größe <tt>capacity</tt> 

Die folgende intuitive Abschätzung zeigt, dass es sinnvoll ist, die Größe des allokierten Speichers jeweils zu verdoppeln. Wir starten bei einem Array der Größe <tt>size = capacity</tt> = N. Da der verfügbare Speicher voll ist, müssen wir bei der nächsten Anfügung die N vorhandenen Elemente in ein neues Array der Länge <tt>new_capacity</tt> kopieren (Aufwand <math>N\cdot O(1)</math>). Danach können wir K Elemente billig einfügen (Aufwand <math>K\cdot O(1)</math>), wobei
:K = <tt>new_capacity - capacity</tt>
die Anzahl der nach dem Kopieren noch unbenutzen Speicherzellen ist. Der durchschnittliche Aufwand für diese K Einfügungen ist somit
:<math>\bar T = \frac{N \cdot O(1) + K \cdot O(1)}{K}=\frac{N+K}{K}\cdot O(1)</math>
Damit die mittlere Zeit in O(1) sein kann, muss der Quotient <math>(N+K)/K</math> eine Konstante sein. Wir setzen <math>K = a N</math> und erhalten:
:<math>\bar T = \frac{(a+1)N}{a N}\cdot O(1)=\frac{a+1}{a}\cdot O(1)</math>
Der amortisierte Aufwand über K Einfügungen ist also konstant, wenn <math>a</math> eine (kleine) von N unabhängige Zahl ist. Typischerweise wählt man
:<math>a = 1</math>
und mit <math>K = 1\cdot N</math> ergibt sich
:<tt>new_capacity = capacity</tt> + N = <tt>2 * capacity</tt>

Die Vorgehensweise beim Zufügen eines neuen Elements im Fall <tt>size == capacity</tt> ist also
* capacity wird verdoppelt 
: <tt>neue capacity = 2 * alte capacity</tt>
: (allgemein genügt es auch, wenn capacity um einen bestimmten Prozentsatz vergrößert wird,
:: <tt>neue capacity = alte capacity * c</tt>
: mit c > 1, z.B. c = 1.2, das entspricht oben der Wahl <math>a = 0.2</math>)
* ein neues statisches Array der Größe 'neue capacity' wird erzeugt
* das alte Array wird ins neue kopiert und danach freigegeben
* das anzufügende Element wird ins neue Array eingefügt
Umgekehrt geht man beim Entfernen des ''letzten'' Array-Elements vor. Normalerweise überschreibt man einfach das letzte Element mit <tt>None</tt> und dekrementiert <tt>size</tt>. Wird dadurch das Array zu klein (üblicherweise <tt>size < capacity / 4</tt>), wird die Kapazität halbiert, genauer:
* ein neues Array mit 
: <tt>neue capacity = alte capacity / 2 </tt>
: wird angelegt (bzw. mit
:: <tt>neue capacity = alte capacity / c </tt>
: wenn ein anderer Vergrößerungsfaktor verwendet wird)
* das alte Array wird ins neue kopiert und danach freigegeben

'''Folge:''' Die Kosten für das Vergrößern/Verkleinern der Kapazität werden amortisiert über viele Einfügungen, die kein Vergrößern erfordern. Die Operation <tt>append</tt> besitzt amortisierte Komplexität O(1). Im folgenden Abschnitt zeigen wir dies mathematisch exakt mit der Potentialmethode.

====Komplexitätsanalyse des dynamischen Arrays mit Potentialmethode====

Durchschnitt der Gesamtkosten für N-maliges append = <math>\frac{1}{N} \sum_{i = 1}^N Kosten(i)</math>. Zur Analyse der amortisierten Komplexität wird ein Potential 
::Φi = 2*sizei - capacityi 
eingeführt, wobei das Array nach dem i-ten Einfüge-Schritt die Größe sizei und die Kapizität capacityi hat. Wir nehmen vereinfachend an, dass es keine Löschoperationen gibt. Dann gilt nach dem i-ten Schritt jeweils
::Φi = 2*i - capacityi 

Fall 1: Array ist nicht voll 
Es wird kein Umkopieren benötigt, da das Array noch nicht voll ist 
→ sizei-1 < capacityi-1 
→ capacityi == capacityi-1

Kosten: 1 (für Einfügen des neuen Elements) 
Potenzial vor append: Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append: Φi = 2i - capacityi-1 

amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = 1 + (2i - capacityi-1) - [2(i - 1) - capacityi-1]
::::: = 1 + 2i - capacityi-1 - 2i + 2 + capacityi-1
::::: = 1 + <del>2i</del> - <del>capacityi-1</del> - <del>2i</del> + 2 + <del>capacityi-1</del>
::::: = 1 + 2
::::: = 3 = O(1) → konstant

Fall 2: Array ist voll 
Vor dem i-ten append muss umkopiert werden 
→ sizei-1 == capacityi-1 == i-1 
→ Allokieren eines neuen statischen Arrays mit verdoppelter Kapazität notwendig, also capacityi == 2*capacityi-1

Kosten: (i-1) + 1 (für Umkopieren und Einfügen des neuen Elements) 
Potenzial vor append = Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append = Φi = 2i - 2 capacityi-1 
amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = ((i - 1) + 1) + 2i - 2 capacityi-1 - [2(i-1) - capacityi-1]
::::: = i + <del>2i</del> - 2 capacityi-1 - <del>2i</del> + 2 - capacityi-1
::::: = i + 2 - capacityi-1
::::: = i + 2 - (i - 1) (da capacityi-1 = i-1)
::::: = 3 = O(1) → konstant

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine amortisierte Komplexität von 3 Einheiten hat, also <tt>append</tt> ∈ O(1)'''. Diese Operation kann deshalb gefahrlos in der inneren Schleife eines Algorithmus benutzt werden.

==== Beispiel für 9 Einfügeoperationen ====

{| border="1" cellspacing="0" cellpadding="5"
!Array 
(wie es aussehen könnte)
!size
!capacity
!Kosten für append (einschließlich Umkopieren)
!Summe Kosten
!Durchschnittskosten
!Φi = 2 * size - capacity 
(i = size)
!Potenzialdifferenz 
Δ Φi = Φi - Φi-1
!amortisierte Kosteni 
= Kosteni + Δ Φi
|-
| <center>[None]</center>
| <center>0</center>
| <center>1</center>
| <center>-</center>
| <center>-</center>
| <center>-</center>
| <center>-1</center>
| <center>-</center>
| <center>-</center>
|-
| <center>[a]</center><center>Array ist voll!</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b]</center><center>Array ist voll!</center>
| <center>2</center>
| <center>2</center>
| <center>1 + 1</center>
| <center>3</center>
| <center>3/2</center>
| <center>2</center>
| <center>1</center>
| <center>3</center>
|-
| <center>[a,b,c,None]</center>
| <center>3</center>
| <center>4</center>
| <center>2 + 1</center>
| <center>6</center>
| <center>6/3</center>
| <center>2</center>
| <center>0</center>
| <center>3</center>
|-
| <center>[a,b,c,d]</center><center>Array ist voll!</center>
| <center>4</center>
| <center>4</center>
| <center>1</center>
| <center>7</center>
| <center>7/4</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,None,None,None]</center>
| <center>5</center>
| <center>8</center>
| <center>4 + 1</center>
| <center>12</center>
| <center>12/5</center>
| <center>2</center>
| <center>-2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,None,None]</center>
| <center>6</center>
| <center>8</center>
| <center>1</center>
| <center>13</center>
| <center>13/6</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,None]</center>
| <center>7</center>
| <center>8</center>
| <center>1</center>
| <center>14</center>
| <center>14/7</center>
| <center>6</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h]</center><center>Array ist voll!</center>
| <center>8</center>
| <center>8</center>
| <center>1</center>
| <center>15</center>
| <center>15/8</center>
| <center>8</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h,j,None,None,None, 
None,None,None,None]</center>
| <center>9</center>
| <center>16</center>
| <center>8 + 1</center>
| <center>24</center>
| <center>24/9</center>
| <center>2</center>
| <center>-6</center>
| <center>3</center>
|-
|}

Die durchschnittlichen Kosten betragen stets etwa 2 Einheiten, schwanken allerdings so, dass nicht unmittelbar ersichtlich ist, ob dies für sämtliche Einfügeoperationen gilt. Die amortisierte Komplexität, die mit Hilfe des Potentials berechnet wird, ist hingegen konstant 3, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

[[Suchen|Nächstes Thema]]

Effizienz

2012-07-27T16:02:47Z

Ukoethe: /* Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur */

Bei der Diskussion von Effizienz müssen wir zwischen der Laufzeit eines Algorithmus auf einem bestimmten System und seiner prinzipiellen Leistungsfähigkeit (Algorithmenkomplexität) unterscheiden. Der Benutzer ist natürlich vor allem an der Laufzeit interessiert, denn diese bestimmt letztendlich seine Arbeitsproduktivität. Ein Softwaredesigner hingegen muss eine Implementation wählen, die auf verschiedenen Systemen und in verschiedenen Anwendungen schnell ist. Für ihn sind daher auch Aussagen zur Algorithmenkomplexität sehr wichtig, um den am besten geeigneten Algorithmus auszuwählen.

== Laufzeit ==

Aus Anwendersicht ist ein Algorithmus effizient, wenn er die in der Spezifikation verlangten Laufzeitgrenzen einhält. Ein Algorithmus muss also nicht immer so schnell wie möglich sein, sondern so schnell wie nötig. Dies führt in verschiedenen Anwendungen zu ganz unterschiedliche Laufzeitanforderungen:

* Berechnen des nächsten Steuerkommandos für eine Maschine: ca. 1/1000s
* Berechnen des nächsten Bildes für eine Videopräsentation (z.B. Dekompression von MPEG-kodierten Bildern): ca. 1/25s
: Geringere Bildraten führen zu ruckeligen Filmen.
* Sichtbare Antwort auf ein interaktives Kommando (z.B. Mausklick): ca. 1/2s
: Wird diese Antwortzeit überschritten, vermuten viele Benutzer, dass der Mausklick nicht funktioniert hat, und klicken nochmals, mit eventuell fatalen Folgen. Wenn ein Algorithmus notwendigerweise länger dauert als 1/2s, sollte ein Fortschrittsbalken angezeigt werden.
* Wettervorhersage: muss spätestens am Vorabend des vorhergesagten Tages beendet sein

===Laufzeitvergleich===

Da die Laufzeit für den Benutzer ein so wichtiges Kriterium ist, werden häufig Laufzeitvergleiche durchgeführt. Deren Ergebnisse hängen allerdings von vielen Faktoren ab, die möglicherweise nicht kontrollierbar sind:
* Geschwindigkeit und Anzahl der Prozessoren
* Auslastung des Systems
* Größe des Hauptspeichers und Cache, Geschwindigkeit des Datenbus
* Qualität des Compilers/Optimierers (ist der Compiler für die spezielle Prozessor-Architektur optimiert?)
* Geschick des Programmierers
* Daten (Beispiel Quicksort: Best case und worst case [vorsortierter Input] stark unterschiedlich)
All diese Faktoren sind untereinander abhängig. Laufzeitvergleiche sind daher mit Vorsicht zu interpretieren.
Generell sollten bei Vergleichen möglichst wenige Parameter verändert werden, z.B.
* gleiches Programm (gleiche Kompilierung), gleiche Daten, andere Prozessoren
oder
* gleiche CPU, Daten, andere Programme (Vergleich von Algorithmen)
Zur Verbesserung der Vergleichbarkeit gibt es standardisierte [http://en.wikipedia.org/wiki/Benchmark_(computing) Benchmarks], die bestimmte Aspekte eines Systems unter möglichst realitätsnahen Bedingungen testen. Generell gilt aber: Durch Laufzeitmessung ist schwer festzustellen, ob ein Algorithmus ''prinzipiell'' besser ist als ein anderer. Dafür ist die Analyse der [[Effizienz#Algorithmen-Komplexität|Algorithmenkomplexität]] notwendig.

===Optimierung der Laufzeit===

Wenn sich herausstellt, dass ein bereits implementierter Algorithmus zu langsam läuft, geht man wie folgt vor:

# Man verwendet einen [http://en.wikipedia.org/wiki/Performance_analysis Profiler], um zunächst den Flaschenhals zu bestimmen. Ein Profiler ist ein Hilfsprogramm, das während der Ausführung eines Programms misst, wieviel Zeit in jeder Funktion und Unterfunktion verbraucht wird. Dadurch kann man herausfinden, welcher Teil des Algorithmus überhaupt Probleme bereitet. Donald Knuth gibt z.B. als Erfahrungswert an, dass Programme während des größten Teils ihrer Laufzeit nur 3% des Quellcodes (natürlich mehrmals wiederholt) ausführen [http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf]. Es ist sehr wichtig, diese 3% experimentell zu bestimmen, weil die Erfahrung zeigt, dass man beim Erraten der kritischen Programmteile oft falsch liegt. Man spricht dann von "[http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize premature optimization]", also von voreiliger Optimierung ohne experimentelle Untersuchung der wirklichen Laufzeiten, was laut Knuth "the root of all evil" ist. Der Python-Profiler wird in [http://docs.python.org/lib/profile.html Kapitel 25] der Python-Dokumentation beschrieben.
# Man kann dann versuchen, die kritischen Programmteile zu optimieren.
# Falls der Laufzeitgewinn durch Optimierung zu gering ist, muss man einen prinzipiell schnelleren Algorithmus verwenden, falls es einen gibt.

Einige wichtige Techniken der Programmoptimierung sollen hier erwähnt werden. Wenn man einen optimierenden Compiler verwendet, werden einige Optimierungen automatisch ausgeführt [http://en.wikipedia.org/wiki/Compiler_optimization]. In Python trifft dies jedoch nicht zu. Um den Sinn einiger Optimierungen zu verstehen, benötigt man Grundkenntnisse der Computerarchitektur.

;Elimination von redundantem Code: Es ist offensichtlich überflüssig, dasselbe Ergebnis mehrmals zu berechnen, wenn es auch zwischengespeichert werden könnte. Diese Optimierung wird von vielen automatischen Optimierern unterstützt und kommt im wesentlichen in zwei Ausprägungen vor:
:; common subexpression elimination: In mathematischen Ausdrücken wird ein Teilergebnis häufig mehrmals benötigt. Man betrachte z.B. die Lösung der quadratischen Gleichung <math>x^2+p\,x+q = 0</math>:
x1 = - p / 2.0 + sqrt(p*p/4.0 - q)
x2 = - p / 2.0 - sqrt(p*p/4.0 - q)
::Die mehrmalige Berechnung von Teilausdrücken wird vermieden, wenn man stattdessen schreibt:
p2 = - p / 2.0
r = sqrt(p2*p2 - q)
x1 = p2 + r
x2 = p2 - r
:; loop invariant elimination: Wenn ein Teilausdruck sich in einer Schleife nicht ändert, muss man ihn nicht bei jedem Schleifendurchlauf neu berechnen, sondern kann dies einmal vor Beginn der Schleife tun. Ein typisches Beispiel hierfür ist die Adressierung von Matrizen, die als 1-dimensionales Array gespeichert sind. Angenommen, wir speichern eine NxN Matrix <tt>m</tt> in einem Array <tt>a</tt> der Größe N2, so dass das Matrixelement <tt>mij</tt> durch <tt>a[i + j*N]</tt> indexiert wird. Wir betrachten die Aufgabe, eine Einheitsmatrix zu initialisieren. Ein nicht optimierter Algorithmus dafür lautet:
for j in range(N):
for i in range(N):
if i == j:
a[i + j*N] = 1.0
else:
a[i + j*N] = 0.0
::Der Ausdruck <tt>j*N</tt> wird hier in jedem Schleifendurchlauf erneut berechnet, obwohl sich <tt>j</tt> in der inneren Schleife gar nicht verändert. Man kann deshalb optimieren zu:
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
;Vereinfachung der inneren Schleife: Generell sollte man sich bei der Optimierung auf die innere Schleife eines Algorithmus konzentrieren, weil dieser Code am häufigsten ausgeführt wird. Insbesondere sollte man die Anzahl der Befehle in der inneren Schleife so gering wie möglich halten und teure Befehle vermeiden. Früher waren vor allem Floating-Point Befehle teuer, die man oft durch die schnellere Integer-Arithmetik ersetzt hat, falls dies algorithmisch möglich war (diesen Rat findet man noch oft in der Literatur). Heute hat sich die Hardware so verbessert, dass im Allgemeinen nur noch die Floating-Point Division deutlich langsamer ist als die anderen Operatoren. Im obigen Beispiel der quadratischen Gleichung ist es daher sinnvoll, den Ausdruck
p2 = -p / 2.0
:durch
p2 = -0.5 * p
:zu ersetzen. Dadurch ersetzt man eine Division durch eine Multiplikation und spart außerdem das Negieren von <tt>p</tt>, da der Compiler direkt mit <tt>-0.5</tt> multipliziert.
;Ausnutzung der Prozessor-Pipeline: Moderne Prozessoren führen mehrere Befehle parallel aus. Dies ist möglich, weil jeder Befehl in mehrere Teilschritte zerlegt werden kann. Eine generische Unterteilung in vier Teilschritte ist z.B.:
:# Dekodieren des nächsten Befehls
:# Beschaffen der Daten, die der Befehl verwendet (aus Prozessorregistern, dem Cache, oder dem Hauptspeicher)
:# Ausführen des Befehls
:# Schreiben der Ergebnisse
:Man bezeichnet dies als die "[http://en.wikipedia.org/wiki/Instruction_pipeline instruction pipeline]" des Prozessors (heutige Prozessoren verwenden wesentlich feinere Unterteilungen). Prozessoren werden nun so gebaut, dass mehrere Befehle parallel, auf verschiedenen Ausführungsstufen ausgeführt werden. Wenn Befehl 1 also beim Schreiben der Ergebnisse angelangt ist, kann Befehl 2 die Hardware zum Ausführen des Befehls benutzen, während Befehl 3 seine Daten holt, und Befehl 4 soeben dekodiert wird. Unter bestimmten Bedingungen funktioniert diese Parallelverarbeitung jedoch nicht. Dies gibt Anlass zu Optimierungen:
:;Vermeiden unnötiger Typkonvertierungen: Der Prozessor verarbeitet Interger- und Floating-Point-Befehle in verschiedenen Pipelines, weil die Hardwareanforderungen sehr verschieden sind. Wird jetzt ein Ergebnis von Integer nach Floating-Point umgewandelt oder umgekehrt, muss die jeweils andere Pipeline warten, bis die erste Pipeline ihre Berechnung beendet. Es kann dann besser sein, Berechnungen in Floating-Point zu Ende zu führen, auch wenn sie semantisch eigentlich Integer-Berechnungen sind.
:;Reduzierung der Anzahl von Verzweigungen: Wenn der Code verzweigt (z.B. durch eine <tt>if</tt>- oder <tt>while</tt>-Anweisung), ist nicht klar, welcher Befehl nach der Verzweigung ausgeführt werden soll, bevor Stufe 3 der Pipeline die Verzweigungsbedingung ausgewertet hat. Bis dahin wären die ersten beiden Stufen der Pipeline unbenutzt. Moderne Prozessoren benutzen zwar ausgefeilte Heuristiken, um das Ergebnis der Bedingung vorherzusagen, und führen den hoffentlich richtigen Zweig des Codes spekulativ aus, aber dies funktioniert nicht immer. Man sollte deshalb generell die Anzahl der Verzweigungen minimieren. Als Nebeneffekt führt dies meist auch zu besser lesbarem, verständlicherem Code. Im Matrixbeispiel kann man
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
::durch
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
ersetzen. Die Diagonalelemente <tt>a[j + jN]</tt> werden jetzt zwar zweimal initialisiert (in der Schleife auf Null, dann auf Eins), aber durch Elimination der <tt>if</tt>-Abfrage wird dies wahrscheinlich mehr als ausgeglichen, zumal dadurch die innere Schleife wesentlich vereinfacht wurde.
;Ausnutzen des Prozessor-Cache: Zugriffe auf den Hauptspeicher sind sehr langsam. Deshalb werden stets ganze Speicherseiten auf einmal in den [http://en.wikipedia.org/wiki/Cache Cache] des Prozessors geladen. Wenn unmittelbar nacheinander benutzte Daten auch im Speicher nahe beieinander liegen (sogenannte "[http://en.wikipedia.org/wiki/Locality_of_reference locality of reference]"), ist die Wahrscheinlichkeit groß, dass die als nächstes benötigten Daten bereits im Cache sind und damit schnell gelesen werden können. Bei vielen Algorithmen kann man die Implementation so umordnen, dass die locality of reference verbessert wird, was zu einer drastischen Beschleunigung führt. Im Matrix-Beispiel ist z.B. die Reihenfolge der Schleifen wichtig. Für konstanten Index <tt>j</tt> liegen die Indizes <tt>i</tt> im Speicher hintereinander. Deshalb ist es günstig, in der inneren Schleife über <tt>i</tt> zu iterieren:
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
:Die umgekehrte Reihenfolge der Schleifen ist hingegen ungünstig
for i in range(N):
for j in range(N):
a[i + j*N] = 0.0
a[i + i*N] = 1.0
:Jetzt werden in der inneren Schleife stets N Datenelemente übersprungen. Besonders bei großem N muss man daher häufig den Cache neu füllen, was bei der ersten Implementation nicht notwendig war. (Außerdem verliert man hier die Optimierung <tt>jN = j*N</tt>, die jetzt nicht mehr möglich ist.)

Als Faustregel kann man durch Optimierung eine Verdoppelung der Geschwindigkeit erreichen (in Ausnahmefällen auch mehr). Benötigt man stärkere Verbesserungen, muss man wohl oder übel einen besseren Algorithmus oder einen schnelleren Computer verwenden.

== Algorithmen-Komplexität ==

Komplexitätsbetrachtungen ermöglichen den Vergleich der prinzipiellen Eigenschaften von Algorithmen unabhängig von einer Implementation, Umgebung etc.

Eine einfache Möglichkeit ist das Zählen der Aufrufe einer Schlüsseloperation. Beispiel Sortieren:
* Anzahl der Vergleiche
* Anzahl der Vertauschungen

=== Beispiel: Selection Sort ===

for i in range(len(a)-1):
max = i
for j in range(i+1, len(a)):
if a[j] < a[max]:
max = j
a[max], a[i] = a[i], a[max] # swap

*Anzahl der Vergleiche: Ein Vergleich in jedem Durchlauf der inneren Schleife. Es ergibt sich folgende Komplexität:
*:Ingesamt <math>\sum_{i=0}^{N-2} \sum_{j=i+1}^{N-1}1 = \frac{N}{2} (N-1) \!</math> Vergleiche.

*Anzahl der Vertauschungen (swaps): Eine Vertauschung pro Durchlauf der äußeren Schleife:
*:Insgesamt <math>N-1 \!</math> Vertauschungen

Die Komplexität wird durch die Operationen bestimmt, die am häufigsten ausgeführt werden, hier also die Anzahl der Vergleiche. Die Anzahl der Vertauschungen ist hingegen kein geeignetes Kriterium für die Komplexität von selection sort, weil der Aufwand in der inneren Schleife ignoriert würde.

=== Fallunterscheidung: Worst und Average Case ===

Die Komplexität ist in der Regel eine Funktion der Eingabegröße (Anzahl der Eingabebits, Anzahl der Eingabeelemente). Sie kann aber auch von der Art der Daten abhängen, nicht nur von der Menge, z.B. vorsortierte Daten bei Quicksort. Um von der Art der Daten unabhängig zu werden, kann man zwei Fälle der Komplexität unterscheiden:

* Komplexität im ungünstigsten Fall
*: Der ungünstigste Fall ist die Eingabe gegebener Länge, für die der Algorithmus am langsamsten ist. Der Nachteil dieser Methode besteht darin, dass dieser ungünstige Fall in der Praxis vielleicht gar nicht oder nur selten vorkommt, so dass sich der Algorithmus in Wirklichkeit besser verhält als man nach dieser Analyse erwarten würde. Beim Quicksort-Algorithmus mit zufälliger Wahl des Pivot-Elements müsste z.B. stets das kleinste oder größte Element des aktuellen Intervalls als Pivot-Element gewählt werden, was äußerst unwahrscheinlich ist.
* Komplexität im durchschnittlichen/typischen Fall
*: Der typische Fall ist die mittlere Komplexität des Algorithmus über alle möglichen Eingaben. Dazu muss man die Wahrscheinlichkeit jeder möglichen Eingabe kennen, und berechnet dann die mittlere Laufzeit über dieser Wahrscheinlichkeitsverteilung. Leider ist die Wahrscheinlichkeit der Eingaben oft nicht bekannt, so dass man geeignete Annahmen treffen muss. Bei Sortieralgorithmen können z.B. alle möglichen Permutationen des Eingabearrays als gleich wahrscheinlich angenommen werden, und der typische Fall ist dann die mittlere Komplexität über alle diese Eingaben. Oft hat man jedoch in der Praxis andere Wahrscheinlichkeitsverteilungen, z.B. sind die Daten oft "fast sortiert" (nur wenige Elemente sind an der falschen Stelle). Dann verhält sich der Algorithmus ebenfalls anders als vorhergesagt.

Wir beschränken uns in dieser Vorlesung auf die Komplexität im ungünstigseten Fall. '''Exakte''' Formeln für Komplexität sind aber auch dann schwer zu gewinnen, wie das folgende Beispiel zeigt:

=== Beispiele aus den Übungen (Gemessene Laufzeiten für Mergesort/Selectionsort) ===

* Mergesort: <math>\frac{0,977N\log N}{\log 2} + 0,267N-4.39 \!</math>
*: andere Lösung: <math>1140 N\log(N) - 1819N + 6413 \!</math>
* Selectionsort: <math>\frac{1}{2}N^2 - \frac{1}{2N} - 10^{-12} \!</math>
*: andere Lösung: <math>1275N^2 - 116003^N + 11111144 \!</math>

Aus diesen Formeln wird nicht offensichtlich, welcher Algorithmus besser ist.
Näherung: Betrachte nur '''sehr große Eingaben''' (meist sind alle Algorithmen schnell genug für kleine Eingaben). Dieses Vorgehen wird als '''Asymptotische Komplexität''' bezeichnet (N gegen unendlich).

=== Asymptotische Komplexität am Beispiel Polynom ===

Polynom: <math>a\,x^2+b\,x+c=p\!</math>

<math>x \!</math> sei die Eingabegröße, und wir betrachten die Entwicklung von <math>p \!</math> in Abhängigkeit von <math>x \!</math>.

* <math>x=0 \!</math>
*: <math>p=c \!</math>
* <math>x=1 \!</math>
*: <math>p=a+b+c \!</math>
* <math>x=1000 \!</math>
*: <math>p=1000000a+1000b+c \approx 1000000a\!</math>
* <math>x \to \infty \!</math>
*: <math>p \approx x^2a\!</math>

Für sehr große Eingaben verlieren also ''b'' und ''c'' immer mehr an Bedeutung, so dass am Ende nur noch ''a'' für die Komplexitätsbetrachtung wichtig ist.

== Landau-Symbole ==

Um die asymptotische Komplexität verschiedener Algorithmen miteinander vergleichen zu können, verwendet man die sogenannten [http://de.wikipedia.org/wiki/Landau-Symbole Landau-Symbole]. Das wichtigste Landau-Symbol ist <math>\mathcal{O}</math>, mit dem man eine ''obere Schranke'' <math>f \in \mathcal{O}(g)</math> für die Komplexität angeben kann.

Schreibt man <math>f \in \Omega(g)</math>, so stellt dies eine asymptotische ''untere Schranke'' für die Funktion f dar.

Schließlich bedeutet <math>f \in \Theta(g)</math>, dass die Funktion f genauso schnell wie die Funktion g wächst, das heißt man hat eine asymptotisch ''scharfe Schranke'' für f. Hierzu muss sowohl <math>f\in\mathcal{O}(g)</math> als auch <math>f \in \Omega(g)</math> erfüllt sein.

Im nun folgenden soll auf die verschiedenen Landau-Symbole noch näher eingegeangen werden.

===O-Notation===

Intuitiv gilt: Für große N dominieren die am schnellsten wachsenden Terme einer Funktion. Die Notation <math>f \in \mathcal{O}(g)</math> (sprich "f ist in O von g" oder "f ist von derselben Größenordnung wie g") formalisiert eine solche Abschätzung der asymptotischen Komplexität der Funktion f von oben.
; Asymptotische Komplexität: Für zwei Funktionen f(x) und g(x) gilt
::<math>f(x) \in \mathcal{O}(g(x))</math>
: genau dann wenn es eine Konstante <math>c>0</math> und ein Argument <math>x_0</math> gibt, so dass
::<math>\forall x \ge x_0:\quad f(x) \le c\,g(x)</math>.
:Die Menge <math>\mathcal{O}(g(x))</math> aller durch g(x) abschätzbaren Funktionen ist also formal definiert durch
::<math>\mathcal{O}(g(x)) = \{ f(x)\ |\ \exists c>0: \forall x \ge x_0: 0 \le f(x) \le c\,g(x)\}</math>

Die Idee hinter dieser Definition ist, dass g(x) eine wesentlich einfachere Funktion ist als f(x), die sich aber nach geeigneter Skalierung (Multiplikation mit c) und für große Argumente x im wesentlichen genauso wie f(x) verhält. Man kann deshalb in der Algorithmenanalyse f(x) durch g(x) ersetzen. <math>f(x) \in \mathcal{O}(g(x))</math> spielt für Funktionen eine ähnliche Rolle wie der Operator ≤ für Zahlen: Falls a ≤ b gilt, kann bei einer Abschätzung von oben ebenfalls a durch b ersetzt werden.

==== Ein einfaches Beispiel ====

[[Image:Sqsqrt.png]]

Rot = <math>x^2 \!</math>
Blau = <math>\sqrt{x} \!</math>

<math>\sqrt{x} \in \mathcal{O}(x^2)\!</math> weil <math>\sqrt{x} \le c\,x^2\!</math> für alle <math>x \ge x_0 = 1 \!</math> und <math>c = 1\!</math>, oder auch für <math>x \ge x_0 = 4 \!</math> und <math>c = 1/16</math> (die Wahl von c und x0 in der Definition von O(.) ist beliebig, solange die Bedingungen erfüllt sind).

==== Komplexität bei kleinen Eingaben ====

Algorithmus 1: <math>\mathcal{O}(N^2) \!</math> 
Algorithmus 2: <math>\mathcal{O}(N\log{N}) \!</math>

Algorithmus 2 ist schneller (von geringerer Komplexität) für große Eingaben, aber bei kleinen Eingaben (insbesondere, wenn der Algorithmus in einer Schleife immer wieder mit kleinen Eingaben aufgerufen wird) könnte Algorithmus 1 schneller sein, falls der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor ''c'' bei Algorithmus 2 einen wesentlich größeren Wert hat als bei Algorithmus 1.

==== Eigenschaften der O-Notation (Rechenregeln) ====

# Transitiv:
#: <math>f(x) \in \mathcal{O}(g(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) \in \mathcal{O}(h(x)) \!</math>
# Additiv:
#: <math>f(x) \in \mathcal{O}(h(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) + g(x) \in \mathcal{O}(h(x)) \!</math>
# Für Monome gilt:
#: <math>x^k \in \mathcal{O}(x^k)</math> und
#: <math>x^k \in \mathcal{O}(x^{k+j}), \forall j \ge 0 \!</math>
# Multiplikation mit einer Konstanten:
#: <math>f(x) \in \mathcal{O}(g(x)) \to c\,f(x) \in \mathcal{O}(g(x))\!</math>
#: andere Schreibweise:
#: <math>f(x) = c\,g(x) \to f(x) \in \mathcal{O}(g(x))\!</math>
# Folgerung aus 3. und 4. für Polynome:
#: <math>a_0+a_1\,x + ... + a_n\,x^n \in \mathcal{O}(x^n)\!</math>
#: Beispiel: <math>a\,x^2+b\,x+c \in \mathcal{O}(x^2)\!</math>
# Logarithmus:
#: <math>a, b > 1\!</math>
#: <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>
#: Die Basis des Logarithmus spielt also keine Rolle.
#: Beweis hierfür:
#:: <math>\log_{a}{x} = \frac{\log_{b}{x}}{\log_{b}{a}}\!</math>
#:: Mit <math>c = 1 / \log_{b}{a}\,</math> gilt: <math>\log_{a}{x} = c\,\log_{b}{x}\!</math>.
#:: Wird hier die (zweite) Regel für Multiplikation mit einer Konstanten angewendet, fällt der konstante Faktor weg, also <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>.
#: Insbesondere gilt auch <math>\log_{a}{x} \in \mathcal{O}(\log_{2}{x})\!</math>, es kann also immer der 2er Logarithmus verwendet werden.

==== O-Kalkül ====

Das O-Kalkül definiert wichtige Vereinfachungsregeln for Ausdrücke in O-Notation (Beweise: siehe Übungsaufgabe):

# <math>f(x) \in \mathcal{O}(f(x))\!</math>
# <math>\mathcal{O}(\mathcal{O}(f(x))) \in \mathcal{O}(f(x))\!</math>
# <math>c\,\mathcal{O}(f(x)) \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# <math>\mathcal{O}(f(x))+c \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# Sequenzregel:
#: Wenn zwei nacheinander ausgeführte Programmteile die Komplexität <math>\mathcal{O}(f(x))</math> bzw. <math>\mathcal{O}(g(x))</math> haben, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(f(x))</math> falls <math>g(x) < \mathcal{O}(f(x))</math> bzw.
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(g(x))\!</math> falls <math>f(x) < \mathcal{O}(g(x))</math>.
#: Informell schreibt man auch: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(max(f(x), g(x)))\!</math>.
# Schachtelungsregel bzw. Aufrufregel:
#: Wenn in einer geschachtelten Schleife die äußere Schleife die Komplexität <math>\mathcal{O}(f(x))</math> hat, und die innere <math>\mathcal{O}(g(x))</math>, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) * \mathcal{O}(g(x)) \in \mathcal{O}(f(x) * g(x))\!</math>.
#: Gleiches gilt wenn eine Funktion <math>\mathcal{O}(f(x))</math>-mal aufgerufen wird, und die Komplexität der Funktion selbst <math>\mathcal{O}(g(x))</math> ist.

;Beispiel für 5.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Dies gilt auch für ihre Hintereinanderausführung:
for i in range(N):
a[i] = i
for i in range(N):
print a[i]
;Beispiele für 6.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Ihre Verschachtelung hat daher die Komplexität <math>\mathcal{O}(N^2)</math>.
for i in range(N):
for j in range(N):
a[i*N + j] = i+j
: Dies gilt ebenso, wenn statt der inneren Schleife eine Funktion mit Komplexität <math>\mathcal{O}(N)</math> ausgeführt wird:
for i in range(N):
a[i] = foo(i, N) # <math>\mathrm{foo}(i, N) \in \mathcal{O}(N)</math>

==== O-Kalkül auf das Beispiel des Selectionsort angewandt ====

Selectionsort: Wir hatten gezeigt dass <math>f(N) = \frac{N^2}{2} - \frac{N}{2}</math>. Nach der Regel für Polynome vereinfacht sich dies zu <math>f(N) \in \mathcal{O}\left(\frac{N^2}{2}\right) = \mathcal{O}(N^2)\!</math>.

Alternativ via Schachtelungsregel:
: Die äußere Schleife wird (''N''-1)-mal durchlaufen: <math>N-1 \in \mathcal{O}(N)</math>
: Die innere Schleife wird (''N-i''-1)-mal durchlaufen. Das sind im Mittel ''N''/2 Durchläufe: <math>N/2 \in \mathcal{O}(N)</math>
: Zusammen: <math>\mathcal{O}(N)*\mathcal{O}(N) \in \mathcal{O}(N^2)</math>

Nach beiden Vorgehensweisen kommen wir zur Schlussfolgerung, dass der Selectionsort die asymptotische Komplexität <math>\mathcal{O}(N^2)\!</math> besitzt.

==== Zusammenhang zwischen Komplexität und Laufzeit ====

Wenn eine Operation 1ms dauert, erreichen Algorithmen verschiedener Komplexität folgende Leistungen (wobei angenommen wird, dass der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor immer etwa gleich 1 ist):

{| class="wikitable" style="text-align:left" cellpadding="7"
|+
|-
! Komplexität !! Operationen in 1s !! Operationen in 1min !! Operationen in 1h
|-
! <math>\mathcal{O}(N)</math>
| 1000 || 60.000 || 3.600.000
|-
! <math>\mathcal{O}(N\log_2{N})</math>
| 140 || 4895 || 204094
|-
! <math>\mathcal{O}(N^2)</math>
| 32 || 245 || 1898
|-
! <math>\mathcal{O}(N^3)</math>
| 10 || 39 || 153
|-
! <math>\mathcal{O}(2^N)</math>
| 10 || 16 || 21
|}

==== Exponentielle Komplexität ====
Der letzte Fall <math>\mathcal{O}(2^N)</math> ist von exponentieller Komplexität. Das bedeutet, dass eine Verdopplung des Aufwands nur bewirkt, dass die maximale Problemgröße um eine Konstante wächst. Algorithmen mit exponentieller (oder noch höherer) Komplexität werden deshalb als '''ineffizient''' bezeichnet. Algorithmen mit höchstens polynomieller Komplexität gelten hingegen als effizient.

In der Praxis sind allerdings auch polynomielle Algorithmen mit hohem Exponenten meist zu langsam. Als Faustregel kann man eine praktische Grenze von <math>\mathcal{O}(N^3)</math> ansehen. Bei einer Komplexität von <math>\mathcal{O}(N^3)</math> bewirkt ein verdoppelter Aufwand immer noch eine Steigerung der maximalen Problemgröße um den Faktor <math>\sqrt[3]{2}</math> (also eine ''multiplikative'' Vergrößerung um ca. 25%, statt nur einer additiven Vergrößerung wie bei exponentieller Komplexität).

===<math>\Omega</math>- Notation===

Genauso wie <math>f \in \mathcal{O}(g)</math> eine Art <math>\le</math>-Operator für Funktionen ist, definiert <math>f \in \Omega(g) </math> eine Abschätzung von unten, analog zum <math>\ge</math>-Operator für Zahlen. Formal kann man <math>f(N) \in \Omega(g(N)) </math> genau dann schreiben, falls es eine Konstante <math> c > 0 </math> gibt, so dass

<math> f(N) \ge c \cdot g(N) </math> für <math> N \ge N_0 </math>

gilt.
Man verwendet diese Notation also um abzuschätzen, wie groß der Aufwand (die Komplexität) für einen bestimmten Algorithmus ''mindestens'' ist und nicht ''höchstens'', was man mit der <math>\mathcal{O}</math> - Notation ausdrücken würde.

Ein praktisches Beispiel für eine Anwendung der <math>\Omega</math>- Notation wäre die Fragestellung, ob es ''prinzipiell'' einen besseren Algorithmus für ein bestimmtes Problem gibt. Wie später im Abschnitt [[Suchen#Sortieren_als_Suchproblem|Sortieren als Suchproblem]] gezeigt wird, ist das Sortieren eines Arrays durch paarweise Vergleiche von Elementen immer mindestens von der Komplexität <math> \Omega(N\cdot \ln N) </math>, was konkret bedeutet, dass kein Sortieralgorithmus, der nach diesem Prinzip arbeitet, jemals eine geringere Komplexität als beispielsweise Merge-Sort haben wird. Natürlich kann man den entsprechenden Sortieralgorithmus, also Merge-Sort zum Beispiel, unter Umständen noch optimieren, aber die Komplexität wird erhalten bleiben. Mit diesem Wissen kann man sich viel (vergebliche) Arbeit sparen.

===<math>\Theta</math>- Notation===

<math>f(N) \in \Theta(g(N))</math> ist eine scharfe Abschätzung der asymptotischen Komplexität einer Funktion f.

Damit dies gilt, muss <math>f(N) \in \mathcal{O}(g(N))</math> und ''gleichzeitig'' <math>f(N) \in \Omega(g(N))</math> erfüllt sein.

Dies ist natürlich auch die beste Abschätzung der asymptotischen Komplexität einer Funktion f. Formal bedeutet <math>f(N) \in \Theta(g(N))</math> dass es zwei Konstanten <math> c_1 </math> und <math> c_2 </math>, beide größer als Null, gibt, so dass für alle <math> N \geq N_0 </math> gilt:

<math> c_1 \cdot g(N) \leq f(N) \leq c_2 \cdot g(N) </math>.

In der Praxis wird manchmal statt der <math>\Theta</math>-Notation auch dann die <math>\mathcal{O}</math>-Notation benutzt, wenn eine scharfe Schranke ausgedrückt werden soll. Dies ist zwar formal nicht korrekt, aber man kann die intendierte Bedeutung meist aus dem Kontext erschließen.

== Komplexitätsvergleich zweier Algorithmen ==

In diesem Abschnitt wollen wir der Frage nachgehen, wie ein formaler Beweis für die Behauptung <math> f(N) \in \mathcal{O}(g(N))</math> geschehen kann. Hierbei werden zwei Beweismethoden vorgestellt werden, und zwar der '''Beweis über die Definition der Komplexität''' sowie der '''Beweis durch Dividieren'''.

===Beweis über die Definition der asymptotischen Komplexität===

Die Definition der asymptotischen Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> war:

Es gibt eine Konstante <math> c > 0 </math>, so dass <math> f(N) \le c \cdot g(N) </math> für <math> N \ge N_0 </math> erfüllt ist.

Um also die die asymptotische Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> zu beweisen, muss man die oben erwähnten Konstanten c und <math> N_0 </math> finden, so dass

<math> f(N) \leq c \cdot g(N) </math> für alle <math> N \ge N_0 </math> erfüllt ist.

Dies geschieht zweckmäßigerweise mit dem Beweisprinzip der ''vollständigen Induktion''. Hierbei ist zu zeigen, dass
# <math> f(N_0) \leq g(N_0) </math> für die eine zu bestimmende Konstante <math> N_0 </math> gilt (''Induktionsanfang'') und
# falls <math> f(N) \leq g(N) </math>, dann auch <math> f(N+1) \leq g(N+1) </math> (''Induktionsschritt'') gilt.

===Beweis durch Dividieren===

Hierbei wählt man eine Konstante c und zeigt, dass <math> \lim_{N \rightarrow \infty} \frac{f(N)}{c \cdot g(N)} \leq 1 </math> gilt (für die O-Notation, bei Ω-Notation gilt entsprechend <math>\geq 1 </math>). Man kann dies auch als alternative Definition der Komplexität verwenden.

Als Beispiel betrachten wir die beiden Funktionen <math> f(N) = N \,\lg N </math> und <math> g(N) = N^2 </math> und wollen zeigen, dass <math>f(N) \in \mathcal{O}(g(N))</math> gilt.

Als Konstante c wählen wir <math> c = 1 </math>

<math> \lim_{N \rightarrow \infty} \frac{f(N)}{g(N)} = \lim_{N \rightarrow \infty} \frac{\lg N}{N} = \frac{\infty}{\infty} </math>

Unbestimmte Ausdrücke der Form
<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} </math>,
in denen sowohl <math> f(x) </math> als auch <math> g(x) </math> mit <math> x \rightarrow x_0 </math> gegen Null oder gegen Unendlich streben, kann man manchmal mit den Regeln von [http://de.wikipedia.org/wiki/L%27Hospital%27sche_Regel ''l'Hospital''] berechnen. Danach darf man die Funktionen f und g zur Berechnung des unbestimmten Ausdrucks durch ihre k-ten Ableitungen ersetzen:

<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} = \lim_{x \rightarrow x_0} \frac{f^{(k)}(x)}{g^{(k)}(x)} </math>

In unserem Fall verwenden wir die erste Ableitung und erhalten:
<math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)} = \lim_{N \rightarrow \infty} \frac{1/N}{1} \rightarrow 0 </math>

Damit wurde <math>f(N) \in \mathcal{O}(g(N))</math>, also <math>N \lg N \in \mathcal{O}(N^2)</math> gezeigt.

Man beachte hierbei, dass <math>N \lg N \in \mathcal{O}(N^2)</math> keine enge Grenze für die Komplexität von <math>N \,\lg N</math> darstellt, da der Grenzwert <math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)}\, </math> gegen 0 und nicht gegen eine von Null verschiedene Konstante strebt. In diesem Fall haben wir die Komplexität von <math>N \cdot \lg N </math> also nur nach oben abschätzen können.

===Beispiel für den Komplexitätsvergleich: Gleitender Mittelwert (Running Average)===

Wir berechnen für ein gegebenes Array <tt>a</tt> einen gleitenden Mittelwert über <tt>k</tt> Elemente: 
::<math>r_i = \frac{1}{k} \sum_{j=i-k+1}^i a_j</math> 
Das heisst, für jedes <tt>i</tt> mitteln wir die letzten <tt>k</tt> Elemente von <tt>a</tt> und schreiben das Ergebnis in <tt>r[i]</tt>. Diese Operation ist z.B. bei Börsenkursen wichtig: Neben dem aktuellen Kurs für jeden Tag wird dort meist auch der gleitende Mittelwert der letzten 30 Tage sowie der letzten 200 Tage angegeben. In diesen Mittelwerten erkennt man besser die langfristige Tendenz, weil die täglichen Schwankungen herausgemittelt werden. Wir nehmen außerdem an, dass
* Array-Zugriff hat eine Komplexität von O(1)
* <math>k \ll N</math>, d.h. <math>N-k\approx N</math>.

Die beiden folgenden Algorithmen berechnen die Mittelwerte auf unterschiedliche Art. Der linke folgt der obigen Definition durch eine Summe, während der rechte inkrementell arbeitet: Man kann den Bereich der <tt>k</tt> letzten Werte als Fenster betrachten, das über das Array <tt>a</tt> geschoben wird. Schiebt man das Fenster ein Element weiter, fällt links ein Element heraus, und rechts kommt eins hinzu. Man muss also nicht jedes Mal die Summe neu berechnen, sondern kann den vorigen Wert aktualisieren. Wir werden sehen, dass dies Folgen für die Komplexität des Algorithmus hat.

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1: O(N * k)
! Komplexität
! Version 2: O(N)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|
<tt>for i in range(k):</tt>
|
'''<center>O(k)</center>'''
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|
:: <tt>r[k-1] += a[i]</tt>
|
'''<center>O(1)</center>'''
|-
|
6.
|
:::: <tt>r[j] += a[i]</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(k, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|
:: <tt>r[j] = (a[j] - a[j-k] + r[j-1])</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(len(a)):</tt>
|
'''<center>O(N)</center>'''
|-
|
9.
|

|

|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
10.
|

|

|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Wir zeigen unten dass Version 2 eine geringere Komplexität besitzt, obwohl sie mehr Zeilen benötigt.

Wir haben in der Tabelle die Komplexität jeder Zeile für sich angegeben. Einfache Anweisungen (Berechnungen, Lese- und Schreibzugriffe auf das Array, Zuweiseungen) haben konstante Komplexität, die Komplexität des Schleifenkopfes allein (also der <tt>for</tt>-Anweisung ohne den eingerückten Schleifenkörper) entspricht der Anzahl der Durchläufe. Wir müssen jetzt noch die Verschachtelung der Schleifen und die Nacheinanderausführung von Anweisungen berücksichtigen.

====Berechnung der Komplexität von Version 1====

(Wiederholung der Rechenregeln: siehe Abschnitt [[Effizienz#O-Notation|O-Notation]])

Wir betrachten zunächst die innere Schleife (Zeilen 5 und 6 von Version 1):

Der Schleifenkopf (Zeile 5) hat die Komplexität <math>\mathcal{O}(k)</math>, weil die Schleife k-mal durchlaufen wird. Der Schleifenkörper (Zeile 6) hat die Komplexität <math>\mathcal{O}(1)</math>. Nach der Verschachtelungsregel müssen wir die beiden Komplexitäten multiplizieren, und es ergibt sich:

::<math>\mathcal{O}(k)\cdot\mathcal{O}(1) = \mathcal{O}(k\cdot 1)=\mathcal{O}(k)</math>

Wir betrachten nun die äußere Schleife. Der Schleifenkopf (Zeile 4) wird (N-k)-mal durchlaufen und hat somit eine Komplexität von <math>\mathcal{O}(N)</math>. Der Schleifenkörper (Zeilen 5 bis 7) besteht aus der inneren Schleife (Zeilen 5 und 6) mit der gerade berechneten Komplexität <math>\mathcal{O}(k)</math> sowie einer einfachen Anweisung (Zeile 7) mit Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel wird die Komplexität des Schleifenkörpers durch Addition berechnet:

::<math>\mathcal{O}(k)+\mathcal{O}(1) = \mathcal{O}(\max(k,1)) = \mathcal{O}(k)</math>

Die Komplexität der gesamten äußeren Schleife erhalten wir nach der Verschachtelungsregel wieder durch multiplizieren:

::<math>\mathcal{O}(N)\cdot\mathcal{O}(k) = \mathcal{O}(N\cdot k)</math>

Die übrigen Schritte des Algorithmus werden einfach nacheinander ausgeführt, so dass sie ebenfalls nach der Sequenzregel behandelt werden. Wir erhalten

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(N\cdot k)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,N\cdot k,1)) = \mathcal{O}(N\cdot k)</math>

Der gesamte Algorithmus hat also die Komplexität <math>\mathcal{O}(N\cdot k)</math>.

====Berechnung der Komplexität von Version 2====

Hier gibt es nur einfache Schleifen ohne Verschachtelung. Da der Schleifenkörper jeder Schleife nur einfache Anweisungen der Komplexität <math>\mathcal{O}(1)</math> enthält, ergibt sich die Komplexität der Schleifen nach der Verschachtelungsregel als

::<math>\mathcal{O}(X)\cdot\mathcal{O}(1) = \mathcal{O}(X\cdot 1)=\mathcal{O}(X)</math>

wobei <math>\mathcal{O}(X)</math> die Komplexität des jeweiligen Schleifenkopfes ist. Wir erhalten also für Zeilen 4 und 5: <math>\mathcal{O}(k)</math>, Zeilen 6 und 7: <math>\mathcal{O}(N)</math>, Zeilen 8 und 9: <math>\mathcal{O}(N)</math>. Die Hintereinanderausführung wird nach der Sequenzregel behandelt:

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(k)+\mathcal{O}(N)+\mathcal{O}(N)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,k,N,N,1)) = \mathcal{O}(N)</math>

Dieser Algorithmus hat also nur die Komplexität <math>\mathcal{O}(N)</math>.

====Fazit====

Obwohl Version 2 mehr Schritte benötigt hat sie eine geringere Komplexität, da die for-Schleifen nicht wie bei Version 1 verschachtelt/untergeordnet sind. Bei verschachtelten for-Schleifen muss die Multiplikationsregel angewendet werden → höhere Komplexität.

Die gerade berechnete Komplexität gilt aber nur unter der Annahme, dass Array-Zugriffe konstante Komplexität <math>\mathcal{O}(1)</math> besitzen. Wenn dies nicht der Fall ist, kann sich die Komplexität des Algorithmus drastisch verschlechtern.

{| border="1" cellspacing="0" cellpadding="5"
|Allgemein gilt: 
Algorithmen-Analysen beruhen auf der Annahme, dass Zugriffe auf die Daten optimal schnell sind, dass heißt, dass die für den jeweiligen Algorithmus am besten geeignete Datenstruktur verwendetet wird. → Ansonsten: Komplexitätsverschlechterung!
|}
 

====Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur====

Wir verwende im Mittelwert-Algorithmus eine verkettete Liste anstelle des Eingabe-Arrays <tt>a</tt>. Wir benötigen dazu eine Funktion, die das j-te Element der Liste zurückgibt. Wie üblich ist die Liste mit Hilfe einer Knotenklasse implementiert:
class Node:
def __init__(self, data):
self.data = data
self.next = None

Die Listenklasse selbst hat ein Feld <tt>head</tt>, das eine Referenz auf den ersten Knoten speichert, und jeder Knoten speichert im Feld <tt>next</tt> eine Referenz auf seinen Nachfolger. Um zum j-ten Element zu gelangen, muss man die Liste sequenziell durchlaufen
def get_jth(list, j):
r = list.head
while j > 0:
r = r.head
j -= 1
return r.data
Die Komplexität dieser Funktion ist offensichtlich <math>\mathcal{O}(j)</math> (Komplexitätsberechnung wie oben). Wir setzen jetzt bei Version 1 des Mittelwert-Algorithmus diese Funktion in Zeile 6 anstelle des Indexzugriffs <tt>a[i]</tt> ein (nur in dieser Zeile wird auf die Elemente des Arrays zugegriffen). Wir erhalten folgende Implementation (die Änderungen sind rot markiert):

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1 mit Liste: O(N * k)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|-
|
6.
|
:::: <tt>r[j] += get_jth(a, i)</tt>
|
'''<center>O(i)</center>'''
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Der Aufruf der Funktion <tt>get_jth</tt> ist jetzt gleichbedeutend mit einer dreifach verschachtelten Schleife (weil <tt>get_jth</tt> ja eine zusatzliche Schleife enthält). Die Anzahl der Operationen in Zeile 4 bis 6 ist jetzt

::<math>f(N,k)=\sum_{j=k-1}^{N-1}\,\sum_{i=j-k+1}^j\,\mathcal{O}(i)</math>

wobei das <math>\mathcal{O}(i)</math> die neue Schleife durch Verwendung der Liste repräsentiert. Mit Mathematica-Hilfe [http://www.wolfram.com/] lässt sich diese Summe exakt ausrechnen

::<math>f(N,k)=\frac{1}{2}(k N^2-k^2 N+k^2-k)\in \mathcal{O}(k N^2)</math>

Die Komplexitätsberechnung erfolgte dabei nach der Regel für Polynome unter Beachtung von <math>k \ll N</math>.

====Fazit:====

Die Komplexität von Version 1 mit einer verketteten Liste wäre O(N2 * k)
'''→ Die richtige Datenstruktur ist wichtig, da es sonst zu einer Komplexitätsverschlechterung kommen kann!'''

Auf Version 2 unseres Running Average-Beispiels hätte eine verkettete Liste allerdings keine Auswirkungen, da die inkrementelle Berechnung der Summen in Zeile 7 weiterhin möglich ist (bei geschickter Implementation!) und somit Version 2 immer noch eine Komplexität von O(N) hätte.

==Amortisierte Komplexität==

Bis jetzt wurde die Komplexität nur im schlechtesten Fall (Worst Case) betrachtet. Bei einigen Operationen schwankt die Komplexität jedoch sehr stark, wenn man sie mehrmals hintereinander ausführt, und der schlechteste Fall kommt nur selten vor. Dann ist es sinnvoll, die amortisierte Komplexität zu betrachten, die sich mit der durchschnittlichen Komplexität über viele Aufrufe der selben Operation beschäftigt.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse Wikipedia: Amortisierte Laufzeitanalyse]]

===Beispiel: Inkrementieren von Binärzahlen===

Frage: Angenommen, das Umdrehen eines Bits einer Binärzahl verursacht Kosten von 1 Einheit. Wir erzeugen die Folge der natürlichen Zahlen in Binärdarstellung durch sukzessives Inkrementieren, von Null beginnend. Bei jeder Inkrementierung werden einige Bits verändert, aber diese Zahl (und damit die Kosten der Inkrementierungen) ''schwanken'' sehr stark. Wir fragen jetzt, was eine Inkrementierung im Durchschnitt kostet?

Um diese Durchschnittskosten zu berechnen, bezahlen wir bei jeder Inkrementierung 2 Einheiten. Wenn davon nach Abzug der Kosten der jeweiligen Operation noch etwas übrig bleibt, wird der Rest dem Guthaben zugeschrieben. Umgekehrt wird ein eventueller Fehlbetrag (wenn eine Inkrementierung mehr als 2 Bits umdreht) aus dem Guthaben gedeckt. Dadurch werden die ansonsten großen Schwankungen der Kosten ausgeglichen:
:: Kosten < Einzahlung → es wird gespart
:: Kosten = Einzahlung → Guthaben bleibt unverändert
:: Kosten > Einzahlung → Guthaben wird für die Kosten verbraucht

{| border="1" cellspacing="0" cellpadding="5"
!Schritte
!Zahlen
!Kosten 
(Anzahl der geänderten Bits)
! Einzahlung
!Guthaben = 
altes Guthaben + Einzahlung - Kosten
|-
|1.
|00001
|1
|'''2'''
|'''1'''
|-
|2.
|00010
|2
|'''2'''
|'''1'''
|-
|3.
|00011
|1
|'''2'''
|'''2'''
|-
|4.
|00100
|3
|'''2'''
|'''1'''
|-
|5.
|00101
|1
|'''2'''
|'''2'''
|-
|6.
|00110
|2
|'''2'''
|'''2'''
|-
|7.
|00111
|1
|'''2'''
|'''3'''
|-
|8.
|01000
|4
|'''2'''
|'''1'''
|-
|}

Die Kosten ergeben sich aus der Anzahl der Ziffern die von 1 nach 0, bzw. von 0 nach 1 verändert werden

Rechnung:

1. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

2. Schritt: Kosten: 2 = Einzahlung: 2 
:: → es wird nicht gespart 
:: → Guthaben bleibt so wie es ist 

3. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

4. Schritt: Kosten: 3 > Einzahlung: 2 
:: → es wird eine 1 vom Guthaben genommen um die Kosten zu zahlen 

usw.

Man erkennt, dass vor teuren Operation (Wechsel von 3 auf 4 bzw. von 7 auf 8) genügend Guthaben angespart wurde, um die Kosten zu decken. Das Guthaben geht bei diesen Operationen immer wieder auf 1 zurück, aber es wird nie vollständig verbraucht (Dies kann natürlich auch mathematisch exakt bewiesen werden, wie wir es unten am Beispiel des dynamische Arrays zeigen). Wir schließen daraus, dass die durchschnittlichen oder '''amortisierten Kosten''' einer Inkrementierungsoperation gleich 2 sind.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Account-Methode Wikipedia Account-Methode]]

====Fazit====
Die amortisierte Komplexität beschäftigt sich mit dem Durchschnitt aller Operation im ungünstigsten Fall. Operationen mit hohen Kosten, die aber nur selten ausgeführt werden, fallen bei der amortisierten Komplexität nicht so ins Gewicht. Bei Algorithmen, die gelegentlich eine "teure" Operation benutzen, ansonsten jedoch "billige" Operationen aufrufen, kann die amortisierte Komplexität niedriger sein als die Komplexität im schlechtesten (Einzel-)Fall.

In unserem Beispiel fallen die teuren Einzelschritte (z.B. 4. und 8. Schritt) bei den amortisierten Kosten nicht so ins Gewicht, da wir die Kosten aus unserem Guthaben mitbezahlen können. Das Guthaben ist immer groß genug, weil jeder zweite Aufruf eine billige Operation ist, die nur ein Bit umdreht und somit das Ansparen ermöglicht. Diese Betrachtung zeigt, dass die amortisierte (d.h. durchschnittliche) Komplexität des Algoithmus niedriger (nämlich konstant) ist als die Komplexität im schlechtesten Fall.

===Anwendung: Dynamisches Array===

Ein dynamisches Array hat die Eigenschaft, dass man effizient am Ende des Arrays neue Elemente anfügen kann, indem man die Länge des Arrays entsprechend vergrößert (siehe Übung 1). Die Analyse der amortisierten Komplexität der Anfüge-Operation zeigt uns, wie man das Vergrößern des Arrays richtig implementiert, damit die Operation wirklich effizient abläuft.

==== Ineffiziente naive Lösung ====

Wenn wir an ein Array ein Element anhängen wollen, müssen wir neuen Speicher allokieren, der die gewünschte Länge hat. Die Werte aus dem alten Array müssen dann in den neuen Speicher umkopiert werden. Danach kann das neue Element hinten angefügt werden, weil wir im neuen Array bereits Speicher für dieses Element reserviert haben. Bei der naiven Implementation des dynamischen Arrays wiederholt man dies bei jeder Anfügeoperation. Für die Analyse nehmen wir an, dass das Kopieren eines Elements konstante Zeit O(1) erfordert, ebenso das Einfügen eines neuen Elements auf in eine noch unbenutzte Speicherposition.

Naives Anhängen eines weiteren Elements an ein Array:

{| border="1" cellspacing="0" cellpadding="5" align="right"
!Schritte
|'''Array'''
(wie es nach jedem Schritt aussieht)
!Komplexität
|-
|<center>altes Array (N=4)</center>
|<center>[0,1,2,3]</center>
|<center>-</center>
|-
|1. neuer Speicher für    (N+1) Elemente
|<center>[None,None,None,None,None]</center>
|<center>O(N+1) = '''O(N)'''</center>(wenn der Speicher initialisiert wird (hier auf <tt>None</tt>), sonst O(1))
|-
|2. Kopieren
|<center>[0,1,2,3,None]</center>
|<center>'''O(N)'''</center>
|-
|3. append von "x"
|<center>[0,1,2,3,'x']</center>
|<center>'''O(1)'''</center>
|-
|}

altesArray = [0,1,2,3] 
altesArray.append('x')

1. Es wird ein neues Array der Größe N+1 erzeugt 
2. Die N Datenelemente aus dem alten Array werden in das neue Array kopiert 
Das sind N Operationen der Komplexität O(1), also ein Gesamtaufwand von O(N). 
3. 'x' wird mit Aufwand O(1) an die letzte Stelle des neuen Arrays geschrieben

Additionsregel: 
O(N) + O(1) ∈ O(N)

Folgerung:

Bei der naiven Methode erfordert jede Anfügung einen Aufwand O(N) (wobei N die derzeitige Arraygröße ist). Dies ist nicht effizient.

====Effiziente Lösung durch Verdoppeln der Kapazität====

Offensichtlich kommt man nicht darum heraum, den Inhalt des alten Arrays zu kopieren, wenn der allokierte Speicher voll ist. Der Trick für die effiziente Implementation der Anfügeoperation besteht darin, das Kopieren so selten wie möglich durchzuführen, also nicht wie in der naiven Lösung bei jeder Anfügeoperation. Hier kommt die amortisierte Komplexität ins Spiel: Ab und zu gibt es eine teure Anfügeoperation (wenn nämlich kopiert werden muss), aber wenn man den durchschnittlichen Aufwand über viele Anfügungen betrachtet, ist die Operation effizient. Der teure Fall wird sozusagen "herausgemittelt".

Um nur selten kopieren zu müssen, werden beim dynamischen Array mehr Speicherelemente reserviert als zur Zeit benötigt werden (in der naiven Lösung wurde dagegen immer nur Speicher für ein einziges neues Element reserviert). Wir unterscheiden deshalb

:<tt>capacity</tt> = Anzahl der allokierten Speicherzellen, d.h. der möglichen Elemente, die in das Array passen 
:<tt>size</tt> = Anzahl der Elemente, die im Array zur Zeit gespeichert sind 

Die Daten selbst werden in einem statischen Array gespeichert:
:<tt>data</tt> = statisches Array der Größe <tt>capacity</tt> 

Die folgende intuitive Abschätzung zeigt, dass es sinnvoll ist, die Größe des allokierten Speichers jeweils zu verdoppeln. Wir starten bei einem Array der Größe <tt>size = capacity</tt> = N. Da der verfügbare Speicher voll ist, müssen wir bei der nächsten Anfügung die N vorhandenen Elemente in ein neues Array der Länge <tt>new_capacity</tt> kopieren (Aufwand <math>N\cdot O(1)</math>). Danach können wir K Elemente billig einfügen (Aufwand <math>K\cdot O(1)</math>), wobei
:K = <tt>new_capacity - capacity</tt>
die Anzahl der nach dem Kopieren noch unbenutzen Speicherzellen ist. Der durchschnittliche Aufwand für diese K Einfügungen ist somit
:<math>\bar T = \frac{N \cdot O(1) + K \cdot O(1)}{K}=\frac{N+K}{K}\cdot O(1)</math>
Damit die mittlere Zeit in O(1) sein kann, muss der Quotient <math>(N+K)/K</math> eine Konstante sein. Wir setzen <math>K = a N</math> und erhalten:
:<math>\bar T = \frac{(a+1)N}{a N}\cdot O(1)=\frac{a+1}{a}\cdot O(1)</math>
Der amortisierte Aufwand über K Einfügungen ist also konstant, wenn <math>a</math> eine (kleine) von N unabhängige Zahl ist. Typischerweise wählt man
:<math>a = 1</math>
und mit <math>K = 1\cdot N</math> ergibt sich
:<tt>new_capacity = capacity</tt> + N = <tt>2 * capacity</tt>

Die Vorgehensweise beim Zufügen eines neuen Elements im Fall <tt>size == capacity</tt> ist also
* capacity wird verdoppelt 
: <tt>neue capacity = 2 * alte capacity</tt>
: (allgemein genügt es auch, wenn capacity um einen bestimmten Prozentsatz vergrößert wird,
:: <tt>neue capacity = alte capacity * c</tt>
: mit c > 1, z.B. c = 1.2, das entspricht oben der Wahl <math>a = 0.2</math>)
* ein neues statisches Array der Größe 'neue capacity' wird erzeugt
* das alte Array wird ins neue kopiert und danach freigegeben
* das anzufügende Element wird ins neue Array eingefügt
Umgekehrt geht man beim Entfernen des ''letzten'' Array-Elements vor. Normalerweise überschreibt man einfach das letzte Element mit <tt>None</tt> und dekrementiert <tt>size</tt>. Wird dadurch das Array zu klein (üblicherweise <tt>size < capacity / 4</tt>), wird die Kapazität halbiert, genauer:
* ein neues Array mit 
: <tt>neue capacity = alte capacity / 2 </tt>
: wird angelegt (bzw. mit
:: <tt>neue capacity = alte capacity / c </tt>
: wenn ein anderer Vergrößerungsfaktor verwendet wird)
* das alte Array wird ins neue kopiert und danach freigegeben

'''Folge:''' Die Kosten für das Vergrößern/Verkleinern der Kapazität werden amortisiert über viele Einfügungen, die kein Vergrößern erfordern. Die Operation <tt>append</tt> besitzt amortisierte Komplexität O(1). Im folgenden Abschnitt zeigen wir dies mathematisch exakt mit der Potentialmethode.

====Komplexitätsanalyse des dynamischen Arrays mit Potentialmethode====

Durchschnitt der Gesamtkosten für N-maliges append = <math>\frac{1}{N} \sum_{i = 1}^N Kosten(i)</math>. Zur Analyse der amortisierten Komplexität wird ein Potential 
::Φi = 2*sizei - capacityi 
eingeführt, wobei das Array nach dem i-ten Einfüge-Schritt die Größe sizei und die Kapizität capacityi hat. Wir nehmen vereinfachend an, dass es keine Löschoperationen gibt. Dann gilt nach dem i-ten Schritt jeweils
::Φi = 2*i - capacityi 

Fall 1: Array ist nicht voll 
Es wird kein Umkopieren benötigt, da das Array noch nicht voll ist 
→ sizei-1 < capacityi-1 
→ capacityi == capacityi-1

Kosten: 1 (für Einfügen des neuen Elements) 
Potenzial vor append: Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append: Φi = 2i - capacityi-1 

amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = 1 + (2i - capacityi-1) - [2(i - 1) - capacityi-1]
::::: = 1 + 2i - capacityi-1 - 2i + 2 + capacityi-1
::::: = 1 + <del>2i</del> - <del>capacityi-1</del> - <del>2i</del> + 2 + <del>capacityi-1</del>
::::: = 1 + 2
::::: = 3 = O(1) → konstant

Fall 2: Array ist voll 
Vor dem i-ten append muss umkopiert werden 
→ sizei-1 == capacityi-1 == i-1 
→ Allokieren eines neuen statischen Arrays mit verdoppelter Kapazität notwendig, also capacityi == 2*capacityi-1

Kosten: (i-1) + 1 (für Umkopieren und Einfügen des neuen Elements) 
Potenzial vor append = Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append = Φi = 2i - 2 capacityi-1 
amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = ((i - 1) + 1) + 2i - 2 capacityi-1 - [2(i-1) - capacityi-1]
::::: = i + <del>2i</del> - 2 capacityi-1 - <del>2i</del> + 2 - capacityi-1
::::: = i + 2 - capacityi-1
::::: = i + 2 - (i - 1) (da capacityi-1 = i-1)
::::: = 3 = O(1) → konstant

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine amortisierte Komplexität von 3 Einheiten hat, also <tt>append</tt> ∈ O(1)'''. Diese Operation kann deshalb gefahrlos in der inneren Schleife eines Algorithmus benutzt werden.

==== Beispiel für 9 Einfügeoperationen ====

{| border="1" cellspacing="0" cellpadding="5"
!Array 
(wie es aussehen könnte)
!size
!capacity
!Kosten für append (einschließlich Umkopieren)
!Summe Kosten
!Durchschnittskosten
!Φi = 2 * size - capacity 
(i = size)
!Potenzialdifferenz 
Δ Φi = Φi - Φi-1
!amortisierte Kosteni 
= Kosteni + Δ Φi
|-
| <center>[None]</center>
| <center>0</center>
| <center>1</center>
| <center>-</center>
| <center>-</center>
| <center>-</center>
| <center>-1</center>
| <center>-</center>
| <center>-</center>
|-
| <center>[a]</center><center>Array ist voll!</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b]</center><center>Array ist voll!</center>
| <center>2</center>
| <center>2</center>
| <center>1 + 1</center>
| <center>3</center>
| <center>3/2</center>
| <center>2</center>
| <center>1</center>
| <center>3</center>
|-
| <center>[a,b,c,None]</center>
| <center>3</center>
| <center>4</center>
| <center>2 + 1</center>
| <center>6</center>
| <center>6/3</center>
| <center>2</center>
| <center>0</center>
| <center>3</center>
|-
| <center>[a,b,c,d]</center><center>Array ist voll!</center>
| <center>4</center>
| <center>4</center>
| <center>1</center>
| <center>7</center>
| <center>7/4</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,None,None,None]</center>
| <center>5</center>
| <center>8</center>
| <center>4 + 1</center>
| <center>12</center>
| <center>12/5</center>
| <center>2</center>
| <center>-2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,None,None]</center>
| <center>6</center>
| <center>8</center>
| <center>1</center>
| <center>13</center>
| <center>13/6</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,None]</center>
| <center>7</center>
| <center>8</center>
| <center>1</center>
| <center>14</center>
| <center>14/7</center>
| <center>6</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h]</center><center>Array ist voll!</center>
| <center>8</center>
| <center>8</center>
| <center>1</center>
| <center>15</center>
| <center>15/8</center>
| <center>8</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h,j,None,None,None, 
None,None,None,None]</center>
| <center>9</center>
| <center>16</center>
| <center>8 + 1</center>
| <center>24</center>
| <center>24/9</center>
| <center>2</center>
| <center>-6</center>
| <center>3</center>
|-
|}

Die durchschnittlichen Kosten betragen stets etwa 2 Einheiten, schwanken allerdings so, dass nicht unmittelbar ersichtlich ist, ob dies für sämtliche Einfügeoperationen gilt. Die amortisierte Komplexität, die mit Hilfe des Potentials berechnet wird, ist hingegen konstant 3, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

[[Suchen|Nächstes Thema]]

Effizienz

2012-07-27T16:02:09Z

Ukoethe: /* Fazit */

Bei der Diskussion von Effizienz müssen wir zwischen der Laufzeit eines Algorithmus auf einem bestimmten System und seiner prinzipiellen Leistungsfähigkeit (Algorithmenkomplexität) unterscheiden. Der Benutzer ist natürlich vor allem an der Laufzeit interessiert, denn diese bestimmt letztendlich seine Arbeitsproduktivität. Ein Softwaredesigner hingegen muss eine Implementation wählen, die auf verschiedenen Systemen und in verschiedenen Anwendungen schnell ist. Für ihn sind daher auch Aussagen zur Algorithmenkomplexität sehr wichtig, um den am besten geeigneten Algorithmus auszuwählen.

== Laufzeit ==

Aus Anwendersicht ist ein Algorithmus effizient, wenn er die in der Spezifikation verlangten Laufzeitgrenzen einhält. Ein Algorithmus muss also nicht immer so schnell wie möglich sein, sondern so schnell wie nötig. Dies führt in verschiedenen Anwendungen zu ganz unterschiedliche Laufzeitanforderungen:

* Berechnen des nächsten Steuerkommandos für eine Maschine: ca. 1/1000s
* Berechnen des nächsten Bildes für eine Videopräsentation (z.B. Dekompression von MPEG-kodierten Bildern): ca. 1/25s
: Geringere Bildraten führen zu ruckeligen Filmen.
* Sichtbare Antwort auf ein interaktives Kommando (z.B. Mausklick): ca. 1/2s
: Wird diese Antwortzeit überschritten, vermuten viele Benutzer, dass der Mausklick nicht funktioniert hat, und klicken nochmals, mit eventuell fatalen Folgen. Wenn ein Algorithmus notwendigerweise länger dauert als 1/2s, sollte ein Fortschrittsbalken angezeigt werden.
* Wettervorhersage: muss spätestens am Vorabend des vorhergesagten Tages beendet sein

===Laufzeitvergleich===

Da die Laufzeit für den Benutzer ein so wichtiges Kriterium ist, werden häufig Laufzeitvergleiche durchgeführt. Deren Ergebnisse hängen allerdings von vielen Faktoren ab, die möglicherweise nicht kontrollierbar sind:
* Geschwindigkeit und Anzahl der Prozessoren
* Auslastung des Systems
* Größe des Hauptspeichers und Cache, Geschwindigkeit des Datenbus
* Qualität des Compilers/Optimierers (ist der Compiler für die spezielle Prozessor-Architektur optimiert?)
* Geschick des Programmierers
* Daten (Beispiel Quicksort: Best case und worst case [vorsortierter Input] stark unterschiedlich)
All diese Faktoren sind untereinander abhängig. Laufzeitvergleiche sind daher mit Vorsicht zu interpretieren.
Generell sollten bei Vergleichen möglichst wenige Parameter verändert werden, z.B.
* gleiches Programm (gleiche Kompilierung), gleiche Daten, andere Prozessoren
oder
* gleiche CPU, Daten, andere Programme (Vergleich von Algorithmen)
Zur Verbesserung der Vergleichbarkeit gibt es standardisierte [http://en.wikipedia.org/wiki/Benchmark_(computing) Benchmarks], die bestimmte Aspekte eines Systems unter möglichst realitätsnahen Bedingungen testen. Generell gilt aber: Durch Laufzeitmessung ist schwer festzustellen, ob ein Algorithmus ''prinzipiell'' besser ist als ein anderer. Dafür ist die Analyse der [[Effizienz#Algorithmen-Komplexität|Algorithmenkomplexität]] notwendig.

===Optimierung der Laufzeit===

Wenn sich herausstellt, dass ein bereits implementierter Algorithmus zu langsam läuft, geht man wie folgt vor:

# Man verwendet einen [http://en.wikipedia.org/wiki/Performance_analysis Profiler], um zunächst den Flaschenhals zu bestimmen. Ein Profiler ist ein Hilfsprogramm, das während der Ausführung eines Programms misst, wieviel Zeit in jeder Funktion und Unterfunktion verbraucht wird. Dadurch kann man herausfinden, welcher Teil des Algorithmus überhaupt Probleme bereitet. Donald Knuth gibt z.B. als Erfahrungswert an, dass Programme während des größten Teils ihrer Laufzeit nur 3% des Quellcodes (natürlich mehrmals wiederholt) ausführen [http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf]. Es ist sehr wichtig, diese 3% experimentell zu bestimmen, weil die Erfahrung zeigt, dass man beim Erraten der kritischen Programmteile oft falsch liegt. Man spricht dann von "[http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize premature optimization]", also von voreiliger Optimierung ohne experimentelle Untersuchung der wirklichen Laufzeiten, was laut Knuth "the root of all evil" ist. Der Python-Profiler wird in [http://docs.python.org/lib/profile.html Kapitel 25] der Python-Dokumentation beschrieben.
# Man kann dann versuchen, die kritischen Programmteile zu optimieren.
# Falls der Laufzeitgewinn durch Optimierung zu gering ist, muss man einen prinzipiell schnelleren Algorithmus verwenden, falls es einen gibt.

Einige wichtige Techniken der Programmoptimierung sollen hier erwähnt werden. Wenn man einen optimierenden Compiler verwendet, werden einige Optimierungen automatisch ausgeführt [http://en.wikipedia.org/wiki/Compiler_optimization]. In Python trifft dies jedoch nicht zu. Um den Sinn einiger Optimierungen zu verstehen, benötigt man Grundkenntnisse der Computerarchitektur.

;Elimination von redundantem Code: Es ist offensichtlich überflüssig, dasselbe Ergebnis mehrmals zu berechnen, wenn es auch zwischengespeichert werden könnte. Diese Optimierung wird von vielen automatischen Optimierern unterstützt und kommt im wesentlichen in zwei Ausprägungen vor:
:; common subexpression elimination: In mathematischen Ausdrücken wird ein Teilergebnis häufig mehrmals benötigt. Man betrachte z.B. die Lösung der quadratischen Gleichung <math>x^2+p\,x+q = 0</math>:
x1 = - p / 2.0 + sqrt(p*p/4.0 - q)
x2 = - p / 2.0 - sqrt(p*p/4.0 - q)
::Die mehrmalige Berechnung von Teilausdrücken wird vermieden, wenn man stattdessen schreibt:
p2 = - p / 2.0
r = sqrt(p2*p2 - q)
x1 = p2 + r
x2 = p2 - r
:; loop invariant elimination: Wenn ein Teilausdruck sich in einer Schleife nicht ändert, muss man ihn nicht bei jedem Schleifendurchlauf neu berechnen, sondern kann dies einmal vor Beginn der Schleife tun. Ein typisches Beispiel hierfür ist die Adressierung von Matrizen, die als 1-dimensionales Array gespeichert sind. Angenommen, wir speichern eine NxN Matrix <tt>m</tt> in einem Array <tt>a</tt> der Größe N2, so dass das Matrixelement <tt>mij</tt> durch <tt>a[i + j*N]</tt> indexiert wird. Wir betrachten die Aufgabe, eine Einheitsmatrix zu initialisieren. Ein nicht optimierter Algorithmus dafür lautet:
for j in range(N):
for i in range(N):
if i == j:
a[i + j*N] = 1.0
else:
a[i + j*N] = 0.0
::Der Ausdruck <tt>j*N</tt> wird hier in jedem Schleifendurchlauf erneut berechnet, obwohl sich <tt>j</tt> in der inneren Schleife gar nicht verändert. Man kann deshalb optimieren zu:
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
;Vereinfachung der inneren Schleife: Generell sollte man sich bei der Optimierung auf die innere Schleife eines Algorithmus konzentrieren, weil dieser Code am häufigsten ausgeführt wird. Insbesondere sollte man die Anzahl der Befehle in der inneren Schleife so gering wie möglich halten und teure Befehle vermeiden. Früher waren vor allem Floating-Point Befehle teuer, die man oft durch die schnellere Integer-Arithmetik ersetzt hat, falls dies algorithmisch möglich war (diesen Rat findet man noch oft in der Literatur). Heute hat sich die Hardware so verbessert, dass im Allgemeinen nur noch die Floating-Point Division deutlich langsamer ist als die anderen Operatoren. Im obigen Beispiel der quadratischen Gleichung ist es daher sinnvoll, den Ausdruck
p2 = -p / 2.0
:durch
p2 = -0.5 * p
:zu ersetzen. Dadurch ersetzt man eine Division durch eine Multiplikation und spart außerdem das Negieren von <tt>p</tt>, da der Compiler direkt mit <tt>-0.5</tt> multipliziert.
;Ausnutzung der Prozessor-Pipeline: Moderne Prozessoren führen mehrere Befehle parallel aus. Dies ist möglich, weil jeder Befehl in mehrere Teilschritte zerlegt werden kann. Eine generische Unterteilung in vier Teilschritte ist z.B.:
:# Dekodieren des nächsten Befehls
:# Beschaffen der Daten, die der Befehl verwendet (aus Prozessorregistern, dem Cache, oder dem Hauptspeicher)
:# Ausführen des Befehls
:# Schreiben der Ergebnisse
:Man bezeichnet dies als die "[http://en.wikipedia.org/wiki/Instruction_pipeline instruction pipeline]" des Prozessors (heutige Prozessoren verwenden wesentlich feinere Unterteilungen). Prozessoren werden nun so gebaut, dass mehrere Befehle parallel, auf verschiedenen Ausführungsstufen ausgeführt werden. Wenn Befehl 1 also beim Schreiben der Ergebnisse angelangt ist, kann Befehl 2 die Hardware zum Ausführen des Befehls benutzen, während Befehl 3 seine Daten holt, und Befehl 4 soeben dekodiert wird. Unter bestimmten Bedingungen funktioniert diese Parallelverarbeitung jedoch nicht. Dies gibt Anlass zu Optimierungen:
:;Vermeiden unnötiger Typkonvertierungen: Der Prozessor verarbeitet Interger- und Floating-Point-Befehle in verschiedenen Pipelines, weil die Hardwareanforderungen sehr verschieden sind. Wird jetzt ein Ergebnis von Integer nach Floating-Point umgewandelt oder umgekehrt, muss die jeweils andere Pipeline warten, bis die erste Pipeline ihre Berechnung beendet. Es kann dann besser sein, Berechnungen in Floating-Point zu Ende zu führen, auch wenn sie semantisch eigentlich Integer-Berechnungen sind.
:;Reduzierung der Anzahl von Verzweigungen: Wenn der Code verzweigt (z.B. durch eine <tt>if</tt>- oder <tt>while</tt>-Anweisung), ist nicht klar, welcher Befehl nach der Verzweigung ausgeführt werden soll, bevor Stufe 3 der Pipeline die Verzweigungsbedingung ausgewertet hat. Bis dahin wären die ersten beiden Stufen der Pipeline unbenutzt. Moderne Prozessoren benutzen zwar ausgefeilte Heuristiken, um das Ergebnis der Bedingung vorherzusagen, und führen den hoffentlich richtigen Zweig des Codes spekulativ aus, aber dies funktioniert nicht immer. Man sollte deshalb generell die Anzahl der Verzweigungen minimieren. Als Nebeneffekt führt dies meist auch zu besser lesbarem, verständlicherem Code. Im Matrixbeispiel kann man
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
::durch
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
ersetzen. Die Diagonalelemente <tt>a[j + jN]</tt> werden jetzt zwar zweimal initialisiert (in der Schleife auf Null, dann auf Eins), aber durch Elimination der <tt>if</tt>-Abfrage wird dies wahrscheinlich mehr als ausgeglichen, zumal dadurch die innere Schleife wesentlich vereinfacht wurde.
;Ausnutzen des Prozessor-Cache: Zugriffe auf den Hauptspeicher sind sehr langsam. Deshalb werden stets ganze Speicherseiten auf einmal in den [http://en.wikipedia.org/wiki/Cache Cache] des Prozessors geladen. Wenn unmittelbar nacheinander benutzte Daten auch im Speicher nahe beieinander liegen (sogenannte "[http://en.wikipedia.org/wiki/Locality_of_reference locality of reference]"), ist die Wahrscheinlichkeit groß, dass die als nächstes benötigten Daten bereits im Cache sind und damit schnell gelesen werden können. Bei vielen Algorithmen kann man die Implementation so umordnen, dass die locality of reference verbessert wird, was zu einer drastischen Beschleunigung führt. Im Matrix-Beispiel ist z.B. die Reihenfolge der Schleifen wichtig. Für konstanten Index <tt>j</tt> liegen die Indizes <tt>i</tt> im Speicher hintereinander. Deshalb ist es günstig, in der inneren Schleife über <tt>i</tt> zu iterieren:
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
:Die umgekehrte Reihenfolge der Schleifen ist hingegen ungünstig
for i in range(N):
for j in range(N):
a[i + j*N] = 0.0
a[i + i*N] = 1.0
:Jetzt werden in der inneren Schleife stets N Datenelemente übersprungen. Besonders bei großem N muss man daher häufig den Cache neu füllen, was bei der ersten Implementation nicht notwendig war. (Außerdem verliert man hier die Optimierung <tt>jN = j*N</tt>, die jetzt nicht mehr möglich ist.)

Als Faustregel kann man durch Optimierung eine Verdoppelung der Geschwindigkeit erreichen (in Ausnahmefällen auch mehr). Benötigt man stärkere Verbesserungen, muss man wohl oder übel einen besseren Algorithmus oder einen schnelleren Computer verwenden.

== Algorithmen-Komplexität ==

Komplexitätsbetrachtungen ermöglichen den Vergleich der prinzipiellen Eigenschaften von Algorithmen unabhängig von einer Implementation, Umgebung etc.

Eine einfache Möglichkeit ist das Zählen der Aufrufe einer Schlüsseloperation. Beispiel Sortieren:
* Anzahl der Vergleiche
* Anzahl der Vertauschungen

=== Beispiel: Selection Sort ===

for i in range(len(a)-1):
max = i
for j in range(i+1, len(a)):
if a[j] < a[max]:
max = j
a[max], a[i] = a[i], a[max] # swap

*Anzahl der Vergleiche: Ein Vergleich in jedem Durchlauf der inneren Schleife. Es ergibt sich folgende Komplexität:
*:Ingesamt <math>\sum_{i=0}^{N-2} \sum_{j=i+1}^{N-1}1 = \frac{N}{2} (N-1) \!</math> Vergleiche.

*Anzahl der Vertauschungen (swaps): Eine Vertauschung pro Durchlauf der äußeren Schleife:
*:Insgesamt <math>N-1 \!</math> Vertauschungen

Die Komplexität wird durch die Operationen bestimmt, die am häufigsten ausgeführt werden, hier also die Anzahl der Vergleiche. Die Anzahl der Vertauschungen ist hingegen kein geeignetes Kriterium für die Komplexität von selection sort, weil der Aufwand in der inneren Schleife ignoriert würde.

=== Fallunterscheidung: Worst und Average Case ===

Die Komplexität ist in der Regel eine Funktion der Eingabegröße (Anzahl der Eingabebits, Anzahl der Eingabeelemente). Sie kann aber auch von der Art der Daten abhängen, nicht nur von der Menge, z.B. vorsortierte Daten bei Quicksort. Um von der Art der Daten unabhängig zu werden, kann man zwei Fälle der Komplexität unterscheiden:

* Komplexität im ungünstigsten Fall
*: Der ungünstigste Fall ist die Eingabe gegebener Länge, für die der Algorithmus am langsamsten ist. Der Nachteil dieser Methode besteht darin, dass dieser ungünstige Fall in der Praxis vielleicht gar nicht oder nur selten vorkommt, so dass sich der Algorithmus in Wirklichkeit besser verhält als man nach dieser Analyse erwarten würde. Beim Quicksort-Algorithmus mit zufälliger Wahl des Pivot-Elements müsste z.B. stets das kleinste oder größte Element des aktuellen Intervalls als Pivot-Element gewählt werden, was äußerst unwahrscheinlich ist.
* Komplexität im durchschnittlichen/typischen Fall
*: Der typische Fall ist die mittlere Komplexität des Algorithmus über alle möglichen Eingaben. Dazu muss man die Wahrscheinlichkeit jeder möglichen Eingabe kennen, und berechnet dann die mittlere Laufzeit über dieser Wahrscheinlichkeitsverteilung. Leider ist die Wahrscheinlichkeit der Eingaben oft nicht bekannt, so dass man geeignete Annahmen treffen muss. Bei Sortieralgorithmen können z.B. alle möglichen Permutationen des Eingabearrays als gleich wahrscheinlich angenommen werden, und der typische Fall ist dann die mittlere Komplexität über alle diese Eingaben. Oft hat man jedoch in der Praxis andere Wahrscheinlichkeitsverteilungen, z.B. sind die Daten oft "fast sortiert" (nur wenige Elemente sind an der falschen Stelle). Dann verhält sich der Algorithmus ebenfalls anders als vorhergesagt.

Wir beschränken uns in dieser Vorlesung auf die Komplexität im ungünstigseten Fall. '''Exakte''' Formeln für Komplexität sind aber auch dann schwer zu gewinnen, wie das folgende Beispiel zeigt:

=== Beispiele aus den Übungen (Gemessene Laufzeiten für Mergesort/Selectionsort) ===

* Mergesort: <math>\frac{0,977N\log N}{\log 2} + 0,267N-4.39 \!</math>
*: andere Lösung: <math>1140 N\log(N) - 1819N + 6413 \!</math>
* Selectionsort: <math>\frac{1}{2}N^2 - \frac{1}{2N} - 10^{-12} \!</math>
*: andere Lösung: <math>1275N^2 - 116003^N + 11111144 \!</math>

Aus diesen Formeln wird nicht offensichtlich, welcher Algorithmus besser ist.
Näherung: Betrachte nur '''sehr große Eingaben''' (meist sind alle Algorithmen schnell genug für kleine Eingaben). Dieses Vorgehen wird als '''Asymptotische Komplexität''' bezeichnet (N gegen unendlich).

=== Asymptotische Komplexität am Beispiel Polynom ===

Polynom: <math>a\,x^2+b\,x+c=p\!</math>

<math>x \!</math> sei die Eingabegröße, und wir betrachten die Entwicklung von <math>p \!</math> in Abhängigkeit von <math>x \!</math>.

* <math>x=0 \!</math>
*: <math>p=c \!</math>
* <math>x=1 \!</math>
*: <math>p=a+b+c \!</math>
* <math>x=1000 \!</math>
*: <math>p=1000000a+1000b+c \approx 1000000a\!</math>
* <math>x \to \infty \!</math>
*: <math>p \approx x^2a\!</math>

Für sehr große Eingaben verlieren also ''b'' und ''c'' immer mehr an Bedeutung, so dass am Ende nur noch ''a'' für die Komplexitätsbetrachtung wichtig ist.

== Landau-Symbole ==

Um die asymptotische Komplexität verschiedener Algorithmen miteinander vergleichen zu können, verwendet man die sogenannten [http://de.wikipedia.org/wiki/Landau-Symbole Landau-Symbole]. Das wichtigste Landau-Symbol ist <math>\mathcal{O}</math>, mit dem man eine ''obere Schranke'' <math>f \in \mathcal{O}(g)</math> für die Komplexität angeben kann.

Schreibt man <math>f \in \Omega(g)</math>, so stellt dies eine asymptotische ''untere Schranke'' für die Funktion f dar.

Schließlich bedeutet <math>f \in \Theta(g)</math>, dass die Funktion f genauso schnell wie die Funktion g wächst, das heißt man hat eine asymptotisch ''scharfe Schranke'' für f. Hierzu muss sowohl <math>f\in\mathcal{O}(g)</math> als auch <math>f \in \Omega(g)</math> erfüllt sein.

Im nun folgenden soll auf die verschiedenen Landau-Symbole noch näher eingegeangen werden.

===O-Notation===

Intuitiv gilt: Für große N dominieren die am schnellsten wachsenden Terme einer Funktion. Die Notation <math>f \in \mathcal{O}(g)</math> (sprich "f ist in O von g" oder "f ist von derselben Größenordnung wie g") formalisiert eine solche Abschätzung der asymptotischen Komplexität der Funktion f von oben.
; Asymptotische Komplexität: Für zwei Funktionen f(x) und g(x) gilt
::<math>f(x) \in \mathcal{O}(g(x))</math>
: genau dann wenn es eine Konstante <math>c>0</math> und ein Argument <math>x_0</math> gibt, so dass
::<math>\forall x \ge x_0:\quad f(x) \le c\,g(x)</math>.
:Die Menge <math>\mathcal{O}(g(x))</math> aller durch g(x) abschätzbaren Funktionen ist also formal definiert durch
::<math>\mathcal{O}(g(x)) = \{ f(x)\ |\ \exists c>0: \forall x \ge x_0: 0 \le f(x) \le c\,g(x)\}</math>

Die Idee hinter dieser Definition ist, dass g(x) eine wesentlich einfachere Funktion ist als f(x), die sich aber nach geeigneter Skalierung (Multiplikation mit c) und für große Argumente x im wesentlichen genauso wie f(x) verhält. Man kann deshalb in der Algorithmenanalyse f(x) durch g(x) ersetzen. <math>f(x) \in \mathcal{O}(g(x))</math> spielt für Funktionen eine ähnliche Rolle wie der Operator ≤ für Zahlen: Falls a ≤ b gilt, kann bei einer Abschätzung von oben ebenfalls a durch b ersetzt werden.

==== Ein einfaches Beispiel ====

[[Image:Sqsqrt.png]]

Rot = <math>x^2 \!</math>
Blau = <math>\sqrt{x} \!</math>

<math>\sqrt{x} \in \mathcal{O}(x^2)\!</math> weil <math>\sqrt{x} \le c\,x^2\!</math> für alle <math>x \ge x_0 = 1 \!</math> und <math>c = 1\!</math>, oder auch für <math>x \ge x_0 = 4 \!</math> und <math>c = 1/16</math> (die Wahl von c und x0 in der Definition von O(.) ist beliebig, solange die Bedingungen erfüllt sind).

==== Komplexität bei kleinen Eingaben ====

Algorithmus 1: <math>\mathcal{O}(N^2) \!</math> 
Algorithmus 2: <math>\mathcal{O}(N\log{N}) \!</math>

Algorithmus 2 ist schneller (von geringerer Komplexität) für große Eingaben, aber bei kleinen Eingaben (insbesondere, wenn der Algorithmus in einer Schleife immer wieder mit kleinen Eingaben aufgerufen wird) könnte Algorithmus 1 schneller sein, falls der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor ''c'' bei Algorithmus 2 einen wesentlich größeren Wert hat als bei Algorithmus 1.

==== Eigenschaften der O-Notation (Rechenregeln) ====

# Transitiv:
#: <math>f(x) \in \mathcal{O}(g(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) \in \mathcal{O}(h(x)) \!</math>
# Additiv:
#: <math>f(x) \in \mathcal{O}(h(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) + g(x) \in \mathcal{O}(h(x)) \!</math>
# Für Monome gilt:
#: <math>x^k \in \mathcal{O}(x^k)</math> und
#: <math>x^k \in \mathcal{O}(x^{k+j}), \forall j \ge 0 \!</math>
# Multiplikation mit einer Konstanten:
#: <math>f(x) \in \mathcal{O}(g(x)) \to c\,f(x) \in \mathcal{O}(g(x))\!</math>
#: andere Schreibweise:
#: <math>f(x) = c\,g(x) \to f(x) \in \mathcal{O}(g(x))\!</math>
# Folgerung aus 3. und 4. für Polynome:
#: <math>a_0+a_1\,x + ... + a_n\,x^n \in \mathcal{O}(x^n)\!</math>
#: Beispiel: <math>a\,x^2+b\,x+c \in \mathcal{O}(x^2)\!</math>
# Logarithmus:
#: <math>a, b > 1\!</math>
#: <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>
#: Die Basis des Logarithmus spielt also keine Rolle.
#: Beweis hierfür:
#:: <math>\log_{a}{x} = \frac{\log_{b}{x}}{\log_{b}{a}}\!</math>
#:: Mit <math>c = 1 / \log_{b}{a}\,</math> gilt: <math>\log_{a}{x} = c\,\log_{b}{x}\!</math>.
#:: Wird hier die (zweite) Regel für Multiplikation mit einer Konstanten angewendet, fällt der konstante Faktor weg, also <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>.
#: Insbesondere gilt auch <math>\log_{a}{x} \in \mathcal{O}(\log_{2}{x})\!</math>, es kann also immer der 2er Logarithmus verwendet werden.

==== O-Kalkül ====

Das O-Kalkül definiert wichtige Vereinfachungsregeln for Ausdrücke in O-Notation (Beweise: siehe Übungsaufgabe):

# <math>f(x) \in \mathcal{O}(f(x))\!</math>
# <math>\mathcal{O}(\mathcal{O}(f(x))) \in \mathcal{O}(f(x))\!</math>
# <math>c\,\mathcal{O}(f(x)) \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# <math>\mathcal{O}(f(x))+c \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# Sequenzregel:
#: Wenn zwei nacheinander ausgeführte Programmteile die Komplexität <math>\mathcal{O}(f(x))</math> bzw. <math>\mathcal{O}(g(x))</math> haben, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(f(x))</math> falls <math>g(x) < \mathcal{O}(f(x))</math> bzw.
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(g(x))\!</math> falls <math>f(x) < \mathcal{O}(g(x))</math>.
#: Informell schreibt man auch: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(max(f(x), g(x)))\!</math>.
# Schachtelungsregel bzw. Aufrufregel:
#: Wenn in einer geschachtelten Schleife die äußere Schleife die Komplexität <math>\mathcal{O}(f(x))</math> hat, und die innere <math>\mathcal{O}(g(x))</math>, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) * \mathcal{O}(g(x)) \in \mathcal{O}(f(x) * g(x))\!</math>.
#: Gleiches gilt wenn eine Funktion <math>\mathcal{O}(f(x))</math>-mal aufgerufen wird, und die Komplexität der Funktion selbst <math>\mathcal{O}(g(x))</math> ist.

;Beispiel für 5.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Dies gilt auch für ihre Hintereinanderausführung:
for i in range(N):
a[i] = i
for i in range(N):
print a[i]
;Beispiele für 6.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Ihre Verschachtelung hat daher die Komplexität <math>\mathcal{O}(N^2)</math>.
for i in range(N):
for j in range(N):
a[i*N + j] = i+j
: Dies gilt ebenso, wenn statt der inneren Schleife eine Funktion mit Komplexität <math>\mathcal{O}(N)</math> ausgeführt wird:
for i in range(N):
a[i] = foo(i, N) # <math>\mathrm{foo}(i, N) \in \mathcal{O}(N)</math>

==== O-Kalkül auf das Beispiel des Selectionsort angewandt ====

Selectionsort: Wir hatten gezeigt dass <math>f(N) = \frac{N^2}{2} - \frac{N}{2}</math>. Nach der Regel für Polynome vereinfacht sich dies zu <math>f(N) \in \mathcal{O}\left(\frac{N^2}{2}\right) = \mathcal{O}(N^2)\!</math>.

Alternativ via Schachtelungsregel:
: Die äußere Schleife wird (''N''-1)-mal durchlaufen: <math>N-1 \in \mathcal{O}(N)</math>
: Die innere Schleife wird (''N-i''-1)-mal durchlaufen. Das sind im Mittel ''N''/2 Durchläufe: <math>N/2 \in \mathcal{O}(N)</math>
: Zusammen: <math>\mathcal{O}(N)*\mathcal{O}(N) \in \mathcal{O}(N^2)</math>

Nach beiden Vorgehensweisen kommen wir zur Schlussfolgerung, dass der Selectionsort die asymptotische Komplexität <math>\mathcal{O}(N^2)\!</math> besitzt.

==== Zusammenhang zwischen Komplexität und Laufzeit ====

Wenn eine Operation 1ms dauert, erreichen Algorithmen verschiedener Komplexität folgende Leistungen (wobei angenommen wird, dass der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor immer etwa gleich 1 ist):

{| class="wikitable" style="text-align:left" cellpadding="7"
|+
|-
! Komplexität !! Operationen in 1s !! Operationen in 1min !! Operationen in 1h
|-
! <math>\mathcal{O}(N)</math>
| 1000 || 60.000 || 3.600.000
|-
! <math>\mathcal{O}(N\log_2{N})</math>
| 140 || 4895 || 204094
|-
! <math>\mathcal{O}(N^2)</math>
| 32 || 245 || 1898
|-
! <math>\mathcal{O}(N^3)</math>
| 10 || 39 || 153
|-
! <math>\mathcal{O}(2^N)</math>
| 10 || 16 || 21
|}

==== Exponentielle Komplexität ====
Der letzte Fall <math>\mathcal{O}(2^N)</math> ist von exponentieller Komplexität. Das bedeutet, dass eine Verdopplung des Aufwands nur bewirkt, dass die maximale Problemgröße um eine Konstante wächst. Algorithmen mit exponentieller (oder noch höherer) Komplexität werden deshalb als '''ineffizient''' bezeichnet. Algorithmen mit höchstens polynomieller Komplexität gelten hingegen als effizient.

In der Praxis sind allerdings auch polynomielle Algorithmen mit hohem Exponenten meist zu langsam. Als Faustregel kann man eine praktische Grenze von <math>\mathcal{O}(N^3)</math> ansehen. Bei einer Komplexität von <math>\mathcal{O}(N^3)</math> bewirkt ein verdoppelter Aufwand immer noch eine Steigerung der maximalen Problemgröße um den Faktor <math>\sqrt[3]{2}</math> (also eine ''multiplikative'' Vergrößerung um ca. 25%, statt nur einer additiven Vergrößerung wie bei exponentieller Komplexität).

===<math>\Omega</math>- Notation===

Genauso wie <math>f \in \mathcal{O}(g)</math> eine Art <math>\le</math>-Operator für Funktionen ist, definiert <math>f \in \Omega(g) </math> eine Abschätzung von unten, analog zum <math>\ge</math>-Operator für Zahlen. Formal kann man <math>f(N) \in \Omega(g(N)) </math> genau dann schreiben, falls es eine Konstante <math> c > 0 </math> gibt, so dass

<math> f(N) \ge c \cdot g(N) </math> für <math> N \ge N_0 </math>

gilt.
Man verwendet diese Notation also um abzuschätzen, wie groß der Aufwand (die Komplexität) für einen bestimmten Algorithmus ''mindestens'' ist und nicht ''höchstens'', was man mit der <math>\mathcal{O}</math> - Notation ausdrücken würde.

Ein praktisches Beispiel für eine Anwendung der <math>\Omega</math>- Notation wäre die Fragestellung, ob es ''prinzipiell'' einen besseren Algorithmus für ein bestimmtes Problem gibt. Wie später im Abschnitt [[Suchen#Sortieren_als_Suchproblem|Sortieren als Suchproblem]] gezeigt wird, ist das Sortieren eines Arrays durch paarweise Vergleiche von Elementen immer mindestens von der Komplexität <math> \Omega(N\cdot \ln N) </math>, was konkret bedeutet, dass kein Sortieralgorithmus, der nach diesem Prinzip arbeitet, jemals eine geringere Komplexität als beispielsweise Merge-Sort haben wird. Natürlich kann man den entsprechenden Sortieralgorithmus, also Merge-Sort zum Beispiel, unter Umständen noch optimieren, aber die Komplexität wird erhalten bleiben. Mit diesem Wissen kann man sich viel (vergebliche) Arbeit sparen.

===<math>\Theta</math>- Notation===

<math>f(N) \in \Theta(g(N))</math> ist eine scharfe Abschätzung der asymptotischen Komplexität einer Funktion f.

Damit dies gilt, muss <math>f(N) \in \mathcal{O}(g(N))</math> und ''gleichzeitig'' <math>f(N) \in \Omega(g(N))</math> erfüllt sein.

Dies ist natürlich auch die beste Abschätzung der asymptotischen Komplexität einer Funktion f. Formal bedeutet <math>f(N) \in \Theta(g(N))</math> dass es zwei Konstanten <math> c_1 </math> und <math> c_2 </math>, beide größer als Null, gibt, so dass für alle <math> N \geq N_0 </math> gilt:

<math> c_1 \cdot g(N) \leq f(N) \leq c_2 \cdot g(N) </math>.

In der Praxis wird manchmal statt der <math>\Theta</math>-Notation auch dann die <math>\mathcal{O}</math>-Notation benutzt, wenn eine scharfe Schranke ausgedrückt werden soll. Dies ist zwar formal nicht korrekt, aber man kann die intendierte Bedeutung meist aus dem Kontext erschließen.

== Komplexitätsvergleich zweier Algorithmen ==

In diesem Abschnitt wollen wir der Frage nachgehen, wie ein formaler Beweis für die Behauptung <math> f(N) \in \mathcal{O}(g(N))</math> geschehen kann. Hierbei werden zwei Beweismethoden vorgestellt werden, und zwar der '''Beweis über die Definition der Komplexität''' sowie der '''Beweis durch Dividieren'''.

===Beweis über die Definition der asymptotischen Komplexität===

Die Definition der asymptotischen Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> war:

Es gibt eine Konstante <math> c > 0 </math>, so dass <math> f(N) \le c \cdot g(N) </math> für <math> N \ge N_0 </math> erfüllt ist.

Um also die die asymptotische Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> zu beweisen, muss man die oben erwähnten Konstanten c und <math> N_0 </math> finden, so dass

<math> f(N) \leq c \cdot g(N) </math> für alle <math> N \ge N_0 </math> erfüllt ist.

Dies geschieht zweckmäßigerweise mit dem Beweisprinzip der ''vollständigen Induktion''. Hierbei ist zu zeigen, dass
# <math> f(N_0) \leq g(N_0) </math> für die eine zu bestimmende Konstante <math> N_0 </math> gilt (''Induktionsanfang'') und
# falls <math> f(N) \leq g(N) </math>, dann auch <math> f(N+1) \leq g(N+1) </math> (''Induktionsschritt'') gilt.

===Beweis durch Dividieren===

Hierbei wählt man eine Konstante c und zeigt, dass <math> \lim_{N \rightarrow \infty} \frac{f(N)}{c \cdot g(N)} \leq 1 </math> gilt (für die O-Notation, bei Ω-Notation gilt entsprechend <math>\geq 1 </math>). Man kann dies auch als alternative Definition der Komplexität verwenden.

Als Beispiel betrachten wir die beiden Funktionen <math> f(N) = N \,\lg N </math> und <math> g(N) = N^2 </math> und wollen zeigen, dass <math>f(N) \in \mathcal{O}(g(N))</math> gilt.

Als Konstante c wählen wir <math> c = 1 </math>

<math> \lim_{N \rightarrow \infty} \frac{f(N)}{g(N)} = \lim_{N \rightarrow \infty} \frac{\lg N}{N} = \frac{\infty}{\infty} </math>

Unbestimmte Ausdrücke der Form
<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} </math>,
in denen sowohl <math> f(x) </math> als auch <math> g(x) </math> mit <math> x \rightarrow x_0 </math> gegen Null oder gegen Unendlich streben, kann man manchmal mit den Regeln von [http://de.wikipedia.org/wiki/L%27Hospital%27sche_Regel ''l'Hospital''] berechnen. Danach darf man die Funktionen f und g zur Berechnung des unbestimmten Ausdrucks durch ihre k-ten Ableitungen ersetzen:

<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} = \lim_{x \rightarrow x_0} \frac{f^{(k)}(x)}{g^{(k)}(x)} </math>

In unserem Fall verwenden wir die erste Ableitung und erhalten:
<math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)} = \lim_{N \rightarrow \infty} \frac{1/N}{1} \rightarrow 0 </math>

Damit wurde <math>f(N) \in \mathcal{O}(g(N))</math>, also <math>N \lg N \in \mathcal{O}(N^2)</math> gezeigt.

Man beachte hierbei, dass <math>N \lg N \in \mathcal{O}(N^2)</math> keine enge Grenze für die Komplexität von <math>N \,\lg N</math> darstellt, da der Grenzwert <math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)}\, </math> gegen 0 und nicht gegen eine von Null verschiedene Konstante strebt. In diesem Fall haben wir die Komplexität von <math>N \cdot \lg N </math> also nur nach oben abschätzen können.

===Beispiel für den Komplexitätsvergleich: Gleitender Mittelwert (Running Average)===

Wir berechnen für ein gegebenes Array <tt>a</tt> einen gleitenden Mittelwert über <tt>k</tt> Elemente: 
::<math>r_i = \frac{1}{k} \sum_{j=i-k+1}^i a_j</math> 
Das heisst, für jedes <tt>i</tt> mitteln wir die letzten <tt>k</tt> Elemente von <tt>a</tt> und schreiben das Ergebnis in <tt>r[i]</tt>. Diese Operation ist z.B. bei Börsenkursen wichtig: Neben dem aktuellen Kurs für jeden Tag wird dort meist auch der gleitende Mittelwert der letzten 30 Tage sowie der letzten 200 Tage angegeben. In diesen Mittelwerten erkennt man besser die langfristige Tendenz, weil die täglichen Schwankungen herausgemittelt werden. Wir nehmen außerdem an, dass
* Array-Zugriff hat eine Komplexität von O(1)
* <math>k \ll N</math>, d.h. <math>N-k\approx N</math>.

Die beiden folgenden Algorithmen berechnen die Mittelwerte auf unterschiedliche Art. Der linke folgt der obigen Definition durch eine Summe, während der rechte inkrementell arbeitet: Man kann den Bereich der <tt>k</tt> letzten Werte als Fenster betrachten, das über das Array <tt>a</tt> geschoben wird. Schiebt man das Fenster ein Element weiter, fällt links ein Element heraus, und rechts kommt eins hinzu. Man muss also nicht jedes Mal die Summe neu berechnen, sondern kann den vorigen Wert aktualisieren. Wir werden sehen, dass dies Folgen für die Komplexität des Algorithmus hat.

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1: O(N * k)
! Komplexität
! Version 2: O(N)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|
<tt>for i in range(k):</tt>
|
'''<center>O(k)</center>'''
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|
:: <tt>r[k-1] += a[i]</tt>
|
'''<center>O(1)</center>'''
|-
|
6.
|
:::: <tt>r[j] += a[i]</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(k, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|
:: <tt>r[j] = (a[j] - a[j-k] + r[j-1])</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(len(a)):</tt>
|
'''<center>O(N)</center>'''
|-
|
9.
|

|

|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
10.
|

|

|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Wir zeigen unten dass Version 2 eine geringere Komplexität besitzt, obwohl sie mehr Zeilen benötigt.

Wir haben in der Tabelle die Komplexität jeder Zeile für sich angegeben. Einfache Anweisungen (Berechnungen, Lese- und Schreibzugriffe auf das Array, Zuweiseungen) haben konstante Komplexität, die Komplexität des Schleifenkopfes allein (also der <tt>for</tt>-Anweisung ohne den eingerückten Schleifenkörper) entspricht der Anzahl der Durchläufe. Wir müssen jetzt noch die Verschachtelung der Schleifen und die Nacheinanderausführung von Anweisungen berücksichtigen.

====Berechnung der Komplexität von Version 1====

(Wiederholung der Rechenregeln: siehe Abschnitt [[Effizienz#O-Notation|O-Notation]])

Wir betrachten zunächst die innere Schleife (Zeilen 5 und 6 von Version 1):

Der Schleifenkopf (Zeile 5) hat die Komplexität <math>\mathcal{O}(k)</math>, weil die Schleife k-mal durchlaufen wird. Der Schleifenkörper (Zeile 6) hat die Komplexität <math>\mathcal{O}(1)</math>. Nach der Verschachtelungsregel müssen wir die beiden Komplexitäten multiplizieren, und es ergibt sich:

::<math>\mathcal{O}(k)\cdot\mathcal{O}(1) = \mathcal{O}(k\cdot 1)=\mathcal{O}(k)</math>

Wir betrachten nun die äußere Schleife. Der Schleifenkopf (Zeile 4) wird (N-k)-mal durchlaufen und hat somit eine Komplexität von <math>\mathcal{O}(N)</math>. Der Schleifenkörper (Zeilen 5 bis 7) besteht aus der inneren Schleife (Zeilen 5 und 6) mit der gerade berechneten Komplexität <math>\mathcal{O}(k)</math> sowie einer einfachen Anweisung (Zeile 7) mit Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel wird die Komplexität des Schleifenkörpers durch Addition berechnet:

::<math>\mathcal{O}(k)+\mathcal{O}(1) = \mathcal{O}(\max(k,1)) = \mathcal{O}(k)</math>

Die Komplexität der gesamten äußeren Schleife erhalten wir nach der Verschachtelungsregel wieder durch multiplizieren:

::<math>\mathcal{O}(N)\cdot\mathcal{O}(k) = \mathcal{O}(N\cdot k)</math>

Die übrigen Schritte des Algorithmus werden einfach nacheinander ausgeführt, so dass sie ebenfalls nach der Sequenzregel behandelt werden. Wir erhalten

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(N\cdot k)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,N\cdot k,1)) = \mathcal{O}(N\cdot k)</math>

Der gesamte Algorithmus hat also die Komplexität <math>\mathcal{O}(N\cdot k)</math>.

====Berechnung der Komplexität von Version 2====

Hier gibt es nur einfache Schleifen ohne Verschachtelung. Da der Schleifenkörper jeder Schleife nur einfache Anweisungen der Komplexität <math>\mathcal{O}(1)</math> enthält, ergibt sich die Komplexität der Schleifen nach der Verschachtelungsregel als

::<math>\mathcal{O}(X)\cdot\mathcal{O}(1) = \mathcal{O}(X\cdot 1)=\mathcal{O}(X)</math>

wobei <math>\mathcal{O}(X)</math> die Komplexität des jeweiligen Schleifenkopfes ist. Wir erhalten also für Zeilen 4 und 5: <math>\mathcal{O}(k)</math>, Zeilen 6 und 7: <math>\mathcal{O}(N)</math>, Zeilen 8 und 9: <math>\mathcal{O}(N)</math>. Die Hintereinanderausführung wird nach der Sequenzregel behandelt:

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(k)+\mathcal{O}(N)+\mathcal{O}(N)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,k,N,N,1)) = \mathcal{O}(N)</math>

Dieser Algorithmus hat also nur die Komplexität <math>\mathcal{O}(N)</math>.

====Fazit====

Obwohl Version 2 mehr Schritte benötigt hat sie eine geringere Komplexität, da die for-Schleifen nicht wie bei Version 1 verschachtelt/untergeordnet sind. Bei verschachtelten for-Schleifen muss die Multiplikationsregel angewendet werden → höhere Komplexität.

Die gerade berechnete Komplexität gilt aber nur unter der Annahme, dass Array-Zugriffe konstante Komplexität <math>\mathcal{O}(1)</math> besitzen. Wenn dies nicht der Fall ist, kann sich die Komplexität des Algorithmus drastisch verschlechtern.

{| border="1" cellspacing="0" cellpadding="5"
|Allgemein gilt: 
Algorithmen-Analysen beruhen auf der Annahme, dass Zugriffe auf die Daten optimal schnell sind, dass heißt, dass die für den jeweiligen Algorithmus am besten geeignete Datenstruktur verwendetet wird. → Ansonsten: Komplexitätsverschlechterung!
|}
 

====Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur====

Wir verwende im Mittelwert-Algorithmus eine verkettete Liste anstelle des Eingabe-Arrays a. Wir benötigen dazu eine Funktion, die das j-te Element der Liste zurückgibt. Wie üblich ist die Liste mit Hilfe einer Knotenklasse implementiert:
class Node:
def __init__(self, data):
self.data = data
self.next = None

Die Listenklasse selbst hat ein Feld <tt>head</tt>, das eine Referenz auf den ersten Knoten speichert, und jeder Knoten speichert im Feld <tt>next</tt> eine Referenz auf seinen Nachfolger. Um zum j-ten Element zu gelangen, muss man die Liste sequenziell durchlaufen
def get_jth(list, j):
r = list.head
while j > 0:
r = r.head
j -= 1
return r.data
Die Komplexität dieser Funktion ist offensichtlich <math>\mathcal{O}(j)</math> (Komplexitätsberechnung wie oben). Wir setzen jetzt bei Version 1 des Mittelwert-Algorithmus diese Funktion in Zeile 6 anstelle des Indexzugriffs <tt>a[i]</tt> ein (nur in dieser Zeile wird auf die Elemente des Arrays zugegriffen). Wir erhalten folgende Implementation (die Änderungen sind rot markiert):

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1 mit Liste: O(N * k)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|-
|
6.
|
:::: <tt>r[j] += get_jth(a, i)</tt>
|
'''<center>O(i)</center>'''
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Der Aufruf der Funktion <tt>get_jth</tt> ist jetzt gleichbedeutend mit einer dreifach verschachtelten Schleife (weil <tt>get_jth</tt> ja eine zusatzliche Schleife enthält). Die Anzahl der Operationen in Zeile 4 bis 6 ist jetzt

::<math>f(N,k)=\sum_{j=k-1}^{N-1}\,\sum_{i=j-k+1}^j\,\mathcal{O}(i)</math>

wobei das <math>\mathcal{O}(i)</math> die neue Schleife durch Verwendung der Liste repräsentiert. Mit Mathematica-Hilfe [http://www.wolfram.com/] lässt sich diese Summe exakt ausrechnen

::<math>f(N,k)=\frac{1}{2}(k N^2-k^2 N+k^2-k)\in \mathcal{O}(k N^2)</math>

Die Komplexitätsberechnung erfolgte dabei nach der Regel für Polynome unter Beachtung von <math>k \ll N</math>.

====Fazit:====

Die Komplexität von Version 1 mit einer verketteten Liste wäre O(N2 * k)
'''→ Die richtige Datenstruktur ist wichtig, da es sonst zu einer Komplexitätsverschlechterung kommen kann!'''

Auf Version 2 unseres Running Average-Beispiels hätte eine verkettete Liste allerdings keine Auswirkungen, da die inkrementelle Berechnung der Summen in Zeile 7 weiterhin möglich ist (bei geschickter Implementation!) und somit Version 2 immer noch eine Komplexität von O(N) hätte.

==Amortisierte Komplexität==

Bis jetzt wurde die Komplexität nur im schlechtesten Fall (Worst Case) betrachtet. Bei einigen Operationen schwankt die Komplexität jedoch sehr stark, wenn man sie mehrmals hintereinander ausführt, und der schlechteste Fall kommt nur selten vor. Dann ist es sinnvoll, die amortisierte Komplexität zu betrachten, die sich mit der durchschnittlichen Komplexität über viele Aufrufe der selben Operation beschäftigt.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse Wikipedia: Amortisierte Laufzeitanalyse]]

===Beispiel: Inkrementieren von Binärzahlen===

Frage: Angenommen, das Umdrehen eines Bits einer Binärzahl verursacht Kosten von 1 Einheit. Wir erzeugen die Folge der natürlichen Zahlen in Binärdarstellung durch sukzessives Inkrementieren, von Null beginnend. Bei jeder Inkrementierung werden einige Bits verändert, aber diese Zahl (und damit die Kosten der Inkrementierungen) ''schwanken'' sehr stark. Wir fragen jetzt, was eine Inkrementierung im Durchschnitt kostet?

Um diese Durchschnittskosten zu berechnen, bezahlen wir bei jeder Inkrementierung 2 Einheiten. Wenn davon nach Abzug der Kosten der jeweiligen Operation noch etwas übrig bleibt, wird der Rest dem Guthaben zugeschrieben. Umgekehrt wird ein eventueller Fehlbetrag (wenn eine Inkrementierung mehr als 2 Bits umdreht) aus dem Guthaben gedeckt. Dadurch werden die ansonsten großen Schwankungen der Kosten ausgeglichen:
:: Kosten < Einzahlung → es wird gespart
:: Kosten = Einzahlung → Guthaben bleibt unverändert
:: Kosten > Einzahlung → Guthaben wird für die Kosten verbraucht

{| border="1" cellspacing="0" cellpadding="5"
!Schritte
!Zahlen
!Kosten 
(Anzahl der geänderten Bits)
! Einzahlung
!Guthaben = 
altes Guthaben + Einzahlung - Kosten
|-
|1.
|00001
|1
|'''2'''
|'''1'''
|-
|2.
|00010
|2
|'''2'''
|'''1'''
|-
|3.
|00011
|1
|'''2'''
|'''2'''
|-
|4.
|00100
|3
|'''2'''
|'''1'''
|-
|5.
|00101
|1
|'''2'''
|'''2'''
|-
|6.
|00110
|2
|'''2'''
|'''2'''
|-
|7.
|00111
|1
|'''2'''
|'''3'''
|-
|8.
|01000
|4
|'''2'''
|'''1'''
|-
|}

Die Kosten ergeben sich aus der Anzahl der Ziffern die von 1 nach 0, bzw. von 0 nach 1 verändert werden

Rechnung:

1. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

2. Schritt: Kosten: 2 = Einzahlung: 2 
:: → es wird nicht gespart 
:: → Guthaben bleibt so wie es ist 

3. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

4. Schritt: Kosten: 3 > Einzahlung: 2 
:: → es wird eine 1 vom Guthaben genommen um die Kosten zu zahlen 

usw.

Man erkennt, dass vor teuren Operation (Wechsel von 3 auf 4 bzw. von 7 auf 8) genügend Guthaben angespart wurde, um die Kosten zu decken. Das Guthaben geht bei diesen Operationen immer wieder auf 1 zurück, aber es wird nie vollständig verbraucht (Dies kann natürlich auch mathematisch exakt bewiesen werden, wie wir es unten am Beispiel des dynamische Arrays zeigen). Wir schließen daraus, dass die durchschnittlichen oder '''amortisierten Kosten''' einer Inkrementierungsoperation gleich 2 sind.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Account-Methode Wikipedia Account-Methode]]

====Fazit====
Die amortisierte Komplexität beschäftigt sich mit dem Durchschnitt aller Operation im ungünstigsten Fall. Operationen mit hohen Kosten, die aber nur selten ausgeführt werden, fallen bei der amortisierten Komplexität nicht so ins Gewicht. Bei Algorithmen, die gelegentlich eine "teure" Operation benutzen, ansonsten jedoch "billige" Operationen aufrufen, kann die amortisierte Komplexität niedriger sein als die Komplexität im schlechtesten (Einzel-)Fall.

In unserem Beispiel fallen die teuren Einzelschritte (z.B. 4. und 8. Schritt) bei den amortisierten Kosten nicht so ins Gewicht, da wir die Kosten aus unserem Guthaben mitbezahlen können. Das Guthaben ist immer groß genug, weil jeder zweite Aufruf eine billige Operation ist, die nur ein Bit umdreht und somit das Ansparen ermöglicht. Diese Betrachtung zeigt, dass die amortisierte (d.h. durchschnittliche) Komplexität des Algoithmus niedriger (nämlich konstant) ist als die Komplexität im schlechtesten Fall.

===Anwendung: Dynamisches Array===

Ein dynamisches Array hat die Eigenschaft, dass man effizient am Ende des Arrays neue Elemente anfügen kann, indem man die Länge des Arrays entsprechend vergrößert (siehe Übung 1). Die Analyse der amortisierten Komplexität der Anfüge-Operation zeigt uns, wie man das Vergrößern des Arrays richtig implementiert, damit die Operation wirklich effizient abläuft.

==== Ineffiziente naive Lösung ====

Wenn wir an ein Array ein Element anhängen wollen, müssen wir neuen Speicher allokieren, der die gewünschte Länge hat. Die Werte aus dem alten Array müssen dann in den neuen Speicher umkopiert werden. Danach kann das neue Element hinten angefügt werden, weil wir im neuen Array bereits Speicher für dieses Element reserviert haben. Bei der naiven Implementation des dynamischen Arrays wiederholt man dies bei jeder Anfügeoperation. Für die Analyse nehmen wir an, dass das Kopieren eines Elements konstante Zeit O(1) erfordert, ebenso das Einfügen eines neuen Elements auf in eine noch unbenutzte Speicherposition.

Naives Anhängen eines weiteren Elements an ein Array:

{| border="1" cellspacing="0" cellpadding="5" align="right"
!Schritte
|'''Array'''
(wie es nach jedem Schritt aussieht)
!Komplexität
|-
|<center>altes Array (N=4)</center>
|<center>[0,1,2,3]</center>
|<center>-</center>
|-
|1. neuer Speicher für    (N+1) Elemente
|<center>[None,None,None,None,None]</center>
|<center>O(N+1) = '''O(N)'''</center>(wenn der Speicher initialisiert wird (hier auf <tt>None</tt>), sonst O(1))
|-
|2. Kopieren
|<center>[0,1,2,3,None]</center>
|<center>'''O(N)'''</center>
|-
|3. append von "x"
|<center>[0,1,2,3,'x']</center>
|<center>'''O(1)'''</center>
|-
|}

altesArray = [0,1,2,3] 
altesArray.append('x')

1. Es wird ein neues Array der Größe N+1 erzeugt 
2. Die N Datenelemente aus dem alten Array werden in das neue Array kopiert 
Das sind N Operationen der Komplexität O(1), also ein Gesamtaufwand von O(N). 
3. 'x' wird mit Aufwand O(1) an die letzte Stelle des neuen Arrays geschrieben

Additionsregel: 
O(N) + O(1) ∈ O(N)

Folgerung:

Bei der naiven Methode erfordert jede Anfügung einen Aufwand O(N) (wobei N die derzeitige Arraygröße ist). Dies ist nicht effizient.

====Effiziente Lösung durch Verdoppeln der Kapazität====

Offensichtlich kommt man nicht darum heraum, den Inhalt des alten Arrays zu kopieren, wenn der allokierte Speicher voll ist. Der Trick für die effiziente Implementation der Anfügeoperation besteht darin, das Kopieren so selten wie möglich durchzuführen, also nicht wie in der naiven Lösung bei jeder Anfügeoperation. Hier kommt die amortisierte Komplexität ins Spiel: Ab und zu gibt es eine teure Anfügeoperation (wenn nämlich kopiert werden muss), aber wenn man den durchschnittlichen Aufwand über viele Anfügungen betrachtet, ist die Operation effizient. Der teure Fall wird sozusagen "herausgemittelt".

Um nur selten kopieren zu müssen, werden beim dynamischen Array mehr Speicherelemente reserviert als zur Zeit benötigt werden (in der naiven Lösung wurde dagegen immer nur Speicher für ein einziges neues Element reserviert). Wir unterscheiden deshalb

:<tt>capacity</tt> = Anzahl der allokierten Speicherzellen, d.h. der möglichen Elemente, die in das Array passen 
:<tt>size</tt> = Anzahl der Elemente, die im Array zur Zeit gespeichert sind 

Die Daten selbst werden in einem statischen Array gespeichert:
:<tt>data</tt> = statisches Array der Größe <tt>capacity</tt> 

Die folgende intuitive Abschätzung zeigt, dass es sinnvoll ist, die Größe des allokierten Speichers jeweils zu verdoppeln. Wir starten bei einem Array der Größe <tt>size = capacity</tt> = N. Da der verfügbare Speicher voll ist, müssen wir bei der nächsten Anfügung die N vorhandenen Elemente in ein neues Array der Länge <tt>new_capacity</tt> kopieren (Aufwand <math>N\cdot O(1)</math>). Danach können wir K Elemente billig einfügen (Aufwand <math>K\cdot O(1)</math>), wobei
:K = <tt>new_capacity - capacity</tt>
die Anzahl der nach dem Kopieren noch unbenutzen Speicherzellen ist. Der durchschnittliche Aufwand für diese K Einfügungen ist somit
:<math>\bar T = \frac{N \cdot O(1) + K \cdot O(1)}{K}=\frac{N+K}{K}\cdot O(1)</math>
Damit die mittlere Zeit in O(1) sein kann, muss der Quotient <math>(N+K)/K</math> eine Konstante sein. Wir setzen <math>K = a N</math> und erhalten:
:<math>\bar T = \frac{(a+1)N}{a N}\cdot O(1)=\frac{a+1}{a}\cdot O(1)</math>
Der amortisierte Aufwand über K Einfügungen ist also konstant, wenn <math>a</math> eine (kleine) von N unabhängige Zahl ist. Typischerweise wählt man
:<math>a = 1</math>
und mit <math>K = 1\cdot N</math> ergibt sich
:<tt>new_capacity = capacity</tt> + N = <tt>2 * capacity</tt>

Die Vorgehensweise beim Zufügen eines neuen Elements im Fall <tt>size == capacity</tt> ist also
* capacity wird verdoppelt 
: <tt>neue capacity = 2 * alte capacity</tt>
: (allgemein genügt es auch, wenn capacity um einen bestimmten Prozentsatz vergrößert wird,
:: <tt>neue capacity = alte capacity * c</tt>
: mit c > 1, z.B. c = 1.2, das entspricht oben der Wahl <math>a = 0.2</math>)
* ein neues statisches Array der Größe 'neue capacity' wird erzeugt
* das alte Array wird ins neue kopiert und danach freigegeben
* das anzufügende Element wird ins neue Array eingefügt
Umgekehrt geht man beim Entfernen des ''letzten'' Array-Elements vor. Normalerweise überschreibt man einfach das letzte Element mit <tt>None</tt> und dekrementiert <tt>size</tt>. Wird dadurch das Array zu klein (üblicherweise <tt>size < capacity / 4</tt>), wird die Kapazität halbiert, genauer:
* ein neues Array mit 
: <tt>neue capacity = alte capacity / 2 </tt>
: wird angelegt (bzw. mit
:: <tt>neue capacity = alte capacity / c </tt>
: wenn ein anderer Vergrößerungsfaktor verwendet wird)
* das alte Array wird ins neue kopiert und danach freigegeben

'''Folge:''' Die Kosten für das Vergrößern/Verkleinern der Kapazität werden amortisiert über viele Einfügungen, die kein Vergrößern erfordern. Die Operation <tt>append</tt> besitzt amortisierte Komplexität O(1). Im folgenden Abschnitt zeigen wir dies mathematisch exakt mit der Potentialmethode.

====Komplexitätsanalyse des dynamischen Arrays mit Potentialmethode====

Durchschnitt der Gesamtkosten für N-maliges append = <math>\frac{1}{N} \sum_{i = 1}^N Kosten(i)</math>. Zur Analyse der amortisierten Komplexität wird ein Potential 
::Φi = 2*sizei - capacityi 
eingeführt, wobei das Array nach dem i-ten Einfüge-Schritt die Größe sizei und die Kapizität capacityi hat. Wir nehmen vereinfachend an, dass es keine Löschoperationen gibt. Dann gilt nach dem i-ten Schritt jeweils
::Φi = 2*i - capacityi 

Fall 1: Array ist nicht voll 
Es wird kein Umkopieren benötigt, da das Array noch nicht voll ist 
→ sizei-1 < capacityi-1 
→ capacityi == capacityi-1

Kosten: 1 (für Einfügen des neuen Elements) 
Potenzial vor append: Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append: Φi = 2i - capacityi-1 

amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = 1 + (2i - capacityi-1) - [2(i - 1) - capacityi-1]
::::: = 1 + 2i - capacityi-1 - 2i + 2 + capacityi-1
::::: = 1 + <del>2i</del> - <del>capacityi-1</del> - <del>2i</del> + 2 + <del>capacityi-1</del>
::::: = 1 + 2
::::: = 3 = O(1) → konstant

Fall 2: Array ist voll 
Vor dem i-ten append muss umkopiert werden 
→ sizei-1 == capacityi-1 == i-1 
→ Allokieren eines neuen statischen Arrays mit verdoppelter Kapazität notwendig, also capacityi == 2*capacityi-1

Kosten: (i-1) + 1 (für Umkopieren und Einfügen des neuen Elements) 
Potenzial vor append = Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append = Φi = 2i - 2 capacityi-1 
amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = ((i - 1) + 1) + 2i - 2 capacityi-1 - [2(i-1) - capacityi-1]
::::: = i + <del>2i</del> - 2 capacityi-1 - <del>2i</del> + 2 - capacityi-1
::::: = i + 2 - capacityi-1
::::: = i + 2 - (i - 1) (da capacityi-1 = i-1)
::::: = 3 = O(1) → konstant

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine amortisierte Komplexität von 3 Einheiten hat, also <tt>append</tt> ∈ O(1)'''. Diese Operation kann deshalb gefahrlos in der inneren Schleife eines Algorithmus benutzt werden.

==== Beispiel für 9 Einfügeoperationen ====

{| border="1" cellspacing="0" cellpadding="5"
!Array 
(wie es aussehen könnte)
!size
!capacity
!Kosten für append (einschließlich Umkopieren)
!Summe Kosten
!Durchschnittskosten
!Φi = 2 * size - capacity 
(i = size)
!Potenzialdifferenz 
Δ Φi = Φi - Φi-1
!amortisierte Kosteni 
= Kosteni + Δ Φi
|-
| <center>[None]</center>
| <center>0</center>
| <center>1</center>
| <center>-</center>
| <center>-</center>
| <center>-</center>
| <center>-1</center>
| <center>-</center>
| <center>-</center>
|-
| <center>[a]</center><center>Array ist voll!</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b]</center><center>Array ist voll!</center>
| <center>2</center>
| <center>2</center>
| <center>1 + 1</center>
| <center>3</center>
| <center>3/2</center>
| <center>2</center>
| <center>1</center>
| <center>3</center>
|-
| <center>[a,b,c,None]</center>
| <center>3</center>
| <center>4</center>
| <center>2 + 1</center>
| <center>6</center>
| <center>6/3</center>
| <center>2</center>
| <center>0</center>
| <center>3</center>
|-
| <center>[a,b,c,d]</center><center>Array ist voll!</center>
| <center>4</center>
| <center>4</center>
| <center>1</center>
| <center>7</center>
| <center>7/4</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,None,None,None]</center>
| <center>5</center>
| <center>8</center>
| <center>4 + 1</center>
| <center>12</center>
| <center>12/5</center>
| <center>2</center>
| <center>-2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,None,None]</center>
| <center>6</center>
| <center>8</center>
| <center>1</center>
| <center>13</center>
| <center>13/6</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,None]</center>
| <center>7</center>
| <center>8</center>
| <center>1</center>
| <center>14</center>
| <center>14/7</center>
| <center>6</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h]</center><center>Array ist voll!</center>
| <center>8</center>
| <center>8</center>
| <center>1</center>
| <center>15</center>
| <center>15/8</center>
| <center>8</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h,j,None,None,None, 
None,None,None,None]</center>
| <center>9</center>
| <center>16</center>
| <center>8 + 1</center>
| <center>24</center>
| <center>24/9</center>
| <center>2</center>
| <center>-6</center>
| <center>3</center>
|-
|}

Die durchschnittlichen Kosten betragen stets etwa 2 Einheiten, schwanken allerdings so, dass nicht unmittelbar ersichtlich ist, ob dies für sämtliche Einfügeoperationen gilt. Die amortisierte Komplexität, die mit Hilfe des Potentials berechnet wird, ist hingegen konstant 3, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

[[Suchen|Nächstes Thema]]

Effizienz

2012-07-27T16:01:27Z

Ukoethe: /* Fazit */

Bei der Diskussion von Effizienz müssen wir zwischen der Laufzeit eines Algorithmus auf einem bestimmten System und seiner prinzipiellen Leistungsfähigkeit (Algorithmenkomplexität) unterscheiden. Der Benutzer ist natürlich vor allem an der Laufzeit interessiert, denn diese bestimmt letztendlich seine Arbeitsproduktivität. Ein Softwaredesigner hingegen muss eine Implementation wählen, die auf verschiedenen Systemen und in verschiedenen Anwendungen schnell ist. Für ihn sind daher auch Aussagen zur Algorithmenkomplexität sehr wichtig, um den am besten geeigneten Algorithmus auszuwählen.

== Laufzeit ==

Aus Anwendersicht ist ein Algorithmus effizient, wenn er die in der Spezifikation verlangten Laufzeitgrenzen einhält. Ein Algorithmus muss also nicht immer so schnell wie möglich sein, sondern so schnell wie nötig. Dies führt in verschiedenen Anwendungen zu ganz unterschiedliche Laufzeitanforderungen:

* Berechnen des nächsten Steuerkommandos für eine Maschine: ca. 1/1000s
* Berechnen des nächsten Bildes für eine Videopräsentation (z.B. Dekompression von MPEG-kodierten Bildern): ca. 1/25s
: Geringere Bildraten führen zu ruckeligen Filmen.
* Sichtbare Antwort auf ein interaktives Kommando (z.B. Mausklick): ca. 1/2s
: Wird diese Antwortzeit überschritten, vermuten viele Benutzer, dass der Mausklick nicht funktioniert hat, und klicken nochmals, mit eventuell fatalen Folgen. Wenn ein Algorithmus notwendigerweise länger dauert als 1/2s, sollte ein Fortschrittsbalken angezeigt werden.
* Wettervorhersage: muss spätestens am Vorabend des vorhergesagten Tages beendet sein

===Laufzeitvergleich===

Da die Laufzeit für den Benutzer ein so wichtiges Kriterium ist, werden häufig Laufzeitvergleiche durchgeführt. Deren Ergebnisse hängen allerdings von vielen Faktoren ab, die möglicherweise nicht kontrollierbar sind:
* Geschwindigkeit und Anzahl der Prozessoren
* Auslastung des Systems
* Größe des Hauptspeichers und Cache, Geschwindigkeit des Datenbus
* Qualität des Compilers/Optimierers (ist der Compiler für die spezielle Prozessor-Architektur optimiert?)
* Geschick des Programmierers
* Daten (Beispiel Quicksort: Best case und worst case [vorsortierter Input] stark unterschiedlich)
All diese Faktoren sind untereinander abhängig. Laufzeitvergleiche sind daher mit Vorsicht zu interpretieren.
Generell sollten bei Vergleichen möglichst wenige Parameter verändert werden, z.B.
* gleiches Programm (gleiche Kompilierung), gleiche Daten, andere Prozessoren
oder
* gleiche CPU, Daten, andere Programme (Vergleich von Algorithmen)
Zur Verbesserung der Vergleichbarkeit gibt es standardisierte [http://en.wikipedia.org/wiki/Benchmark_(computing) Benchmarks], die bestimmte Aspekte eines Systems unter möglichst realitätsnahen Bedingungen testen. Generell gilt aber: Durch Laufzeitmessung ist schwer festzustellen, ob ein Algorithmus ''prinzipiell'' besser ist als ein anderer. Dafür ist die Analyse der [[Effizienz#Algorithmen-Komplexität|Algorithmenkomplexität]] notwendig.

===Optimierung der Laufzeit===

Wenn sich herausstellt, dass ein bereits implementierter Algorithmus zu langsam läuft, geht man wie folgt vor:

# Man verwendet einen [http://en.wikipedia.org/wiki/Performance_analysis Profiler], um zunächst den Flaschenhals zu bestimmen. Ein Profiler ist ein Hilfsprogramm, das während der Ausführung eines Programms misst, wieviel Zeit in jeder Funktion und Unterfunktion verbraucht wird. Dadurch kann man herausfinden, welcher Teil des Algorithmus überhaupt Probleme bereitet. Donald Knuth gibt z.B. als Erfahrungswert an, dass Programme während des größten Teils ihrer Laufzeit nur 3% des Quellcodes (natürlich mehrmals wiederholt) ausführen [http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf]. Es ist sehr wichtig, diese 3% experimentell zu bestimmen, weil die Erfahrung zeigt, dass man beim Erraten der kritischen Programmteile oft falsch liegt. Man spricht dann von "[http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize premature optimization]", also von voreiliger Optimierung ohne experimentelle Untersuchung der wirklichen Laufzeiten, was laut Knuth "the root of all evil" ist. Der Python-Profiler wird in [http://docs.python.org/lib/profile.html Kapitel 25] der Python-Dokumentation beschrieben.
# Man kann dann versuchen, die kritischen Programmteile zu optimieren.
# Falls der Laufzeitgewinn durch Optimierung zu gering ist, muss man einen prinzipiell schnelleren Algorithmus verwenden, falls es einen gibt.

Einige wichtige Techniken der Programmoptimierung sollen hier erwähnt werden. Wenn man einen optimierenden Compiler verwendet, werden einige Optimierungen automatisch ausgeführt [http://en.wikipedia.org/wiki/Compiler_optimization]. In Python trifft dies jedoch nicht zu. Um den Sinn einiger Optimierungen zu verstehen, benötigt man Grundkenntnisse der Computerarchitektur.

;Elimination von redundantem Code: Es ist offensichtlich überflüssig, dasselbe Ergebnis mehrmals zu berechnen, wenn es auch zwischengespeichert werden könnte. Diese Optimierung wird von vielen automatischen Optimierern unterstützt und kommt im wesentlichen in zwei Ausprägungen vor:
:; common subexpression elimination: In mathematischen Ausdrücken wird ein Teilergebnis häufig mehrmals benötigt. Man betrachte z.B. die Lösung der quadratischen Gleichung <math>x^2+p\,x+q = 0</math>:
x1 = - p / 2.0 + sqrt(p*p/4.0 - q)
x2 = - p / 2.0 - sqrt(p*p/4.0 - q)
::Die mehrmalige Berechnung von Teilausdrücken wird vermieden, wenn man stattdessen schreibt:
p2 = - p / 2.0
r = sqrt(p2*p2 - q)
x1 = p2 + r
x2 = p2 - r
:; loop invariant elimination: Wenn ein Teilausdruck sich in einer Schleife nicht ändert, muss man ihn nicht bei jedem Schleifendurchlauf neu berechnen, sondern kann dies einmal vor Beginn der Schleife tun. Ein typisches Beispiel hierfür ist die Adressierung von Matrizen, die als 1-dimensionales Array gespeichert sind. Angenommen, wir speichern eine NxN Matrix <tt>m</tt> in einem Array <tt>a</tt> der Größe N2, so dass das Matrixelement <tt>mij</tt> durch <tt>a[i + j*N]</tt> indexiert wird. Wir betrachten die Aufgabe, eine Einheitsmatrix zu initialisieren. Ein nicht optimierter Algorithmus dafür lautet:
for j in range(N):
for i in range(N):
if i == j:
a[i + j*N] = 1.0
else:
a[i + j*N] = 0.0
::Der Ausdruck <tt>j*N</tt> wird hier in jedem Schleifendurchlauf erneut berechnet, obwohl sich <tt>j</tt> in der inneren Schleife gar nicht verändert. Man kann deshalb optimieren zu:
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
;Vereinfachung der inneren Schleife: Generell sollte man sich bei der Optimierung auf die innere Schleife eines Algorithmus konzentrieren, weil dieser Code am häufigsten ausgeführt wird. Insbesondere sollte man die Anzahl der Befehle in der inneren Schleife so gering wie möglich halten und teure Befehle vermeiden. Früher waren vor allem Floating-Point Befehle teuer, die man oft durch die schnellere Integer-Arithmetik ersetzt hat, falls dies algorithmisch möglich war (diesen Rat findet man noch oft in der Literatur). Heute hat sich die Hardware so verbessert, dass im Allgemeinen nur noch die Floating-Point Division deutlich langsamer ist als die anderen Operatoren. Im obigen Beispiel der quadratischen Gleichung ist es daher sinnvoll, den Ausdruck
p2 = -p / 2.0
:durch
p2 = -0.5 * p
:zu ersetzen. Dadurch ersetzt man eine Division durch eine Multiplikation und spart außerdem das Negieren von <tt>p</tt>, da der Compiler direkt mit <tt>-0.5</tt> multipliziert.
;Ausnutzung der Prozessor-Pipeline: Moderne Prozessoren führen mehrere Befehle parallel aus. Dies ist möglich, weil jeder Befehl in mehrere Teilschritte zerlegt werden kann. Eine generische Unterteilung in vier Teilschritte ist z.B.:
:# Dekodieren des nächsten Befehls
:# Beschaffen der Daten, die der Befehl verwendet (aus Prozessorregistern, dem Cache, oder dem Hauptspeicher)
:# Ausführen des Befehls
:# Schreiben der Ergebnisse
:Man bezeichnet dies als die "[http://en.wikipedia.org/wiki/Instruction_pipeline instruction pipeline]" des Prozessors (heutige Prozessoren verwenden wesentlich feinere Unterteilungen). Prozessoren werden nun so gebaut, dass mehrere Befehle parallel, auf verschiedenen Ausführungsstufen ausgeführt werden. Wenn Befehl 1 also beim Schreiben der Ergebnisse angelangt ist, kann Befehl 2 die Hardware zum Ausführen des Befehls benutzen, während Befehl 3 seine Daten holt, und Befehl 4 soeben dekodiert wird. Unter bestimmten Bedingungen funktioniert diese Parallelverarbeitung jedoch nicht. Dies gibt Anlass zu Optimierungen:
:;Vermeiden unnötiger Typkonvertierungen: Der Prozessor verarbeitet Interger- und Floating-Point-Befehle in verschiedenen Pipelines, weil die Hardwareanforderungen sehr verschieden sind. Wird jetzt ein Ergebnis von Integer nach Floating-Point umgewandelt oder umgekehrt, muss die jeweils andere Pipeline warten, bis die erste Pipeline ihre Berechnung beendet. Es kann dann besser sein, Berechnungen in Floating-Point zu Ende zu führen, auch wenn sie semantisch eigentlich Integer-Berechnungen sind.
:;Reduzierung der Anzahl von Verzweigungen: Wenn der Code verzweigt (z.B. durch eine <tt>if</tt>- oder <tt>while</tt>-Anweisung), ist nicht klar, welcher Befehl nach der Verzweigung ausgeführt werden soll, bevor Stufe 3 der Pipeline die Verzweigungsbedingung ausgewertet hat. Bis dahin wären die ersten beiden Stufen der Pipeline unbenutzt. Moderne Prozessoren benutzen zwar ausgefeilte Heuristiken, um das Ergebnis der Bedingung vorherzusagen, und führen den hoffentlich richtigen Zweig des Codes spekulativ aus, aber dies funktioniert nicht immer. Man sollte deshalb generell die Anzahl der Verzweigungen minimieren. Als Nebeneffekt führt dies meist auch zu besser lesbarem, verständlicherem Code. Im Matrixbeispiel kann man
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
::durch
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
ersetzen. Die Diagonalelemente <tt>a[j + jN]</tt> werden jetzt zwar zweimal initialisiert (in der Schleife auf Null, dann auf Eins), aber durch Elimination der <tt>if</tt>-Abfrage wird dies wahrscheinlich mehr als ausgeglichen, zumal dadurch die innere Schleife wesentlich vereinfacht wurde.
;Ausnutzen des Prozessor-Cache: Zugriffe auf den Hauptspeicher sind sehr langsam. Deshalb werden stets ganze Speicherseiten auf einmal in den [http://en.wikipedia.org/wiki/Cache Cache] des Prozessors geladen. Wenn unmittelbar nacheinander benutzte Daten auch im Speicher nahe beieinander liegen (sogenannte "[http://en.wikipedia.org/wiki/Locality_of_reference locality of reference]"), ist die Wahrscheinlichkeit groß, dass die als nächstes benötigten Daten bereits im Cache sind und damit schnell gelesen werden können. Bei vielen Algorithmen kann man die Implementation so umordnen, dass die locality of reference verbessert wird, was zu einer drastischen Beschleunigung führt. Im Matrix-Beispiel ist z.B. die Reihenfolge der Schleifen wichtig. Für konstanten Index <tt>j</tt> liegen die Indizes <tt>i</tt> im Speicher hintereinander. Deshalb ist es günstig, in der inneren Schleife über <tt>i</tt> zu iterieren:
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
:Die umgekehrte Reihenfolge der Schleifen ist hingegen ungünstig
for i in range(N):
for j in range(N):
a[i + j*N] = 0.0
a[i + i*N] = 1.0
:Jetzt werden in der inneren Schleife stets N Datenelemente übersprungen. Besonders bei großem N muss man daher häufig den Cache neu füllen, was bei der ersten Implementation nicht notwendig war. (Außerdem verliert man hier die Optimierung <tt>jN = j*N</tt>, die jetzt nicht mehr möglich ist.)

Als Faustregel kann man durch Optimierung eine Verdoppelung der Geschwindigkeit erreichen (in Ausnahmefällen auch mehr). Benötigt man stärkere Verbesserungen, muss man wohl oder übel einen besseren Algorithmus oder einen schnelleren Computer verwenden.

== Algorithmen-Komplexität ==

Komplexitätsbetrachtungen ermöglichen den Vergleich der prinzipiellen Eigenschaften von Algorithmen unabhängig von einer Implementation, Umgebung etc.

Eine einfache Möglichkeit ist das Zählen der Aufrufe einer Schlüsseloperation. Beispiel Sortieren:
* Anzahl der Vergleiche
* Anzahl der Vertauschungen

=== Beispiel: Selection Sort ===

for i in range(len(a)-1):
max = i
for j in range(i+1, len(a)):
if a[j] < a[max]:
max = j
a[max], a[i] = a[i], a[max] # swap

*Anzahl der Vergleiche: Ein Vergleich in jedem Durchlauf der inneren Schleife. Es ergibt sich folgende Komplexität:
*:Ingesamt <math>\sum_{i=0}^{N-2} \sum_{j=i+1}^{N-1}1 = \frac{N}{2} (N-1) \!</math> Vergleiche.

*Anzahl der Vertauschungen (swaps): Eine Vertauschung pro Durchlauf der äußeren Schleife:
*:Insgesamt <math>N-1 \!</math> Vertauschungen

Die Komplexität wird durch die Operationen bestimmt, die am häufigsten ausgeführt werden, hier also die Anzahl der Vergleiche. Die Anzahl der Vertauschungen ist hingegen kein geeignetes Kriterium für die Komplexität von selection sort, weil der Aufwand in der inneren Schleife ignoriert würde.

=== Fallunterscheidung: Worst und Average Case ===

Die Komplexität ist in der Regel eine Funktion der Eingabegröße (Anzahl der Eingabebits, Anzahl der Eingabeelemente). Sie kann aber auch von der Art der Daten abhängen, nicht nur von der Menge, z.B. vorsortierte Daten bei Quicksort. Um von der Art der Daten unabhängig zu werden, kann man zwei Fälle der Komplexität unterscheiden:

* Komplexität im ungünstigsten Fall
*: Der ungünstigste Fall ist die Eingabe gegebener Länge, für die der Algorithmus am langsamsten ist. Der Nachteil dieser Methode besteht darin, dass dieser ungünstige Fall in der Praxis vielleicht gar nicht oder nur selten vorkommt, so dass sich der Algorithmus in Wirklichkeit besser verhält als man nach dieser Analyse erwarten würde. Beim Quicksort-Algorithmus mit zufälliger Wahl des Pivot-Elements müsste z.B. stets das kleinste oder größte Element des aktuellen Intervalls als Pivot-Element gewählt werden, was äußerst unwahrscheinlich ist.
* Komplexität im durchschnittlichen/typischen Fall
*: Der typische Fall ist die mittlere Komplexität des Algorithmus über alle möglichen Eingaben. Dazu muss man die Wahrscheinlichkeit jeder möglichen Eingabe kennen, und berechnet dann die mittlere Laufzeit über dieser Wahrscheinlichkeitsverteilung. Leider ist die Wahrscheinlichkeit der Eingaben oft nicht bekannt, so dass man geeignete Annahmen treffen muss. Bei Sortieralgorithmen können z.B. alle möglichen Permutationen des Eingabearrays als gleich wahrscheinlich angenommen werden, und der typische Fall ist dann die mittlere Komplexität über alle diese Eingaben. Oft hat man jedoch in der Praxis andere Wahrscheinlichkeitsverteilungen, z.B. sind die Daten oft "fast sortiert" (nur wenige Elemente sind an der falschen Stelle). Dann verhält sich der Algorithmus ebenfalls anders als vorhergesagt.

Wir beschränken uns in dieser Vorlesung auf die Komplexität im ungünstigseten Fall. '''Exakte''' Formeln für Komplexität sind aber auch dann schwer zu gewinnen, wie das folgende Beispiel zeigt:

=== Beispiele aus den Übungen (Gemessene Laufzeiten für Mergesort/Selectionsort) ===

* Mergesort: <math>\frac{0,977N\log N}{\log 2} + 0,267N-4.39 \!</math>
*: andere Lösung: <math>1140 N\log(N) - 1819N + 6413 \!</math>
* Selectionsort: <math>\frac{1}{2}N^2 - \frac{1}{2N} - 10^{-12} \!</math>
*: andere Lösung: <math>1275N^2 - 116003^N + 11111144 \!</math>

Aus diesen Formeln wird nicht offensichtlich, welcher Algorithmus besser ist.
Näherung: Betrachte nur '''sehr große Eingaben''' (meist sind alle Algorithmen schnell genug für kleine Eingaben). Dieses Vorgehen wird als '''Asymptotische Komplexität''' bezeichnet (N gegen unendlich).

=== Asymptotische Komplexität am Beispiel Polynom ===

Polynom: <math>a\,x^2+b\,x+c=p\!</math>

<math>x \!</math> sei die Eingabegröße, und wir betrachten die Entwicklung von <math>p \!</math> in Abhängigkeit von <math>x \!</math>.

* <math>x=0 \!</math>
*: <math>p=c \!</math>
* <math>x=1 \!</math>
*: <math>p=a+b+c \!</math>
* <math>x=1000 \!</math>
*: <math>p=1000000a+1000b+c \approx 1000000a\!</math>
* <math>x \to \infty \!</math>
*: <math>p \approx x^2a\!</math>

Für sehr große Eingaben verlieren also ''b'' und ''c'' immer mehr an Bedeutung, so dass am Ende nur noch ''a'' für die Komplexitätsbetrachtung wichtig ist.

== Landau-Symbole ==

Um die asymptotische Komplexität verschiedener Algorithmen miteinander vergleichen zu können, verwendet man die sogenannten [http://de.wikipedia.org/wiki/Landau-Symbole Landau-Symbole]. Das wichtigste Landau-Symbol ist <math>\mathcal{O}</math>, mit dem man eine ''obere Schranke'' <math>f \in \mathcal{O}(g)</math> für die Komplexität angeben kann.

Schreibt man <math>f \in \Omega(g)</math>, so stellt dies eine asymptotische ''untere Schranke'' für die Funktion f dar.

Schließlich bedeutet <math>f \in \Theta(g)</math>, dass die Funktion f genauso schnell wie die Funktion g wächst, das heißt man hat eine asymptotisch ''scharfe Schranke'' für f. Hierzu muss sowohl <math>f\in\mathcal{O}(g)</math> als auch <math>f \in \Omega(g)</math> erfüllt sein.

Im nun folgenden soll auf die verschiedenen Landau-Symbole noch näher eingegeangen werden.

===O-Notation===

Intuitiv gilt: Für große N dominieren die am schnellsten wachsenden Terme einer Funktion. Die Notation <math>f \in \mathcal{O}(g)</math> (sprich "f ist in O von g" oder "f ist von derselben Größenordnung wie g") formalisiert eine solche Abschätzung der asymptotischen Komplexität der Funktion f von oben.
; Asymptotische Komplexität: Für zwei Funktionen f(x) und g(x) gilt
::<math>f(x) \in \mathcal{O}(g(x))</math>
: genau dann wenn es eine Konstante <math>c>0</math> und ein Argument <math>x_0</math> gibt, so dass
::<math>\forall x \ge x_0:\quad f(x) \le c\,g(x)</math>.
:Die Menge <math>\mathcal{O}(g(x))</math> aller durch g(x) abschätzbaren Funktionen ist also formal definiert durch
::<math>\mathcal{O}(g(x)) = \{ f(x)\ |\ \exists c>0: \forall x \ge x_0: 0 \le f(x) \le c\,g(x)\}</math>

Die Idee hinter dieser Definition ist, dass g(x) eine wesentlich einfachere Funktion ist als f(x), die sich aber nach geeigneter Skalierung (Multiplikation mit c) und für große Argumente x im wesentlichen genauso wie f(x) verhält. Man kann deshalb in der Algorithmenanalyse f(x) durch g(x) ersetzen. <math>f(x) \in \mathcal{O}(g(x))</math> spielt für Funktionen eine ähnliche Rolle wie der Operator ≤ für Zahlen: Falls a ≤ b gilt, kann bei einer Abschätzung von oben ebenfalls a durch b ersetzt werden.

==== Ein einfaches Beispiel ====

[[Image:Sqsqrt.png]]

Rot = <math>x^2 \!</math>
Blau = <math>\sqrt{x} \!</math>

<math>\sqrt{x} \in \mathcal{O}(x^2)\!</math> weil <math>\sqrt{x} \le c\,x^2\!</math> für alle <math>x \ge x_0 = 1 \!</math> und <math>c = 1\!</math>, oder auch für <math>x \ge x_0 = 4 \!</math> und <math>c = 1/16</math> (die Wahl von c und x0 in der Definition von O(.) ist beliebig, solange die Bedingungen erfüllt sind).

==== Komplexität bei kleinen Eingaben ====

Algorithmus 1: <math>\mathcal{O}(N^2) \!</math> 
Algorithmus 2: <math>\mathcal{O}(N\log{N}) \!</math>

Algorithmus 2 ist schneller (von geringerer Komplexität) für große Eingaben, aber bei kleinen Eingaben (insbesondere, wenn der Algorithmus in einer Schleife immer wieder mit kleinen Eingaben aufgerufen wird) könnte Algorithmus 1 schneller sein, falls der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor ''c'' bei Algorithmus 2 einen wesentlich größeren Wert hat als bei Algorithmus 1.

==== Eigenschaften der O-Notation (Rechenregeln) ====

# Transitiv:
#: <math>f(x) \in \mathcal{O}(g(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) \in \mathcal{O}(h(x)) \!</math>
# Additiv:
#: <math>f(x) \in \mathcal{O}(h(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) + g(x) \in \mathcal{O}(h(x)) \!</math>
# Für Monome gilt:
#: <math>x^k \in \mathcal{O}(x^k)</math> und
#: <math>x^k \in \mathcal{O}(x^{k+j}), \forall j \ge 0 \!</math>
# Multiplikation mit einer Konstanten:
#: <math>f(x) \in \mathcal{O}(g(x)) \to c\,f(x) \in \mathcal{O}(g(x))\!</math>
#: andere Schreibweise:
#: <math>f(x) = c\,g(x) \to f(x) \in \mathcal{O}(g(x))\!</math>
# Folgerung aus 3. und 4. für Polynome:
#: <math>a_0+a_1\,x + ... + a_n\,x^n \in \mathcal{O}(x^n)\!</math>
#: Beispiel: <math>a\,x^2+b\,x+c \in \mathcal{O}(x^2)\!</math>
# Logarithmus:
#: <math>a, b > 1\!</math>
#: <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>
#: Die Basis des Logarithmus spielt also keine Rolle.
#: Beweis hierfür:
#:: <math>\log_{a}{x} = \frac{\log_{b}{x}}{\log_{b}{a}}\!</math>
#:: Mit <math>c = 1 / \log_{b}{a}\,</math> gilt: <math>\log_{a}{x} = c\,\log_{b}{x}\!</math>.
#:: Wird hier die (zweite) Regel für Multiplikation mit einer Konstanten angewendet, fällt der konstante Faktor weg, also <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>.
#: Insbesondere gilt auch <math>\log_{a}{x} \in \mathcal{O}(\log_{2}{x})\!</math>, es kann also immer der 2er Logarithmus verwendet werden.

==== O-Kalkül ====

Das O-Kalkül definiert wichtige Vereinfachungsregeln for Ausdrücke in O-Notation (Beweise: siehe Übungsaufgabe):

# <math>f(x) \in \mathcal{O}(f(x))\!</math>
# <math>\mathcal{O}(\mathcal{O}(f(x))) \in \mathcal{O}(f(x))\!</math>
# <math>c\,\mathcal{O}(f(x)) \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# <math>\mathcal{O}(f(x))+c \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# Sequenzregel:
#: Wenn zwei nacheinander ausgeführte Programmteile die Komplexität <math>\mathcal{O}(f(x))</math> bzw. <math>\mathcal{O}(g(x))</math> haben, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(f(x))</math> falls <math>g(x) < \mathcal{O}(f(x))</math> bzw.
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(g(x))\!</math> falls <math>f(x) < \mathcal{O}(g(x))</math>.
#: Informell schreibt man auch: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(max(f(x), g(x)))\!</math>.
# Schachtelungsregel bzw. Aufrufregel:
#: Wenn in einer geschachtelten Schleife die äußere Schleife die Komplexität <math>\mathcal{O}(f(x))</math> hat, und die innere <math>\mathcal{O}(g(x))</math>, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) * \mathcal{O}(g(x)) \in \mathcal{O}(f(x) * g(x))\!</math>.
#: Gleiches gilt wenn eine Funktion <math>\mathcal{O}(f(x))</math>-mal aufgerufen wird, und die Komplexität der Funktion selbst <math>\mathcal{O}(g(x))</math> ist.

;Beispiel für 5.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Dies gilt auch für ihre Hintereinanderausführung:
for i in range(N):
a[i] = i
for i in range(N):
print a[i]
;Beispiele für 6.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Ihre Verschachtelung hat daher die Komplexität <math>\mathcal{O}(N^2)</math>.
for i in range(N):
for j in range(N):
a[i*N + j] = i+j
: Dies gilt ebenso, wenn statt der inneren Schleife eine Funktion mit Komplexität <math>\mathcal{O}(N)</math> ausgeführt wird:
for i in range(N):
a[i] = foo(i, N) # <math>\mathrm{foo}(i, N) \in \mathcal{O}(N)</math>

==== O-Kalkül auf das Beispiel des Selectionsort angewandt ====

Selectionsort: Wir hatten gezeigt dass <math>f(N) = \frac{N^2}{2} - \frac{N}{2}</math>. Nach der Regel für Polynome vereinfacht sich dies zu <math>f(N) \in \mathcal{O}\left(\frac{N^2}{2}\right) = \mathcal{O}(N^2)\!</math>.

Alternativ via Schachtelungsregel:
: Die äußere Schleife wird (''N''-1)-mal durchlaufen: <math>N-1 \in \mathcal{O}(N)</math>
: Die innere Schleife wird (''N-i''-1)-mal durchlaufen. Das sind im Mittel ''N''/2 Durchläufe: <math>N/2 \in \mathcal{O}(N)</math>
: Zusammen: <math>\mathcal{O}(N)*\mathcal{O}(N) \in \mathcal{O}(N^2)</math>

Nach beiden Vorgehensweisen kommen wir zur Schlussfolgerung, dass der Selectionsort die asymptotische Komplexität <math>\mathcal{O}(N^2)\!</math> besitzt.

==== Zusammenhang zwischen Komplexität und Laufzeit ====

Wenn eine Operation 1ms dauert, erreichen Algorithmen verschiedener Komplexität folgende Leistungen (wobei angenommen wird, dass der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor immer etwa gleich 1 ist):

{| class="wikitable" style="text-align:left" cellpadding="7"
|+
|-
! Komplexität !! Operationen in 1s !! Operationen in 1min !! Operationen in 1h
|-
! <math>\mathcal{O}(N)</math>
| 1000 || 60.000 || 3.600.000
|-
! <math>\mathcal{O}(N\log_2{N})</math>
| 140 || 4895 || 204094
|-
! <math>\mathcal{O}(N^2)</math>
| 32 || 245 || 1898
|-
! <math>\mathcal{O}(N^3)</math>
| 10 || 39 || 153
|-
! <math>\mathcal{O}(2^N)</math>
| 10 || 16 || 21
|}

==== Exponentielle Komplexität ====
Der letzte Fall <math>\mathcal{O}(2^N)</math> ist von exponentieller Komplexität. Das bedeutet, dass eine Verdopplung des Aufwands nur bewirkt, dass die maximale Problemgröße um eine Konstante wächst. Algorithmen mit exponentieller (oder noch höherer) Komplexität werden deshalb als '''ineffizient''' bezeichnet. Algorithmen mit höchstens polynomieller Komplexität gelten hingegen als effizient.

In der Praxis sind allerdings auch polynomielle Algorithmen mit hohem Exponenten meist zu langsam. Als Faustregel kann man eine praktische Grenze von <math>\mathcal{O}(N^3)</math> ansehen. Bei einer Komplexität von <math>\mathcal{O}(N^3)</math> bewirkt ein verdoppelter Aufwand immer noch eine Steigerung der maximalen Problemgröße um den Faktor <math>\sqrt[3]{2}</math> (also eine ''multiplikative'' Vergrößerung um ca. 25%, statt nur einer additiven Vergrößerung wie bei exponentieller Komplexität).

===<math>\Omega</math>- Notation===

Genauso wie <math>f \in \mathcal{O}(g)</math> eine Art <math>\le</math>-Operator für Funktionen ist, definiert <math>f \in \Omega(g) </math> eine Abschätzung von unten, analog zum <math>\ge</math>-Operator für Zahlen. Formal kann man <math>f(N) \in \Omega(g(N)) </math> genau dann schreiben, falls es eine Konstante <math> c > 0 </math> gibt, so dass

<math> f(N) \ge c \cdot g(N) </math> für <math> N \ge N_0 </math>

gilt.
Man verwendet diese Notation also um abzuschätzen, wie groß der Aufwand (die Komplexität) für einen bestimmten Algorithmus ''mindestens'' ist und nicht ''höchstens'', was man mit der <math>\mathcal{O}</math> - Notation ausdrücken würde.

Ein praktisches Beispiel für eine Anwendung der <math>\Omega</math>- Notation wäre die Fragestellung, ob es ''prinzipiell'' einen besseren Algorithmus für ein bestimmtes Problem gibt. Wie später im Abschnitt [[Suchen#Sortieren_als_Suchproblem|Sortieren als Suchproblem]] gezeigt wird, ist das Sortieren eines Arrays durch paarweise Vergleiche von Elementen immer mindestens von der Komplexität <math> \Omega(N\cdot \ln N) </math>, was konkret bedeutet, dass kein Sortieralgorithmus, der nach diesem Prinzip arbeitet, jemals eine geringere Komplexität als beispielsweise Merge-Sort haben wird. Natürlich kann man den entsprechenden Sortieralgorithmus, also Merge-Sort zum Beispiel, unter Umständen noch optimieren, aber die Komplexität wird erhalten bleiben. Mit diesem Wissen kann man sich viel (vergebliche) Arbeit sparen.

===<math>\Theta</math>- Notation===

<math>f(N) \in \Theta(g(N))</math> ist eine scharfe Abschätzung der asymptotischen Komplexität einer Funktion f.

Damit dies gilt, muss <math>f(N) \in \mathcal{O}(g(N))</math> und ''gleichzeitig'' <math>f(N) \in \Omega(g(N))</math> erfüllt sein.

Dies ist natürlich auch die beste Abschätzung der asymptotischen Komplexität einer Funktion f. Formal bedeutet <math>f(N) \in \Theta(g(N))</math> dass es zwei Konstanten <math> c_1 </math> und <math> c_2 </math>, beide größer als Null, gibt, so dass für alle <math> N \geq N_0 </math> gilt:

<math> c_1 \cdot g(N) \leq f(N) \leq c_2 \cdot g(N) </math>.

In der Praxis wird manchmal statt der <math>\Theta</math>-Notation auch dann die <math>\mathcal{O}</math>-Notation benutzt, wenn eine scharfe Schranke ausgedrückt werden soll. Dies ist zwar formal nicht korrekt, aber man kann die intendierte Bedeutung meist aus dem Kontext erschließen.

== Komplexitätsvergleich zweier Algorithmen ==

In diesem Abschnitt wollen wir der Frage nachgehen, wie ein formaler Beweis für die Behauptung <math> f(N) \in \mathcal{O}(g(N))</math> geschehen kann. Hierbei werden zwei Beweismethoden vorgestellt werden, und zwar der '''Beweis über die Definition der Komplexität''' sowie der '''Beweis durch Dividieren'''.

===Beweis über die Definition der asymptotischen Komplexität===

Die Definition der asymptotischen Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> war:

Es gibt eine Konstante <math> c > 0 </math>, so dass <math> f(N) \le c \cdot g(N) </math> für <math> N \ge N_0 </math> erfüllt ist.

Um also die die asymptotische Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> zu beweisen, muss man die oben erwähnten Konstanten c und <math> N_0 </math> finden, so dass

<math> f(N) \leq c \cdot g(N) </math> für alle <math> N \ge N_0 </math> erfüllt ist.

Dies geschieht zweckmäßigerweise mit dem Beweisprinzip der ''vollständigen Induktion''. Hierbei ist zu zeigen, dass
# <math> f(N_0) \leq g(N_0) </math> für die eine zu bestimmende Konstante <math> N_0 </math> gilt (''Induktionsanfang'') und
# falls <math> f(N) \leq g(N) </math>, dann auch <math> f(N+1) \leq g(N+1) </math> (''Induktionsschritt'') gilt.

===Beweis durch Dividieren===

Hierbei wählt man eine Konstante c und zeigt, dass <math> \lim_{N \rightarrow \infty} \frac{f(N)}{c \cdot g(N)} \leq 1 </math> gilt (für die O-Notation, bei Ω-Notation gilt entsprechend <math>\geq 1 </math>). Man kann dies auch als alternative Definition der Komplexität verwenden.

Als Beispiel betrachten wir die beiden Funktionen <math> f(N) = N \,\lg N </math> und <math> g(N) = N^2 </math> und wollen zeigen, dass <math>f(N) \in \mathcal{O}(g(N))</math> gilt.

Als Konstante c wählen wir <math> c = 1 </math>

<math> \lim_{N \rightarrow \infty} \frac{f(N)}{g(N)} = \lim_{N \rightarrow \infty} \frac{\lg N}{N} = \frac{\infty}{\infty} </math>

Unbestimmte Ausdrücke der Form
<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} </math>,
in denen sowohl <math> f(x) </math> als auch <math> g(x) </math> mit <math> x \rightarrow x_0 </math> gegen Null oder gegen Unendlich streben, kann man manchmal mit den Regeln von [http://de.wikipedia.org/wiki/L%27Hospital%27sche_Regel ''l'Hospital''] berechnen. Danach darf man die Funktionen f und g zur Berechnung des unbestimmten Ausdrucks durch ihre k-ten Ableitungen ersetzen:

<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} = \lim_{x \rightarrow x_0} \frac{f^{(k)}(x)}{g^{(k)}(x)} </math>

In unserem Fall verwenden wir die erste Ableitung und erhalten:
<math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)} = \lim_{N \rightarrow \infty} \frac{1/N}{1} \rightarrow 0 </math>

Damit wurde <math>f(N) \in \mathcal{O}(g(N))</math>, also <math>N \lg N \in \mathcal{O}(N^2)</math> gezeigt.

Man beachte hierbei, dass <math>N \lg N \in \mathcal{O}(N^2)</math> keine enge Grenze für die Komplexität von <math>N \,\lg N</math> darstellt, da der Grenzwert <math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)}\, </math> gegen 0 und nicht gegen eine von Null verschiedene Konstante strebt. In diesem Fall haben wir die Komplexität von <math>N \cdot \lg N </math> also nur nach oben abschätzen können.

===Beispiel für den Komplexitätsvergleich: Gleitender Mittelwert (Running Average)===

Wir berechnen für ein gegebenes Array <tt>a</tt> einen gleitenden Mittelwert über <tt>k</tt> Elemente: 
::<math>r_i = \frac{1}{k} \sum_{j=i-k+1}^i a_j</math> 
Das heisst, für jedes <tt>i</tt> mitteln wir die letzten <tt>k</tt> Elemente von <tt>a</tt> und schreiben das Ergebnis in <tt>r[i]</tt>. Diese Operation ist z.B. bei Börsenkursen wichtig: Neben dem aktuellen Kurs für jeden Tag wird dort meist auch der gleitende Mittelwert der letzten 30 Tage sowie der letzten 200 Tage angegeben. In diesen Mittelwerten erkennt man besser die langfristige Tendenz, weil die täglichen Schwankungen herausgemittelt werden. Wir nehmen außerdem an, dass
* Array-Zugriff hat eine Komplexität von O(1)
* <math>k \ll N</math>, d.h. <math>N-k\approx N</math>.

Die beiden folgenden Algorithmen berechnen die Mittelwerte auf unterschiedliche Art. Der linke folgt der obigen Definition durch eine Summe, während der rechte inkrementell arbeitet: Man kann den Bereich der <tt>k</tt> letzten Werte als Fenster betrachten, das über das Array <tt>a</tt> geschoben wird. Schiebt man das Fenster ein Element weiter, fällt links ein Element heraus, und rechts kommt eins hinzu. Man muss also nicht jedes Mal die Summe neu berechnen, sondern kann den vorigen Wert aktualisieren. Wir werden sehen, dass dies Folgen für die Komplexität des Algorithmus hat.

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1: O(N * k)
! Komplexität
! Version 2: O(N)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|
<tt>for i in range(k):</tt>
|
'''<center>O(k)</center>'''
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|
:: <tt>r[k-1] += a[i]</tt>
|
'''<center>O(1)</center>'''
|-
|
6.
|
:::: <tt>r[j] += a[i]</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(k, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|
:: <tt>r[j] = (a[j] - a[j-k] + r[j-1])</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(len(a)):</tt>
|
'''<center>O(N)</center>'''
|-
|
9.
|

|

|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
10.
|

|

|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Wir zeigen unten dass Version 2 eine geringere Komplexität besitzt, obwohl sie mehr Zeilen benötigt.

Wir haben in der Tabelle die Komplexität jeder Zeile für sich angegeben. Einfache Anweisungen (Berechnungen, Lese- und Schreibzugriffe auf das Array, Zuweiseungen) haben konstante Komplexität, die Komplexität des Schleifenkopfes allein (also der <tt>for</tt>-Anweisung ohne den eingerückten Schleifenkörper) entspricht der Anzahl der Durchläufe. Wir müssen jetzt noch die Verschachtelung der Schleifen und die Nacheinanderausführung von Anweisungen berücksichtigen.

====Berechnung der Komplexität von Version 1====

(Wiederholung der Rechenregeln: siehe Abschnitt [[Effizienz#O-Notation|O-Notation]])

Wir betrachten zunächst die innere Schleife (Zeilen 5 und 6 von Version 1):

Der Schleifenkopf (Zeile 5) hat die Komplexität <math>\mathcal{O}(k)</math>, weil die Schleife k-mal durchlaufen wird. Der Schleifenkörper (Zeile 6) hat die Komplexität <math>\mathcal{O}(1)</math>. Nach der Verschachtelungsregel müssen wir die beiden Komplexitäten multiplizieren, und es ergibt sich:

::<math>\mathcal{O}(k)\cdot\mathcal{O}(1) = \mathcal{O}(k\cdot 1)=\mathcal{O}(k)</math>

Wir betrachten nun die äußere Schleife. Der Schleifenkopf (Zeile 4) wird (N-k)-mal durchlaufen und hat somit eine Komplexität von <math>\mathcal{O}(N)</math>. Der Schleifenkörper (Zeilen 5 bis 7) besteht aus der inneren Schleife (Zeilen 5 und 6) mit der gerade berechneten Komplexität <math>\mathcal{O}(k)</math> sowie einer einfachen Anweisung (Zeile 7) mit Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel wird die Komplexität des Schleifenkörpers durch Addition berechnet:

::<math>\mathcal{O}(k)+\mathcal{O}(1) = \mathcal{O}(\max(k,1)) = \mathcal{O}(k)</math>

Die Komplexität der gesamten äußeren Schleife erhalten wir nach der Verschachtelungsregel wieder durch multiplizieren:

::<math>\mathcal{O}(N)\cdot\mathcal{O}(k) = \mathcal{O}(N\cdot k)</math>

Die übrigen Schritte des Algorithmus werden einfach nacheinander ausgeführt, so dass sie ebenfalls nach der Sequenzregel behandelt werden. Wir erhalten

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(N\cdot k)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,N\cdot k,1)) = \mathcal{O}(N\cdot k)</math>

Der gesamte Algorithmus hat also die Komplexität <math>\mathcal{O}(N\cdot k)</math>.

====Berechnung der Komplexität von Version 2====

Hier gibt es nur einfache Schleifen ohne Verschachtelung. Da der Schleifenkörper jeder Schleife nur einfache Anweisungen der Komplexität <math>\mathcal{O}(1)</math> enthält, ergibt sich die Komplexität der Schleifen nach der Verschachtelungsregel als

::<math>\mathcal{O}(X)\cdot\mathcal{O}(1) = \mathcal{O}(X\cdot 1)=\mathcal{O}(X)</math>

wobei <math>\mathcal{O}(X)</math> die Komplexität des jeweiligen Schleifenkopfes ist. Wir erhalten also für Zeilen 4 und 5: <math>\mathcal{O}(k)</math>, Zeilen 6 und 7: <math>\mathcal{O}(N)</math>, Zeilen 8 und 9: <math>\mathcal{O}(N)</math>. Die Hintereinanderausführung wird nach der Sequenzregel behandelt:

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(k)+\mathcal{O}(N)+\mathcal{O}(N)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,k,N,N,1)) = \mathcal{O}(N)</math>

Dieser Algorithmus hat also nur die Komplexität <math>\mathcal{O}(N)</math>.

====Fazit====

Obwohl Version 2 mehr Schritte benötigt hat sie eine geringere Komplexität, da die for-Schleifen nicht wie bei Version 1 verschachtelt/untergeordnet sind. Bei verschachtelten for-Schleifen muss die Multiplikationsregel angewendet werden → höhere Komplexität.

Die gerade berechnete Komplexität gilt aber nur unter der Annahme, dass Array-Zugriffe konstante Komplexität <math>\mathcal{O}(1)</math> besitzen. Wenn dies nicht der Fall ist, kann sich die Komplexität des Algorithmus drastisch verschlechtern.

{| border="1" cellspacing="0" cellpadding="5"
|Allgemein gilt: 
Algorithmen-Analysen beruhen auf der Annahme, dass Zugriffe auf die Daten optimal schnell sind, dass heißt, dass die für den jeweiligen Algorithmus am besten geeignete Datenstruktur verwendetet wird. → Ansonsten: Komplexitätsverschlechterung!
|}
 

====Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur====

Wir verwende im Mittelwert-Algorithmus eine verkettete Liste anstelle des Eingabe-Arrays a. Wir benötigen dazu eine Funktion, die das j-te Element der Liste zurückgibt. Wie üblich ist die Liste mit Hilfe einer Knotenklasse implementiert:
class Node:
def __init__(self, data):
self.data = data
self.next = None

Die Listenklasse selbst hat ein Feld <tt>head</tt>, das eine Referenz auf den ersten Knoten speichert, und jeder Knoten speichert im Feld <tt>next</tt> eine Referenz auf seinen Nachfolger. Um zum j-ten Element zu gelangen, muss man die Liste sequenziell durchlaufen
def get_jth(list, j):
r = list.head
while j > 0:
r = r.head
j -= 1
return r.data
Die Komplexität dieser Funktion ist offensichtlich <math>\mathcal{O}(j)</math> (Komplexitätsberechnung wie oben). Wir setzen jetzt bei Version 1 des Mittelwert-Algorithmus diese Funktion in Zeile 6 anstelle des Indexzugriffs <tt>a[i]</tt> ein (nur in dieser Zeile wird auf die Elemente des Arrays zugegriffen). Wir erhalten folgende Implementation (die Änderungen sind rot markiert):

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1 mit Liste: O(N * k)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|-
|
6.
|
:::: <tt>r[j] += get_jth(a, i)</tt>
|
'''<center>O(i)</center>'''
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Der Aufruf der Funktion <tt>get_jth</tt> ist jetzt gleichbedeutend mit einer dreifach verschachtelten Schleife (weil <tt>get_jth</tt> ja eine zusatzliche Schleife enthält). Die Anzahl der Operationen in Zeile 4 bis 6 ist jetzt

::<math>f(N,k)=\sum_{j=k-1}^{N-1}\,\sum_{i=j-k+1}^j\,\mathcal{O}(i)</math>

wobei das <math>\mathcal{O}(i)</math> die neue Schleife durch Verwendung der Liste repräsentiert. Mit Mathematica-Hilfe [http://www.wolfram.com/] lässt sich diese Summe exakt ausrechnen

::<math>f(N,k)=\frac{1}{2}(k N^2-k^2 N+k^2-k)\in \mathcal{O}(k N^2)</math>

Die Komplexitätsberechnung erfolgte dabei nach der Regel für Polynome unter Beachtung von <math>k \ll N</math>.

====Fazit:====

Die Komplexität von Version 1 mit einer verketteten Liste wäre O(N2 * k)
'''→ Die richtige Datenstruktur ist wichtig, da es sonst zu einer Komplexitätsverschlechterung kommen kann!'''

Auf Version 2 unseres Running Average-Beispiels hätte eine verkettete Liste allerdings keine Auswirkungen, da die inkrementelle Berechnung der Summen in Zeile 7 weiterhin möglich ist (bei geschickter Implementation!) und somit Version 2 immer noch eine Komplexität von O(N) hätte.

==Amortisierte Komplexität==

Bis jetzt wurde die Komplexität nur im schlechtesten Fall (Worst Case) betrachtet. Bei einigen Operationen schwankt die Komplexität jedoch sehr stark, wenn man sie mehrmals hintereinander ausführt, und der schlechteste Fall kommt nur selten vor. Dann ist es sinnvoll, die amortisierte Komplexität zu betrachten, die sich mit der durchschnittlichen Komplexität über viele Aufrufe der selben Operation beschäftigt.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse Wikipedia: Amortisierte Laufzeitanalyse]]

===Beispiel: Inkrementieren von Binärzahlen===

Frage: Angenommen, das Umdrehen eines Bits einer Binärzahl verursacht Kosten von 1 Einheit. Wir erzeugen die Folge der natürlichen Zahlen in Binärdarstellung durch sukzessives Inkrementieren, von Null beginnend. Bei jeder Inkrementierung werden einige Bits verändert, aber diese Zahl (und damit die Kosten der Inkrementierungen) ''schwanken'' sehr stark. Wir fragen jetzt, was eine Inkrementierung im Durchschnitt kostet?

Um diese Durchschnittskosten zu berechnen, bezahlen wir bei jeder Inkrementierung 2 Einheiten. Wenn davon nach Abzug der Kosten der jeweiligen Operation noch etwas übrig bleibt, wird der Rest dem Guthaben zugeschrieben. Umgekehrt wird ein eventueller Fehlbetrag (wenn eine Inkrementierung mehr als 2 Bits umdreht) aus dem Guthaben gedeckt. Dadurch werden die ansonsten großen Schwankungen der Kosten ausgeglichen:
:: Kosten < Einzahlung → es wird gespart
:: Kosten = Einzahlung → Guthaben bleibt unverändert
:: Kosten > Einzahlung → Guthaben wird für die Kosten verbraucht

{| border="1" cellspacing="0" cellpadding="5"
!Schritte
!Zahlen
!Kosten 
(Anzahl der geänderten Bits)
! Einzahlung
!Guthaben = 
altes Guthaben + Einzahlung - Kosten
|-
|1.
|00001
|1
|'''2'''
|'''1'''
|-
|2.
|00010
|2
|'''2'''
|'''1'''
|-
|3.
|00011
|1
|'''2'''
|'''2'''
|-
|4.
|00100
|3
|'''2'''
|'''1'''
|-
|5.
|00101
|1
|'''2'''
|'''2'''
|-
|6.
|00110
|2
|'''2'''
|'''2'''
|-
|7.
|00111
|1
|'''2'''
|'''3'''
|-
|8.
|01000
|4
|'''2'''
|'''1'''
|-
|}

Die Kosten ergeben sich aus der Anzahl der Ziffern die von 1 nach 0, bzw. von 0 nach 1 verändert werden

Rechnung:

1. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

2. Schritt: Kosten: 2 = Einzahlung: 2 
:: → es wird nicht gespart 
:: → Guthaben bleibt so wie es ist 

3. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

4. Schritt: Kosten: 3 > Einzahlung: 2 
:: → es wird eine 1 vom Guthaben genommen um die Kosten zu zahlen 

usw.

Man erkennt, dass vor teuren Operation (Wechsel von 3 auf 4 bzw. von 7 auf 8) genügend Guthaben angespart wurde, um die Kosten zu decken. Das Guthaben geht bei diesen Operationen immer wieder auf 1 zurück, aber es wird nie vollständig verbraucht (Dies kann natürlich auch mathematisch exakt bewiesen werden, wie wir es unten am Beispiel des dynamische Arrays zeigen). Wir schließen daraus, dass die durchschnittlichen oder '''amortisierten Kosten''' einer Inkrementierungsoperation gleich 2 sind.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Account-Methode Wikipedia Account-Methode]]

====Fazit====
Die amortisierte Komplexität beschäftigt sich mit dem Durchschnitt aller Operation im ungünstigsten Fall. Operationen mit hohen Kosten, die aber nur selten ausgeführt werden, fallen bei der amortisierten Komplexität nicht so ins Gewicht. Bei Algorithmen, die gelegentlich eine "teure" Operation benutzen, ansonsten jedoch "billige" Operationen aufrufen, kann die amortisierte Komplexität niedriger sein als die Komplexität im schlechtesten (Einzel-)Fall.

In unserem Beispiel fallen die teuren Einzelschritte (z.B. 4. und 8. Schritt) bei den amortisierten Kosten nicht so ins Gewicht, da wir die Kosten aus unserem Guthaben mitbezahlen können. Das Guthaben ist immer groß genug, weil jeder zweite Aufruf eine billige Operation ist, die nur ein Bit umdreht und somit das Ansparen ermöglichen. Diese Betrachtung zeigt, dass die amortisierte (d.h. durchschnittliche) Komplexität des Algoithmus niedriger (nämlich konstant) ist als die Komplexität im schlechtesten Fall.

===Anwendung: Dynamisches Array===

Ein dynamisches Array hat die Eigenschaft, dass man effizient am Ende des Arrays neue Elemente anfügen kann, indem man die Länge des Arrays entsprechend vergrößert (siehe Übung 1). Die Analyse der amortisierten Komplexität der Anfüge-Operation zeigt uns, wie man das Vergrößern des Arrays richtig implementiert, damit die Operation wirklich effizient abläuft.

==== Ineffiziente naive Lösung ====

Wenn wir an ein Array ein Element anhängen wollen, müssen wir neuen Speicher allokieren, der die gewünschte Länge hat. Die Werte aus dem alten Array müssen dann in den neuen Speicher umkopiert werden. Danach kann das neue Element hinten angefügt werden, weil wir im neuen Array bereits Speicher für dieses Element reserviert haben. Bei der naiven Implementation des dynamischen Arrays wiederholt man dies bei jeder Anfügeoperation. Für die Analyse nehmen wir an, dass das Kopieren eines Elements konstante Zeit O(1) erfordert, ebenso das Einfügen eines neuen Elements auf in eine noch unbenutzte Speicherposition.

Naives Anhängen eines weiteren Elements an ein Array:

{| border="1" cellspacing="0" cellpadding="5" align="right"
!Schritte
|'''Array'''
(wie es nach jedem Schritt aussieht)
!Komplexität
|-
|<center>altes Array (N=4)</center>
|<center>[0,1,2,3]</center>
|<center>-</center>
|-
|1. neuer Speicher für    (N+1) Elemente
|<center>[None,None,None,None,None]</center>
|<center>O(N+1) = '''O(N)'''</center>(wenn der Speicher initialisiert wird (hier auf <tt>None</tt>), sonst O(1))
|-
|2. Kopieren
|<center>[0,1,2,3,None]</center>
|<center>'''O(N)'''</center>
|-
|3. append von "x"
|<center>[0,1,2,3,'x']</center>
|<center>'''O(1)'''</center>
|-
|}

altesArray = [0,1,2,3] 
altesArray.append('x')

1. Es wird ein neues Array der Größe N+1 erzeugt 
2. Die N Datenelemente aus dem alten Array werden in das neue Array kopiert 
Das sind N Operationen der Komplexität O(1), also ein Gesamtaufwand von O(N). 
3. 'x' wird mit Aufwand O(1) an die letzte Stelle des neuen Arrays geschrieben

Additionsregel: 
O(N) + O(1) ∈ O(N)

Folgerung:

Bei der naiven Methode erfordert jede Anfügung einen Aufwand O(N) (wobei N die derzeitige Arraygröße ist). Dies ist nicht effizient.

====Effiziente Lösung durch Verdoppeln der Kapazität====

Offensichtlich kommt man nicht darum heraum, den Inhalt des alten Arrays zu kopieren, wenn der allokierte Speicher voll ist. Der Trick für die effiziente Implementation der Anfügeoperation besteht darin, das Kopieren so selten wie möglich durchzuführen, also nicht wie in der naiven Lösung bei jeder Anfügeoperation. Hier kommt die amortisierte Komplexität ins Spiel: Ab und zu gibt es eine teure Anfügeoperation (wenn nämlich kopiert werden muss), aber wenn man den durchschnittlichen Aufwand über viele Anfügungen betrachtet, ist die Operation effizient. Der teure Fall wird sozusagen "herausgemittelt".

Um nur selten kopieren zu müssen, werden beim dynamischen Array mehr Speicherelemente reserviert als zur Zeit benötigt werden (in der naiven Lösung wurde dagegen immer nur Speicher für ein einziges neues Element reserviert). Wir unterscheiden deshalb

:<tt>capacity</tt> = Anzahl der allokierten Speicherzellen, d.h. der möglichen Elemente, die in das Array passen 
:<tt>size</tt> = Anzahl der Elemente, die im Array zur Zeit gespeichert sind 

Die Daten selbst werden in einem statischen Array gespeichert:
:<tt>data</tt> = statisches Array der Größe <tt>capacity</tt> 

Die folgende intuitive Abschätzung zeigt, dass es sinnvoll ist, die Größe des allokierten Speichers jeweils zu verdoppeln. Wir starten bei einem Array der Größe <tt>size = capacity</tt> = N. Da der verfügbare Speicher voll ist, müssen wir bei der nächsten Anfügung die N vorhandenen Elemente in ein neues Array der Länge <tt>new_capacity</tt> kopieren (Aufwand <math>N\cdot O(1)</math>). Danach können wir K Elemente billig einfügen (Aufwand <math>K\cdot O(1)</math>), wobei
:K = <tt>new_capacity - capacity</tt>
die Anzahl der nach dem Kopieren noch unbenutzen Speicherzellen ist. Der durchschnittliche Aufwand für diese K Einfügungen ist somit
:<math>\bar T = \frac{N \cdot O(1) + K \cdot O(1)}{K}=\frac{N+K}{K}\cdot O(1)</math>
Damit die mittlere Zeit in O(1) sein kann, muss der Quotient <math>(N+K)/K</math> eine Konstante sein. Wir setzen <math>K = a N</math> und erhalten:
:<math>\bar T = \frac{(a+1)N}{a N}\cdot O(1)=\frac{a+1}{a}\cdot O(1)</math>
Der amortisierte Aufwand über K Einfügungen ist also konstant, wenn <math>a</math> eine (kleine) von N unabhängige Zahl ist. Typischerweise wählt man
:<math>a = 1</math>
und mit <math>K = 1\cdot N</math> ergibt sich
:<tt>new_capacity = capacity</tt> + N = <tt>2 * capacity</tt>

Die Vorgehensweise beim Zufügen eines neuen Elements im Fall <tt>size == capacity</tt> ist also
* capacity wird verdoppelt 
: <tt>neue capacity = 2 * alte capacity</tt>
: (allgemein genügt es auch, wenn capacity um einen bestimmten Prozentsatz vergrößert wird,
:: <tt>neue capacity = alte capacity * c</tt>
: mit c > 1, z.B. c = 1.2, das entspricht oben der Wahl <math>a = 0.2</math>)
* ein neues statisches Array der Größe 'neue capacity' wird erzeugt
* das alte Array wird ins neue kopiert und danach freigegeben
* das anzufügende Element wird ins neue Array eingefügt
Umgekehrt geht man beim Entfernen des ''letzten'' Array-Elements vor. Normalerweise überschreibt man einfach das letzte Element mit <tt>None</tt> und dekrementiert <tt>size</tt>. Wird dadurch das Array zu klein (üblicherweise <tt>size < capacity / 4</tt>), wird die Kapazität halbiert, genauer:
* ein neues Array mit 
: <tt>neue capacity = alte capacity / 2 </tt>
: wird angelegt (bzw. mit
:: <tt>neue capacity = alte capacity / c </tt>
: wenn ein anderer Vergrößerungsfaktor verwendet wird)
* das alte Array wird ins neue kopiert und danach freigegeben

'''Folge:''' Die Kosten für das Vergrößern/Verkleinern der Kapazität werden amortisiert über viele Einfügungen, die kein Vergrößern erfordern. Die Operation <tt>append</tt> besitzt amortisierte Komplexität O(1). Im folgenden Abschnitt zeigen wir dies mathematisch exakt mit der Potentialmethode.

====Komplexitätsanalyse des dynamischen Arrays mit Potentialmethode====

Durchschnitt der Gesamtkosten für N-maliges append = <math>\frac{1}{N} \sum_{i = 1}^N Kosten(i)</math>. Zur Analyse der amortisierten Komplexität wird ein Potential 
::Φi = 2*sizei - capacityi 
eingeführt, wobei das Array nach dem i-ten Einfüge-Schritt die Größe sizei und die Kapizität capacityi hat. Wir nehmen vereinfachend an, dass es keine Löschoperationen gibt. Dann gilt nach dem i-ten Schritt jeweils
::Φi = 2*i - capacityi 

Fall 1: Array ist nicht voll 
Es wird kein Umkopieren benötigt, da das Array noch nicht voll ist 
→ sizei-1 < capacityi-1 
→ capacityi == capacityi-1

Kosten: 1 (für Einfügen des neuen Elements) 
Potenzial vor append: Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append: Φi = 2i - capacityi-1 

amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = 1 + (2i - capacityi-1) - [2(i - 1) - capacityi-1]
::::: = 1 + 2i - capacityi-1 - 2i + 2 + capacityi-1
::::: = 1 + <del>2i</del> - <del>capacityi-1</del> - <del>2i</del> + 2 + <del>capacityi-1</del>
::::: = 1 + 2
::::: = 3 = O(1) → konstant

Fall 2: Array ist voll 
Vor dem i-ten append muss umkopiert werden 
→ sizei-1 == capacityi-1 == i-1 
→ Allokieren eines neuen statischen Arrays mit verdoppelter Kapazität notwendig, also capacityi == 2*capacityi-1

Kosten: (i-1) + 1 (für Umkopieren und Einfügen des neuen Elements) 
Potenzial vor append = Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append = Φi = 2i - 2 capacityi-1 
amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = ((i - 1) + 1) + 2i - 2 capacityi-1 - [2(i-1) - capacityi-1]
::::: = i + <del>2i</del> - 2 capacityi-1 - <del>2i</del> + 2 - capacityi-1
::::: = i + 2 - capacityi-1
::::: = i + 2 - (i - 1) (da capacityi-1 = i-1)
::::: = 3 = O(1) → konstant

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine amortisierte Komplexität von 3 Einheiten hat, also <tt>append</tt> ∈ O(1)'''. Diese Operation kann deshalb gefahrlos in der inneren Schleife eines Algorithmus benutzt werden.

==== Beispiel für 9 Einfügeoperationen ====

{| border="1" cellspacing="0" cellpadding="5"
!Array 
(wie es aussehen könnte)
!size
!capacity
!Kosten für append (einschließlich Umkopieren)
!Summe Kosten
!Durchschnittskosten
!Φi = 2 * size - capacity 
(i = size)
!Potenzialdifferenz 
Δ Φi = Φi - Φi-1
!amortisierte Kosteni 
= Kosteni + Δ Φi
|-
| <center>[None]</center>
| <center>0</center>
| <center>1</center>
| <center>-</center>
| <center>-</center>
| <center>-</center>
| <center>-1</center>
| <center>-</center>
| <center>-</center>
|-
| <center>[a]</center><center>Array ist voll!</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b]</center><center>Array ist voll!</center>
| <center>2</center>
| <center>2</center>
| <center>1 + 1</center>
| <center>3</center>
| <center>3/2</center>
| <center>2</center>
| <center>1</center>
| <center>3</center>
|-
| <center>[a,b,c,None]</center>
| <center>3</center>
| <center>4</center>
| <center>2 + 1</center>
| <center>6</center>
| <center>6/3</center>
| <center>2</center>
| <center>0</center>
| <center>3</center>
|-
| <center>[a,b,c,d]</center><center>Array ist voll!</center>
| <center>4</center>
| <center>4</center>
| <center>1</center>
| <center>7</center>
| <center>7/4</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,None,None,None]</center>
| <center>5</center>
| <center>8</center>
| <center>4 + 1</center>
| <center>12</center>
| <center>12/5</center>
| <center>2</center>
| <center>-2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,None,None]</center>
| <center>6</center>
| <center>8</center>
| <center>1</center>
| <center>13</center>
| <center>13/6</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,None]</center>
| <center>7</center>
| <center>8</center>
| <center>1</center>
| <center>14</center>
| <center>14/7</center>
| <center>6</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h]</center><center>Array ist voll!</center>
| <center>8</center>
| <center>8</center>
| <center>1</center>
| <center>15</center>
| <center>15/8</center>
| <center>8</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h,j,None,None,None, 
None,None,None,None]</center>
| <center>9</center>
| <center>16</center>
| <center>8 + 1</center>
| <center>24</center>
| <center>24/9</center>
| <center>2</center>
| <center>-6</center>
| <center>3</center>
|-
|}

Die durchschnittlichen Kosten betragen stets etwa 2 Einheiten, schwanken allerdings so, dass nicht unmittelbar ersichtlich ist, ob dies für sämtliche Einfügeoperationen gilt. Die amortisierte Komplexität, die mit Hilfe des Potentials berechnet wird, ist hingegen konstant 3, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

[[Suchen|Nächstes Thema]]

Effizienz

2012-07-27T15:58:31Z

Ukoethe: /* Amortisierte Komplexität */

Bei der Diskussion von Effizienz müssen wir zwischen der Laufzeit eines Algorithmus auf einem bestimmten System und seiner prinzipiellen Leistungsfähigkeit (Algorithmenkomplexität) unterscheiden. Der Benutzer ist natürlich vor allem an der Laufzeit interessiert, denn diese bestimmt letztendlich seine Arbeitsproduktivität. Ein Softwaredesigner hingegen muss eine Implementation wählen, die auf verschiedenen Systemen und in verschiedenen Anwendungen schnell ist. Für ihn sind daher auch Aussagen zur Algorithmenkomplexität sehr wichtig, um den am besten geeigneten Algorithmus auszuwählen.

== Laufzeit ==

Aus Anwendersicht ist ein Algorithmus effizient, wenn er die in der Spezifikation verlangten Laufzeitgrenzen einhält. Ein Algorithmus muss also nicht immer so schnell wie möglich sein, sondern so schnell wie nötig. Dies führt in verschiedenen Anwendungen zu ganz unterschiedliche Laufzeitanforderungen:

* Berechnen des nächsten Steuerkommandos für eine Maschine: ca. 1/1000s
* Berechnen des nächsten Bildes für eine Videopräsentation (z.B. Dekompression von MPEG-kodierten Bildern): ca. 1/25s
: Geringere Bildraten führen zu ruckeligen Filmen.
* Sichtbare Antwort auf ein interaktives Kommando (z.B. Mausklick): ca. 1/2s
: Wird diese Antwortzeit überschritten, vermuten viele Benutzer, dass der Mausklick nicht funktioniert hat, und klicken nochmals, mit eventuell fatalen Folgen. Wenn ein Algorithmus notwendigerweise länger dauert als 1/2s, sollte ein Fortschrittsbalken angezeigt werden.
* Wettervorhersage: muss spätestens am Vorabend des vorhergesagten Tages beendet sein

===Laufzeitvergleich===

Da die Laufzeit für den Benutzer ein so wichtiges Kriterium ist, werden häufig Laufzeitvergleiche durchgeführt. Deren Ergebnisse hängen allerdings von vielen Faktoren ab, die möglicherweise nicht kontrollierbar sind:
* Geschwindigkeit und Anzahl der Prozessoren
* Auslastung des Systems
* Größe des Hauptspeichers und Cache, Geschwindigkeit des Datenbus
* Qualität des Compilers/Optimierers (ist der Compiler für die spezielle Prozessor-Architektur optimiert?)
* Geschick des Programmierers
* Daten (Beispiel Quicksort: Best case und worst case [vorsortierter Input] stark unterschiedlich)
All diese Faktoren sind untereinander abhängig. Laufzeitvergleiche sind daher mit Vorsicht zu interpretieren.
Generell sollten bei Vergleichen möglichst wenige Parameter verändert werden, z.B.
* gleiches Programm (gleiche Kompilierung), gleiche Daten, andere Prozessoren
oder
* gleiche CPU, Daten, andere Programme (Vergleich von Algorithmen)
Zur Verbesserung der Vergleichbarkeit gibt es standardisierte [http://en.wikipedia.org/wiki/Benchmark_(computing) Benchmarks], die bestimmte Aspekte eines Systems unter möglichst realitätsnahen Bedingungen testen. Generell gilt aber: Durch Laufzeitmessung ist schwer festzustellen, ob ein Algorithmus ''prinzipiell'' besser ist als ein anderer. Dafür ist die Analyse der [[Effizienz#Algorithmen-Komplexität|Algorithmenkomplexität]] notwendig.

===Optimierung der Laufzeit===

Wenn sich herausstellt, dass ein bereits implementierter Algorithmus zu langsam läuft, geht man wie folgt vor:

# Man verwendet einen [http://en.wikipedia.org/wiki/Performance_analysis Profiler], um zunächst den Flaschenhals zu bestimmen. Ein Profiler ist ein Hilfsprogramm, das während der Ausführung eines Programms misst, wieviel Zeit in jeder Funktion und Unterfunktion verbraucht wird. Dadurch kann man herausfinden, welcher Teil des Algorithmus überhaupt Probleme bereitet. Donald Knuth gibt z.B. als Erfahrungswert an, dass Programme während des größten Teils ihrer Laufzeit nur 3% des Quellcodes (natürlich mehrmals wiederholt) ausführen [http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf]. Es ist sehr wichtig, diese 3% experimentell zu bestimmen, weil die Erfahrung zeigt, dass man beim Erraten der kritischen Programmteile oft falsch liegt. Man spricht dann von "[http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize premature optimization]", also von voreiliger Optimierung ohne experimentelle Untersuchung der wirklichen Laufzeiten, was laut Knuth "the root of all evil" ist. Der Python-Profiler wird in [http://docs.python.org/lib/profile.html Kapitel 25] der Python-Dokumentation beschrieben.
# Man kann dann versuchen, die kritischen Programmteile zu optimieren.
# Falls der Laufzeitgewinn durch Optimierung zu gering ist, muss man einen prinzipiell schnelleren Algorithmus verwenden, falls es einen gibt.

Einige wichtige Techniken der Programmoptimierung sollen hier erwähnt werden. Wenn man einen optimierenden Compiler verwendet, werden einige Optimierungen automatisch ausgeführt [http://en.wikipedia.org/wiki/Compiler_optimization]. In Python trifft dies jedoch nicht zu. Um den Sinn einiger Optimierungen zu verstehen, benötigt man Grundkenntnisse der Computerarchitektur.

;Elimination von redundantem Code: Es ist offensichtlich überflüssig, dasselbe Ergebnis mehrmals zu berechnen, wenn es auch zwischengespeichert werden könnte. Diese Optimierung wird von vielen automatischen Optimierern unterstützt und kommt im wesentlichen in zwei Ausprägungen vor:
:; common subexpression elimination: In mathematischen Ausdrücken wird ein Teilergebnis häufig mehrmals benötigt. Man betrachte z.B. die Lösung der quadratischen Gleichung <math>x^2+p\,x+q = 0</math>:
x1 = - p / 2.0 + sqrt(p*p/4.0 - q)
x2 = - p / 2.0 - sqrt(p*p/4.0 - q)
::Die mehrmalige Berechnung von Teilausdrücken wird vermieden, wenn man stattdessen schreibt:
p2 = - p / 2.0
r = sqrt(p2*p2 - q)
x1 = p2 + r
x2 = p2 - r
:; loop invariant elimination: Wenn ein Teilausdruck sich in einer Schleife nicht ändert, muss man ihn nicht bei jedem Schleifendurchlauf neu berechnen, sondern kann dies einmal vor Beginn der Schleife tun. Ein typisches Beispiel hierfür ist die Adressierung von Matrizen, die als 1-dimensionales Array gespeichert sind. Angenommen, wir speichern eine NxN Matrix <tt>m</tt> in einem Array <tt>a</tt> der Größe N2, so dass das Matrixelement <tt>mij</tt> durch <tt>a[i + j*N]</tt> indexiert wird. Wir betrachten die Aufgabe, eine Einheitsmatrix zu initialisieren. Ein nicht optimierter Algorithmus dafür lautet:
for j in range(N):
for i in range(N):
if i == j:
a[i + j*N] = 1.0
else:
a[i + j*N] = 0.0
::Der Ausdruck <tt>j*N</tt> wird hier in jedem Schleifendurchlauf erneut berechnet, obwohl sich <tt>j</tt> in der inneren Schleife gar nicht verändert. Man kann deshalb optimieren zu:
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
;Vereinfachung der inneren Schleife: Generell sollte man sich bei der Optimierung auf die innere Schleife eines Algorithmus konzentrieren, weil dieser Code am häufigsten ausgeführt wird. Insbesondere sollte man die Anzahl der Befehle in der inneren Schleife so gering wie möglich halten und teure Befehle vermeiden. Früher waren vor allem Floating-Point Befehle teuer, die man oft durch die schnellere Integer-Arithmetik ersetzt hat, falls dies algorithmisch möglich war (diesen Rat findet man noch oft in der Literatur). Heute hat sich die Hardware so verbessert, dass im Allgemeinen nur noch die Floating-Point Division deutlich langsamer ist als die anderen Operatoren. Im obigen Beispiel der quadratischen Gleichung ist es daher sinnvoll, den Ausdruck
p2 = -p / 2.0
:durch
p2 = -0.5 * p
:zu ersetzen. Dadurch ersetzt man eine Division durch eine Multiplikation und spart außerdem das Negieren von <tt>p</tt>, da der Compiler direkt mit <tt>-0.5</tt> multipliziert.
;Ausnutzung der Prozessor-Pipeline: Moderne Prozessoren führen mehrere Befehle parallel aus. Dies ist möglich, weil jeder Befehl in mehrere Teilschritte zerlegt werden kann. Eine generische Unterteilung in vier Teilschritte ist z.B.:
:# Dekodieren des nächsten Befehls
:# Beschaffen der Daten, die der Befehl verwendet (aus Prozessorregistern, dem Cache, oder dem Hauptspeicher)
:# Ausführen des Befehls
:# Schreiben der Ergebnisse
:Man bezeichnet dies als die "[http://en.wikipedia.org/wiki/Instruction_pipeline instruction pipeline]" des Prozessors (heutige Prozessoren verwenden wesentlich feinere Unterteilungen). Prozessoren werden nun so gebaut, dass mehrere Befehle parallel, auf verschiedenen Ausführungsstufen ausgeführt werden. Wenn Befehl 1 also beim Schreiben der Ergebnisse angelangt ist, kann Befehl 2 die Hardware zum Ausführen des Befehls benutzen, während Befehl 3 seine Daten holt, und Befehl 4 soeben dekodiert wird. Unter bestimmten Bedingungen funktioniert diese Parallelverarbeitung jedoch nicht. Dies gibt Anlass zu Optimierungen:
:;Vermeiden unnötiger Typkonvertierungen: Der Prozessor verarbeitet Interger- und Floating-Point-Befehle in verschiedenen Pipelines, weil die Hardwareanforderungen sehr verschieden sind. Wird jetzt ein Ergebnis von Integer nach Floating-Point umgewandelt oder umgekehrt, muss die jeweils andere Pipeline warten, bis die erste Pipeline ihre Berechnung beendet. Es kann dann besser sein, Berechnungen in Floating-Point zu Ende zu führen, auch wenn sie semantisch eigentlich Integer-Berechnungen sind.
:;Reduzierung der Anzahl von Verzweigungen: Wenn der Code verzweigt (z.B. durch eine <tt>if</tt>- oder <tt>while</tt>-Anweisung), ist nicht klar, welcher Befehl nach der Verzweigung ausgeführt werden soll, bevor Stufe 3 der Pipeline die Verzweigungsbedingung ausgewertet hat. Bis dahin wären die ersten beiden Stufen der Pipeline unbenutzt. Moderne Prozessoren benutzen zwar ausgefeilte Heuristiken, um das Ergebnis der Bedingung vorherzusagen, und führen den hoffentlich richtigen Zweig des Codes spekulativ aus, aber dies funktioniert nicht immer. Man sollte deshalb generell die Anzahl der Verzweigungen minimieren. Als Nebeneffekt führt dies meist auch zu besser lesbarem, verständlicherem Code. Im Matrixbeispiel kann man
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
::durch
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
ersetzen. Die Diagonalelemente <tt>a[j + jN]</tt> werden jetzt zwar zweimal initialisiert (in der Schleife auf Null, dann auf Eins), aber durch Elimination der <tt>if</tt>-Abfrage wird dies wahrscheinlich mehr als ausgeglichen, zumal dadurch die innere Schleife wesentlich vereinfacht wurde.
;Ausnutzen des Prozessor-Cache: Zugriffe auf den Hauptspeicher sind sehr langsam. Deshalb werden stets ganze Speicherseiten auf einmal in den [http://en.wikipedia.org/wiki/Cache Cache] des Prozessors geladen. Wenn unmittelbar nacheinander benutzte Daten auch im Speicher nahe beieinander liegen (sogenannte "[http://en.wikipedia.org/wiki/Locality_of_reference locality of reference]"), ist die Wahrscheinlichkeit groß, dass die als nächstes benötigten Daten bereits im Cache sind und damit schnell gelesen werden können. Bei vielen Algorithmen kann man die Implementation so umordnen, dass die locality of reference verbessert wird, was zu einer drastischen Beschleunigung führt. Im Matrix-Beispiel ist z.B. die Reihenfolge der Schleifen wichtig. Für konstanten Index <tt>j</tt> liegen die Indizes <tt>i</tt> im Speicher hintereinander. Deshalb ist es günstig, in der inneren Schleife über <tt>i</tt> zu iterieren:
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
:Die umgekehrte Reihenfolge der Schleifen ist hingegen ungünstig
for i in range(N):
for j in range(N):
a[i + j*N] = 0.0
a[i + i*N] = 1.0
:Jetzt werden in der inneren Schleife stets N Datenelemente übersprungen. Besonders bei großem N muss man daher häufig den Cache neu füllen, was bei der ersten Implementation nicht notwendig war. (Außerdem verliert man hier die Optimierung <tt>jN = j*N</tt>, die jetzt nicht mehr möglich ist.)

Als Faustregel kann man durch Optimierung eine Verdoppelung der Geschwindigkeit erreichen (in Ausnahmefällen auch mehr). Benötigt man stärkere Verbesserungen, muss man wohl oder übel einen besseren Algorithmus oder einen schnelleren Computer verwenden.

== Algorithmen-Komplexität ==

Komplexitätsbetrachtungen ermöglichen den Vergleich der prinzipiellen Eigenschaften von Algorithmen unabhängig von einer Implementation, Umgebung etc.

Eine einfache Möglichkeit ist das Zählen der Aufrufe einer Schlüsseloperation. Beispiel Sortieren:
* Anzahl der Vergleiche
* Anzahl der Vertauschungen

=== Beispiel: Selection Sort ===

for i in range(len(a)-1):
max = i
for j in range(i+1, len(a)):
if a[j] < a[max]:
max = j
a[max], a[i] = a[i], a[max] # swap

*Anzahl der Vergleiche: Ein Vergleich in jedem Durchlauf der inneren Schleife. Es ergibt sich folgende Komplexität:
*:Ingesamt <math>\sum_{i=0}^{N-2} \sum_{j=i+1}^{N-1}1 = \frac{N}{2} (N-1) \!</math> Vergleiche.

*Anzahl der Vertauschungen (swaps): Eine Vertauschung pro Durchlauf der äußeren Schleife:
*:Insgesamt <math>N-1 \!</math> Vertauschungen

Die Komplexität wird durch die Operationen bestimmt, die am häufigsten ausgeführt werden, hier also die Anzahl der Vergleiche. Die Anzahl der Vertauschungen ist hingegen kein geeignetes Kriterium für die Komplexität von selection sort, weil der Aufwand in der inneren Schleife ignoriert würde.

=== Fallunterscheidung: Worst und Average Case ===

Die Komplexität ist in der Regel eine Funktion der Eingabegröße (Anzahl der Eingabebits, Anzahl der Eingabeelemente). Sie kann aber auch von der Art der Daten abhängen, nicht nur von der Menge, z.B. vorsortierte Daten bei Quicksort. Um von der Art der Daten unabhängig zu werden, kann man zwei Fälle der Komplexität unterscheiden:

* Komplexität im ungünstigsten Fall
*: Der ungünstigste Fall ist die Eingabe gegebener Länge, für die der Algorithmus am langsamsten ist. Der Nachteil dieser Methode besteht darin, dass dieser ungünstige Fall in der Praxis vielleicht gar nicht oder nur selten vorkommt, so dass sich der Algorithmus in Wirklichkeit besser verhält als man nach dieser Analyse erwarten würde. Beim Quicksort-Algorithmus mit zufälliger Wahl des Pivot-Elements müsste z.B. stets das kleinste oder größte Element des aktuellen Intervalls als Pivot-Element gewählt werden, was äußerst unwahrscheinlich ist.
* Komplexität im durchschnittlichen/typischen Fall
*: Der typische Fall ist die mittlere Komplexität des Algorithmus über alle möglichen Eingaben. Dazu muss man die Wahrscheinlichkeit jeder möglichen Eingabe kennen, und berechnet dann die mittlere Laufzeit über dieser Wahrscheinlichkeitsverteilung. Leider ist die Wahrscheinlichkeit der Eingaben oft nicht bekannt, so dass man geeignete Annahmen treffen muss. Bei Sortieralgorithmen können z.B. alle möglichen Permutationen des Eingabearrays als gleich wahrscheinlich angenommen werden, und der typische Fall ist dann die mittlere Komplexität über alle diese Eingaben. Oft hat man jedoch in der Praxis andere Wahrscheinlichkeitsverteilungen, z.B. sind die Daten oft "fast sortiert" (nur wenige Elemente sind an der falschen Stelle). Dann verhält sich der Algorithmus ebenfalls anders als vorhergesagt.

Wir beschränken uns in dieser Vorlesung auf die Komplexität im ungünstigseten Fall. '''Exakte''' Formeln für Komplexität sind aber auch dann schwer zu gewinnen, wie das folgende Beispiel zeigt:

=== Beispiele aus den Übungen (Gemessene Laufzeiten für Mergesort/Selectionsort) ===

* Mergesort: <math>\frac{0,977N\log N}{\log 2} + 0,267N-4.39 \!</math>
*: andere Lösung: <math>1140 N\log(N) - 1819N + 6413 \!</math>
* Selectionsort: <math>\frac{1}{2}N^2 - \frac{1}{2N} - 10^{-12} \!</math>
*: andere Lösung: <math>1275N^2 - 116003^N + 11111144 \!</math>

Aus diesen Formeln wird nicht offensichtlich, welcher Algorithmus besser ist.
Näherung: Betrachte nur '''sehr große Eingaben''' (meist sind alle Algorithmen schnell genug für kleine Eingaben). Dieses Vorgehen wird als '''Asymptotische Komplexität''' bezeichnet (N gegen unendlich).

=== Asymptotische Komplexität am Beispiel Polynom ===

Polynom: <math>a\,x^2+b\,x+c=p\!</math>

<math>x \!</math> sei die Eingabegröße, und wir betrachten die Entwicklung von <math>p \!</math> in Abhängigkeit von <math>x \!</math>.

* <math>x=0 \!</math>
*: <math>p=c \!</math>
* <math>x=1 \!</math>
*: <math>p=a+b+c \!</math>
* <math>x=1000 \!</math>
*: <math>p=1000000a+1000b+c \approx 1000000a\!</math>
* <math>x \to \infty \!</math>
*: <math>p \approx x^2a\!</math>

Für sehr große Eingaben verlieren also ''b'' und ''c'' immer mehr an Bedeutung, so dass am Ende nur noch ''a'' für die Komplexitätsbetrachtung wichtig ist.

== Landau-Symbole ==

Um die asymptotische Komplexität verschiedener Algorithmen miteinander vergleichen zu können, verwendet man die sogenannten [http://de.wikipedia.org/wiki/Landau-Symbole Landau-Symbole]. Das wichtigste Landau-Symbol ist <math>\mathcal{O}</math>, mit dem man eine ''obere Schranke'' <math>f \in \mathcal{O}(g)</math> für die Komplexität angeben kann.

Schreibt man <math>f \in \Omega(g)</math>, so stellt dies eine asymptotische ''untere Schranke'' für die Funktion f dar.

Schließlich bedeutet <math>f \in \Theta(g)</math>, dass die Funktion f genauso schnell wie die Funktion g wächst, das heißt man hat eine asymptotisch ''scharfe Schranke'' für f. Hierzu muss sowohl <math>f\in\mathcal{O}(g)</math> als auch <math>f \in \Omega(g)</math> erfüllt sein.

Im nun folgenden soll auf die verschiedenen Landau-Symbole noch näher eingegeangen werden.

===O-Notation===

Intuitiv gilt: Für große N dominieren die am schnellsten wachsenden Terme einer Funktion. Die Notation <math>f \in \mathcal{O}(g)</math> (sprich "f ist in O von g" oder "f ist von derselben Größenordnung wie g") formalisiert eine solche Abschätzung der asymptotischen Komplexität der Funktion f von oben.
; Asymptotische Komplexität: Für zwei Funktionen f(x) und g(x) gilt
::<math>f(x) \in \mathcal{O}(g(x))</math>
: genau dann wenn es eine Konstante <math>c>0</math> und ein Argument <math>x_0</math> gibt, so dass
::<math>\forall x \ge x_0:\quad f(x) \le c\,g(x)</math>.
:Die Menge <math>\mathcal{O}(g(x))</math> aller durch g(x) abschätzbaren Funktionen ist also formal definiert durch
::<math>\mathcal{O}(g(x)) = \{ f(x)\ |\ \exists c>0: \forall x \ge x_0: 0 \le f(x) \le c\,g(x)\}</math>

Die Idee hinter dieser Definition ist, dass g(x) eine wesentlich einfachere Funktion ist als f(x), die sich aber nach geeigneter Skalierung (Multiplikation mit c) und für große Argumente x im wesentlichen genauso wie f(x) verhält. Man kann deshalb in der Algorithmenanalyse f(x) durch g(x) ersetzen. <math>f(x) \in \mathcal{O}(g(x))</math> spielt für Funktionen eine ähnliche Rolle wie der Operator ≤ für Zahlen: Falls a ≤ b gilt, kann bei einer Abschätzung von oben ebenfalls a durch b ersetzt werden.

==== Ein einfaches Beispiel ====

[[Image:Sqsqrt.png]]

Rot = <math>x^2 \!</math>
Blau = <math>\sqrt{x} \!</math>

<math>\sqrt{x} \in \mathcal{O}(x^2)\!</math> weil <math>\sqrt{x} \le c\,x^2\!</math> für alle <math>x \ge x_0 = 1 \!</math> und <math>c = 1\!</math>, oder auch für <math>x \ge x_0 = 4 \!</math> und <math>c = 1/16</math> (die Wahl von c und x0 in der Definition von O(.) ist beliebig, solange die Bedingungen erfüllt sind).

==== Komplexität bei kleinen Eingaben ====

Algorithmus 1: <math>\mathcal{O}(N^2) \!</math> 
Algorithmus 2: <math>\mathcal{O}(N\log{N}) \!</math>

Algorithmus 2 ist schneller (von geringerer Komplexität) für große Eingaben, aber bei kleinen Eingaben (insbesondere, wenn der Algorithmus in einer Schleife immer wieder mit kleinen Eingaben aufgerufen wird) könnte Algorithmus 1 schneller sein, falls der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor ''c'' bei Algorithmus 2 einen wesentlich größeren Wert hat als bei Algorithmus 1.

==== Eigenschaften der O-Notation (Rechenregeln) ====

# Transitiv:
#: <math>f(x) \in \mathcal{O}(g(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) \in \mathcal{O}(h(x)) \!</math>
# Additiv:
#: <math>f(x) \in \mathcal{O}(h(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) + g(x) \in \mathcal{O}(h(x)) \!</math>
# Für Monome gilt:
#: <math>x^k \in \mathcal{O}(x^k)</math> und
#: <math>x^k \in \mathcal{O}(x^{k+j}), \forall j \ge 0 \!</math>
# Multiplikation mit einer Konstanten:
#: <math>f(x) \in \mathcal{O}(g(x)) \to c\,f(x) \in \mathcal{O}(g(x))\!</math>
#: andere Schreibweise:
#: <math>f(x) = c\,g(x) \to f(x) \in \mathcal{O}(g(x))\!</math>
# Folgerung aus 3. und 4. für Polynome:
#: <math>a_0+a_1\,x + ... + a_n\,x^n \in \mathcal{O}(x^n)\!</math>
#: Beispiel: <math>a\,x^2+b\,x+c \in \mathcal{O}(x^2)\!</math>
# Logarithmus:
#: <math>a, b > 1\!</math>
#: <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>
#: Die Basis des Logarithmus spielt also keine Rolle.
#: Beweis hierfür:
#:: <math>\log_{a}{x} = \frac{\log_{b}{x}}{\log_{b}{a}}\!</math>
#:: Mit <math>c = 1 / \log_{b}{a}\,</math> gilt: <math>\log_{a}{x} = c\,\log_{b}{x}\!</math>.
#:: Wird hier die (zweite) Regel für Multiplikation mit einer Konstanten angewendet, fällt der konstante Faktor weg, also <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>.
#: Insbesondere gilt auch <math>\log_{a}{x} \in \mathcal{O}(\log_{2}{x})\!</math>, es kann also immer der 2er Logarithmus verwendet werden.

==== O-Kalkül ====

Das O-Kalkül definiert wichtige Vereinfachungsregeln for Ausdrücke in O-Notation (Beweise: siehe Übungsaufgabe):

# <math>f(x) \in \mathcal{O}(f(x))\!</math>
# <math>\mathcal{O}(\mathcal{O}(f(x))) \in \mathcal{O}(f(x))\!</math>
# <math>c\,\mathcal{O}(f(x)) \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# <math>\mathcal{O}(f(x))+c \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# Sequenzregel:
#: Wenn zwei nacheinander ausgeführte Programmteile die Komplexität <math>\mathcal{O}(f(x))</math> bzw. <math>\mathcal{O}(g(x))</math> haben, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(f(x))</math> falls <math>g(x) < \mathcal{O}(f(x))</math> bzw.
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(g(x))\!</math> falls <math>f(x) < \mathcal{O}(g(x))</math>.
#: Informell schreibt man auch: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(max(f(x), g(x)))\!</math>.
# Schachtelungsregel bzw. Aufrufregel:
#: Wenn in einer geschachtelten Schleife die äußere Schleife die Komplexität <math>\mathcal{O}(f(x))</math> hat, und die innere <math>\mathcal{O}(g(x))</math>, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) * \mathcal{O}(g(x)) \in \mathcal{O}(f(x) * g(x))\!</math>.
#: Gleiches gilt wenn eine Funktion <math>\mathcal{O}(f(x))</math>-mal aufgerufen wird, und die Komplexität der Funktion selbst <math>\mathcal{O}(g(x))</math> ist.

;Beispiel für 5.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Dies gilt auch für ihre Hintereinanderausführung:
for i in range(N):
a[i] = i
for i in range(N):
print a[i]
;Beispiele für 6.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Ihre Verschachtelung hat daher die Komplexität <math>\mathcal{O}(N^2)</math>.
for i in range(N):
for j in range(N):
a[i*N + j] = i+j
: Dies gilt ebenso, wenn statt der inneren Schleife eine Funktion mit Komplexität <math>\mathcal{O}(N)</math> ausgeführt wird:
for i in range(N):
a[i] = foo(i, N) # <math>\mathrm{foo}(i, N) \in \mathcal{O}(N)</math>

==== O-Kalkül auf das Beispiel des Selectionsort angewandt ====

Selectionsort: Wir hatten gezeigt dass <math>f(N) = \frac{N^2}{2} - \frac{N}{2}</math>. Nach der Regel für Polynome vereinfacht sich dies zu <math>f(N) \in \mathcal{O}\left(\frac{N^2}{2}\right) = \mathcal{O}(N^2)\!</math>.

Alternativ via Schachtelungsregel:
: Die äußere Schleife wird (''N''-1)-mal durchlaufen: <math>N-1 \in \mathcal{O}(N)</math>
: Die innere Schleife wird (''N-i''-1)-mal durchlaufen. Das sind im Mittel ''N''/2 Durchläufe: <math>N/2 \in \mathcal{O}(N)</math>
: Zusammen: <math>\mathcal{O}(N)*\mathcal{O}(N) \in \mathcal{O}(N^2)</math>

Nach beiden Vorgehensweisen kommen wir zur Schlussfolgerung, dass der Selectionsort die asymptotische Komplexität <math>\mathcal{O}(N^2)\!</math> besitzt.

==== Zusammenhang zwischen Komplexität und Laufzeit ====

Wenn eine Operation 1ms dauert, erreichen Algorithmen verschiedener Komplexität folgende Leistungen (wobei angenommen wird, dass der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor immer etwa gleich 1 ist):

{| class="wikitable" style="text-align:left" cellpadding="7"
|+
|-
! Komplexität !! Operationen in 1s !! Operationen in 1min !! Operationen in 1h
|-
! <math>\mathcal{O}(N)</math>
| 1000 || 60.000 || 3.600.000
|-
! <math>\mathcal{O}(N\log_2{N})</math>
| 140 || 4895 || 204094
|-
! <math>\mathcal{O}(N^2)</math>
| 32 || 245 || 1898
|-
! <math>\mathcal{O}(N^3)</math>
| 10 || 39 || 153
|-
! <math>\mathcal{O}(2^N)</math>
| 10 || 16 || 21
|}

==== Exponentielle Komplexität ====
Der letzte Fall <math>\mathcal{O}(2^N)</math> ist von exponentieller Komplexität. Das bedeutet, dass eine Verdopplung des Aufwands nur bewirkt, dass die maximale Problemgröße um eine Konstante wächst. Algorithmen mit exponentieller (oder noch höherer) Komplexität werden deshalb als '''ineffizient''' bezeichnet. Algorithmen mit höchstens polynomieller Komplexität gelten hingegen als effizient.

In der Praxis sind allerdings auch polynomielle Algorithmen mit hohem Exponenten meist zu langsam. Als Faustregel kann man eine praktische Grenze von <math>\mathcal{O}(N^3)</math> ansehen. Bei einer Komplexität von <math>\mathcal{O}(N^3)</math> bewirkt ein verdoppelter Aufwand immer noch eine Steigerung der maximalen Problemgröße um den Faktor <math>\sqrt[3]{2}</math> (also eine ''multiplikative'' Vergrößerung um ca. 25%, statt nur einer additiven Vergrößerung wie bei exponentieller Komplexität).

===<math>\Omega</math>- Notation===

Genauso wie <math>f \in \mathcal{O}(g)</math> eine Art <math>\le</math>-Operator für Funktionen ist, definiert <math>f \in \Omega(g) </math> eine Abschätzung von unten, analog zum <math>\ge</math>-Operator für Zahlen. Formal kann man <math>f(N) \in \Omega(g(N)) </math> genau dann schreiben, falls es eine Konstante <math> c > 0 </math> gibt, so dass

<math> f(N) \ge c \cdot g(N) </math> für <math> N \ge N_0 </math>

gilt.
Man verwendet diese Notation also um abzuschätzen, wie groß der Aufwand (die Komplexität) für einen bestimmten Algorithmus ''mindestens'' ist und nicht ''höchstens'', was man mit der <math>\mathcal{O}</math> - Notation ausdrücken würde.

Ein praktisches Beispiel für eine Anwendung der <math>\Omega</math>- Notation wäre die Fragestellung, ob es ''prinzipiell'' einen besseren Algorithmus für ein bestimmtes Problem gibt. Wie später im Abschnitt [[Suchen#Sortieren_als_Suchproblem|Sortieren als Suchproblem]] gezeigt wird, ist das Sortieren eines Arrays durch paarweise Vergleiche von Elementen immer mindestens von der Komplexität <math> \Omega(N\cdot \ln N) </math>, was konkret bedeutet, dass kein Sortieralgorithmus, der nach diesem Prinzip arbeitet, jemals eine geringere Komplexität als beispielsweise Merge-Sort haben wird. Natürlich kann man den entsprechenden Sortieralgorithmus, also Merge-Sort zum Beispiel, unter Umständen noch optimieren, aber die Komplexität wird erhalten bleiben. Mit diesem Wissen kann man sich viel (vergebliche) Arbeit sparen.

===<math>\Theta</math>- Notation===

<math>f(N) \in \Theta(g(N))</math> ist eine scharfe Abschätzung der asymptotischen Komplexität einer Funktion f.

Damit dies gilt, muss <math>f(N) \in \mathcal{O}(g(N))</math> und ''gleichzeitig'' <math>f(N) \in \Omega(g(N))</math> erfüllt sein.

Dies ist natürlich auch die beste Abschätzung der asymptotischen Komplexität einer Funktion f. Formal bedeutet <math>f(N) \in \Theta(g(N))</math> dass es zwei Konstanten <math> c_1 </math> und <math> c_2 </math>, beide größer als Null, gibt, so dass für alle <math> N \geq N_0 </math> gilt:

<math> c_1 \cdot g(N) \leq f(N) \leq c_2 \cdot g(N) </math>.

In der Praxis wird manchmal statt der <math>\Theta</math>-Notation auch dann die <math>\mathcal{O}</math>-Notation benutzt, wenn eine scharfe Schranke ausgedrückt werden soll. Dies ist zwar formal nicht korrekt, aber man kann die intendierte Bedeutung meist aus dem Kontext erschließen.

== Komplexitätsvergleich zweier Algorithmen ==

In diesem Abschnitt wollen wir der Frage nachgehen, wie ein formaler Beweis für die Behauptung <math> f(N) \in \mathcal{O}(g(N))</math> geschehen kann. Hierbei werden zwei Beweismethoden vorgestellt werden, und zwar der '''Beweis über die Definition der Komplexität''' sowie der '''Beweis durch Dividieren'''.

===Beweis über die Definition der asymptotischen Komplexität===

Die Definition der asymptotischen Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> war:

Es gibt eine Konstante <math> c > 0 </math>, so dass <math> f(N) \le c \cdot g(N) </math> für <math> N \ge N_0 </math> erfüllt ist.

Um also die die asymptotische Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> zu beweisen, muss man die oben erwähnten Konstanten c und <math> N_0 </math> finden, so dass

<math> f(N) \leq c \cdot g(N) </math> für alle <math> N \ge N_0 </math> erfüllt ist.

Dies geschieht zweckmäßigerweise mit dem Beweisprinzip der ''vollständigen Induktion''. Hierbei ist zu zeigen, dass
# <math> f(N_0) \leq g(N_0) </math> für die eine zu bestimmende Konstante <math> N_0 </math> gilt (''Induktionsanfang'') und
# falls <math> f(N) \leq g(N) </math>, dann auch <math> f(N+1) \leq g(N+1) </math> (''Induktionsschritt'') gilt.

===Beweis durch Dividieren===

Hierbei wählt man eine Konstante c und zeigt, dass <math> \lim_{N \rightarrow \infty} \frac{f(N)}{c \cdot g(N)} \leq 1 </math> gilt (für die O-Notation, bei Ω-Notation gilt entsprechend <math>\geq 1 </math>). Man kann dies auch als alternative Definition der Komplexität verwenden.

Als Beispiel betrachten wir die beiden Funktionen <math> f(N) = N \,\lg N </math> und <math> g(N) = N^2 </math> und wollen zeigen, dass <math>f(N) \in \mathcal{O}(g(N))</math> gilt.

Als Konstante c wählen wir <math> c = 1 </math>

<math> \lim_{N \rightarrow \infty} \frac{f(N)}{g(N)} = \lim_{N \rightarrow \infty} \frac{\lg N}{N} = \frac{\infty}{\infty} </math>

Unbestimmte Ausdrücke der Form
<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} </math>,
in denen sowohl <math> f(x) </math> als auch <math> g(x) </math> mit <math> x \rightarrow x_0 </math> gegen Null oder gegen Unendlich streben, kann man manchmal mit den Regeln von [http://de.wikipedia.org/wiki/L%27Hospital%27sche_Regel ''l'Hospital''] berechnen. Danach darf man die Funktionen f und g zur Berechnung des unbestimmten Ausdrucks durch ihre k-ten Ableitungen ersetzen:

<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} = \lim_{x \rightarrow x_0} \frac{f^{(k)}(x)}{g^{(k)}(x)} </math>

In unserem Fall verwenden wir die erste Ableitung und erhalten:
<math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)} = \lim_{N \rightarrow \infty} \frac{1/N}{1} \rightarrow 0 </math>

Damit wurde <math>f(N) \in \mathcal{O}(g(N))</math>, also <math>N \lg N \in \mathcal{O}(N^2)</math> gezeigt.

Man beachte hierbei, dass <math>N \lg N \in \mathcal{O}(N^2)</math> keine enge Grenze für die Komplexität von <math>N \,\lg N</math> darstellt, da der Grenzwert <math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)}\, </math> gegen 0 und nicht gegen eine von Null verschiedene Konstante strebt. In diesem Fall haben wir die Komplexität von <math>N \cdot \lg N </math> also nur nach oben abschätzen können.

===Beispiel für den Komplexitätsvergleich: Gleitender Mittelwert (Running Average)===

Wir berechnen für ein gegebenes Array <tt>a</tt> einen gleitenden Mittelwert über <tt>k</tt> Elemente: 
::<math>r_i = \frac{1}{k} \sum_{j=i-k+1}^i a_j</math> 
Das heisst, für jedes <tt>i</tt> mitteln wir die letzten <tt>k</tt> Elemente von <tt>a</tt> und schreiben das Ergebnis in <tt>r[i]</tt>. Diese Operation ist z.B. bei Börsenkursen wichtig: Neben dem aktuellen Kurs für jeden Tag wird dort meist auch der gleitende Mittelwert der letzten 30 Tage sowie der letzten 200 Tage angegeben. In diesen Mittelwerten erkennt man besser die langfristige Tendenz, weil die täglichen Schwankungen herausgemittelt werden. Wir nehmen außerdem an, dass
* Array-Zugriff hat eine Komplexität von O(1)
* <math>k \ll N</math>, d.h. <math>N-k\approx N</math>.

Die beiden folgenden Algorithmen berechnen die Mittelwerte auf unterschiedliche Art. Der linke folgt der obigen Definition durch eine Summe, während der rechte inkrementell arbeitet: Man kann den Bereich der <tt>k</tt> letzten Werte als Fenster betrachten, das über das Array <tt>a</tt> geschoben wird. Schiebt man das Fenster ein Element weiter, fällt links ein Element heraus, und rechts kommt eins hinzu. Man muss also nicht jedes Mal die Summe neu berechnen, sondern kann den vorigen Wert aktualisieren. Wir werden sehen, dass dies Folgen für die Komplexität des Algorithmus hat.

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1: O(N * k)
! Komplexität
! Version 2: O(N)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|
<tt>for i in range(k):</tt>
|
'''<center>O(k)</center>'''
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|
:: <tt>r[k-1] += a[i]</tt>
|
'''<center>O(1)</center>'''
|-
|
6.
|
:::: <tt>r[j] += a[i]</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(k, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|
:: <tt>r[j] = (a[j] - a[j-k] + r[j-1])</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(len(a)):</tt>
|
'''<center>O(N)</center>'''
|-
|
9.
|

|

|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
10.
|

|

|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Wir zeigen unten dass Version 2 eine geringere Komplexität besitzt, obwohl sie mehr Zeilen benötigt.

Wir haben in der Tabelle die Komplexität jeder Zeile für sich angegeben. Einfache Anweisungen (Berechnungen, Lese- und Schreibzugriffe auf das Array, Zuweiseungen) haben konstante Komplexität, die Komplexität des Schleifenkopfes allein (also der <tt>for</tt>-Anweisung ohne den eingerückten Schleifenkörper) entspricht der Anzahl der Durchläufe. Wir müssen jetzt noch die Verschachtelung der Schleifen und die Nacheinanderausführung von Anweisungen berücksichtigen.

====Berechnung der Komplexität von Version 1====

(Wiederholung der Rechenregeln: siehe Abschnitt [[Effizienz#O-Notation|O-Notation]])

Wir betrachten zunächst die innere Schleife (Zeilen 5 und 6 von Version 1):

Der Schleifenkopf (Zeile 5) hat die Komplexität <math>\mathcal{O}(k)</math>, weil die Schleife k-mal durchlaufen wird. Der Schleifenkörper (Zeile 6) hat die Komplexität <math>\mathcal{O}(1)</math>. Nach der Verschachtelungsregel müssen wir die beiden Komplexitäten multiplizieren, und es ergibt sich:

::<math>\mathcal{O}(k)\cdot\mathcal{O}(1) = \mathcal{O}(k\cdot 1)=\mathcal{O}(k)</math>

Wir betrachten nun die äußere Schleife. Der Schleifenkopf (Zeile 4) wird (N-k)-mal durchlaufen und hat somit eine Komplexität von <math>\mathcal{O}(N)</math>. Der Schleifenkörper (Zeilen 5 bis 7) besteht aus der inneren Schleife (Zeilen 5 und 6) mit der gerade berechneten Komplexität <math>\mathcal{O}(k)</math> sowie einer einfachen Anweisung (Zeile 7) mit Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel wird die Komplexität des Schleifenkörpers durch Addition berechnet:

::<math>\mathcal{O}(k)+\mathcal{O}(1) = \mathcal{O}(\max(k,1)) = \mathcal{O}(k)</math>

Die Komplexität der gesamten äußeren Schleife erhalten wir nach der Verschachtelungsregel wieder durch multiplizieren:

::<math>\mathcal{O}(N)\cdot\mathcal{O}(k) = \mathcal{O}(N\cdot k)</math>

Die übrigen Schritte des Algorithmus werden einfach nacheinander ausgeführt, so dass sie ebenfalls nach der Sequenzregel behandelt werden. Wir erhalten

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(N\cdot k)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,N\cdot k,1)) = \mathcal{O}(N\cdot k)</math>

Der gesamte Algorithmus hat also die Komplexität <math>\mathcal{O}(N\cdot k)</math>.

====Berechnung der Komplexität von Version 2====

Hier gibt es nur einfache Schleifen ohne Verschachtelung. Da der Schleifenkörper jeder Schleife nur einfache Anweisungen der Komplexität <math>\mathcal{O}(1)</math> enthält, ergibt sich die Komplexität der Schleifen nach der Verschachtelungsregel als

::<math>\mathcal{O}(X)\cdot\mathcal{O}(1) = \mathcal{O}(X\cdot 1)=\mathcal{O}(X)</math>

wobei <math>\mathcal{O}(X)</math> die Komplexität des jeweiligen Schleifenkopfes ist. Wir erhalten also für Zeilen 4 und 5: <math>\mathcal{O}(k)</math>, Zeilen 6 und 7: <math>\mathcal{O}(N)</math>, Zeilen 8 und 9: <math>\mathcal{O}(N)</math>. Die Hintereinanderausführung wird nach der Sequenzregel behandelt:

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(k)+\mathcal{O}(N)+\mathcal{O}(N)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,k,N,N,1)) = \mathcal{O}(N)</math>

Dieser Algorithmus hat also nur die Komplexität <math>\mathcal{O}(N)</math>.

====Fazit====

Obwohl Version 2 mehr Schritte benötigt hat sie eine geringere Komplexität, da die for-Schleifen nicht wie bei Version 1 verschachtelt/untergeordnet sind. Bei verschachtelten for-Schleifen muss die Multiplikationsregel angewendet werden → höhere Komplexität.

Die gerade berechnete Komplexität gilt aber nur unter der Annahme, dass Array-Zugriffe konstante Komplexität <math>\mathcal{O}(1)</math> besitzen. Wenn dies nicht der Fall ist, kann sich die Komplexität des Algorithmus drastisch verschlechtern.

{| border="1" cellspacing="0" cellpadding="5"
|Allgemein gilt: 
Algorithmen-Analysen beruhen auf der Annahme, dass Zugriffe auf die Daten optimal schnell sind, dass heißt, dass die für den jeweiligen Algorithmus am besten geeignete Datenstruktur verwendetet wird. → Ansonsten: Komplexitätsverschlechterung!
|}
 

====Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur====

Wir verwende im Mittelwert-Algorithmus eine verkettete Liste anstelle des Eingabe-Arrays a. Wir benötigen dazu eine Funktion, die das j-te Element der Liste zurückgibt. Wie üblich ist die Liste mit Hilfe einer Knotenklasse implementiert:
class Node:
def __init__(self, data):
self.data = data
self.next = None

Die Listenklasse selbst hat ein Feld <tt>head</tt>, das eine Referenz auf den ersten Knoten speichert, und jeder Knoten speichert im Feld <tt>next</tt> eine Referenz auf seinen Nachfolger. Um zum j-ten Element zu gelangen, muss man die Liste sequenziell durchlaufen
def get_jth(list, j):
r = list.head
while j > 0:
r = r.head
j -= 1
return r.data
Die Komplexität dieser Funktion ist offensichtlich <math>\mathcal{O}(j)</math> (Komplexitätsberechnung wie oben). Wir setzen jetzt bei Version 1 des Mittelwert-Algorithmus diese Funktion in Zeile 6 anstelle des Indexzugriffs <tt>a[i]</tt> ein (nur in dieser Zeile wird auf die Elemente des Arrays zugegriffen). Wir erhalten folgende Implementation (die Änderungen sind rot markiert):

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1 mit Liste: O(N * k)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|-
|
6.
|
:::: <tt>r[j] += get_jth(a, i)</tt>
|
'''<center>O(i)</center>'''
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Der Aufruf der Funktion <tt>get_jth</tt> ist jetzt gleichbedeutend mit einer dreifach verschachtelten Schleife (weil <tt>get_jth</tt> ja eine zusatzliche Schleife enthält). Die Anzahl der Operationen in Zeile 4 bis 6 ist jetzt

::<math>f(N,k)=\sum_{j=k-1}^{N-1}\,\sum_{i=j-k+1}^j\,\mathcal{O}(i)</math>

wobei das <math>\mathcal{O}(i)</math> die neue Schleife durch Verwendung der Liste repräsentiert. Mit Mathematica-Hilfe [http://www.wolfram.com/] lässt sich diese Summe exakt ausrechnen

::<math>f(N,k)=\frac{1}{2}(k N^2-k^2 N+k^2-k)\in \mathcal{O}(k N^2)</math>

Die Komplexitätsberechnung erfolgte dabei nach der Regel für Polynome unter Beachtung von <math>k \ll N</math>.

====Fazit:====

Die Komplexität von Version 1 mit einer verketteten Liste wäre O(N2 * k)
'''→ Die richtige Datenstruktur ist wichtig, da es sonst zu einer Komplexitätsverschlechterung kommen kann!'''

Auf Version 2 unseres Running Average-Beispiels hätte eine verkettete Liste allerdings keine Auswirkungen, da die inkrementelle Berechnung der Summen in Zeile 7 weiterhin möglich ist (bei geschickter Implementation!) und somit Version 2 immer noch eine Komplexität von O(N) hätte.

==Amortisierte Komplexität==

Bis jetzt wurde die Komplexität nur im schlechtesten Fall (Worst Case) betrachtet. Bei einigen Operationen schwankt die Komplexität jedoch sehr stark, wenn man sie mehrmals hintereinander ausführt, und der schlechteste Fall kommt nur selten vor. Dann ist es sinnvoll, die amortisierte Komplexität zu betrachten, die sich mit der durchschnittlichen Komplexität über viele Aufrufe der selben Operation beschäftigt.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse Wikipedia: Amortisierte Laufzeitanalyse]]

===Beispiel: Inkrementieren von Binärzahlen===

Frage: Angenommen, das Umdrehen eines Bits einer Binärzahl verursacht Kosten von 1 Einheit. Wir erzeugen die Folge der natürlichen Zahlen in Binärdarstellung durch sukzessives Inkrementieren, von Null beginnend. Bei jeder Inkrementierung werden einige Bits verändert, aber diese Zahl (und damit die Kosten der Inkrementierungen) ''schwanken'' sehr stark. Wir fragen jetzt, was eine Inkrementierung im Durchschnitt kostet?

Um diese Durchschnittskosten zu berechnen, bezahlen wir bei jeder Inkrementierung 2 Einheiten. Wenn davon nach Abzug der Kosten der jeweiligen Operation noch etwas übrig bleibt, wird der Rest dem Guthaben zugeschrieben. Umgekehrt wird ein eventueller Fehlbetrag (wenn eine Inkrementierung mehr als 2 Bits umdreht) aus dem Guthaben gedeckt. Dadurch werden die ansonsten großen Schwankungen der Kosten ausgeglichen:
:: Kosten < Einzahlung → es wird gespart
:: Kosten = Einzahlung → Guthaben bleibt unverändert
:: Kosten > Einzahlung → Guthaben wird für die Kosten verbraucht

{| border="1" cellspacing="0" cellpadding="5"
!Schritte
!Zahlen
!Kosten 
(Anzahl der geänderten Bits)
! Einzahlung
!Guthaben = 
altes Guthaben + Einzahlung - Kosten
|-
|1.
|00001
|1
|'''2'''
|'''1'''
|-
|2.
|00010
|2
|'''2'''
|'''1'''
|-
|3.
|00011
|1
|'''2'''
|'''2'''
|-
|4.
|00100
|3
|'''2'''
|'''1'''
|-
|5.
|00101
|1
|'''2'''
|'''2'''
|-
|6.
|00110
|2
|'''2'''
|'''2'''
|-
|7.
|00111
|1
|'''2'''
|'''3'''
|-
|8.
|01000
|4
|'''2'''
|'''1'''
|-
|}

Die Kosten ergeben sich aus der Anzahl der Ziffern die von 1 nach 0, bzw. von 0 nach 1 verändert werden

Rechnung:

1. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

2. Schritt: Kosten: 2 = Einzahlung: 2 
:: → es wird nicht gespart 
:: → Guthaben bleibt so wie es ist 

3. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

4. Schritt: Kosten: 3 > Einzahlung: 2 
:: → es wird eine 1 vom Guthaben genommen um die Kosten zu zahlen 

usw.

Man erkennt, dass vor teuren Operation (Wechsel von 3 auf 4 bzw. von 7 auf 8) genügend Guthaben angespart wurde, um die Kosten zu decken. Das Guthaben geht bei diesen Operationen immer wieder auf 1 zurück, aber es wird nie vollständig verbraucht (Dies kann natürlich auch mathematisch exakt bewiesen werden, wie wir es unten am Beispiel des dynamische Arrays zeigen). Wir schließen daraus, dass die durchschnittlichen oder '''amortisierten Kosten''' einer Inkrementierungsoperation gleich 2 sind.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Account-Methode Wikipedia Account-Methode]]

====Fazit====
Die amortisierte Komplexität beschäftigt sich mit dem Durchschnitt aller Operation im ungünstigsten Fall. Operationen mit hohen Kosten, die aber nur selten ausgeführt werden, fallen bei der amortisierten Komplexität nicht so ins Gewicht. Bei Algorithmen, die gelegentlich eine "teure" Operation benutzen, ansonsten jedoch "billigen" Operationen aufrufen, kann die amortisierte Komplexität niedriger sein als die Komplexität im schlechtesten (Einzel-)Fall.

In unserem Beispiel fallen die teuren Einzelschritte (z.B. 4. und 8. Schritt) bei den amortisierten Kosten nicht so ins Gewicht, da wir die Kosten aus unserem Guthaben mitbezahlen können. Das Guthaben ist immer groß genug, weil jeder zweite Aufruf eine billige Operation ist, die nur ein Bit umdreht und somit das Ansparen ermöglichen. Diese Betrachtung zeigt, dass die amortisierte (d.h. durchschnittliche) Komplexität des Algoithmus niedriger (nämlich konstant) ist als die Komplexität im schlechtesten Fall.

===Anwendung: Dynamisches Array===

Ein dynamisches Array hat die Eigenschaft, dass man effizient am Ende des Arrays neue Elemente anfügen kann, indem man die Länge des Arrays entsprechend vergrößert (siehe Übung 1). Die Analyse der amortisierten Komplexität der Anfüge-Operation zeigt uns, wie man das Vergrößern des Arrays richtig implementiert, damit die Operation wirklich effizient abläuft.

==== Ineffiziente naive Lösung ====

Wenn wir an ein Array ein Element anhängen wollen, müssen wir neuen Speicher allokieren, der die gewünschte Länge hat. Die Werte aus dem alten Array müssen dann in den neuen Speicher umkopiert werden. Danach kann das neue Element hinten angefügt werden, weil wir im neuen Array bereits Speicher für dieses Element reserviert haben. Bei der naiven Implementation des dynamischen Arrays wiederholt man dies bei jeder Anfügeoperation. Für die Analyse nehmen wir an, dass das Kopieren eines Elements konstante Zeit O(1) erfordert, ebenso das Einfügen eines neuen Elements auf in eine noch unbenutzte Speicherposition.

Naives Anhängen eines weiteren Elements an ein Array:

{| border="1" cellspacing="0" cellpadding="5" align="right"
!Schritte
|'''Array'''
(wie es nach jedem Schritt aussieht)
!Komplexität
|-
|<center>altes Array (N=4)</center>
|<center>[0,1,2,3]</center>
|<center>-</center>
|-
|1. neuer Speicher für    (N+1) Elemente
|<center>[None,None,None,None,None]</center>
|<center>O(N+1) = '''O(N)'''</center>(wenn der Speicher initialisiert wird (hier auf <tt>None</tt>), sonst O(1))
|-
|2. Kopieren
|<center>[0,1,2,3,None]</center>
|<center>'''O(N)'''</center>
|-
|3. append von "x"
|<center>[0,1,2,3,'x']</center>
|<center>'''O(1)'''</center>
|-
|}

altesArray = [0,1,2,3] 
altesArray.append('x')

1. Es wird ein neues Array der Größe N+1 erzeugt 
2. Die N Datenelemente aus dem alten Array werden in das neue Array kopiert 
Das sind N Operationen der Komplexität O(1), also ein Gesamtaufwand von O(N). 
3. 'x' wird mit Aufwand O(1) an die letzte Stelle des neuen Arrays geschrieben

Additionsregel: 
O(N) + O(1) ∈ O(N)

Folgerung:

Bei der naiven Methode erfordert jede Anfügung einen Aufwand O(N) (wobei N die derzeitige Arraygröße ist). Dies ist nicht effizient.

====Effiziente Lösung durch Verdoppeln der Kapazität====

Offensichtlich kommt man nicht darum heraum, den Inhalt des alten Arrays zu kopieren, wenn der allokierte Speicher voll ist. Der Trick für die effiziente Implementation der Anfügeoperation besteht darin, das Kopieren so selten wie möglich durchzuführen, also nicht wie in der naiven Lösung bei jeder Anfügeoperation. Hier kommt die amortisierte Komplexität ins Spiel: Ab und zu gibt es eine teure Anfügeoperation (wenn nämlich kopiert werden muss), aber wenn man den durchschnittlichen Aufwand über viele Anfügungen betrachtet, ist die Operation effizient. Der teure Fall wird sozusagen "herausgemittelt".

Um nur selten kopieren zu müssen, werden beim dynamischen Array mehr Speicherelemente reserviert als zur Zeit benötigt werden (in der naiven Lösung wurde dagegen immer nur Speicher für ein einziges neues Element reserviert). Wir unterscheiden deshalb

:<tt>capacity</tt> = Anzahl der allokierten Speicherzellen, d.h. der möglichen Elemente, die in das Array passen 
:<tt>size</tt> = Anzahl der Elemente, die im Array zur Zeit gespeichert sind 

Die Daten selbst werden in einem statischen Array gespeichert:
:<tt>data</tt> = statisches Array der Größe <tt>capacity</tt> 

Die folgende intuitive Abschätzung zeigt, dass es sinnvoll ist, die Größe des allokierten Speichers jeweils zu verdoppeln. Wir starten bei einem Array der Größe <tt>size = capacity</tt> = N. Da der verfügbare Speicher voll ist, müssen wir bei der nächsten Anfügung die N vorhandenen Elemente in ein neues Array der Länge <tt>new_capacity</tt> kopieren (Aufwand <math>N\cdot O(1)</math>). Danach können wir K Elemente billig einfügen (Aufwand <math>K\cdot O(1)</math>), wobei
:K = <tt>new_capacity - capacity</tt>
die Anzahl der nach dem Kopieren noch unbenutzen Speicherzellen ist. Der durchschnittliche Aufwand für diese K Einfügungen ist somit
:<math>\bar T = \frac{N \cdot O(1) + K \cdot O(1)}{K}=\frac{N+K}{K}\cdot O(1)</math>
Damit die mittlere Zeit in O(1) sein kann, muss der Quotient <math>(N+K)/K</math> eine Konstante sein. Wir setzen <math>K = a N</math> und erhalten:
:<math>\bar T = \frac{(a+1)N}{a N}\cdot O(1)=\frac{a+1}{a}\cdot O(1)</math>
Der amortisierte Aufwand über K Einfügungen ist also konstant, wenn <math>a</math> eine (kleine) von N unabhängige Zahl ist. Typischerweise wählt man
:<math>a = 1</math>
und mit <math>K = 1\cdot N</math> ergibt sich
:<tt>new_capacity = capacity</tt> + N = <tt>2 * capacity</tt>

Die Vorgehensweise beim Zufügen eines neuen Elements im Fall <tt>size == capacity</tt> ist also
* capacity wird verdoppelt 
: <tt>neue capacity = 2 * alte capacity</tt>
: (allgemein genügt es auch, wenn capacity um einen bestimmten Prozentsatz vergrößert wird,
:: <tt>neue capacity = alte capacity * c</tt>
: mit c > 1, z.B. c = 1.2, das entspricht oben der Wahl <math>a = 0.2</math>)
* ein neues statisches Array der Größe 'neue capacity' wird erzeugt
* das alte Array wird ins neue kopiert und danach freigegeben
* das anzufügende Element wird ins neue Array eingefügt
Umgekehrt geht man beim Entfernen des ''letzten'' Array-Elements vor. Normalerweise überschreibt man einfach das letzte Element mit <tt>None</tt> und dekrementiert <tt>size</tt>. Wird dadurch das Array zu klein (üblicherweise <tt>size < capacity / 4</tt>), wird die Kapazität halbiert, genauer:
* ein neues Array mit 
: <tt>neue capacity = alte capacity / 2 </tt>
: wird angelegt (bzw. mit
:: <tt>neue capacity = alte capacity / c </tt>
: wenn ein anderer Vergrößerungsfaktor verwendet wird)
* das alte Array wird ins neue kopiert und danach freigegeben

'''Folge:''' Die Kosten für das Vergrößern/Verkleinern der Kapazität werden amortisiert über viele Einfügungen, die kein Vergrößern erfordern. Die Operation <tt>append</tt> besitzt amortisierte Komplexität O(1). Im folgenden Abschnitt zeigen wir dies mathematisch exakt mit der Potentialmethode.

====Komplexitätsanalyse des dynamischen Arrays mit Potentialmethode====

Durchschnitt der Gesamtkosten für N-maliges append = <math>\frac{1}{N} \sum_{i = 1}^N Kosten(i)</math>. Zur Analyse der amortisierten Komplexität wird ein Potential 
::Φi = 2*sizei - capacityi 
eingeführt, wobei das Array nach dem i-ten Einfüge-Schritt die Größe sizei und die Kapizität capacityi hat. Wir nehmen vereinfachend an, dass es keine Löschoperationen gibt. Dann gilt nach dem i-ten Schritt jeweils
::Φi = 2*i - capacityi 

Fall 1: Array ist nicht voll 
Es wird kein Umkopieren benötigt, da das Array noch nicht voll ist 
→ sizei-1 < capacityi-1 
→ capacityi == capacityi-1

Kosten: 1 (für Einfügen des neuen Elements) 
Potenzial vor append: Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append: Φi = 2i - capacityi-1 

amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = 1 + (2i - capacityi-1) - [2(i - 1) - capacityi-1]
::::: = 1 + 2i - capacityi-1 - 2i + 2 + capacityi-1
::::: = 1 + <del>2i</del> - <del>capacityi-1</del> - <del>2i</del> + 2 + <del>capacityi-1</del>
::::: = 1 + 2
::::: = 3 = O(1) → konstant

Fall 2: Array ist voll 
Vor dem i-ten append muss umkopiert werden 
→ sizei-1 == capacityi-1 == i-1 
→ Allokieren eines neuen statischen Arrays mit verdoppelter Kapazität notwendig, also capacityi == 2*capacityi-1

Kosten: (i-1) + 1 (für Umkopieren und Einfügen des neuen Elements) 
Potenzial vor append = Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append = Φi = 2i - 2 capacityi-1 
amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = ((i - 1) + 1) + 2i - 2 capacityi-1 - [2(i-1) - capacityi-1]
::::: = i + <del>2i</del> - 2 capacityi-1 - <del>2i</del> + 2 - capacityi-1
::::: = i + 2 - capacityi-1
::::: = i + 2 - (i - 1) (da capacityi-1 = i-1)
::::: = 3 = O(1) → konstant

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine amortisierte Komplexität von 3 Einheiten hat, also <tt>append</tt> ∈ O(1)'''. Diese Operation kann deshalb gefahrlos in der inneren Schleife eines Algorithmus benutzt werden.

==== Beispiel für 9 Einfügeoperationen ====

{| border="1" cellspacing="0" cellpadding="5"
!Array 
(wie es aussehen könnte)
!size
!capacity
!Kosten für append (einschließlich Umkopieren)
!Summe Kosten
!Durchschnittskosten
!Φi = 2 * size - capacity 
(i = size)
!Potenzialdifferenz 
Δ Φi = Φi - Φi-1
!amortisierte Kosteni 
= Kosteni + Δ Φi
|-
| <center>[None]</center>
| <center>0</center>
| <center>1</center>
| <center>-</center>
| <center>-</center>
| <center>-</center>
| <center>-1</center>
| <center>-</center>
| <center>-</center>
|-
| <center>[a]</center><center>Array ist voll!</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b]</center><center>Array ist voll!</center>
| <center>2</center>
| <center>2</center>
| <center>1 + 1</center>
| <center>3</center>
| <center>3/2</center>
| <center>2</center>
| <center>1</center>
| <center>3</center>
|-
| <center>[a,b,c,None]</center>
| <center>3</center>
| <center>4</center>
| <center>2 + 1</center>
| <center>6</center>
| <center>6/3</center>
| <center>2</center>
| <center>0</center>
| <center>3</center>
|-
| <center>[a,b,c,d]</center><center>Array ist voll!</center>
| <center>4</center>
| <center>4</center>
| <center>1</center>
| <center>7</center>
| <center>7/4</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,None,None,None]</center>
| <center>5</center>
| <center>8</center>
| <center>4 + 1</center>
| <center>12</center>
| <center>12/5</center>
| <center>2</center>
| <center>-2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,None,None]</center>
| <center>6</center>
| <center>8</center>
| <center>1</center>
| <center>13</center>
| <center>13/6</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,None]</center>
| <center>7</center>
| <center>8</center>
| <center>1</center>
| <center>14</center>
| <center>14/7</center>
| <center>6</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h]</center><center>Array ist voll!</center>
| <center>8</center>
| <center>8</center>
| <center>1</center>
| <center>15</center>
| <center>15/8</center>
| <center>8</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h,j,None,None,None, 
None,None,None,None]</center>
| <center>9</center>
| <center>16</center>
| <center>8 + 1</center>
| <center>24</center>
| <center>24/9</center>
| <center>2</center>
| <center>-6</center>
| <center>3</center>
|-
|}

Die durchschnittlichen Kosten betragen stets etwa 2 Einheiten, schwanken allerdings so, dass nicht unmittelbar ersichtlich ist, ob dies für sämtliche Einfügeoperationen gilt. Die amortisierte Komplexität, die mit Hilfe des Potentials berechnet wird, ist hingegen konstant 3, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

[[Suchen|Nächstes Thema]]

Effizienz

2012-07-27T15:37:50Z

Ukoethe: /* Amortisierte Komplexität */

Bei der Diskussion von Effizienz müssen wir zwischen der Laufzeit eines Algorithmus auf einem bestimmten System und seiner prinzipiellen Leistungsfähigkeit (Algorithmenkomplexität) unterscheiden. Der Benutzer ist natürlich vor allem an der Laufzeit interessiert, denn diese bestimmt letztendlich seine Arbeitsproduktivität. Ein Softwaredesigner hingegen muss eine Implementation wählen, die auf verschiedenen Systemen und in verschiedenen Anwendungen schnell ist. Für ihn sind daher auch Aussagen zur Algorithmenkomplexität sehr wichtig, um den am besten geeigneten Algorithmus auszuwählen.

== Laufzeit ==

Aus Anwendersicht ist ein Algorithmus effizient, wenn er die in der Spezifikation verlangten Laufzeitgrenzen einhält. Ein Algorithmus muss also nicht immer so schnell wie möglich sein, sondern so schnell wie nötig. Dies führt in verschiedenen Anwendungen zu ganz unterschiedliche Laufzeitanforderungen:

* Berechnen des nächsten Steuerkommandos für eine Maschine: ca. 1/1000s
* Berechnen des nächsten Bildes für eine Videopräsentation (z.B. Dekompression von MPEG-kodierten Bildern): ca. 1/25s
: Geringere Bildraten führen zu ruckeligen Filmen.
* Sichtbare Antwort auf ein interaktives Kommando (z.B. Mausklick): ca. 1/2s
: Wird diese Antwortzeit überschritten, vermuten viele Benutzer, dass der Mausklick nicht funktioniert hat, und klicken nochmals, mit eventuell fatalen Folgen. Wenn ein Algorithmus notwendigerweise länger dauert als 1/2s, sollte ein Fortschrittsbalken angezeigt werden.
* Wettervorhersage: muss spätestens am Vorabend des vorhergesagten Tages beendet sein

===Laufzeitvergleich===

Da die Laufzeit für den Benutzer ein so wichtiges Kriterium ist, werden häufig Laufzeitvergleiche durchgeführt. Deren Ergebnisse hängen allerdings von vielen Faktoren ab, die möglicherweise nicht kontrollierbar sind:
* Geschwindigkeit und Anzahl der Prozessoren
* Auslastung des Systems
* Größe des Hauptspeichers und Cache, Geschwindigkeit des Datenbus
* Qualität des Compilers/Optimierers (ist der Compiler für die spezielle Prozessor-Architektur optimiert?)
* Geschick des Programmierers
* Daten (Beispiel Quicksort: Best case und worst case [vorsortierter Input] stark unterschiedlich)
All diese Faktoren sind untereinander abhängig. Laufzeitvergleiche sind daher mit Vorsicht zu interpretieren.
Generell sollten bei Vergleichen möglichst wenige Parameter verändert werden, z.B.
* gleiches Programm (gleiche Kompilierung), gleiche Daten, andere Prozessoren
oder
* gleiche CPU, Daten, andere Programme (Vergleich von Algorithmen)
Zur Verbesserung der Vergleichbarkeit gibt es standardisierte [http://en.wikipedia.org/wiki/Benchmark_(computing) Benchmarks], die bestimmte Aspekte eines Systems unter möglichst realitätsnahen Bedingungen testen. Generell gilt aber: Durch Laufzeitmessung ist schwer festzustellen, ob ein Algorithmus ''prinzipiell'' besser ist als ein anderer. Dafür ist die Analyse der [[Effizienz#Algorithmen-Komplexität|Algorithmenkomplexität]] notwendig.

===Optimierung der Laufzeit===

Wenn sich herausstellt, dass ein bereits implementierter Algorithmus zu langsam läuft, geht man wie folgt vor:

# Man verwendet einen [http://en.wikipedia.org/wiki/Performance_analysis Profiler], um zunächst den Flaschenhals zu bestimmen. Ein Profiler ist ein Hilfsprogramm, das während der Ausführung eines Programms misst, wieviel Zeit in jeder Funktion und Unterfunktion verbraucht wird. Dadurch kann man herausfinden, welcher Teil des Algorithmus überhaupt Probleme bereitet. Donald Knuth gibt z.B. als Erfahrungswert an, dass Programme während des größten Teils ihrer Laufzeit nur 3% des Quellcodes (natürlich mehrmals wiederholt) ausführen [http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf]. Es ist sehr wichtig, diese 3% experimentell zu bestimmen, weil die Erfahrung zeigt, dass man beim Erraten der kritischen Programmteile oft falsch liegt. Man spricht dann von "[http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize premature optimization]", also von voreiliger Optimierung ohne experimentelle Untersuchung der wirklichen Laufzeiten, was laut Knuth "the root of all evil" ist. Der Python-Profiler wird in [http://docs.python.org/lib/profile.html Kapitel 25] der Python-Dokumentation beschrieben.
# Man kann dann versuchen, die kritischen Programmteile zu optimieren.
# Falls der Laufzeitgewinn durch Optimierung zu gering ist, muss man einen prinzipiell schnelleren Algorithmus verwenden, falls es einen gibt.

Einige wichtige Techniken der Programmoptimierung sollen hier erwähnt werden. Wenn man einen optimierenden Compiler verwendet, werden einige Optimierungen automatisch ausgeführt [http://en.wikipedia.org/wiki/Compiler_optimization]. In Python trifft dies jedoch nicht zu. Um den Sinn einiger Optimierungen zu verstehen, benötigt man Grundkenntnisse der Computerarchitektur.

;Elimination von redundantem Code: Es ist offensichtlich überflüssig, dasselbe Ergebnis mehrmals zu berechnen, wenn es auch zwischengespeichert werden könnte. Diese Optimierung wird von vielen automatischen Optimierern unterstützt und kommt im wesentlichen in zwei Ausprägungen vor:
:; common subexpression elimination: In mathematischen Ausdrücken wird ein Teilergebnis häufig mehrmals benötigt. Man betrachte z.B. die Lösung der quadratischen Gleichung <math>x^2+p\,x+q = 0</math>:
x1 = - p / 2.0 + sqrt(p*p/4.0 - q)
x2 = - p / 2.0 - sqrt(p*p/4.0 - q)
::Die mehrmalige Berechnung von Teilausdrücken wird vermieden, wenn man stattdessen schreibt:
p2 = - p / 2.0
r = sqrt(p2*p2 - q)
x1 = p2 + r
x2 = p2 - r
:; loop invariant elimination: Wenn ein Teilausdruck sich in einer Schleife nicht ändert, muss man ihn nicht bei jedem Schleifendurchlauf neu berechnen, sondern kann dies einmal vor Beginn der Schleife tun. Ein typisches Beispiel hierfür ist die Adressierung von Matrizen, die als 1-dimensionales Array gespeichert sind. Angenommen, wir speichern eine NxN Matrix <tt>m</tt> in einem Array <tt>a</tt> der Größe N2, so dass das Matrixelement <tt>mij</tt> durch <tt>a[i + j*N]</tt> indexiert wird. Wir betrachten die Aufgabe, eine Einheitsmatrix zu initialisieren. Ein nicht optimierter Algorithmus dafür lautet:
for j in range(N):
for i in range(N):
if i == j:
a[i + j*N] = 1.0
else:
a[i + j*N] = 0.0
::Der Ausdruck <tt>j*N</tt> wird hier in jedem Schleifendurchlauf erneut berechnet, obwohl sich <tt>j</tt> in der inneren Schleife gar nicht verändert. Man kann deshalb optimieren zu:
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
;Vereinfachung der inneren Schleife: Generell sollte man sich bei der Optimierung auf die innere Schleife eines Algorithmus konzentrieren, weil dieser Code am häufigsten ausgeführt wird. Insbesondere sollte man die Anzahl der Befehle in der inneren Schleife so gering wie möglich halten und teure Befehle vermeiden. Früher waren vor allem Floating-Point Befehle teuer, die man oft durch die schnellere Integer-Arithmetik ersetzt hat, falls dies algorithmisch möglich war (diesen Rat findet man noch oft in der Literatur). Heute hat sich die Hardware so verbessert, dass im Allgemeinen nur noch die Floating-Point Division deutlich langsamer ist als die anderen Operatoren. Im obigen Beispiel der quadratischen Gleichung ist es daher sinnvoll, den Ausdruck
p2 = -p / 2.0
:durch
p2 = -0.5 * p
:zu ersetzen. Dadurch ersetzt man eine Division durch eine Multiplikation und spart außerdem das Negieren von <tt>p</tt>, da der Compiler direkt mit <tt>-0.5</tt> multipliziert.
;Ausnutzung der Prozessor-Pipeline: Moderne Prozessoren führen mehrere Befehle parallel aus. Dies ist möglich, weil jeder Befehl in mehrere Teilschritte zerlegt werden kann. Eine generische Unterteilung in vier Teilschritte ist z.B.:
:# Dekodieren des nächsten Befehls
:# Beschaffen der Daten, die der Befehl verwendet (aus Prozessorregistern, dem Cache, oder dem Hauptspeicher)
:# Ausführen des Befehls
:# Schreiben der Ergebnisse
:Man bezeichnet dies als die "[http://en.wikipedia.org/wiki/Instruction_pipeline instruction pipeline]" des Prozessors (heutige Prozessoren verwenden wesentlich feinere Unterteilungen). Prozessoren werden nun so gebaut, dass mehrere Befehle parallel, auf verschiedenen Ausführungsstufen ausgeführt werden. Wenn Befehl 1 also beim Schreiben der Ergebnisse angelangt ist, kann Befehl 2 die Hardware zum Ausführen des Befehls benutzen, während Befehl 3 seine Daten holt, und Befehl 4 soeben dekodiert wird. Unter bestimmten Bedingungen funktioniert diese Parallelverarbeitung jedoch nicht. Dies gibt Anlass zu Optimierungen:
:;Vermeiden unnötiger Typkonvertierungen: Der Prozessor verarbeitet Interger- und Floating-Point-Befehle in verschiedenen Pipelines, weil die Hardwareanforderungen sehr verschieden sind. Wird jetzt ein Ergebnis von Integer nach Floating-Point umgewandelt oder umgekehrt, muss die jeweils andere Pipeline warten, bis die erste Pipeline ihre Berechnung beendet. Es kann dann besser sein, Berechnungen in Floating-Point zu Ende zu führen, auch wenn sie semantisch eigentlich Integer-Berechnungen sind.
:;Reduzierung der Anzahl von Verzweigungen: Wenn der Code verzweigt (z.B. durch eine <tt>if</tt>- oder <tt>while</tt>-Anweisung), ist nicht klar, welcher Befehl nach der Verzweigung ausgeführt werden soll, bevor Stufe 3 der Pipeline die Verzweigungsbedingung ausgewertet hat. Bis dahin wären die ersten beiden Stufen der Pipeline unbenutzt. Moderne Prozessoren benutzen zwar ausgefeilte Heuristiken, um das Ergebnis der Bedingung vorherzusagen, und führen den hoffentlich richtigen Zweig des Codes spekulativ aus, aber dies funktioniert nicht immer. Man sollte deshalb generell die Anzahl der Verzweigungen minimieren. Als Nebeneffekt führt dies meist auch zu besser lesbarem, verständlicherem Code. Im Matrixbeispiel kann man
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
::durch
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
ersetzen. Die Diagonalelemente <tt>a[j + jN]</tt> werden jetzt zwar zweimal initialisiert (in der Schleife auf Null, dann auf Eins), aber durch Elimination der <tt>if</tt>-Abfrage wird dies wahrscheinlich mehr als ausgeglichen, zumal dadurch die innere Schleife wesentlich vereinfacht wurde.
;Ausnutzen des Prozessor-Cache: Zugriffe auf den Hauptspeicher sind sehr langsam. Deshalb werden stets ganze Speicherseiten auf einmal in den [http://en.wikipedia.org/wiki/Cache Cache] des Prozessors geladen. Wenn unmittelbar nacheinander benutzte Daten auch im Speicher nahe beieinander liegen (sogenannte "[http://en.wikipedia.org/wiki/Locality_of_reference locality of reference]"), ist die Wahrscheinlichkeit groß, dass die als nächstes benötigten Daten bereits im Cache sind und damit schnell gelesen werden können. Bei vielen Algorithmen kann man die Implementation so umordnen, dass die locality of reference verbessert wird, was zu einer drastischen Beschleunigung führt. Im Matrix-Beispiel ist z.B. die Reihenfolge der Schleifen wichtig. Für konstanten Index <tt>j</tt> liegen die Indizes <tt>i</tt> im Speicher hintereinander. Deshalb ist es günstig, in der inneren Schleife über <tt>i</tt> zu iterieren:
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
:Die umgekehrte Reihenfolge der Schleifen ist hingegen ungünstig
for i in range(N):
for j in range(N):
a[i + j*N] = 0.0
a[i + i*N] = 1.0
:Jetzt werden in der inneren Schleife stets N Datenelemente übersprungen. Besonders bei großem N muss man daher häufig den Cache neu füllen, was bei der ersten Implementation nicht notwendig war. (Außerdem verliert man hier die Optimierung <tt>jN = j*N</tt>, die jetzt nicht mehr möglich ist.)

Als Faustregel kann man durch Optimierung eine Verdoppelung der Geschwindigkeit erreichen (in Ausnahmefällen auch mehr). Benötigt man stärkere Verbesserungen, muss man wohl oder übel einen besseren Algorithmus oder einen schnelleren Computer verwenden.

== Algorithmen-Komplexität ==

Komplexitätsbetrachtungen ermöglichen den Vergleich der prinzipiellen Eigenschaften von Algorithmen unabhängig von einer Implementation, Umgebung etc.

Eine einfache Möglichkeit ist das Zählen der Aufrufe einer Schlüsseloperation. Beispiel Sortieren:
* Anzahl der Vergleiche
* Anzahl der Vertauschungen

=== Beispiel: Selection Sort ===

for i in range(len(a)-1):
max = i
for j in range(i+1, len(a)):
if a[j] < a[max]:
max = j
a[max], a[i] = a[i], a[max] # swap

*Anzahl der Vergleiche: Ein Vergleich in jedem Durchlauf der inneren Schleife. Es ergibt sich folgende Komplexität:
*:Ingesamt <math>\sum_{i=0}^{N-2} \sum_{j=i+1}^{N-1}1 = \frac{N}{2} (N-1) \!</math> Vergleiche.

*Anzahl der Vertauschungen (swaps): Eine Vertauschung pro Durchlauf der äußeren Schleife:
*:Insgesamt <math>N-1 \!</math> Vertauschungen

Die Komplexität wird durch die Operationen bestimmt, die am häufigsten ausgeführt werden, hier also die Anzahl der Vergleiche. Die Anzahl der Vertauschungen ist hingegen kein geeignetes Kriterium für die Komplexität von selection sort, weil der Aufwand in der inneren Schleife ignoriert würde.

=== Fallunterscheidung: Worst und Average Case ===

Die Komplexität ist in der Regel eine Funktion der Eingabegröße (Anzahl der Eingabebits, Anzahl der Eingabeelemente). Sie kann aber auch von der Art der Daten abhängen, nicht nur von der Menge, z.B. vorsortierte Daten bei Quicksort. Um von der Art der Daten unabhängig zu werden, kann man zwei Fälle der Komplexität unterscheiden:

* Komplexität im ungünstigsten Fall
*: Der ungünstigste Fall ist die Eingabe gegebener Länge, für die der Algorithmus am langsamsten ist. Der Nachteil dieser Methode besteht darin, dass dieser ungünstige Fall in der Praxis vielleicht gar nicht oder nur selten vorkommt, so dass sich der Algorithmus in Wirklichkeit besser verhält als man nach dieser Analyse erwarten würde. Beim Quicksort-Algorithmus mit zufälliger Wahl des Pivot-Elements müsste z.B. stets das kleinste oder größte Element des aktuellen Intervalls als Pivot-Element gewählt werden, was äußerst unwahrscheinlich ist.
* Komplexität im durchschnittlichen/typischen Fall
*: Der typische Fall ist die mittlere Komplexität des Algorithmus über alle möglichen Eingaben. Dazu muss man die Wahrscheinlichkeit jeder möglichen Eingabe kennen, und berechnet dann die mittlere Laufzeit über dieser Wahrscheinlichkeitsverteilung. Leider ist die Wahrscheinlichkeit der Eingaben oft nicht bekannt, so dass man geeignete Annahmen treffen muss. Bei Sortieralgorithmen können z.B. alle möglichen Permutationen des Eingabearrays als gleich wahrscheinlich angenommen werden, und der typische Fall ist dann die mittlere Komplexität über alle diese Eingaben. Oft hat man jedoch in der Praxis andere Wahrscheinlichkeitsverteilungen, z.B. sind die Daten oft "fast sortiert" (nur wenige Elemente sind an der falschen Stelle). Dann verhält sich der Algorithmus ebenfalls anders als vorhergesagt.

Wir beschränken uns in dieser Vorlesung auf die Komplexität im ungünstigseten Fall. '''Exakte''' Formeln für Komplexität sind aber auch dann schwer zu gewinnen, wie das folgende Beispiel zeigt:

=== Beispiele aus den Übungen (Gemessene Laufzeiten für Mergesort/Selectionsort) ===

* Mergesort: <math>\frac{0,977N\log N}{\log 2} + 0,267N-4.39 \!</math>
*: andere Lösung: <math>1140 N\log(N) - 1819N + 6413 \!</math>
* Selectionsort: <math>\frac{1}{2}N^2 - \frac{1}{2N} - 10^{-12} \!</math>
*: andere Lösung: <math>1275N^2 - 116003^N + 11111144 \!</math>

Aus diesen Formeln wird nicht offensichtlich, welcher Algorithmus besser ist.
Näherung: Betrachte nur '''sehr große Eingaben''' (meist sind alle Algorithmen schnell genug für kleine Eingaben). Dieses Vorgehen wird als '''Asymptotische Komplexität''' bezeichnet (N gegen unendlich).

=== Asymptotische Komplexität am Beispiel Polynom ===

Polynom: <math>a\,x^2+b\,x+c=p\!</math>

<math>x \!</math> sei die Eingabegröße, und wir betrachten die Entwicklung von <math>p \!</math> in Abhängigkeit von <math>x \!</math>.

* <math>x=0 \!</math>
*: <math>p=c \!</math>
* <math>x=1 \!</math>
*: <math>p=a+b+c \!</math>
* <math>x=1000 \!</math>
*: <math>p=1000000a+1000b+c \approx 1000000a\!</math>
* <math>x \to \infty \!</math>
*: <math>p \approx x^2a\!</math>

Für sehr große Eingaben verlieren also ''b'' und ''c'' immer mehr an Bedeutung, so dass am Ende nur noch ''a'' für die Komplexitätsbetrachtung wichtig ist.

== Landau-Symbole ==

Um die asymptotische Komplexität verschiedener Algorithmen miteinander vergleichen zu können, verwendet man die sogenannten [http://de.wikipedia.org/wiki/Landau-Symbole Landau-Symbole]. Das wichtigste Landau-Symbol ist <math>\mathcal{O}</math>, mit dem man eine ''obere Schranke'' <math>f \in \mathcal{O}(g)</math> für die Komplexität angeben kann.

Schreibt man <math>f \in \Omega(g)</math>, so stellt dies eine asymptotische ''untere Schranke'' für die Funktion f dar.

Schließlich bedeutet <math>f \in \Theta(g)</math>, dass die Funktion f genauso schnell wie die Funktion g wächst, das heißt man hat eine asymptotisch ''scharfe Schranke'' für f. Hierzu muss sowohl <math>f\in\mathcal{O}(g)</math> als auch <math>f \in \Omega(g)</math> erfüllt sein.

Im nun folgenden soll auf die verschiedenen Landau-Symbole noch näher eingegeangen werden.

===O-Notation===

Intuitiv gilt: Für große N dominieren die am schnellsten wachsenden Terme einer Funktion. Die Notation <math>f \in \mathcal{O}(g)</math> (sprich "f ist in O von g" oder "f ist von derselben Größenordnung wie g") formalisiert eine solche Abschätzung der asymptotischen Komplexität der Funktion f von oben.
; Asymptotische Komplexität: Für zwei Funktionen f(x) und g(x) gilt
::<math>f(x) \in \mathcal{O}(g(x))</math>
: genau dann wenn es eine Konstante <math>c>0</math> und ein Argument <math>x_0</math> gibt, so dass
::<math>\forall x \ge x_0:\quad f(x) \le c\,g(x)</math>.
:Die Menge <math>\mathcal{O}(g(x))</math> aller durch g(x) abschätzbaren Funktionen ist also formal definiert durch
::<math>\mathcal{O}(g(x)) = \{ f(x)\ |\ \exists c>0: \forall x \ge x_0: 0 \le f(x) \le c\,g(x)\}</math>

Die Idee hinter dieser Definition ist, dass g(x) eine wesentlich einfachere Funktion ist als f(x), die sich aber nach geeigneter Skalierung (Multiplikation mit c) und für große Argumente x im wesentlichen genauso wie f(x) verhält. Man kann deshalb in der Algorithmenanalyse f(x) durch g(x) ersetzen. <math>f(x) \in \mathcal{O}(g(x))</math> spielt für Funktionen eine ähnliche Rolle wie der Operator ≤ für Zahlen: Falls a ≤ b gilt, kann bei einer Abschätzung von oben ebenfalls a durch b ersetzt werden.

==== Ein einfaches Beispiel ====

[[Image:Sqsqrt.png]]

Rot = <math>x^2 \!</math>
Blau = <math>\sqrt{x} \!</math>

<math>\sqrt{x} \in \mathcal{O}(x^2)\!</math> weil <math>\sqrt{x} \le c\,x^2\!</math> für alle <math>x \ge x_0 = 1 \!</math> und <math>c = 1\!</math>, oder auch für <math>x \ge x_0 = 4 \!</math> und <math>c = 1/16</math> (die Wahl von c und x0 in der Definition von O(.) ist beliebig, solange die Bedingungen erfüllt sind).

==== Komplexität bei kleinen Eingaben ====

Algorithmus 1: <math>\mathcal{O}(N^2) \!</math> 
Algorithmus 2: <math>\mathcal{O}(N\log{N}) \!</math>

Algorithmus 2 ist schneller (von geringerer Komplexität) für große Eingaben, aber bei kleinen Eingaben (insbesondere, wenn der Algorithmus in einer Schleife immer wieder mit kleinen Eingaben aufgerufen wird) könnte Algorithmus 1 schneller sein, falls der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor ''c'' bei Algorithmus 2 einen wesentlich größeren Wert hat als bei Algorithmus 1.

==== Eigenschaften der O-Notation (Rechenregeln) ====

# Transitiv:
#: <math>f(x) \in \mathcal{O}(g(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) \in \mathcal{O}(h(x)) \!</math>
# Additiv:
#: <math>f(x) \in \mathcal{O}(h(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) + g(x) \in \mathcal{O}(h(x)) \!</math>
# Für Monome gilt:
#: <math>x^k \in \mathcal{O}(x^k)</math> und
#: <math>x^k \in \mathcal{O}(x^{k+j}), \forall j \ge 0 \!</math>
# Multiplikation mit einer Konstanten:
#: <math>f(x) \in \mathcal{O}(g(x)) \to c\,f(x) \in \mathcal{O}(g(x))\!</math>
#: andere Schreibweise:
#: <math>f(x) = c\,g(x) \to f(x) \in \mathcal{O}(g(x))\!</math>
# Folgerung aus 3. und 4. für Polynome:
#: <math>a_0+a_1\,x + ... + a_n\,x^n \in \mathcal{O}(x^n)\!</math>
#: Beispiel: <math>a\,x^2+b\,x+c \in \mathcal{O}(x^2)\!</math>
# Logarithmus:
#: <math>a, b > 1\!</math>
#: <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>
#: Die Basis des Logarithmus spielt also keine Rolle.
#: Beweis hierfür:
#:: <math>\log_{a}{x} = \frac{\log_{b}{x}}{\log_{b}{a}}\!</math>
#:: Mit <math>c = 1 / \log_{b}{a}\,</math> gilt: <math>\log_{a}{x} = c\,\log_{b}{x}\!</math>.
#:: Wird hier die (zweite) Regel für Multiplikation mit einer Konstanten angewendet, fällt der konstante Faktor weg, also <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>.
#: Insbesondere gilt auch <math>\log_{a}{x} \in \mathcal{O}(\log_{2}{x})\!</math>, es kann also immer der 2er Logarithmus verwendet werden.

==== O-Kalkül ====

Das O-Kalkül definiert wichtige Vereinfachungsregeln for Ausdrücke in O-Notation (Beweise: siehe Übungsaufgabe):

# <math>f(x) \in \mathcal{O}(f(x))\!</math>
# <math>\mathcal{O}(\mathcal{O}(f(x))) \in \mathcal{O}(f(x))\!</math>
# <math>c\,\mathcal{O}(f(x)) \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# <math>\mathcal{O}(f(x))+c \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# Sequenzregel:
#: Wenn zwei nacheinander ausgeführte Programmteile die Komplexität <math>\mathcal{O}(f(x))</math> bzw. <math>\mathcal{O}(g(x))</math> haben, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(f(x))</math> falls <math>g(x) < \mathcal{O}(f(x))</math> bzw.
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(g(x))\!</math> falls <math>f(x) < \mathcal{O}(g(x))</math>.
#: Informell schreibt man auch: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(max(f(x), g(x)))\!</math>.
# Schachtelungsregel bzw. Aufrufregel:
#: Wenn in einer geschachtelten Schleife die äußere Schleife die Komplexität <math>\mathcal{O}(f(x))</math> hat, und die innere <math>\mathcal{O}(g(x))</math>, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) * \mathcal{O}(g(x)) \in \mathcal{O}(f(x) * g(x))\!</math>.
#: Gleiches gilt wenn eine Funktion <math>\mathcal{O}(f(x))</math>-mal aufgerufen wird, und die Komplexität der Funktion selbst <math>\mathcal{O}(g(x))</math> ist.

;Beispiel für 5.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Dies gilt auch für ihre Hintereinanderausführung:
for i in range(N):
a[i] = i
for i in range(N):
print a[i]
;Beispiele für 6.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Ihre Verschachtelung hat daher die Komplexität <math>\mathcal{O}(N^2)</math>.
for i in range(N):
for j in range(N):
a[i*N + j] = i+j
: Dies gilt ebenso, wenn statt der inneren Schleife eine Funktion mit Komplexität <math>\mathcal{O}(N)</math> ausgeführt wird:
for i in range(N):
a[i] = foo(i, N) # <math>\mathrm{foo}(i, N) \in \mathcal{O}(N)</math>

==== O-Kalkül auf das Beispiel des Selectionsort angewandt ====

Selectionsort: Wir hatten gezeigt dass <math>f(N) = \frac{N^2}{2} - \frac{N}{2}</math>. Nach der Regel für Polynome vereinfacht sich dies zu <math>f(N) \in \mathcal{O}\left(\frac{N^2}{2}\right) = \mathcal{O}(N^2)\!</math>.

Alternativ via Schachtelungsregel:
: Die äußere Schleife wird (''N''-1)-mal durchlaufen: <math>N-1 \in \mathcal{O}(N)</math>
: Die innere Schleife wird (''N-i''-1)-mal durchlaufen. Das sind im Mittel ''N''/2 Durchläufe: <math>N/2 \in \mathcal{O}(N)</math>
: Zusammen: <math>\mathcal{O}(N)*\mathcal{O}(N) \in \mathcal{O}(N^2)</math>

Nach beiden Vorgehensweisen kommen wir zur Schlussfolgerung, dass der Selectionsort die asymptotische Komplexität <math>\mathcal{O}(N^2)\!</math> besitzt.

==== Zusammenhang zwischen Komplexität und Laufzeit ====

Wenn eine Operation 1ms dauert, erreichen Algorithmen verschiedener Komplexität folgende Leistungen (wobei angenommen wird, dass der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor immer etwa gleich 1 ist):

{| class="wikitable" style="text-align:left" cellpadding="7"
|+
|-
! Komplexität !! Operationen in 1s !! Operationen in 1min !! Operationen in 1h
|-
! <math>\mathcal{O}(N)</math>
| 1000 || 60.000 || 3.600.000
|-
! <math>\mathcal{O}(N\log_2{N})</math>
| 140 || 4895 || 204094
|-
! <math>\mathcal{O}(N^2)</math>
| 32 || 245 || 1898
|-
! <math>\mathcal{O}(N^3)</math>
| 10 || 39 || 153
|-
! <math>\mathcal{O}(2^N)</math>
| 10 || 16 || 21
|}

==== Exponentielle Komplexität ====
Der letzte Fall <math>\mathcal{O}(2^N)</math> ist von exponentieller Komplexität. Das bedeutet, dass eine Verdopplung des Aufwands nur bewirkt, dass die maximale Problemgröße um eine Konstante wächst. Algorithmen mit exponentieller (oder noch höherer) Komplexität werden deshalb als '''ineffizient''' bezeichnet. Algorithmen mit höchstens polynomieller Komplexität gelten hingegen als effizient.

In der Praxis sind allerdings auch polynomielle Algorithmen mit hohem Exponenten meist zu langsam. Als Faustregel kann man eine praktische Grenze von <math>\mathcal{O}(N^3)</math> ansehen. Bei einer Komplexität von <math>\mathcal{O}(N^3)</math> bewirkt ein verdoppelter Aufwand immer noch eine Steigerung der maximalen Problemgröße um den Faktor <math>\sqrt[3]{2}</math> (also eine ''multiplikative'' Vergrößerung um ca. 25%, statt nur einer additiven Vergrößerung wie bei exponentieller Komplexität).

===<math>\Omega</math>- Notation===

Genauso wie <math>f \in \mathcal{O}(g)</math> eine Art <math>\le</math>-Operator für Funktionen ist, definiert <math>f \in \Omega(g) </math> eine Abschätzung von unten, analog zum <math>\ge</math>-Operator für Zahlen. Formal kann man <math>f(N) \in \Omega(g(N)) </math> genau dann schreiben, falls es eine Konstante <math> c > 0 </math> gibt, so dass

<math> f(N) \ge c \cdot g(N) </math> für <math> N \ge N_0 </math>

gilt.
Man verwendet diese Notation also um abzuschätzen, wie groß der Aufwand (die Komplexität) für einen bestimmten Algorithmus ''mindestens'' ist und nicht ''höchstens'', was man mit der <math>\mathcal{O}</math> - Notation ausdrücken würde.

Ein praktisches Beispiel für eine Anwendung der <math>\Omega</math>- Notation wäre die Fragestellung, ob es ''prinzipiell'' einen besseren Algorithmus für ein bestimmtes Problem gibt. Wie später im Abschnitt [[Suchen#Sortieren_als_Suchproblem|Sortieren als Suchproblem]] gezeigt wird, ist das Sortieren eines Arrays durch paarweise Vergleiche von Elementen immer mindestens von der Komplexität <math> \Omega(N\cdot \ln N) </math>, was konkret bedeutet, dass kein Sortieralgorithmus, der nach diesem Prinzip arbeitet, jemals eine geringere Komplexität als beispielsweise Merge-Sort haben wird. Natürlich kann man den entsprechenden Sortieralgorithmus, also Merge-Sort zum Beispiel, unter Umständen noch optimieren, aber die Komplexität wird erhalten bleiben. Mit diesem Wissen kann man sich viel (vergebliche) Arbeit sparen.

===<math>\Theta</math>- Notation===

<math>f(N) \in \Theta(g(N))</math> ist eine scharfe Abschätzung der asymptotischen Komplexität einer Funktion f.

Damit dies gilt, muss <math>f(N) \in \mathcal{O}(g(N))</math> und ''gleichzeitig'' <math>f(N) \in \Omega(g(N))</math> erfüllt sein.

Dies ist natürlich auch die beste Abschätzung der asymptotischen Komplexität einer Funktion f. Formal bedeutet <math>f(N) \in \Theta(g(N))</math> dass es zwei Konstanten <math> c_1 </math> und <math> c_2 </math>, beide größer als Null, gibt, so dass für alle <math> N \geq N_0 </math> gilt:

<math> c_1 \cdot g(N) \leq f(N) \leq c_2 \cdot g(N) </math>.

In der Praxis wird manchmal statt der <math>\Theta</math>-Notation auch dann die <math>\mathcal{O}</math>-Notation benutzt, wenn eine scharfe Schranke ausgedrückt werden soll. Dies ist zwar formal nicht korrekt, aber man kann die intendierte Bedeutung meist aus dem Kontext erschließen.

== Komplexitätsvergleich zweier Algorithmen ==

In diesem Abschnitt wollen wir der Frage nachgehen, wie ein formaler Beweis für die Behauptung <math> f(N) \in \mathcal{O}(g(N))</math> geschehen kann. Hierbei werden zwei Beweismethoden vorgestellt werden, und zwar der '''Beweis über die Definition der Komplexität''' sowie der '''Beweis durch Dividieren'''.

===Beweis über die Definition der asymptotischen Komplexität===

Die Definition der asymptotischen Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> war:

Es gibt eine Konstante <math> c > 0 </math>, so dass <math> f(N) \le c \cdot g(N) </math> für <math> N \ge N_0 </math> erfüllt ist.

Um also die die asymptotische Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> zu beweisen, muss man die oben erwähnten Konstanten c und <math> N_0 </math> finden, so dass

<math> f(N) \leq c \cdot g(N) </math> für alle <math> N \ge N_0 </math> erfüllt ist.

Dies geschieht zweckmäßigerweise mit dem Beweisprinzip der ''vollständigen Induktion''. Hierbei ist zu zeigen, dass
# <math> f(N_0) \leq g(N_0) </math> für die eine zu bestimmende Konstante <math> N_0 </math> gilt (''Induktionsanfang'') und
# falls <math> f(N) \leq g(N) </math>, dann auch <math> f(N+1) \leq g(N+1) </math> (''Induktionsschritt'') gilt.

===Beweis durch Dividieren===

Hierbei wählt man eine Konstante c und zeigt, dass <math> \lim_{N \rightarrow \infty} \frac{f(N)}{c \cdot g(N)} \leq 1 </math> gilt (für die O-Notation, bei Ω-Notation gilt entsprechend <math>\geq 1 </math>). Man kann dies auch als alternative Definition der Komplexität verwenden.

Als Beispiel betrachten wir die beiden Funktionen <math> f(N) = N \,\lg N </math> und <math> g(N) = N^2 </math> und wollen zeigen, dass <math>f(N) \in \mathcal{O}(g(N))</math> gilt.

Als Konstante c wählen wir <math> c = 1 </math>

<math> \lim_{N \rightarrow \infty} \frac{f(N)}{g(N)} = \lim_{N \rightarrow \infty} \frac{\lg N}{N} = \frac{\infty}{\infty} </math>

Unbestimmte Ausdrücke der Form
<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} </math>,
in denen sowohl <math> f(x) </math> als auch <math> g(x) </math> mit <math> x \rightarrow x_0 </math> gegen Null oder gegen Unendlich streben, kann man manchmal mit den Regeln von [http://de.wikipedia.org/wiki/L%27Hospital%27sche_Regel ''l'Hospital''] berechnen. Danach darf man die Funktionen f und g zur Berechnung des unbestimmten Ausdrucks durch ihre k-ten Ableitungen ersetzen:

<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} = \lim_{x \rightarrow x_0} \frac{f^{(k)}(x)}{g^{(k)}(x)} </math>

In unserem Fall verwenden wir die erste Ableitung und erhalten:
<math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)} = \lim_{N \rightarrow \infty} \frac{1/N}{1} \rightarrow 0 </math>

Damit wurde <math>f(N) \in \mathcal{O}(g(N))</math>, also <math>N \lg N \in \mathcal{O}(N^2)</math> gezeigt.

Man beachte hierbei, dass <math>N \lg N \in \mathcal{O}(N^2)</math> keine enge Grenze für die Komplexität von <math>N \,\lg N</math> darstellt, da der Grenzwert <math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)}\, </math> gegen 0 und nicht gegen eine von Null verschiedene Konstante strebt. In diesem Fall haben wir die Komplexität von <math>N \cdot \lg N </math> also nur nach oben abschätzen können.

===Beispiel für den Komplexitätsvergleich: Gleitender Mittelwert (Running Average)===

Wir berechnen für ein gegebenes Array <tt>a</tt> einen gleitenden Mittelwert über <tt>k</tt> Elemente: 
::<math>r_i = \frac{1}{k} \sum_{j=i-k+1}^i a_j</math> 
Das heisst, für jedes <tt>i</tt> mitteln wir die letzten <tt>k</tt> Elemente von <tt>a</tt> und schreiben das Ergebnis in <tt>r[i]</tt>. Diese Operation ist z.B. bei Börsenkursen wichtig: Neben dem aktuellen Kurs für jeden Tag wird dort meist auch der gleitende Mittelwert der letzten 30 Tage sowie der letzten 200 Tage angegeben. In diesen Mittelwerten erkennt man besser die langfristige Tendenz, weil die täglichen Schwankungen herausgemittelt werden. Wir nehmen außerdem an, dass
* Array-Zugriff hat eine Komplexität von O(1)
* <math>k \ll N</math>, d.h. <math>N-k\approx N</math>.

Die beiden folgenden Algorithmen berechnen die Mittelwerte auf unterschiedliche Art. Der linke folgt der obigen Definition durch eine Summe, während der rechte inkrementell arbeitet: Man kann den Bereich der <tt>k</tt> letzten Werte als Fenster betrachten, das über das Array <tt>a</tt> geschoben wird. Schiebt man das Fenster ein Element weiter, fällt links ein Element heraus, und rechts kommt eins hinzu. Man muss also nicht jedes Mal die Summe neu berechnen, sondern kann den vorigen Wert aktualisieren. Wir werden sehen, dass dies Folgen für die Komplexität des Algorithmus hat.

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1: O(N * k)
! Komplexität
! Version 2: O(N)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|
<tt>for i in range(k):</tt>
|
'''<center>O(k)</center>'''
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|
:: <tt>r[k-1] += a[i]</tt>
|
'''<center>O(1)</center>'''
|-
|
6.
|
:::: <tt>r[j] += a[i]</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(k, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|
:: <tt>r[j] = (a[j] - a[j-k] + r[j-1])</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(len(a)):</tt>
|
'''<center>O(N)</center>'''
|-
|
9.
|

|

|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
10.
|

|

|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Wir zeigen unten dass Version 2 eine geringere Komplexität besitzt, obwohl sie mehr Zeilen benötigt.

Wir haben in der Tabelle die Komplexität jeder Zeile für sich angegeben. Einfache Anweisungen (Berechnungen, Lese- und Schreibzugriffe auf das Array, Zuweiseungen) haben konstante Komplexität, die Komplexität des Schleifenkopfes allein (also der <tt>for</tt>-Anweisung ohne den eingerückten Schleifenkörper) entspricht der Anzahl der Durchläufe. Wir müssen jetzt noch die Verschachtelung der Schleifen und die Nacheinanderausführung von Anweisungen berücksichtigen.

====Berechnung der Komplexität von Version 1====

(Wiederholung der Rechenregeln: siehe Abschnitt [[Effizienz#O-Notation|O-Notation]])

Wir betrachten zunächst die innere Schleife (Zeilen 5 und 6 von Version 1):

Der Schleifenkopf (Zeile 5) hat die Komplexität <math>\mathcal{O}(k)</math>, weil die Schleife k-mal durchlaufen wird. Der Schleifenkörper (Zeile 6) hat die Komplexität <math>\mathcal{O}(1)</math>. Nach der Verschachtelungsregel müssen wir die beiden Komplexitäten multiplizieren, und es ergibt sich:

::<math>\mathcal{O}(k)\cdot\mathcal{O}(1) = \mathcal{O}(k\cdot 1)=\mathcal{O}(k)</math>

Wir betrachten nun die äußere Schleife. Der Schleifenkopf (Zeile 4) wird (N-k)-mal durchlaufen und hat somit eine Komplexität von <math>\mathcal{O}(N)</math>. Der Schleifenkörper (Zeilen 5 bis 7) besteht aus der inneren Schleife (Zeilen 5 und 6) mit der gerade berechneten Komplexität <math>\mathcal{O}(k)</math> sowie einer einfachen Anweisung (Zeile 7) mit Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel wird die Komplexität des Schleifenkörpers durch Addition berechnet:

::<math>\mathcal{O}(k)+\mathcal{O}(1) = \mathcal{O}(\max(k,1)) = \mathcal{O}(k)</math>

Die Komplexität der gesamten äußeren Schleife erhalten wir nach der Verschachtelungsregel wieder durch multiplizieren:

::<math>\mathcal{O}(N)\cdot\mathcal{O}(k) = \mathcal{O}(N\cdot k)</math>

Die übrigen Schritte des Algorithmus werden einfach nacheinander ausgeführt, so dass sie ebenfalls nach der Sequenzregel behandelt werden. Wir erhalten

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(N\cdot k)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,N\cdot k,1)) = \mathcal{O}(N\cdot k)</math>

Der gesamte Algorithmus hat also die Komplexität <math>\mathcal{O}(N\cdot k)</math>.

====Berechnung der Komplexität von Version 2====

Hier gibt es nur einfache Schleifen ohne Verschachtelung. Da der Schleifenkörper jeder Schleife nur einfache Anweisungen der Komplexität <math>\mathcal{O}(1)</math> enthält, ergibt sich die Komplexität der Schleifen nach der Verschachtelungsregel als

::<math>\mathcal{O}(X)\cdot\mathcal{O}(1) = \mathcal{O}(X\cdot 1)=\mathcal{O}(X)</math>

wobei <math>\mathcal{O}(X)</math> die Komplexität des jeweiligen Schleifenkopfes ist. Wir erhalten also für Zeilen 4 und 5: <math>\mathcal{O}(k)</math>, Zeilen 6 und 7: <math>\mathcal{O}(N)</math>, Zeilen 8 und 9: <math>\mathcal{O}(N)</math>. Die Hintereinanderausführung wird nach der Sequenzregel behandelt:

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(k)+\mathcal{O}(N)+\mathcal{O}(N)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,k,N,N,1)) = \mathcal{O}(N)</math>

Dieser Algorithmus hat also nur die Komplexität <math>\mathcal{O}(N)</math>.

====Fazit====

Obwohl Version 2 mehr Schritte benötigt hat sie eine geringere Komplexität, da die for-Schleifen nicht wie bei Version 1 verschachtelt/untergeordnet sind. Bei verschachtelten for-Schleifen muss die Multiplikationsregel angewendet werden → höhere Komplexität.

Die gerade berechnete Komplexität gilt aber nur unter der Annahme, dass Array-Zugriffe konstante Komplexität <math>\mathcal{O}(1)</math> besitzen. Wenn dies nicht der Fall ist, kann sich die Komplexität des Algorithmus drastisch verschlechtern.

{| border="1" cellspacing="0" cellpadding="5"
|Allgemein gilt: 
Algorithmen-Analysen beruhen auf der Annahme, dass Zugriffe auf die Daten optimal schnell sind, dass heißt, dass die für den jeweiligen Algorithmus am besten geeignete Datenstruktur verwendetet wird. → Ansonsten: Komplexitätsverschlechterung!
|}
 

====Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur====

Wir verwende im Mittelwert-Algorithmus eine verkettete Liste anstelle des Eingabe-Arrays a. Wir benötigen dazu eine Funktion, die das j-te Element der Liste zurückgibt. Wie üblich ist die Liste mit Hilfe einer Knotenklasse implementiert:
class Node:
def __init__(self, data):
self.data = data
self.next = None

Die Listenklasse selbst hat ein Feld <tt>head</tt>, das eine Referenz auf den ersten Knoten speichert, und jeder Knoten speichert im Feld <tt>next</tt> eine Referenz auf seinen Nachfolger. Um zum j-ten Element zu gelangen, muss man die Liste sequenziell durchlaufen
def get_jth(list, j):
r = list.head
while j > 0:
r = r.head
j -= 1
return r.data
Die Komplexität dieser Funktion ist offensichtlich <math>\mathcal{O}(j)</math> (Komplexitätsberechnung wie oben). Wir setzen jetzt bei Version 1 des Mittelwert-Algorithmus diese Funktion in Zeile 6 anstelle des Indexzugriffs <tt>a[i]</tt> ein (nur in dieser Zeile wird auf die Elemente des Arrays zugegriffen). Wir erhalten folgende Implementation (die Änderungen sind rot markiert):

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1 mit Liste: O(N * k)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|-
|
6.
|
:::: <tt>r[j] += get_jth(a, i)</tt>
|
'''<center>O(i)</center>'''
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Der Aufruf der Funktion <tt>get_jth</tt> ist jetzt gleichbedeutend mit einer dreifach verschachtelten Schleife (weil <tt>get_jth</tt> ja eine zusatzliche Schleife enthält). Die Anzahl der Operationen in Zeile 4 bis 6 ist jetzt

::<math>f(N,k)=\sum_{j=k-1}^{N-1}\,\sum_{i=j-k+1}^j\,\mathcal{O}(i)</math>

wobei das <math>\mathcal{O}(i)</math> die neue Schleife durch Verwendung der Liste repräsentiert. Mit Mathematica-Hilfe [http://www.wolfram.com/] lässt sich diese Summe exakt ausrechnen

::<math>f(N,k)=\frac{1}{2}(k N^2-k^2 N+k^2-k)\in \mathcal{O}(k N^2)</math>

Die Komplexitätsberechnung erfolgte dabei nach der Regel für Polynome unter Beachtung von <math>k \ll N</math>.

====Fazit:====

Die Komplexität von Version 1 mit einer verketteten Liste wäre O(N2 * k)
'''→ Die richtige Datenstruktur ist wichtig, da es sonst zu einer Komplexitätsverschlechterung kommen kann!'''

Auf Version 2 unseres Running Average-Beispiels hätte eine verkettete Liste allerdings keine Auswirkungen, da die inkrementelle Berechnung der Summen in Zeile 7 weiterhin möglich ist (bei geschickter Implementation!) und somit Version 2 immer noch eine Komplexität von O(N) hätte.

==Amortisierte Komplexität==

Bis jetzt wurde die Komplexität nur im schlechtesten Fall (Worst Case) betrachtet. Bei einigen Algorithmen schwankt die Komplexität im schlechtesten Fall jedoch, wenn man die ungünstige Operation mehrmals hintereinander ausführt. Die amortisierte Komplexität beschäftigt sich mit der durchschnittlichen Komplexität über viele Aufrufe der ungünstigsten Operation.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse Wikipedia: Amortisierte Laufzeitanalyse]]

===Beispiel: Inkrementieren von Binärzahlen===

Frage: Angenommen, das Umdrehen eines Bits einer Binärzahl verursacht Kosten von 1 Einheit. Wir erzeugen die Folge der natürlichen Zahlen durch sukzessives Inkrementieren, von Null beginnend. Bei jeder Inkrementierung werden einige Bits verändert, aber diese Zahl (und damit die Kosten der Inkrementierungen) ''schwanken'' sehr stark. Wir fragen jetzt, was eine Inkrementierung im Durchschnitt kostet?

Um diese Durchschnittskosten zu berechnen, bezahlen wir bei jeder Inkrementierung 2 Einheiten. Wenn davon nach Abzug der Kosten der jeweiligen Operation noch etwas übrig bleibt, wird der Rest dem Guthaben zugeschrieben. Umgekehrt wird ein eventueller Fehlbetrag (wenn eine Inkrementierung mehr als 2 Bits umdreht) aus dem Guthaben gedeckt. Dadurch werden die ansonsten großen Schwankungen der Kosten ausgeglichen:
:: Kosten < Einzahlung → es wird gespart
:: Kosten = Einzahlung → Guthaben bleibt unverändert
:: Kosten > Einzahlung → Guthaben wird für die Kosten verbraucht

{| border="1" cellspacing="0" cellpadding="5"
!Schritte
!Zahlen
!Kosten 
(Anzahl der geänderten Bits)
! Einzahlung
!Guthaben = 
altes Guthaben + Einzahlung - Kosten
|-
|1.
|00001
|1
|'''2'''
|'''1'''
|-
|2.
|00010
|2
|'''2'''
|'''1'''
|-
|3.
|00011
|1
|'''2'''
|'''2'''
|-
|4.
|00100
|3
|'''2'''
|'''1'''
|-
|5.
|00101
|1
|'''2'''
|'''2'''
|-
|6.
|00110
|2
|'''2'''
|'''2'''
|-
|7.
|00111
|1
|'''2'''
|'''3'''
|-
|8.
|01000
|4
|'''2'''
|'''1'''
|-
|}

Die Kosten ergeben sich aus der Anzahl der Ziffern die von 1 nach 0, bzw. von 0 nach 1 verändert werden

Rechnung:

1. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

2. Schritt: Kosten: 2 = Einzahlung: 2 
:: → es wird nicht gespart 
:: → Guthaben bleibt so wie es ist 

3. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

4. Schritt: Kosten: 3 > Einzahlung: 2 
:: → es wird eine 1 vom Guthaben genommen um die Kosten zu zahlen 

usw.

Man erkennt, dass vor teuren Operation (Wechsel von 3 auf 4 bzw. von 7 auf 8) genügend Guthaben angespart wurde, um die Kosten zu decken. Das Guthaben geht bei diesen Operationen immer wieder auf 1 zurück, aber es wird nie vollständig verbraucht (Dies kann natürlich auch mathematisch exakt bewiesen werden, wie wir es unten am Beispiel des dynamische Arrays zeigen). Wir schließen daraus, dass die durchschnittlichen oder '''amortisierten Kosten''' einer Inkrementierungsoperation gleich 2 sind.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Account-Methode Wikipedia Account-Methode]]

====Fazit====
Die amortisierte Komplexität beschäftigt sich mit dem Durchschnitt aller Operation im ungünstigsten Fall. Operationen mit hohen Kosten, die aber nur selten ausgeführt werden, fallen bei der amortisierten Komplexität nicht so ins Gewicht. Bei Algorithmen, die gelegentlich eine "teure" Operation benutzen, ansonsten jedoch "billigen" Operationen aufrufen, kann die amortisierte Komplexität niedriger sein als die Komplexität im schlechtesten (Einzel-)Fall.

In unserem Beispiel fallen die teuren Einzelschritte (z.B. 4. und 8. Schritt) bei den amortisierten Kosten nicht so ins Gewicht, da wir die Kosten aus unserem Guthaben mitbezahlen können. Das Guthaben ist immer groß genug, weil jeder zweite Aufruf eine billige Operation ist, die nur ein Bit umdreht und somit das Ansparen ermöglichen. Diese Betrachtung zeigt, dass die amortisierte (d.h. durchschnittliche) Komplexität des Algoithmus niedriger (nämlich konstant) ist als die Komplexität im schlechtesten Fall.

===Anwendung: Dynamisches Array===

Ein dynamisches Array hat die Eigenschaft, dass man effizient am Ende des Arrays neue Elemente anfügen kann, indem man die Länge des Arrays entsprechend vergrößert (siehe Übung 1). Die Analyse der amortisierten Komplexität der Anfüge-Operation zeigt uns, wie man das Vergrößern des Arrays richtig implementiert, damit die Operation wirklich effizient abläuft.

==== Ineffiziente naive Lösung ====

Wenn wir an ein Array ein Element anhängen wollen, müssen wir neuen Speicher allokieren, der die gewünschte Länge hat. Die Werte aus dem alten Array müssen dann in den neuen Speicher umkopiert werden. Danach kann das neue Element hinten angefügt werden, weil wir im neuen Array bereits Speicher für dieses Element reserviert haben. Bei der naiven Implementation des dynamischen Arrays wiederholt man dies bei jeder Anfügeoperation. Für die Analyse nehmen wir an, dass das Kopieren eines Elements konstante Zeit O(1) erfordert, ebenso das Einfügen eines neuen Elements auf in eine noch unbenutzte Speicherposition.

Naives Anhängen eines weiteren Elements an ein Array:

{| border="1" cellspacing="0" cellpadding="5" align="right"
!Schritte
|'''Array'''
(wie es nach jedem Schritt aussieht)
!Komplexität
|-
|<center>altes Array (N=4)</center>
|<center>[0,1,2,3]</center>
|<center>-</center>
|-
|1. neuer Speicher für    (N+1) Elemente
|<center>[None,None,None,None,None]</center>
|<center>O(N+1) = '''O(N)'''</center>(wenn der Speicher initialisiert wird (hier auf <tt>None</tt>), sonst O(1))
|-
|2. Kopieren
|<center>[0,1,2,3,None]</center>
|<center>'''O(N)'''</center>
|-
|3. append von "x"
|<center>[0,1,2,3,'x']</center>
|<center>'''O(1)'''</center>
|-
|}

altesArray = [0,1,2,3] 
altesArray.append('x')

1. Es wird ein neues Array der Größe N+1 erzeugt 
2. Die N Datenelemente aus dem alten Array werden in das neue Array kopiert 
Das sind N Operationen der Komplexität O(1), also ein Gesamtaufwand von O(N). 
3. 'x' wird mit Aufwand O(1) an die letzte Stelle des neuen Arrays geschrieben

Additionsregel: 
O(N) + O(1) ∈ O(N)

Folgerung:

Bei der naiven Methode erfordert jede Anfügung einen Aufwand O(N) (wobei N die derzeitige Arraygröße ist). Dies ist nicht effizient.

====Effiziente Lösung durch Verdoppeln der Kapazität====

Offensichtlich kommt man nicht darum heraum, den Inhalt des alten Arrays zu kopieren, wenn der allokierte Speicher voll ist. Der Trick für die effiziente Implementation der Anfügeoperation besteht darin, das Kopieren so selten wie möglich durchzuführen, also nicht wie in der naiven Lösung bei jeder Anfügeoperation. Hier kommt die amortisierte Komplexität ins Spiel: Ab und zu gibt es eine teure Anfügeoperation (wenn nämlich kopiert werden muss), aber wenn man den durchschnittlichen Aufwand über viele Anfügungen betrachtet, ist die Operation effizient. Der teure Fall wird sozusagen "herausgemittelt".

Um nur selten kopieren zu müssen, werden beim dynamischen Array mehr Speicherelemente reserviert als zur Zeit benötigt werden (in der naiven Lösung wurde dagegen immer nur Speicher für ein einziges neues Element reserviert). Wir unterscheiden deshalb

:<tt>capacity</tt> = Anzahl der allokierten Speicherzellen, d.h. der möglichen Elemente, die in das Array passen 
:<tt>size</tt> = Anzahl der Elemente, die im Array zur Zeit gespeichert sind 

Die Daten selbst werden in einem statischen Array gespeichert:
:<tt>data</tt> = statisches Array der Größe <tt>capacity</tt> 

Die folgende intuitive Abschätzung zeigt, dass es sinnvoll ist, die Größe des allokierten Speichers jeweils zu verdoppeln. Wir starten bei einem Array der Größe <tt>size = capacity</tt> = N. Da der verfügbare Speicher voll ist, müssen wir bei der nächsten Anfügung die N vorhandenen Elemente in ein neues Array der Länge <tt>new_capacity</tt> kopieren (Aufwand <math>N\cdot O(1)</math>). Danach können wir K Elemente billig einfügen (Aufwand <math>K\cdot O(1)</math>), wobei
:K = <tt>new_capacity - capacity</tt>
die Anzahl der nach dem Kopieren noch unbenutzen Speicherzellen ist. Der durchschnittliche Aufwand für diese K Einfügungen ist somit
:<math>\bar T = \frac{N \cdot O(1) + K \cdot O(1)}{K}=\frac{N+K}{K}\cdot O(1)</math>
Damit die mittlere Zeit in O(1) sein kann, muss der Quotient <math>(N+K)/K</math> eine Konstante sein. Wir setzen <math>K = a N</math> und erhalten:
:<math>\bar T = \frac{(a+1)N}{a N}\cdot O(1)=\frac{a+1}{a}\cdot O(1)</math>
Der amortisierte Aufwand über K Einfügungen ist also konstant, wenn <math>a</math> eine (kleine) von N unabhängige Zahl ist. Typischerweise wählt man
:<math>a = 1</math>
und mit <math>K = 1\cdot N</math> ergibt sich
:<tt>new_capacity = capacity</tt> + N = <tt>2 * capacity</tt>

Die Vorgehensweise beim Zufügen eines neuen Elements im Fall <tt>size == capacity</tt> ist also
* capacity wird verdoppelt 
: <tt>neue capacity = 2 * alte capacity</tt>
: (allgemein genügt es auch, wenn capacity um einen bestimmten Prozentsatz vergrößert wird,
:: <tt>neue capacity = alte capacity * c</tt>
: mit c > 1, z.B. c = 1.2, das entspricht oben der Wahl <math>a = 0.2</math>)
* ein neues statisches Array der Größe 'neue capacity' wird erzeugt
* das alte Array wird ins neue kopiert und danach freigegeben
* das anzufügende Element wird ins neue Array eingefügt
Umgekehrt geht man beim Entfernen des ''letzten'' Array-Elements vor. Normalerweise überschreibt man einfach das letzte Element mit <tt>None</tt> und dekrementiert <tt>size</tt>. Wird dadurch das Array zu klein (üblicherweise <tt>size < capacity / 4</tt>), wird die Kapazität halbiert, genauer:
* ein neues Array mit 
: <tt>neue capacity = alte capacity / 2 </tt>
: wird angelegt (bzw. mit
:: <tt>neue capacity = alte capacity / c </tt>
: wenn ein anderer Vergrößerungsfaktor verwendet wird)
* das alte Array wird ins neue kopiert und danach freigegeben

'''Folge:''' Die Kosten für das Vergrößern/Verkleinern der Kapazität werden amortisiert über viele Einfügungen, die kein Vergrößern erfordern. Die Operation <tt>append</tt> besitzt amortisierte Komplexität O(1). Im folgenden Abschnitt zeigen wir dies mathematisch exakt mit der Potentialmethode.

====Komplexitätsanalyse des dynamischen Arrays mit Potentialmethode====

Durchschnitt der Gesamtkosten für N-maliges append = <math>\frac{1}{N} \sum_{i = 1}^N Kosten(i)</math>. Zur Analyse der amortisierten Komplexität wird ein Potential 
::Φi = 2*sizei - capacityi 
eingeführt, wobei das Array nach dem i-ten Einfüge-Schritt die Größe sizei und die Kapizität capacityi hat. Wir nehmen vereinfachend an, dass es keine Löschoperationen gibt. Dann gilt nach dem i-ten Schritt jeweils
::Φi = 2*i - capacityi 

Fall 1: Array ist nicht voll 
Es wird kein Umkopieren benötigt, da das Array noch nicht voll ist 
→ sizei-1 < capacityi-1 
→ capacityi == capacityi-1

Kosten: 1 (für Einfügen des neuen Elements) 
Potenzial vor append: Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append: Φi = 2i - capacityi-1 

amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = 1 + (2i - capacityi-1) - [2(i - 1) - capacityi-1]
::::: = 1 + 2i - capacityi-1 - 2i + 2 + capacityi-1
::::: = 1 + <del>2i</del> - <del>capacityi-1</del> - <del>2i</del> + 2 + <del>capacityi-1</del>
::::: = 1 + 2
::::: = 3 = O(1) → konstant

Fall 2: Array ist voll 
Vor dem i-ten append muss umkopiert werden 
→ sizei-1 == capacityi-1 == i-1 
→ Allokieren eines neuen statischen Arrays mit verdoppelter Kapazität notwendig, also capacityi == 2*capacityi-1

Kosten: (i-1) + 1 (für Umkopieren und Einfügen des neuen Elements) 
Potenzial vor append = Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append = Φi = 2i - 2 capacityi-1 
amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = ((i - 1) + 1) + 2i - 2 capacityi-1 - [2(i-1) - capacityi-1]
::::: = i + <del>2i</del> - 2 capacityi-1 - <del>2i</del> + 2 - capacityi-1
::::: = i + 2 - capacityi-1
::::: = i + 2 - (i - 1) (da capacityi-1 = i-1)
::::: = 3 = O(1) → konstant

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine amortisierte Komplexität von 3 Einheiten hat, also <tt>append</tt> ∈ O(1)'''. Diese Operation kann deshalb gefahrlos in der inneren Schleife eines Algorithmus benutzt werden.

==== Beispiel für 9 Einfügeoperationen ====

{| border="1" cellspacing="0" cellpadding="5"
!Array 
(wie es aussehen könnte)
!size
!capacity
!Kosten für append (einschließlich Umkopieren)
!Summe Kosten
!Durchschnittskosten
!Φi = 2 * size - capacity 
(i = size)
!Potenzialdifferenz 
Δ Φi = Φi - Φi-1
!amortisierte Kosteni 
= Kosteni + Δ Φi
|-
| <center>[None]</center>
| <center>0</center>
| <center>1</center>
| <center>-</center>
| <center>-</center>
| <center>-</center>
| <center>-1</center>
| <center>-</center>
| <center>-</center>
|-
| <center>[a]</center><center>Array ist voll!</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b]</center><center>Array ist voll!</center>
| <center>2</center>
| <center>2</center>
| <center>1 + 1</center>
| <center>3</center>
| <center>3/2</center>
| <center>2</center>
| <center>1</center>
| <center>3</center>
|-
| <center>[a,b,c,None]</center>
| <center>3</center>
| <center>4</center>
| <center>2 + 1</center>
| <center>6</center>
| <center>6/3</center>
| <center>2</center>
| <center>0</center>
| <center>3</center>
|-
| <center>[a,b,c,d]</center><center>Array ist voll!</center>
| <center>4</center>
| <center>4</center>
| <center>1</center>
| <center>7</center>
| <center>7/4</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,None,None,None]</center>
| <center>5</center>
| <center>8</center>
| <center>4 + 1</center>
| <center>12</center>
| <center>12/5</center>
| <center>2</center>
| <center>-2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,None,None]</center>
| <center>6</center>
| <center>8</center>
| <center>1</center>
| <center>13</center>
| <center>13/6</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,None]</center>
| <center>7</center>
| <center>8</center>
| <center>1</center>
| <center>14</center>
| <center>14/7</center>
| <center>6</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h]</center><center>Array ist voll!</center>
| <center>8</center>
| <center>8</center>
| <center>1</center>
| <center>15</center>
| <center>15/8</center>
| <center>8</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h,j,None,None,None, 
None,None,None,None]</center>
| <center>9</center>
| <center>16</center>
| <center>8 + 1</center>
| <center>24</center>
| <center>24/9</center>
| <center>2</center>
| <center>-6</center>
| <center>3</center>
|-
|}

Die durchschnittlichen Kosten betragen stets etwa 2 Einheiten, schwanken allerdings so, dass nicht unmittelbar ersichtlich ist, ob dies für sämtliche Einfügeoperationen gilt. Die amortisierte Komplexität, die mit Hilfe des Potentials berechnet wird, ist hingegen konstant 3, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

[[Suchen|Nächstes Thema]]

Main Page

2012-07-27T10:32:28Z

Ukoethe: /* Übungsaufgaben */

== Vorlesung Algorithmen und Datenstrukturen ==

Dr. Ullrich Köthe, Universität Heidelberg, Sommersemester 2012

Die Vorlesung findet '''dienstags''' und '''donnerstags''' jeweils um 14:15 Uhr in INF 227 (KIP), HS 2 statt.

=== Klausur und Nachprüfung ===

Die '''Abschlussklausur''' findet am Dienstag, dem 31.7.2012 von 10:00 bis 12:00 Uhr im HS 1 in INF 306 statt. Zur Klausur wird zugelassen, wer mindestens 50% der Übungspunkte erreicht. (Hinweis: Sie benötigen einen Lichtbildausweis, um sich bei der Klausur zu indentifizieren!) Falls notwendig, wird eine Nachklausur kurz vor Beginn des neuen Semesters stattfinden, näheres wird noch bekanntgegeben.


=== Leistungsnachweise ===
Für alle Leistungsnachweise ist die erfolgreiche Teilnahme an den Übungen erforderlich. Für Leistungspunkte bzw. den Klausurschein muss außerdem die schriftliche Prüfung bestanden werden. Einzelheiten werden noch bekanntgegeben.


=== Übungsbetrieb ===
* Termine und Räume:
** Mo 14:00 - 16:00 Uhr, INF 227 (KIP), Seminarraum 2.402 (Tutor: Sven Ebser [mailto:sven@ebsers.de sven AT ebsers.de])
** Di 9:00 - 11:00 Uhr, INF 227 (KIP), Seminarraum 2.403 (Tutor: Christoph Koke [mailto:koke@kip.uni-heidelberg.de koke AT kip.uni-heidelberg.de])
** Di 11:00 - 13:00 Uhr, INF 227 (KIP), Seminarraum 2.403 (Tutor: Kai Karius [mailto:kai.karius@googlemail.com kai.karius AT googlemail.com])
** Mi 14:00 - 16:00 Uhr, INF 227 (KIP), Seminarraum 2.401 (Tutor: Stephan Meister [mailto:stephan.meister@iwr.uni-heidelberg.de stephan.meister AT iwr.uni-heidelberg.de])
* Die Übungsgruppen werden über [https://www.mathi.uni-heidelberg.de/muesli/lecture/view/169 MÜSLI] verwaltet. Dort erfolgt auch die Anmeldung.

* [[Main Page#Übungsaufgaben|Übungsaufgaben]] (Übungszettel mit Abgabetermin, Musterlösungen). Lösungen bitte per Email an den jeweiligen Übungsgruppenleiter.
* Zur Klausur wird zugelassen, wer mindestens 50% der Übungspunkte erreicht. Außerdem muss jeder Teilnehmer eine Lösung (bzw. einen Teil davon) in der Übungsgruppe vorrechnen.
* Durch das Lösen von Bonusaufgaben und gute Mitarbeit in den Übungen können Sie Zusatzpunkte erlangen. Zusatzpunkte werden auch vergeben, wenn Sie größere Verbesserungen an diesem Wiki vornehmen. Damit solche Verbesserungen der richtigen Person zugeordnet werden, sollten Sie dafür ein eigenes Wiki-Login verwenden, das Ihnen Stephan Meister oder Ullrich Köthe auf Anfrage gerne einrichten.

=== Prüfungsvorbereitung ===

Zur Hilfe bei der Prüfungsvorbereitung hat Andreas Fay [http://de.neemoy.com/quizcategories/31/ Quizfragen] erstellt.

=== Literatur ===

* R. Sedgewick: Algorithmen (empfohlen für den ersten Teil, bis einschließlich Graphenalgorithmen)
* J. Kleinberg, E.Tardos: Algorithm Design (empfohlen für den zweiten Teil, einschließlich Graphenalgorithmen)
* T. Cormen, C. Leiserson, R.Rivest: Algorithmen - eine Einführung (empfohlen zum Thema Komplexität)
* Wikipedia und andere Internetseiten (sehr gute Seiten über viele Algorithmen und Datenstrukturen)

=== Gliederung der Vorlesung ===

# [[Einführung]] (17.4.2012)
#* Definition von Algorithmen und Datenstrukturen, Geschichte
#* Fundamentale Algorithmen: create, assign, copy, swap, compare etc.
#* Fundamentale Datenstrukturen: Zahlen, Container, Handles
#* Python-Grundlagen

# [[Container]] (19.4.2012)
#* Anforderungen von Algorithmen an Container
#* Einteilung der Container
#* Grundlegende Container: Array, verkettete Liste, Stack und Queue
#* Sequenzen und Intervalle (Ranges)

# [[Sortieren]] (24. und 26.4.2012)
#* Spezifikation des Sortierproblems
#* Selection Sort und Insertion Sort
#* Merge Sort
#* Quick Sort und seine Varianten
#* Vergleich der Anzahl der benötigten Schritte
#* Laufzeitmessung in Python

# [[Korrektheit]] (3. und 8.5.2012)
#* Definition von Korrektheit, Algorithmen-Spezifikation
#* Korrektheitsbeweise versus Testen
#* Vor- und Nachbedingungen, Invarianten, Programming by contract
#* Testen, Execution paths, Unit Tests in Python
#* Ausnahmen (exceptions) und Ausnahmebehandlung in Python

# [[Effizienz]] (10. und 15.5.2012)
#* Laufzeit und Optimierung: Innere Schleife, Caches, locality of reference
#* Laufzeit versus Komplexität
#* Landausymbole (O-Notation, <math>\Omega</math>-Notation, <math>\Theta</math>-Notation), Komplexitätsklassen
#* Bester, schlechtester, durchschnittlicher Fall
#* Amortisierte Komplexität

# [[Suchen]] (22. und 24.5.2012)
#* Sequentielle Suche
#* Binäre Suche in sortierten Arrays, Medianproblem
#* Suchbäume, balancierte Bäume
#* selbst-balancierende Bäume, Rotationen
#* Komplexität der Suche

# [[Sortieren in linearer Zeit]] (29.5.2012)
#* Permutationen
#* Sortieren als Suchproblem
#* Bucket Prinzip, Bucket Sort

# [[Prioritätswarteschlangen]] (31.5.2012)
#* Heap-Datenstruktur
#* Einfüge- und Löschoperationen
#* Heapsort
#* Komplexität des Heaps

# [[Assoziative Arrays]] (5.6.2012)
#* Datenstruktur-Dreieck für assoziative Arrays
#* Definition des abstrakten Datentyps
#* JSON-Datenformat
#* Realisierung durch sequentielle Suche und durch Suchbäume

# [[Hashing und Hashtabellen]] (5.6.und 12.6.2012)
#* Implementation assoziativer Arrays mit Bäumen
#* Hashing und Hashfunktionen
#* Implementation assoziativer Arrays als Hashtabelle mit linearer Verkettung bzw. mit offener Adressierung
#* Anwendung des Hashing zur String-Suche: Rabin-Karp-Algorithmus

# [[Iteration versus Rekursion]] (14.6.2012)
#* Typen der Rekursion und ihre Umwandlung in Iteration
#* Auflösung rekursiver Formeln mittels Master-Methode und Substitutionsmethode

# [[Generizität]] (19.6.2012)
#* Abstrakte Datentypen, Typspezifikation
#* Required Interface versus Offered Interface
#* Adapter und Typattribute, Funktoren
#* Beispiel: Algebraische Konzepte und Zahlendatentypen
#* Operator overloading in Python

# [[Graphen und Graphenalgorithmen]] (21.6. bis 5.7.2012)
#* Einführung
#* Graphendatenstrukturen, Adjazenzlisten und Adjazenzmatrizen
#* Gerichtete und ungerichtete Graphen
#* Vollständige Graphen
#* Planare Graphen, duale Graphen
#* Pfade, Zyklen
#* Tiefensuche und Breitensuche
#* Zusammenhang, Komponenten
#* Gewichtete Graphen
#* Minimaler Spannbaum
#* Kürzeste Wege, Best-first search (Dijkstra)
#* Most-Promising-first search (A*)
#* Problem des Handlungsreisenden, exakte Algorithmen (erschöpfende Suche, Branch-and-Bound-Methode) und Approximationen
#* Erfüllbarkeitsproblem, Darstellung des 2-SAT-Problems durch gerichtete Graphen, stark zusammenhängende Komponenten












# [[Randomisierte Algorithmen]] (10. und 12.7.2012)
#* Zufallszahlen, Zyklenlänge, Pitfalls
#* Zufallszahlengeneratoren: linear congruential generator, Mersenne Twister
#* Randomisierte vs. deterministische Algorithmen
#* Las Vegas vs. Monte Carlo Algorithmen
#* Beispiel für Las Vegas: Randomisiertes Quicksort
#* Beispiele für Monte Carlo: Randomisierte Lösung des k-SAT Problems
#* RANSAC-Algorithmus, Erfolgswahrscheinlichkeit, Vergleich mit analytischer Optimierung (Methode der kleinsten Quadrate)

# [[Greedy-Algorithmen und Dynamische Programmierung]] (17.7.2012)
#* Prinzipien, Aufwandsreduktion in Entscheidungsbäumen
#* bereits bekannte Algorithmen: minimale Spannbäume nach Kruskal, kürzeste Wege nach Dijkstra
#* Beispiel: Interval Scheduling Problem und Weighted Interval Scheduling Problem
#* Beweis der Optimalität beim Scheduling Problem: "greedy stays ahead"-Prinzip, Directed Acyclic Graph bei dynamischer Programmierung

# [[NP-Vollständigkeit]] (19.7.2012)
#* die Klassen P und NP
#* NP-Vollständigkeit und Problemreduktion

# Reserve und/oder Wiederholung (24. und 26.7.2012)

== Übungsaufgaben ==

(im PDF Format). Die Abgabe erfolgt am angegebenen Tag bis 14:00 Uhr per Email an den jeweiligen Übungsgruppenleiter. Bei Abgabe bis zum folgenden Montag 11:00 Uhr werden noch 50% der erreichten Punkte angerechnet. Danach wird die Musterlösung freigeschaltet. Erreichbare Punkte (ohne Bonusaufgaben): 466.

# [[Media:Übung-1.pdf|Übung]] (Abgabe 24.4.2012) und [[Media:Uebung-1-Musterloesung.pdf|Musterlösung]]
#* Python-Tutorial
#* Sieb des Eratosthenes
#* Wert- und Referenzsemantik
#* Dynamisches Array
# [[Media:Uebung-2.pdf|Übung]] (Abgabe 3.5.2012) und [[Media:Uebung-2-Musterloesung.pdf|Musterlösung]]
#* Sortieren: Implementation und Geschwindigkeitsvergleich (Diagramme in Abhängigkeit von der Problemgröße)
#* Entwicklung eines Gewinnalgorithmus für ein Spiel
#* Bonus: Dynamisches Array mit verringertem Speicherverbrauch
# [[Media:Uebung-3.pdf|Übung]] (Abgabe 10.5.2012) und [[Media:Uebung-3-Musterlösung.pdf|Musterlösung]]
#* Experimente zur Effektivität von Unit Tests
#* Bestimmung von Pi mit dem Algorithmus von Archimedes
#* Deque-Datenstruktur: Vor- und Nachbedingungen der Operationen, Implementation und Unit Tests
# [[Media:Uebung-4.pdf|Übung]] (Abgabe '''Montag''' 21.5.2012) und [[Media:muster_blatt4.pdf|Musterlösung]]
#* Theoretische Aufgaben zur Komplexität
#* Amortisierte Komplexität von array.append()
#* Optimierung der Matrizenmultiplikation
# [[Media:Uebung-5.pdf|Übung]] (31.5.2012) und [[Media:muster_blatt5.pdf|Musterlösung]]
#* Implementation und Analyse eines Binärbaumes
#* Anwendung: einfacher Taschenrechner
# [[Media:Uebung-6.pdf|Übung]] (Abgabe '''Freitag''' 8.6.2012) und [[Media:muster_blatt6.pdf|Musterlösung]]
#* Treap-Datenstruktur: Verbindung von Suchbaum und Heap
#* Anwendung: Worthäufigkeiten (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/die-drei-musketiere.txt die-drei-musketiere.txt]. Die Zeichenkodierung in diesem File ist Latin-1.)
#* BucketSort
# [[Media:Uebung-7.pdf|Übung]] (Abgabe 14.6.2012) und [[Media:muster_blatt07.pdf|Musterlösung]]
#* Absichtliche Konstruktion von Kollisionen für eine Hashfunktion
#* Übungen zum Assoziativen Array und zum JSON-Format: Cocktail-Datenbank (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/cocktails.json cocktails.json]. Die Zeichenkodierung in diesem File ist UTF-8.)
# [[Media:Uebung-8.pdf|Übung]] (Abgabe 21.6.2012) und [[Media:muster_blatt8.pdf|Musterlösung]]
#* Übungen zu Rekursion und Iteration: Fibonaccizahlen, Koch-Schneeflocke, Komplexität rekursiver Algorithmen, Umwandlung von Rekursion in Iteration
# [[Media:Uebung-9.pdf|Übung]] (Abgabe 28.6.2012) und [[Media:muster_blatt9.pdf|Musterlösung]]
#* Planare Graphen: Aufstellen von Adjazenzmatrizen und Adjazenzlisten, obere Schranke für die Zahl der Kanten
#* Übungen zur Generizität: Sortieren mit veränderter Ordnung, Iterator für Tiefensuche
# [[Media:Uebung-10.pdf|Übung]] (Abgabe 5.7.2012) und [[Media:muster_blatt10.pdf|Musterlösung]]
#* Fortgeschrittene Graphenaufgaben: Erzeugen einer perfekten Hashfunktion, Routenplaner (Dazu benötigen Sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/entfernungen.json entfernungen.json]. Die Zeichenkodierung in diesem File ist UTF-8.)
# [[Media:Uebung-11.pdf|Übung]] (Abgabe 12.7.2012) und [[Media:muster_blatt11.pdf|Musterlösung]] sowie schöne [[Media:ballungsgebiete.pdf|Visualisierung der Ballungsgebiete]] von Thorben Kröger
#* Fortgeschrittene Graphenaufgaben 2: Clusterung mittels minimaler Spannbäume, Bildverarbeitung mit Graphen (Dazu benötigen Sie wieder das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/entfernungen.json entfernungen.json] sowie die Files [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/cells.pgm cells.pgm] und [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/pgm.py pgm.py].)
# [[Media:Uebung-12.pdf|Übung]] (Abgabe 19.7.2012) und [[Media:muster_blatt12.pdf|Musterlösung]]
#* Erfüllbarkeitsproblem, Anwendung: Heim- und Auswärtsspiele im Fussball (Dazu benötigen sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/bundesliga-paarungen-12-13.json bundesliga-paarungen-12-13.json].)
#* Randomisierte Algorithmen: RANSAC für Kreise (Dazu benötigen sie das File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/download/noisy-circles.txt noisy-circles.txt].)
# [[Media:Bonusuebung.pdf|Übung (Bonus)]] (Achtung: Abgabe bereits am Dienstag, 24.7.2012)
#* Greedy-Algorithmus
#* Weg durch einen Graphen
#* Wiederholungsaufgaben für die Klausur

== Sonstiges ==
* [[Gnuplot| Gnuplot Kurztutorial]]
* [[Git Kurztutorial]]
* [[neue Startseite|mögliche neue Startseite]]

File:Muster blatt12.pdf

2012-07-27T10:32:22Z

Ukoethe:

Korrektheit

2012-07-25T18:43:09Z

Ukoethe: /* Häufige Fehler */

Man unterscheidet zwischen Prüfung der Korrektheit (Verifikation) und Prüfung der Spezifikation (Validierung). Ein Algorithmus heißt korrekt, wenn er sich gemäß seiner Spezifikation verhält, auch wenn seine Spezifikation nicht immer die gewünschten Ergebnisse liefert. Die Spezifikation beschreibt die Vorbedingungen (was vor der Anwendung des Algorithmus gilt, so dass der Algorithmus überhaupt angewendet werden darf) und die Nachbedingungen (was nach der Anwendung des Algorithmus gilt, welchen Zustand des Systems der Algorithmus also erzeugt). Hier geht es ausschliesslich um die Prüfung der Korrektheit eines Algorithmus, also darum, ob die spezifizierten Nachbedingungen wirklich gelten.

Nebenbemerkungen
# Approximationsalgorithmen liefern nie ein exaktes Ergebnis. Sie gelten als korrekt, wenn der in der Spezifikation angegebene Approximationsfehler nicht überschritten wird.
# Es gibt Algorithmen, die ''nie'' mit einer 100-prozentigen Wahrscheinlichkeit richtige Ergebnisse liefern können (z.B. [http://en.wikipedia.org/wiki/Primality_test#Probabilistic_tests nichtdeterministische Primzahltests]). In diesem Fall muss die in der Spezifikation angegebene Erfolgswahrscheinlichleit erreicht werden.
# '''Korrektheit''' wird in Algorithmenbüchern meist nur im Zusammenhang mit konkreten Algorithmen behandelt, aber nicht als übergreifendes Problem. Dies erscheint der Bedeutung von Korrektheit nicht angemessen.

Will man die Korrektheit eines Algorithmus/Programms feststellen, hat man 3 Vorgehensweisen zur Verfügung: Korrektheitsprüfungen durch die Programmiersprache, formaler Korrektheitsbeweis und Softwaretest.

== Korrektheitsprüfungen durch die Programmiersprache ==

Alle Programmiersprachen beinhalten gewisse Hilfen, um Programmierfehler zu vermeiden, insbesondere die syntaktische Prüfung und die Typprüfung. Zwar kann man dadurch nur relativ einfache Fehler finden (siehe Beispiele unten), aber da diese Prüfungen ohne zusätzlichen Aufwand automatisch passieren, sind sie trotzdem sehr nützlich. Die hier kurz beschriebenen Konzepte werden in den Veranstaltungen zur theoretischen Informatik (Grammatiken) und zum Compilerbau ausführlich behandelt.

=== Syntaktische Prüfung ===
Es wird eine Grammatik definiert, deren Regeln die Implementation des Algorithmus befolgen muss. Für ein Programm heißt das beispielsweise, dass die Syntax der Programmiersprache eingehalten werden muss.

Vorteile des Verfahrens: die Richtigkeit der Syntax lässt sich leicht vom Compiler/Interpreter überprüfen (mehr dazu in der Theoretischen Informatik und Compilerbau). Somit ist es die einfachste Möglichkeit, viele inkorrekte Programme schnell zu erkennen und zurückzuweisen.
>>> if a = 0: # sollte heissen: if a == 0:
File "<stdin>", line 1
if a = 0:
^
SyntaxError: invalid syntax

=== Typprüfung ===
Ein Typ definiert Gruppierung der Daten und die Operationen, die für diese Datengruppierung erlaubt sind (konkreter Typ) bzw. die Bedeutung der Daten und die erlaubten Operationen (abstrakter Datentyp, vgl. Dreieck aus der [[Einführung#Definition von Datenstrukturen|ersten Vorlesung]]). Typen sind Zusicherungen an den Algorithmus und den Compiler/Interpreter, dass Daten und deren Operationen bestimmte semantische Bedingungen einhalten. Wenn man innerhalb des Algorithmus mit Typen arbeitet, darf man von der semantischen Korrektheit der erlaubten Operationen ausgehen. Umgekehrt können Operationen, die zu Typkonflikten führen würden, leicht als inkorrekt zurückgewiesen werden.

Vorteile des Verfahrens: Typprüfung ist teuerer als syntaktische Prüfung, aber billiger als andere Prüfungen der Korrektheit (mehr dazu im Kapitel [[Generizität]]).
>>> a=3
>>> b=None
>>> a+b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

In python ist (ebenso wie in vielen anderen Programmiersprachen) explizite Typprüfung möglich:
>>> import types
>>> a=3
>>> b=None
>>> if isinstance(b, types.IntType): # prüft, ob b ein Integer ist
... print a+b
... else:
... raise TypeError, "b ist kein Integer" # falls b kein Integer ist, wird ein TypeError ausgelöst
...

Traceback (most recent call last):
File "<stdin>", line 4, in <module>
TypeError: b ist kein Integer

=== Prüfen der Vorbedingungen eines Algorithmus ===

Manche Programmiersprachen (z.B. [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel]) testen am Anfang jeder Funktion automatisch alle spezifizierten Vorbedingungen. Dies wird als ''[http://en.wikipedia.org/wiki/Design_by_contract Programming by Contract]'' bezeichnet. In Python hingegen muss man solche Prüfungen, mit Ausnahme der Typprüfungen (die man als Spezialfall der Vorbedingungen betrachten kann), selbst implementieren. Es steht aber mit den ''Exceptions'' ein leistungsfähiger Mechanismus zur Verfügung, um eventuelle Fehler in geordneter Weise zu signalisieren, siehe dazu [http://docs.python.org/tutorial/errors.html Kapitel 8 (Errors and Exceptions) der Pythondokumentation]. Beispielsweise darf die Quadratwurzel nicht für negative Zahlen aufgerufen werden. Man schreibt deshalb:
def sqrt(x):
if x < 0.0:
raise ValueError("sqrt() of negative number.")
Qualitativ hochwertige Software zeichnet sich unter anderem dadurch aus, dass das Programming by Contract konsequent umgesetzt ist, auch wenn die Programmiersprache dafür keine dedizierten Sprachkonstrukte bereitstellt.

== Formaler Korrektheitsbeweis ==

Korrektheitsbeweise können auf drei Arten geführt werden:
* In Algorithmenbüchern findet man typischerweise Beweise für die Korrektheit der grundlegenden Idee eines Algorithmus. Diese Beweise werden auf der Pseudocodeebene geführt, so dass bei der Implementation wieder Fehler unterlaufen können.
* Ein formaler Beweis der Korrektheit einer konkreten Implementation erfordert weit größeren Aufwand, sichert aber, dass der Code keine Fehler mehr enthalten kann.
* Werden im Algorithmus reelle Zahlen mit Hilfe von Gleitkommazahlen implementiert, ist der Algorithmus automatisch ein Approximationsalgorithmus, weil die Gleitkommazahlen nur eine Approximation der reellen Zahlen sind. In diesem Falle beweist man, dass der Approximationsfehler bestimmte Schranken nicht überschreitet. Dies ist eine wichtige Aufgabe der [http://de.wikipedia.org/wiki/Numerische_Mathematik Numerischen Mathematik] und wird hier nicht weiter vertieft.

=== Korrektheitsbeweis der Algorithmenidee ===

Hier ist die entscheidende Technik die Identifikation von ''Invarianten'', die (dank der Vorbedingungen) am Anfang und während der gesamten Ausführung des Algorithmus gelten. Kann man die Erhaltung der Invarianten nachweisen, folgen daraus die Nachbedingungen des Algorithmus und somit dessen Korrektheit. Die Identifikation geeigneter Invarianten ist häufig eine schwierige Aufgabe. Hat man einen Kandidaten gefunden, geht man zum Beweis ähnlich vor wie beim mathematischen Verfahren der vollständigen Induktion: Man beweist zunächst, dass die Invariante am Anfang gilt (''initialization''). Dann nimmt man an, dass die Invariante vor einem bestimmten Statement (z.B. vor der i-ten Iteration einer Schleife) gilt, und beweist, dass daraus die Gültigkeit am Ende des Statement (also nach der i-ten Iteration) folgt (''maintainance''). Kann man außerdem zeigen, dass der Algorithmus terminiert, folgt aus initialization und maintainance die Gültigkeit der Invariante am Ende des Algorithmus.

Wir wollen das Verfahren am Beispiel des '''Selection Sort'''-Algorithmus vorführen. Um den Beweis zu vereinfachen, definieren wir die folgenden Konventionen:
* Ein leeres Array <tt>[]</tt> ist sortiert.
* Das Minimum eines leeren Arrays ist <math>+\infty</math>, und das Maximum ist <math>-\infty</math>.

Der selection sort-Algorithmus hat zwei Invarianten:

* '''I1:''' Vor der i-ten Iteration der äußeren Schleife ist das linke Teilarray <tt>a[:i]</tt> sortiert.

* '''I2:''' Vor der i-ten Iteration der äußeren Schleife ist das Maximum des linken Teilarrays <tt>max(a[:i])</tt> kleiner oder gleich dem Minimum des rechten Teilarrays <tt>min(a[i:])</tt>.

Der Beweis der Initialisierung (Fall <tt>i==0</tt>) ist sehr einfach, weil das linke Teilarray zunächst leer und somit sortiert ist ('''I1'''). Außerdem ist sein Maximum <math>-\infty</math> and damit sicherlich kleiner als jedes Element im Array ('''I2''').

Wir nehmen nun an, dass die Invarianten für ein gewisses <tt>i</tt> gelten und beweisen, dass sie dann auch für <tt>i+1</tt> gelten. Das heißt, wir nehmen an, dass <tt>a[:i]</tt> sortiert ist ('''I1'''), und dass <tt>max(a[:i]) ≤ min(a[i:])</tt> ('''I2'''). Da das Element <tt>a[i]</tt> zum rechten Teilarray gehört, gilt insbesondere auch <tt>max(a[:i]) ≤ a[i]</tt>, und daraus folgt sofort, dass das um ein Element vergrößerte linke Teilarray <tt>a[:i+1]</tt> ebenfalls sortiert ist ('''I1'''), unabhängig davon, welches Element sich an Position <tt>i</tt> befindet. Um aber auch die zweite Invariante zu erfüllen, müssen wir zusätzlich sicherstellen, dass <tt>a[i] ≤ min(a[i:])</tt> gilt, dass sich also ein minimales Element des rechten Teilarrays an Position <tt>i</tt> befindet. Entfernt man nämlich das minimale Element aus einer Menge, wird das neue Minimum der verkleinerten Menge sicherlich nicht kleiner sein als das alte. Die innere Schleife sucht nun gerade das Minimum und verschiebt es an Position <tt>i</tt>. Nach dem Swap gilt somit: <tt> max(a[:i]) ≤ a[i] = min(a[i:]) ≤ min(a[i+1:])</tt> und damit auch <tt>max(a[:i+1]) = a[i] ≤ min(a[i+1:])</tt> ('''I2'''). Außerdem ist klar, dass der Algorithmus terminiert, weil jede Schleife nur endlich viele Schritte ausführt (Iteration bis <tt>len(a)</tt>). Durch Induktion auf den Fall <tt>i == len(a)</tt> folgt aus Invariante '''I1''', dass das Teilarray <tt>a[:len(a)]</tt> sortiert ist. Dies ist aber gerade das gesamte Array, was zu beweisen war.

Zehlreiche Beweise nach diesem Muster findet man z.B. bei Cormen et al.

=== Formales Beweisen der Implementation ===
Man versucht, die Hypothese H: ''die Implementation ist korrekt'' entweder mathematisch zu beweisen oder zu widerlegen. Dieses Beweisverfahren heißt automatisch, wenn es allein von einem Computer durchgeführt wird, und halbautomatisch, wenn der Mensch in den Entscheidungsprozess miteinbezogen ist. Allerdings sind solche Beweise sehr aufwändig und werden daher nur für sicherheitskritische Software verwendet, z.B. für
* die automatische Steuerung der fahrerlosen U-Bahnlinie 14 in Paris (vgl. Lecomte et al.: ''[http://rodin.cs.ncl.ac.uk/Publications/fm_sc_rs_v2.pdf Formal Methods in Safety-Critical Railway Systems]'' and Su et al.: ''[http://deploy-eprints.ecs.soton.ac.uk/316/1/Modes_version_55.pdf From Requirements to Development: Methodology and Example]'' - die Autoren der Steuersoftware versichern, dass in 10 Jahren Betrieb der U-Bahn kein Softwarefehler aufgetreten ist),
* die Sicherheitsmerkmale von [http://en.wikipedia.org/wiki/Smart_card Chipkarten] und
* das Flugzeugbetriebssystem [http://en.wikipedia.org/wiki/INTEGRITY-178B INTEGRITY 178B], das z.B. im Airbus A380 und in der Boeing 787 eingesetzt wird.

Um den Beweis durchführen zu können, ist folgendes nötig:
;eine [http://en.wikipedia.org/wiki/Formal_specification formale Spezifikation] des Algorithmus: eine formale Spezifikation wird in einer [http://en.wikipedia.org/wiki/Specification_language Spezifikationssprache] geschrieben (z.B. der [http://en.wikipedia.org/wiki/B-Method B-Methode] oder der [http://en.wikipedia.org/wiki/Z_notation Z-Notation]). Sie ist
:* deklarativ (d.h. beschreibt, was das Programm tun soll, ist selbst aber nicht ausführbar)
:* formal präzise (kann nur auf eine einzige Weise interpretiert werden)
:* hierarchisch aufgebaut (eine Spezifikation für einen komplizierten Algorithmus greift auf Spezifikationen für einfache Bestandteile dieses Algorithmus zurück)
:* so einfach, dass ihre Korrektheit für einen Menschen mit entsprechender Erfahrung unmittelbar einsichtig ist (denn eine Spezifikation kann nicht formal bewiesen werden - dafür wäre eine weitere Spezifikation nötig, die auch bewiesen werden müsste usw.)
;ein axiomatisiertes Programmiermodell: zum Beispiel
:* eine axiomatisierbare Programmiersprache, wie z.B. WHILE-Programm (s. [[Einführung#Zur Frage der elementaren Schritte|erste Vorlesung]]), Pascal (siehe dazu Hoare's [http://delivery.acm.org/10.1145/70000/63445/cb-p153-hoare.pdf?key1=63445&key2=5041959021&coll=ACM&dl=ACM&CFID=15151515&CFTOKEN=6184618 grundlegenden Artikel]) und rein funktionale Programmiersprachen
:* ein axiomatisierbares Subset einer Programmiersprache (die meisten Programmiersprachen sind zu komplex, um als Ganzes axiomatisierbar zu sein)
:* endliche Automaten

Der Korrektheitsbeweis kann beispielsweise mit dem Hoare-Kalkül (Hoare-Logik) durchgeführt werden (Hoare erfand u.a. den Quicksort-Algorithmus). Diese Methode wurde in
: C.A.R. Hoare: ''"An Axiomatic Basis for Computer Programming"'', Communications of the ACM, 1969 [http://www.cs.ucsb.edu/~kemm/courses/cs266/hoare69.pdf]
erstmalig beschrieben. Im folgenden wird das Verfahren an einem Beispiel erläutert.

==== Beispiel-Algorithmus ====
Zuerst brauchen wir einen Algorithmus, den wir auf Korrektheit prüfen wollen. Wir nehmen als Beispiel die Division x/y durch sukzessives Subtrahieren.

Vorbedingungen:
int x,y
0 < y <= x
Gesucht:
Quotient q, Rest r
Algorithmus:
r = x
q = 0
while y <= r:
r = r - y
q = q + 1
Nachbedingungen:
x == r + y*q and r < y

==== Aufbau der Hoare-Logik ====

Grundlegende syntaktische Struktur:
: p {Q} r
mit '''p''':Vorbedingung, '''Q''': Operation, '''r''': Nachbedingung.
Es bedeutet also schlicht: wenn man im Zustand '''p''' ist und eine Operation '''Q''' ausführt, kommt man in den Zustand '''r'''. Hat eine Operation keine Vorbedingung, schreibt man
: true {Q} r

Die Hoare-Logik besteht aus 5 Axiomen:
;D0 - Axiom der Zuweisung: (Rule of Assignment)
:: R[t] {x=t} R[x]

: '''Beispiel:''' t==5 {x=t} x==5

:Vorbedingung und Nachbedingung sind gleich, mit Ausnahme der Variablen x und t, die in der Zuweisung verknüpft werden: Man erhält die Vorbedingung, wenn man in der Nachbedingung alle Vorkommen von x (bzw. allgemein: alle Vorkommen der linken Variable der Zuweisung) durch t (bzw. allgemein: durch die rechte Variable der Zuweisung) ersetzt.

;D1 - Konsequenzregeln: (Rules of Consequence, besteht aus zwei Axiomen)
:'''D1(a):''' wenn gilt
:: P {Q} R und R ⇒ S
:dann gilt auch
:: P {Q} S
:'''D1(b):''' wenn gilt
:: P {Q} R und S ⇒ P
:dann gilt auch
:: S {Q} R
:'''Beispiel:''' Für jede ganze Zahl gilt (x>5) ⇒ (x>0). Gilt außerdem (x>5) dann gilt erst recht (x>0).

;D2 - Sequenzregel: (Rule of Composition)
:wenn gilt
:: P {Q1} R1 und R1 {Q2} R
:dann gilt auch
:: P {Q1, Q2} R
:Das heißt: wenn man P hat und Q1 darauf anwendet, kommt man zu R1. Wenn man R1 hat und Q2 darauf anwendet, kommt man zu R. Deshalb kann man das so verkürzen: wenn man P hat und nacheinander Q1 und Q2 darauf anwendet, kommt man zu R.

;D3 - Iterationsregel: (Rule of Iteration)
:wenn gilt
:: (P &and; B) {S} P
:dann gilt auch
:: P { while B do S } (¬B &and; P)
:P wird dabei als '''Schleifeninvariante''' bezeichnet, weil es sowohl in der Vor- als auch in der Nachbedingung gilt. B ist die '''Schleifenbedingung''' - solange B erfüllt ist, wird die Schleife weiter ausgeführt.

Da wir in dem Divisions-Algorithmus mit dem Typ '''int''' arbeiten, brauchen wir außerdem die für diesen Typ erlaubten Operationen, also die Axiome der ganzen Zahlen.
: '''A1:''' Kommutativität x+y=y+x, x*y=y*x
: '''A2:''' Assoziativität (x+y)+z=x+(y+z), (x*y)*z=x*(y*z)
: '''A3:''' Distributivität x*(y+z)=x*y+x*z
: '''A4:''' Subtraktion (Inverses Element) y≤x ⇒ (x-y)+y=x
: '''A5:''' Neutrale Elemente x+0=x, x*0=0, x*1=x

==== Beweisen des Algorithmus ====
Vorbedingung: 0 < y,x

Schleifeninvariante P (gleichzeitig Nachbedingung): x == y*q + r
(1) true ⇒ x==x+y*0 y*0==0 und x==x+0 folgen aus A5
(2) x==x+y*0 {r=x} x==r+y*0 D0: ersetze x durch r
(3) x==r+y*0 {q=0} x==r+y*q D0: ersetze 0 durch q
(4) true {r=x} x==r+y*0 D1(b): kombiniere (1) und (2)
(5) true {r=x, q=0} x==r+y*q D2: kombiniere (4) und (3)
(6) x==r+y*q &and; y=r ⇒ x==(r-y)+y*(1+q) folgt aus A1...A5
(7) x==(r-y)+y*(1+q) {r=r-y} x==r+y*(1+q) D0: ersetze (r-y) durch r
(8) x==r+y*(1+q) {q=q+1} x==r+y*q D0: ersetze (q+1) durch q
(9) x==(r-y)+y*(1+q) {r=r-y, q=q+1} x==r+y*q D2: kombiniere (7) und (8)
(10) x==r+y*q &and; y≤r {r=r-y, q=q+1} x==r+y*q D1(b): kombiniere (6) und (9)
(11) x==r+y*q {while y≤r do (r=r-y, q=q+1)} x==r+y*q &and; ¬(y≤r) D3: transformiere (10)
(12) true {r=x, q=0,
while y≤r do (r=r-y, q=q+1)} x==r+y*q &and; ¬(y≤r) D2: kombiniere (5) und (11)

Im obigen Beweis ergibt sich sogar ''true'' als Vorbedingung (i.e. es gibt keine Vorbedingung). Dies liegt daran, dass Hoare in seinem Artikel durchweg von nicht-negativen Zahlen ausgeht. Diese Annahme wird beim Beweis von Zeile (6) benutzt.

In der Praxis führt man solche Beweise natürlich nicht von Hand, sondern benutzt geeignete Programme, sogenannte [http://en.wikipedia.org/wiki/Automated_theorem_proving automatische Beweiser], die man allerding oft interaktiv steuern muss, weil der Beweis ohne diese Hilfe zu lange dauern würde.

=== (Halb-)Automatisches Verfeinern ===
Dieses Verfahren ist beliebter, als das (halb-)automatische Beweisen. Die formale Spezifikation wird nach bestimmten, semantik-erhaltenden Transformationsregeln in ein ausführbares Programm umgewandelt. Mehr dazu z.B. in der [http://en.wikipedia.org/wiki/Program_refinement Wikipedia (Program refinement)]. Der Vorteil dieser Methode besteht darin, dass man die Transformationsregeln so definieren kann, dass nur das axiomatisierte Subset der Zielsprache benutzt wird. Dadurch wird der Korrektheitsbeweis stark vereinfacht.

==Software-Tests==

Dijkstra [http://de.wikipedia.org/wiki/Edsger_Wybe_Dijkstra] ließ einmal den Satz verlauten: "Tests können nie die Abwesenheit von Fehlern beweisen [Anwesenheit schon]"

Nach solch einer Aussage stellt sich die Frage, ob es sich überhaupt lohnt, mit dem Testverfahren die Korrektheit eines Algorithmus zu zeigen. Es erscheint einem doch plausibler sich auf die "formalen Methoden" zu berufen, mit dem Wissen, dass diese uns tatsächlich einen Beweis liefern können, ob nun H oder nicht H gilt. Zudem kommt noch erschwerend hinzu, dass es bei Tests bisher keine Theorie gibt, die sicherstellt, dass das Testprogramm einen vorhandenen Fehler zumindest mit hoher Wahrscheinlichkeit findet.

Ein [http://de.wikipedia.org/wiki/Softwaretest Software-Test] versucht, ein Gegenbeispiel zur Hypothese H "der Algorithmus ist korrekt" zu finden. Dabei gibt es 4 Möglichkeiten:

Algorithmus Testantwort
+ + Algorithmus ist richtig, kein Gegenbeispiel gefunden
- - Alg. ist falsch, und der Test erkennt den Fehler
+ - Bug im Test (Gegenbeispiel, obwohl Alg. richtig ist)
- + Test hat versagt, da er den Fehler im Alg. nicht erkannt hat

Wenn ein Gegenbeispiel zu H gefunden wird, kann man den Algorithmus (oder den Test) debuggen. Wird hingegen keines gefunden, nimmt man an, dass der Algorithmus korrekt ist. Man sieht, dass diese Annahme im Fall 4 nicht stimmt. Da Softwaretests jedoch in der Praxis sehr erfolgreich verwendet werden, ist dieser Fall offenbar nicht so häufig, dass man das Testen als Methode generell ablehnen müßte.

=== Beispiel für das Testen: Freivalds Algorithmus ===

Wir wollen die Wahrscheinlichkeit, dass ein Test einen vorhandenen Fehler übersieht, am Beispiel des [http://en.wikipedia.org/wiki/Freivald's_algorithm Algorithmus von Freivald] studieren. Es handelt sich dabei um einen randomisierten Algorithmus zum Testen der Matrixmultiplikation (siehe J. Hromkovič: ''"Randomisierte Algorithmen"'', Teubner 2004). Ziel dieses Algorithmuses ist es, die Hypothese H: "C ist das Produkt der Matrizen A und B" durch ein Gegenbeispiel zu widerlegen, wobei der Test einen anderen Algorithmus verwendet, um Vergleichsdaten zu gewinnen.

gegeben:
Matrizen A, B, C der Größe NxN
Testhypothese H: <tt>A*B == C</tt> Matrixmultiplikation (d.h. C wurde vorher durch C = mmul(A, B) berechnet,
wobei mmul() der zu testende Multiplikationsalgorithmus ist).

(1) Initialisierung
wähle Zufallsvektor der Länge N aus Nullen und Einsen: <math>\alpha \in \{0, 1\}^N </math>
(2) Matrix-Vektor-Multiplikation (keine Matrix-Matrix-Multiplikation, denn die soll ja gerade verifiziert werden)

<math>\left.\begin{array}{l}
\beta = B*\alpha \\
\gamma=A*\beta
\end{array}\right\}A*(B*\alpha) == (A*B)*\alpha
</math>

<math>\delta=C*\alpha</math>

(3) Test der Korrektheit: falls <tt>A*B == C</tt>, liefert der folgende Test stets <tt>true</tt>:

return γ==δ

Wir analysieren nun, mit welcher Wahrscheinlichkeit der Algorithmus den Fehler findet, wenn es denn einen gibt, d.h.

*Wahrscheinlichkeit '''p''', dass Freivalds Algorithmus den Fehler findet 
oder 
*Wahrscheinlichkeit '''q = 1 - p''', dass Freivalds Algorithmus den Fehler '''nicht''' findet.

Wir schätzen diese Wahrscheinlichkeit ab für den einfachen Fall N=2. Wir definieren:

<math>C=
\begin{pmatrix}
c_{11} & c_{12} \\
c_{21} & c_{22}
\end{pmatrix},\qquad
\alpha=\begin{pmatrix}
\alpha_1 \\
\alpha_2
\end{pmatrix},\qquad
\delta=\begin{pmatrix}
\delta_1 \\
\delta_2
\end{pmatrix}
= \begin{pmatrix}
c_{11}\alpha_1 + c_{12}\alpha_2 \\
c_{21}\alpha_1 + c_{22}\alpha_2
\end{pmatrix}</math>

'''Fallunterscheidung:'''

'''Fall 1:''' C enthält genau 1 Fehler, z.B. <math>c_{11}</math> hat falschen Wert

:Der Fehler wird gefunden, wenn <math>\delta_1 \ne \gamma_1 \Leftrightarrow\alpha_1\ne 0</math>. Da <math>\alpha_1</math> eine Zufallszahl aus <math>\{0,1\}</math> ist, folgt daraus, dass '''p''' = '''q''' = <math>\frac{1}{2}</math>

'''Fall 2:''' C enthält 2 Fehler
:(a) in verschiedenen Zeilen und Spalten, z.B. <math>c_{11}</math> und <math>c_{22}</math>. Es gilt: Der Fehler in <math>c_{11}</math> wird gefunden, wenn <math>\delta_1 \ne \gamma_1 \Leftrightarrow \alpha_1\ne 0</math>. Unabhängig davon wird der Fehler in <math>c_{22}</math> gefunden, wenn <math>\delta_2 \ne \gamma_2 \Leftrightarrow \alpha_2\ne 0</math>. Da <math>\alpha_1</math> und <math>\alpha_2</math> statistisch unabhängig sind, ist die Wahrscheinlichkeit für jedes dieser Ereignisse <math>q_1</math> bzw. <math>q_2</math> jeweils <math>\frac{1}{2}</math>, und die Gesamtwahrscheinlichkeit '''q''', dass ''keiner'' der beiden Fehler gefunden wird, ist deren Produkt: '''q''' = <math>q_1*q_2 = \frac{1}{2}* \frac{1}{2} = \frac{1}{4}</math>.

:(b) in verschiedenen Zeilen, gleichen Spalten, z.B. <math>c_{11}</math> und <math>c_{21}</math>. Es gilt: Der Fehler in <math>c_{11}</math> wird gefunden, wenn <math>\delta_1 \ne \gamma_1 \Leftrightarrow \alpha_1\ne 0</math>. Das gleiche gilt für den Fehler in <math>c_{21}</math>. Die Wahrscheinlichkeit '''q''', dass ''keiner'' der beiden Fehler gefunden wird, ist demzufolge: '''q''' = <math>\frac{1}{2}</math>.

:(c) in der gleichen Zeile, z.B. <math>c_{11}</math> und <math>c_{12}</math>. Es gilt: Der Fehler wird gefunden, wenn <math>\delta_1 \ne \gamma_1 \Leftrightarrow \alpha_1*c_{11}+\alpha_2*c_{12}\ne 0</math>. Hier treten nun zwei ungünstige Fälle auf:
::1) Der Fehler wird u.a. dann nicht gefunden, wenn <math>\alpha_1 = \alpha_2=0</math>. Die Wahrscheinlichkeit dafür ist wieder '''q'''=<math>\frac{1}{4}</math>
::2) <math>\alpha_1=\alpha_2=1</math> (dies geschieht ebenfalls mit Wahrscheinlichkeit <math>\frac{1}{4}</math>), aber die Werte <math>c_{11}</math> und <math>c_{12}</math> sind "zufälligerweise" so falsch, dass sich die Fehler gegenseitig aufheben. Die Wahrscheinlichkeit, dass beide Bedingungen gelten, ist auf jeden Fall '''q''' = <math>\epsilon<\frac{1}{4}</math>.

Analog behandelt man die Fälle, dass C drei oder vier Fehler enthält. Fasst man die Fälle zusammen, ergibt sich, dass die Wahrscheinlichkeit, einen vorhandenen Fehler '''nicht''' zu entdecken, sicher kleiner als <math>\frac{1}{2}</math> ist. Dies gilt auch allgemein:

;Satz:
*Die Wahrscheinlichkeit, dass Freivalds Algorithmus einen vorhandenen Fehler '''nicht''' findet, ist '''q''' < <math>\frac{1}{2}</math>. Wir haben diesen Satz oben für N=2 bewiesen, ein vollständiger Beweis findet sich in der [http://en.wikipedia.org/wiki/Freivald's_algorithm#Error_Analysis Wikipedia].

;Folgerung:
*Lässt man Freivalds Algorithmus mit verschiedenen <math>\alpha</math> k-mal laufen, gilt <math>q_k < 2^{-k}</math> für die Wahrscheinlichkeit, dass '''keiner''' der k Durchläufe einen vorhandenen Fehler findet. Diese Wahrscheinlichkeit konvergiert sehr schnell gegen 0. Das heißt, der Algorithmus findet mit beliebig hoher Wahrscheinlichkeit ein Gegenbeispiel zu H (falls es eins gibt), wenn man ihn nur genügend oft mit jeweils anderen Zufallszahlen wiederholt. Daraus folgt, dass Testen ein effektives Fehlersuchverfahren sein kann -- die oben erwähnte Einschränkung von Dijktra trifft zwar zu, aber Tests, die mit so hoher Wahrscheinlichkeit funktionieren, sind für die Praxis meistens vollkommen ausreichend.

=== Vergleich formaler Korrektheitsbeweis und Testen ===

Nachdem nun die formalen Methoden sowie der Software-Test vorgestellt worden sind, ist nun die Frage aufzugreifen, welcher der beiden Vorgänge der bessere ist. Allgemein gilt:

;randomisierte Algorithmen

*sind schnell und einfach:
#da die Operationen einfach sind und wenig Zeit kosten
#des öfteren eine Auswahl vorgenommen wird ohne die Gesamtmenge näher zu betrachten
#die Auswahl selbst aufgrund einfacher Kriterien (bspw. zufällige Auswahl) erfolgt
*können Lösungen approximieren und liefern gute approximative Lösungen

;formaler Korrektheitsbeweis mit deterministischen Algorithmen (siehe auch [http://de.wikipedia.org/wiki/Determinismus_(Algorithmus)])

*bei jedem Aufruf des Beweisers werden immer die selben Schritte durchlaufen
*keine Zufallswerte
*komplexer Aufbau
*oft sehr lange Laufzeit, z.B. mehrere Tage oder gar Monate

Für die formalen Methoden spricht, dass man mit ihnen im Prinzip beweisen kann, dass H nun entweder tatsächlich falsch oder richtig ist. Die formalen Beweise bei realen Problemen sind allerdings so kompliziert, dass sie ebenfalls mit Computerhilfe erbracht werden müssen. Dadurch liegt auch hier keine 100%-ige Korrektheitsgarantie vor: Auch formale Methoden können zum falschen Ergebnis kommen, z.B. durch Hardwarefehler, Compilerbugs, oder unvorhergesehenes Umkippen von Bits (z.B. durch kosmische Strahlung -- diese Gefahr ist im Weltall sehr ernst zu nehmen). Die Möglichkeit von Hardwarefehlern wirkt sich auf die formalen Methoden wesentlich stärker aus, weil diese typischerweise wesentlich längere Laufzeiten haben als entsprechende Testalgorithmen. Es kann deshalb durchaus vorkommen, dass Tests eine höhere Erfolgswahrscheinlichkeit haben als ein formaler Beweis, wie die folgende Beispielrechnung zeigt. Wir nehmen an, dass die Hardware eine "Halbwertszeit" von 50 Millionen Sekunden hat, d.h. ein Hardwarefehler tritt im Durchschnitt etwa alle 20 Monate auf. Dann ist die Wahrscheinlichkeit, dass ein deterministischer Algorithmus '''nicht''' zum Ergebnis (oder zum falschen Ergebnis) kommt:

* <math>q_{\mathrm{Beweis}} \approx 0.001</math>, falls der Beweisalgorithmus 1 Tag benötigt,
* <math>q_{\mathrm{Beweis}} \approx 0.01</math>, falls der Beweisalgorithmus 1 Woche benötigt,
* <math>q_{\mathrm{Beweis}} \approx 0.035</math>, falls der Beweisalgorithmus 1 Monat benötigt.

Zum Vergleich nehmen wir an, dass der entsprechende Softwaretest einmal pro Sekunde ausgeführt werden kann, und dass jeder Durchlauf den Fehler mit einer Wahrscheinlichkeit von <math>\frac{1}{2}</math> '''nicht''' findet. Unter gleichzeitiger Berücksichtigung der Wahrscheinlichkeit von Hardwarefehlern gilt dann

* <math>q_{\mathrm{Test}} \approx 0.5</math>, falls der Test 1-mal wiederholt wird,
* <math>q_{\mathrm{Test}} \approx 0.001</math>, falls der Test 10-mal wiederholt wird,
* <math>q_{\mathrm{Test}} \approx 10^{-6}</math>, falls der Test 100-mal wiederholt wird.

Mit anderen Worten: hier ist das Testen vorzuziehen, weil es unter realistischen Bedingungen eine höhere Erfolgswahrscheinlichkeit hat als der formale Beweis. Leider gibt es bisher keine Theorie, mit deren Hilfe man für ein gegebenes Problem systematisch Tests konstruieren kann, deren Misserfolgswahrscheinlichkeit bei wiederholter Anwendung garantiert so schnell gegen Null konvergiert wie die des Freivalds Algorithmus. Dies ist ein offenes Problem der Informatik.

==Anwendung des Softwaretestverfahren==
===Beispiel an Python-Code===

Man betrachte die Aufgabe, aus einer Zahl x die Wurzel zu ziehen. Dies kann man erreichen, indem man mit Hilfe des Newtonschen Iterationsverfahrens eine Nullstelle des Polynoms
:<math>f(y) = x - y^2 = 0</math>
sucht. Ist eine Näherungslösung <math>y^{(t)}</math> bekannt, erhält man eine bessere Näherung durch
:<math>y^{(t+1)} = y^{(t)} - \frac{f(y^{(t)})}{f'(y^{(t)})}</math>.
Mit <math>f\,'(y) = -2y</math> wird das zu
:<math>y^{(t+1)} = y^{(t)} + \frac{x-(y^{(t)})^2}{2y^{(t)}}=\frac{y^{(t)}+x/y^{(t)}}{2}</math>.
Im Spezialfall des Wurzelziehens war diese Newton-Iteration übrigens bereits im Altertum als [http://en.wikipedia.org/wiki/Babylonian_method#Babylonian_method Babylonische Methode] bekannt. Man kann dieselbe durch das folgende (allerdings noch nicht korrekte) Pythonprogramm realisieren:

1 def sqrt(x):
2 if (x<0):
3 raise ValueError("sqrt of negative number")
4 y = x / 2
5 while y*y != x:
6 y =(y + x/y) / 2
7 return y:

Für den oben aufgeführten Pythoncode können Tests mit Hilfe des Python-Moduls "[http://docs.python.org/library/unittest.html unittest]" geschrieben werden (siehe auch Übungsaufgaben). Wir erklären hier die wichtigsten Befehle aus diesem Modul. Wir implementieren eine Testfunktionen (diese muss, wie im Python-Handbuch beschrieben, Methode einer Testklasse sein).

class SqrtTest(unittest.TestCase):
def testsqrt(self):
...

Zunächst muss man prüfen, ob die Vorbedingung korrekt getestet wird, d.h. ob bei einer negativen Zahl x eine Exception ausgelöst wird; dafür benötigt man

self.assertRaises(ValueError, sqrt, -1)
Sollte keine Exception vom Type <tt>ValueError</tt> ausgelöst werden, dann würde der Test hier einen Fehler signalisieren. Dieser Test funktioniert aber.

Weiter testen wir einige Beispiele, deren Wurzel wir kennen:

self.assertEqual(sqrt(9),3)
Wäre hier das Ergebnis ungleich 3, würde ebenfalls ein Fehler signalisiert, aber es funktioniert in unserem Falle. Der Test

self.assertEqual(sqrt(1),1)
schlägt jedoch mit <tt>ZeroDivisionError</tt> fehl! Wir sehen, dass in Zeile 4 eine Ganzzahldivision durchgeführt wird, deren Ergebnis stets abgerundet wird, was hier zu <tt>y = 0</tt> und damit zum Fehler in Zeile 6 führt. Wieso hat dann aber der erste Test <tt>sqrt(9) == 3</tt> funktioniert? Hier gilt <tt>x / 2 == 4</tt> und <tt>x / y == 2</tt> (jeweils nach Abrunden), und der Mittelwert der beiden Schätzungen ist gerade <tt>y == 3</tt>, also zufällig das richtige Ergebnis. Allgemein sehen wir jedoch, dass es nicht korrekt ist, mit ganzen Zahlen zu rechnen. Wir müssen also den Input zunächst in einen Gleitkommawert umwandeln:

1 def sqrt(x):
1a x = float(x)
2 if (x<0):
3 raise ValueError("sqrt of negative number")
4 y = x / 2
5 while y*y != x:
6 y =(y + x/y) / 2
7 return y:

Jetzt funktionieren die vorhandenen Tests, aber bei anderen Zahlen (z.B. <tt>x = 1.21</tt>) läuft das Programm in eine Endlosschleife. Dies liegt daran, dass durch die beschränkte Genauigkeit der Gleitkomma-Darstellung selten exakte Gleichheit in der <tt>while</tt>-Bedingung erreicht wird. Man darf nicht auf Gleichheit prüfen, sondern muss den relativen Fehler beschränken:

1 def sqrt(x):
1a x = float(x)
2 if (x<0):
3 raise ValueError("sqrt of negative number")
4 y = x / 2
5 while abs(1.0 - x / y**2) > 1e-15: # check for relative difference
6 y =(y + x/y) / 2
7 return y:

Jetzt terminiert das Programm, aber der Test

self.assertEqual(sqrt(1.21)**2, 1.21) # schlägt fehl

schlägt wegen der beschränkten Genauigkeit der Gleitkommadarstellung fehl. Man umgeht dieses Problem, indem man im Test selbst nur näherungsweise Gleichheit fordert, z.B. auf 15 Dezimalstellen genau (bei 16 Dezimalen würde es nicht mehr funktionieren):

self.assertAlmostEqual(sqrt(1.21)**2, 1.21, 15)

Wenden wir jetzt das ''Prinzip der Condition Coverage'' an (siehe unten), sehen wir, dass die <tt>while</tt>-Bedingung bei allen bisherigen Tests zunächst mindestens einmal <tt>true</tt> gewesen ist. Ein weiterer sinnvoller Tests ist deshalb einer, der diese Bedingung sofort <tt>false</tt> macht. Dies trifft z.B. bei <tt>x == 4</tt> zu, weil <tt>y = x / 2</tt> hier gerade die korrekte Wurzel liefert. Wir fügen deshalb den Test

self.assertEqual(sqrt(4), 2)

hinzu, der erfolgreich verläuft. Das ''Prinzip der Domänen-Zerlegung'' (siehe unten) führt uns weiter dazu, die Wurzel aus Null als sinnvollen Test zu betrachten, weil die Null am Rand des erlaubten Wertebereichs liegt. Der Test

self.assertEqual(sqrt(0), 0) # schlägt fehl

schlägt in der Tat mit einem <tt>ZeroDivisionError</tt> fehl: In der Abfrage der <tt>while</tt>-Bedingung wird jetzt durch <tt>y == 0</tt> geteilt. Wir können diesen Fehler beheben, indem wir die Division aus der Bedingung eliminieren:

1 def sqrt(x):
1a x = float(x)
2 if (x<0):
3 raise ValueError("sqrt of negative number")
4 y = x / 2
5 while abs(y**2 - x) > 1e-15*x: # check for relative difference without division
6 y =(y + x/y) / 2
7 return y:

Damit ist auch dieses Problem behoben. Wir sehen also, wie das systematische Testen uns dabei hilft, Fehler im Programm zu finden und zu eliminieren. Eine ausführbare Version dieses Beispiels finden Sie im File [http://hci.iwr.uni-heidelberg.de/Staff/ukoethe/lehre/Algorithmen2012/SquareRootDebugging.py SquareRootDebugging.py].

===Definition guter Tests===

Wir haben gezeigt, dass Testen eine effektive Methode ist, um Fehler in Algorithmen zu finden. Allerdings gilt das nur, wenn Tests und Testdaten geschickt gewählt werden. Wir zeigen bewährte Methoden dafür.

====Häufige Fehler====

Einige Fehlerklassen treten sehr häufig auf und sollten deshalb beim Testen besondere Aufmerksamkeit genießen:
; [http://en.wikipedia.org/wiki/Off-by-one_error Off-by-One] : Dieser Fehler bezeichnet den Fall, dass eine Berechnung oder Bedingung um Eins neben dem korrekten Wert liegt. Dies passiert besonders bei Schleifenindizes. Man schreibt beispielsweise <tt>if i < j:</tt> wenn <tt>if i <= j:</tt> richtig gewesen wäre, oder <tt>a[i] = a[i+1]</tt> wenn <tt>a[i-1] = a[i]</tt> gemeint war. Die beste Methode um solche Fehler zu finden ist das manuelle Nachvollziehen des Algorithmus auf Papier für kleine Eingaben. Wenn die Schleife, die den Fehler enthält, beispielsweise nur bis zum Index 3 geht, erkennt man den off-by-one-Error meistens sofort, weil offensichtlich auf das falsche Element zugegriffen oder die Schleife zu früh abgebrochen wird.
; Integer-Überlauf : In vielen Sprachen (z.B. C und C++) sind die Integer-Datentypen so definiert, dass die Berechnung auf die kleinstmöglichen Zahl zurückspringt, wenn man zur größtmöglichen Zahl eins addiert (zyklisches Verhalten). Im Falle eines 8-bit Intergertyps gilt z.B.
uint8 i = 255; // größtmögliche 8-bit Zahl
i += 1;
assert(i == 0); // zyklisches Verhalten
:und entsprechend:
uint8 i = 0;
i -= 1;
assert(i == 255);
:Solche Fehler äußern sich typischerweise, wenn man versucht, viele kleine Zahlen zu addieren. Dieses Problem kann allerdings in Python nicht auftreten, weil Python automatisch zum Type <tt>long</tt> (für beliebig große Zahlen) wechselt, wenn die Werte zu groß werden.
; Float-Überlauf : Ein ähnlicher Fehler kann auch bei Gleitkommazahlen auftreten, wenn man zur größten exakt darstellbaren ganzen Zahl eins addiert. Die Grenze hängt hier von der Länge der Mantisse ab. Für 32-bit Gleitkommazahlen (23 bit Mantisse) gilt beispielsweise:
float32 f = pow(2.0, 24); // dies ist die größte ganze Zahl, die float32 exakt darstellen kann
f += 1.0;
assert(f == pow(2.0, 24));
:Im Unterschied zum Integerverhalten hat die Addition hier gar keinen Effekt. Bei 64-bit Gleitkommazahlen tritt der Fehler entsprechend bei <tt>pow(2.0, 53)</tt> auf.
; [http://en.wikipedia.org/wiki/Loss_of_significance Loss-of-Precision] : Dieser Fehler besagt, dass Gleitkommazahlen unter bestimmten Bedingungen ihre Genauigkeit verlieren und dann ungenaue oder sogar unsinnige Ergenisse herauskommen. Dies passiert beispielsweise, wenn man fast gleich große Zahlen voneinander subtrahiert. Dann sind die höherwertigen Bits der Eingaben gleich und löschen sich bei der Subtraktion aus, so dass das Ergebnis nur noch sehr wenige gültige Bits hat und somit sehr ungenau ist. Bei 6-stelliger Dezimaldarstellung wäre z.B. <tt>100.003 - 100.002 = 0.001</tt>, und das Ergebnis hat nur noch eine gültige Dezimalstelle. Dies ist ungünstig, weil die Eingaben ja nur gerundete Darstellungen der wahren Werte sind. Mit 12-stelliger Arithmetik hätte man vielleicht die Zahlen <tt>100.002634611 - 100.002456354 = 0.000178257</tt> erhalten, und das ursprüngliche Resultat <tt>0.001</tt> ist mehr als 5-mal zu groß. In der Praxis beobachtet man dieses Problem z.B. beim Lösen von quadratischen Gleichungen. 
:Ein verwandtes Problem tritt auf, wenn das exakte Ergebniss gleich Null sein sollte. Durch die begrenzte Genauigkeit der Gleitkommaoperationen kommen dann häufig von Null verschiedene kleine Zahlen heraus. Beispielsweise erhält man unter Python <tt>sin(pi) = 1.2246467991473532e-16</tt>, obwohl das Ergebnis Null sein sollte. Daraus folgt, dass man Gleitkommazahlen nicht zuverlässig auf Gleichheit testen kann, weil der Test <tt>f1 == f2</tt> equivalent zum Test <tt>(f1 - f2) == 0.0</tt> ist und meistens fehlschlägt, auch wenn die Zahlen theoretisch gleich sein müssten. 
:Man vermeidet derartige Probleme durch geschicktes algebraisches Umformen der Formeln und durch das Einbauen geeigneter Fehlertoleranzen (z.B. testet man statt auf Gleichheit auf den Ausdruck <tt>abs(f1 -f2) <= 3e-16</tt>, siehe das Beispiel zum <tt>sqrt()</tt>-Algorithmus oben).
; Randwertfehler : Wenn ein Algorithmus verschiedene Eingabedomänen hat, für die er sich prinzipiell anders verhält (der Algorithmus für die Quadratwurzel berechnet z.B. das Ergebnis für nicht-negative Eingaben, aber signalisiert einen Fehler für negative Eingaben), dann treten Bugs besonders gern an der Domänengrenze auf. Bei der Wurzel wäre das der Randwert 0, das heisst <tt>sqrt(0)</tt> verhält sich anders als erwartet (z.B. könnte es einen <tt>ValueError</tt> auslösen, weil der Test <tt>if x < 0.0:</tt> fälschlicherweise als <tt>if x <= 0.0:</tt> geschrieben wurde, oder es passiert eine Division durch Null, weil der Spezialfall nicht richtig abgefangen wurde - siehe das tt>sqrt()</tt>-Beispiel oben). Gute Testprogramme enthalten immer auch Tests für die Randwerte.

====Generieren von Referenzdaten====

Wie immer man die Tests definiert hat, muss man am Ende die Ausgabe des Algorithmus mit dem korrekten Ergebnis vergleichen. Man bezeichnet ein bekanntes korrektes Ergebnis als ''Referenz-Ergebnis''. Dieses muss man aber erst einmal kennen, was sich mitunter als schwierig erweist. Folgende Verfahren haben sich als zweckmäßig erwiesen:
* Bei bestimmten Eingaben ist das Ergebnis für den Menschen einfach zu bestimmen, für den Algorithmus ist diese Eingabe aber ebenso schwierig wie jede andere. Dies gilt zum Beispiel für die Quadratzahlen im obigen Beispiel: der Algorithmus kennt keine Quadratzahlen und behandelt sie wie jede andere reelle Zahl. Deshalb eignen sich die Quadratzahlen zum Testen. Auch beim Sortieren kleiner Listen kann die korrekte Sortierung leicht bestimmt und als Referenz-Ergebnis abgespeichert werden. Der Test vergleicht dann einfach die Ausgabe des Sortieralgorithmus mit dem Referenz-Ergebnis.
* Oft kann man das korrekte Ergenis mit einem alternativen Verfahren berechnen. Dies gilt insbesondere, wenn man einen effizienten, aber komplizierten Algorithmus testen will. Dann berechnet man die Referenz-Ergebnisse mit einem langsamen, aber einfachen Verfahren. Dies ist möglich, weil man die Referenz-Ergebnisse ja abspeichern kann und der langsame Algorithmus daher nur wenige Male benutzt werden muss. Beispielsweise kann man einen komplizierten Sortieralgorithmus (Quicksort) mit Hilfe von selection sort testen.
* In vielen Fällen steht ein alternatives Programm zur Verfügung, z.B. eine ältere Version des zu testenden Programms, oder ein kommerzielles Programm (bzw. eine Demoversion), das dasselbe Problem löst, aber im aktuellen Kontext nicht verwendet werden kann (weil es z.B. zu teuer ist, oder nur auf einem Mac läuft). Diese Methode bietet sich auch an, wenn man einen Algorithmus aus einer Programmiersprache in eine andere portieren muss.
* Manchmal kann das korrekte Ergebnis nicht direkt angegeben werden, aber man kennt bestimmte Eigenschaften. Beim Sortieren kann man z.B. testen, dass kein Element des sortierten Arrays größer ist als das darauffolgende. Man testet also die Nachbedingungen. Eine abgeschwächte Versionen dieser Methode wird für randomisierte Algorithmen verwendet: Ist die Wahrscheinlichkeitsverteilung der Testeingaben bekannt, kann man die Wahrscheinlichkeitsverteilung der Ergebnisse, oder zumindest wichtige Eigenschaften wie z.B. den Mittelwert, mathematisch vorhersagen. Der Test ermittelt dann, ob die Ausgaben über viele Durchläufe des Algorithmus diese statistischen Eigenschaften aufweisen.

====Arten von Tests====

Man unterscheidet 3 grundlegende Arten von Tests:

;Black-box Tests [http://en.wikipedia.org/wiki/Black_box_testing]: Hier ist dem Tester nur die Spezifikation, aber nicht die Implementation des Algorithmus bekannt. Alle Tests sowie die Eingaben und Referenz-Ergebnisse müssen aus der Spezifikation abgeleitet werden. Die automatisierte Generierung guter Tests aus der Spezifikation ist ein aktives Forschungsgebiet.
;Gray-box Tests (auch Glass-box Tests) [http://www.cse.fau.edu/~maria/COURSES/CEN4010-SE/C13/glass.htm]: Hier kennt der Tester auch die Implementation und kann dadurch Tests entwerfen, die für diese spezielle Implementation besonders aussagekräftig sind. Es besteht allerdings die Gefahr, dass der Tester nicht mehr unvoreingenommen an das Testproblem herangeht, und Zustände, die seiner Meinung nach gar nicht vorkommen können, auch nicht testet (erst später stellt sich heraus, dass diese Zustände doch vorkommen).
;White-box Tests [http://en.wikipedia.org/wiki/White_box_testing]: Hier kann der Tester die Implementation sogar in geeigneter Weise verändern, z.B.
:* explizite Tests für Vor- und Nachbedingungen ("Assertions") einbauen. Dies bietet sich insbesondere in der alpha- und beta-Testphase eines Programms an, um Fehler schnell zu lokalisieren. Auch die unter Windows bekannte Dialogbox "Diesen Fehler bitte auch an Microsoft melden" wird durch solche eingebauten Assertions ausgelöst, wenn das Programm in einen illegalen Zustand geraten ist und abgebrochen werden muss.
:* zusätzlichen Code einbauen, der feststellt, ob alle Teile des Programms auch tatsächlich getestet wurden ("[http://blogs.msdn.com/phuene/archive/2007/05/03/code-coverage-instrumentation.aspx code coverage instrumentation]"). Dieser Code gibt nach dem Testen z.B. aus, welche Programmzeilen von keinem existierenden Test aufgerufen worden sind. Wenn der ausgeführte Code sehr stark von den Daten abhängt (z.B. bei interaktiven Programmen), kann es sehr schwierig sein, die ''coverage'' auf andere Weise festzustellen.
:* absichtlich Bugs einbauen (die automatisch wieder abgeschaltet werden, wenn das Testen vorbei ist). Durch diese "[http://en.wikipedia.org/wiki/Fault_injection fault injection]" kann man herausfinden, ob die Tests mächtig genug sind, vorhandene Bugs zu finden.

====Prinzipien für die Generierung von Testdaten====

;Prinzip der Regressionstests ("[http://en.wikipedia.org/wiki/Regression_testing Regression testing]"): Häufig werden Tests während der Programmentwicklung verwendet, um einen Algorithmus zu debuggen. Sobald der Algorithmus aber funktioniert werden die Tests gelöscht, denn sie werden ja jetzt nicht mehr gebraucht. Dies ist ein schwerwiegender ''Fehler'': Jedes erfolgreiche Programm muss früher oder später weiterentwickelt werden (zumindest die Anpassung an eine neue Betriebssystemversion ist ab und zu notwendig). Jede Änderung birgt aber die Gefahr, dass sich neue Bugs in bisher funktionierenden Code einschleichen. Man sollte deshalb alle Tests aufheben und in einer ''test suite'' sammeln. Durch diese "regression tests" kann man nach jeder Änderung feststellen, ob die alte Funktionalität noch intakt ist, und gegebenenfalls die letzte Änderung einfach rückgängig machen. Tut man dies nicht, kann die Gefahr von unbeabsichtigten destruktiven Änderungen so groß werden, dass das Programm gar nicht mehr weiterentwickelt werden kann. Dies wird drastisch durch den bekannten Spruch "never change a running program" ausgedrückt.

;Prinzip der äquivalenten Eingaben (Domain Partitioning oder Equivalence Partitioning) [http://en.wikipedia.org/wiki/Equivalence_partitioning]: Für ähnliche Eingaben verhält sich ein Algorithmus normalerweise ähnlich, und es hat keinen Sinn, alle diese Eingaben zu testen. Statt dessen teilt (partitioniert) man die Eingabedomäne in Äquivalenzklassen, die vom Algorithmus im wesentlichen gleich behandelt werden. Im obigen Beispiel der Wurzelberechnung ergeben sich zwei Klassen aus der Spezifikation: die negativen Zahlen (für die die Wurzel undefiniert ist und deshalb ein Fehler signalisiert werden muss) und die nicht-negativen Zahlen. Wenn man auch den Quellcode kennt (gray-box testing), kann man die Eingaben oft feiner unterteilen. Z.B. werden häufig unterschiedliche Algorithmen für kleine und für große Eingaben benutzt. Viele Quicksort-Implementationen verwenden beispielsweise für Arrays mit höchstens vier Elementen ein explizites Sortierverfahren, für Arrays der Länge 5 bis 25 selection sort, und erst für größere Arrays das eigentliche Quicksort. Aus der Einteilung der Eingabedomäne ergeben sich zwei wichtige Regeln für die Wahl der Testdaten:
:* Aus jeder Äquivelenzklasse wählt man mindestens einen typischen Vertreter, um das normale Verhalten des Algorithmus in jedem Fall zu testen.
:* Aus jeder Äquivelenzklasse wählt man Randwerte, weil gerade bei diesen Werten am häufigsten Fehler gemacht werden. Im obigen Wurzelbeispiel ist der Randwert die Null, die in der Tat in einer Version des Algorithmus zu einem <TT>ZeroDivisionError</tt> geführt hat. Andere typische Randfehler sind, dass Randelemente dem falschen Algorithmenzweig zugeordnet werden (z.B. wenn bei unserem Wurzelbeispiel die Abfrage am Anfang <tt>if x <= 0:</tt> statt <tt>if x < 0:</tt> gewesen wäre), dass Schleifen um einen Index zu spät beginnen oder zu früh abbrechen ("[http://en.wikipedia.org/wiki/Off-by-one_error Off-by-one errors]"), oder dass ein seltener Randfall gar nicht implementiert ist und einfach zum Absturz führt.

;Prinzip, den Fehler zu reproduzieren (Failure Reproduction): Wenn ein Bug gemeldet wird, welches die Tests bisher übersehen haben, fügt man einen Test hinzu, der dieses Bug findet. Im Zusammenhang mit regression tests ist damit sichergestellt, dass dasselbe Bug nicht noch einmal auftreten kann.

;Prinzip der Code Coverage [http://en.wikipedia.org/wiki/Code_coverage]: Hier stellt man sicher, dass tatsächlich der gesamte Code (oder ein vorher festgelegter hoher Prozentsatz) getestet wurde. Gerade bei komplizierten interaktiven Programmen ist diese "code coverage" mitunter nicht leicht zu erreichen, weil manche Programmteile nur bei sehr seltenen oder obskuren Eingaben ausgeführt werden. Eine minimale code coverage erreicht man allerdings bereits, wenn man in einem black-box-Test die Testdaten nach dem Prinzip der äquivalenten Eingaben auswählt, weil dann aus jeder Äquivalenzklasse mindestens ein Vertreter getestet wird. Im Allgemeinen muss man aber den Quellcode zumindest kennen (gray-box-Test), um geeignete Testdaten für code coverage zu identifizieren. Code coverage kann in verschiednen Graden angestrebt werden
:* Function coverage: Jede Funktion eines Programms sollte mindestens einmal aufgerufen werden.
:* Statement coverage: Jedes Statement (d.h. im wesentlichen jede Programmzeile) sollte mindestens einmal ausgeführt werden. Im obigen Wurzelbeispiel erfordert dies, dass z.B. mindestens einmal eine negative Zahl getestet wird, um die Exception zu prüfen.
:* Condition coverage: Jede Bedingung (explizit in <tt>if</tt>-Bedingungen, implizit in den Abbruchbedingungen von <tt>for</tt>- und <tt>while</tt>-Schleifen) sollte mindestens einmal mit dem Ergebnis <tt>True</tt> und einmal mit dem Ergebnis <tt>False</tt> durchlaufen werden. Im Wurzelbeispiel haben wir die Eingabe <tt>x = 4</tt> gewählt, damit die <tt>while</tt>-Schleife auch einmal beim ersten Aufruf sofort <tt>False</tt> liefert.
:* Path coverage: Jeder Programmpfad (d.h. jede Kombination von Wahrheitswerten bei allen Bedingungen) sollte einmal ausgeführt werden. Dies ist im Allgemeinen unerreichbar, weil es unendlich viele, oder zumindest zu viele verschiedene Pfade gibt.
:Die Qualität der Tests steigt, wenn eine hohe Coverage (am besten 100%) erreicht wird, und/oder man eine mächtigere Art von Coverage fordert.

;Prinzip der erschöpfenden Tests: Wenn ein Algorithmus nur wenige mögliche Eingaben hat, kann man sämtliche Eingaben testen. Bei sehr wichtigen Algorithmen kann das auch dann noch sinnvoll sein, wenn es relativ viele mögliche Eingaben gibt. In den meisten Fällen ist es jedoch zu aufwändig.

;Prinzip der vollständigen Paarung (Pair-wise coverage) [http://citeseer.ist.psu.edu/78354.html]: Wenn ein Algorithmus N Eingabeparameter hat, und jeder Parameter hat Ki mögliche Werte, müssen bei der erschöpfenden Suche K1*...*KN Kombinationen getestet werden. Beschränkt man sich in jedem Parameter auf typische Werte und Randwerte jeder Äquivalenzklasse, kann man Ki zwar drastisch reduzieren, aber das Produkt K1*...*KN wird immer noch sehr groß (bei 4 Parametern und nur 3 möglichen Werten pro Parameter hat man bereits 34=81 mögliche Kombinationen). Sei vij der j-te Wert des Parameters i. Anstatt zu versuchen, alle Kombinationen zu testen, kann man fordern, dass zumindest alle möglichen Paare vij und vmj (i≠m) in mindestens einem Test vorkommen. Gibt es nur zwei Parameter, gewinnt man durch diese Einschränkung natürlich nichts, denn man muss mindestens K1*K2 Tests durchführen. Hat man jedoch 3 Parameter, kann man mit weniger Tests auskommen als zuvor, da jeder Test bis zu drei verschiedene Paarungen abdecken kann (eine für den ersten und zweiten Parameter, eine für den ersten und dritten, eine für den zweiten und dritten). Bei vier Parametern werden sogar sechs Paarungen pro Test abgearbeitet usw. Die Theorie des "experimental design" beschreibt nun, wie man systematisch alle möglichen Paarungen mit möglichst wenigen Tests erzeugt. Es stellt sich heraus, dass man alle Paarungen von 3, 4 oder mehr Parametern oft mit genauso vielen Tests erzeugen kann wie bei 2 Parametern nötig wären. Dazu verwendet man die Methode der [http://en.wikipedia.org/wiki/Latin_square Latin Squares]. Wir beschreiben diese Methode für den einfachen Fall von 3 möglichen Werten pro Parameter.

:Ein Latin Square der Größe 3 ist eine 3x3 Matrix, deren Einträge die Zahlen 1...3 sind, und zwar so, dass jede Zahl genau einmal in jeder Zeile und Spalte vorkommt (ähnlich wie beim Sudoku). Eine mögliche Matrix ist z.B.

:<math>P=\begin{pmatrix}1 & 2 & 3 \\
2 & 3 & 1 \\
3 & 1 & 2\end{pmatrix}</math>
:Man bildet jetzt 9 Kombinationen der Zahlen 1...3, indem man zeilenweise durch die Matrix P geht, und den Zeilenindex (die Nummer der aktuellen Zeile) als erste Zahl, den Spaltenindex als zweite Zahl, und den Eintrag an der aktuallen Position als dritte Zahl verwendet. Man erhält
{| border="1" cellspacing="0" cellpadding="7" align="center"
|-align="center"
|
! Komb. 1
! Komb. 2
! Komb. 3
! Komb. 4
! Komb. 5
! Komb. 6
! Komb. 7
! Komb. 8
! Komb. 9
|-
!Zahl 1 (Zeilenindex)
|align="center" | 1
|align="center" | 1
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 3
|-
! Zahl 2 (Spaltenindex)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|-
! Zahl 3 (aktueller Matrixeintrag von P)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 3
|align="center" | 1
|align="center" | 2
|}

:Diese Tabelle bestimmt, welcher Wert in jedem Test für jeden Parameter verwendet wird. Z.B. wird der erste Test mit v11 (erster Wert des ersten Parameters), v21 (erster Wert des zweiten Parameters), v31 (erster Wert des dritten Parameters) aufgerufen
assertEqual( foo(v11, v21, v31), foo_reference1)
:(reference1 ist das korrekte Referenz-Ergebnis für diese Parameterbelegung). Der letzte Test hat die Parameter v13, v23, v32
assertEqual( foo(v13, v23, v32), foo_reference9)
:Man überzeugt sich leicht, dass diese 9 Tests jede mögliche Paarung genau einmal enthalten. Hat der Algorithmus 4 Parameter, benötigt man einen zweiten Latin Square, der zum ersten orthogonal ist. Zwei Latin Squares P und Q heißen orthogonal, wenn alle Paare cij=(Pij, Qij) eindeutig sind, d.h. es gilt cij≠ckl falls i≠k und j≠l. Ein zu dem obigen P orthogonales Q ist z.B.
:<math>Q=\begin{pmatrix}1 & 2 & 3 \\
3 & 1 & 2 \\
2 & 3 & 1\end{pmatrix}</math>
: Jetzt bildet man Kombinationen aus 4 Zahlen, indem man zur obigen Tabelle noch eine vierte Zeile hinzufügt, die die aktuellen Einträge von Q für den jeweiligen Zeilen- und Spaltenindex enthält:
{| border="1" cellspacing="0" cellpadding="7" align="center"
|-align="center"
|
! Komb. 1
! Komb. 2
! Komb. 3
! Komb. 4
! Komb. 5
! Komb. 6
! Komb. 7
! Komb. 8
! Komb. 9
|-
!Zahl 1 (Zeilenindex)
|align="center" | 1
|align="center" | 1
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 3
|-
! Zahl 2 (Spaltenindex)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|-
! Zahl 3 (aktueller Matrixeintrag von P)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 3
|align="center" | 1
|align="center" | 2
|-
! Zahl 4 (aktueller Matrixeintrag von Q)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 1
|}

:Es sind immer noch nur 9 Tests nötig, um alle Paarungen zu erzeugen. Der erste und letzte Test sind nun:
assertEqual( bar(v11, v21, v31, v41), bar_reference1)
...
assertEqual( bar(v13, v23, v32, v41), bar_reference9)
:Die Methode der Latin Squares funktioniert auch, wenn mehr als 3 Belegungen für jeden Parameter möglich sind, und wenn es mehr als 4 Parameter gibt. Für die Einzelheiten verweisen wir auf die Literatur, z.B. [http://citeseer.ist.psu.edu/78354.html], [http://en.wikipedia.org/wiki/Latin_square]. Empirische Untersuchungen haben ergeben, dass die Methode der vollständigen Paarung oft über 90% der Fehler in einem Programm finden kann.

[[Effizienz|Nächstes Thema]]

Graphen und Graphenalgorithmen

2012-07-25T17:38:46Z

Ukoethe: /* Transitive Hülle und stark zusammenhängende Komponenten */

== Einführung zu Graphen ==

=== Motivation -- Königsberger Brückenproblem ===
Leonhard Euler [http://de.wikipedia.org/wiki/Leonhard_Euler] erfand den Graphen-Formalismus 1736, um eine scheinbar banale Frage zu beantworten: Ist es möglich, in Königsberg (siehe Stadtplan von 1809 und die schematische Darstellung) einen Spaziergang zu unternehmen, bei dem jede der 7 Brücken genau einmal überquert wird?

[[Image:Koenigsberg1809.png]] 
[[Image:Koenigsberg.jpg]]

Ein Graph abstrahiert von der Geometrie des Problems und repräsentiert nur die Topologie. Jeder Stadtteil von Königsberg ist ein Knoten des Graphen, jede Brücke eine Kante. Der zum Brückenproblem gehörende Graph sieht also so aus:

O
/| \
\| \
O---O
/| /
\| /
O

Der gesuchte Spaziergang würde existieren, wenn es maximal 2 Knoten gäbe, an denen sich eine ungerade Zahl von Kanten trifft. Die Frage muss für Königsberg also verneint werden, denn hier gibt es vier solche Knoten. Ein leicht modifiziertes Problem ist allerdings lösbar: Im obigen Stadtplan erkennt man eine Fähre, die die Stadtteile Kneiphof und Altstadt verbindet. Bezieht man dieselbe in den Spaziergang ein, ergibt sich folgender Graph, bei dem nur noch zwei Knoten mit ungerader Kantenzahl existieren:

--O
/ /| \
\ \| \
--O---O
/| /
\| /
O

Inzwischen haben Graphen eine riesige Zahl weiterer Anwendungen gefunden. Einige Beispiele:

* Landkarten:
** Knoten: Länder
** Kanten: gemeinsame Grenzen

* Logische Schaltkreise:
** Knoten: Gatter
** Kanten: Verbindungen

* Chemie (Summenformeln):
** Knoten: chemische Elemente
** Kanten: Bindungen

* Soziologie (StudiVZ)
** Soziogramm
*** Knoten: Personen
*** Kanten: Freund von ...

=== Definitionen ===

;Ungerichteter Graph: Ein ungerichteter Graph G = ( V, E ) besteht aus
:* einer endliche Menge V von Knoten (vertices)
:* einer endlichen Menge <math>E \subset V \times V</math> von Kanten (edges)
:Die Paare (u,v) und (v,u) gelten dabei als nur ''eine'' Kante (somit gilt die Symmetriebeziehung: (u,v) ∈ E => (v,u) ∈ E ). Die Anzahl der Kanten, die sich an einem Knoten treffen, wird als ''Grad'' (engl. ''degree'') dieses Knotens bezeichnet:
:::degree(v) = |{v' ∈ V | (v,v') ∈ E}|
:(Die Syntax |{...}| bezeichnet dabei die Mächtigkeit der angegebenen Menge, also die Anzahl der Elemente in der Menge.)

Der Graph des Königsberger Brückenproblems ist ungerichtet. Bezeichnet man die Knoten entsprechend des folgenden Bildes
c
/| \
\| \
b---d
/| /
\| /
a

gilt für die Knotengrade: <tt>degree(a) == degree(c) == degree(d) == 3</tt> und <tt>degree(b) == 5</tt>. Genauer muss man bei diesem Graphen von einem ''Multigraphen'' sprechen, weil es zwischen einigen Knotenpaaren (nämlich (a, b) sowie (b, c)) mehrere Kanten ("Mehrfachkanten") gibt. Wir werden in dieser Vorlesung nicht näher auf Multigraphen eingehen.

;Gerichteter Graph: Ein Graph heißt ''gerichtet'', wenn die Kanten (u,v) und (v,u) unterschieden werden. Die Kante (u,v) ∈ E wird nun als Kante von u nach v (aber nicht umgekehrt) interpretiert. Entsprechend unterscheidet man jetzt den ''eingehenden'' und den ''ausgehenden Grad'' jedes Knotens:
:*out_degree(v) = |{v' ∈ V | (v,v') ∈ E}| 
:*in_degree(v) = |{v' ∈ V| (v',v) ∈ E}|

Das folgende Bild zeigt einen gerichteten Graphen. Hier gilt <tt>out_degree(1) == out_degree(3) == in_degree(2) == in_degree(4) == 2</tt> und
<tt>in_degree(1) == in_degree(3) == out_degree(2) == out_degree(4) == 0</tt>:

[[Image:digraph.png|gerichteter Graph]]

 

;Vollständiger Graph: Ein vollständiger Graph ist ein ungerichteter Graph, bei dem jeder Knoten mit allen anderen Knoten verbunden ist.
:::<math>E = \{ (v,w) | v \in V, w \in V, v \ne w \}</math>
:Ein vollständiger Graph mit |V| Knoten hat <math>|E| = \frac{|V|(|V|-1)}{2}</math> Kanten.

Die folgenden Abbildungen zeigen die vollständigen Graphen mit einem bis fünf Knoten (auch als K1 bis K5 bezeichnet).

{| border="0" cellspacing="0" cellpadding="0" style="margin: 1em auto 1em auto"
|-
| [[Image:k1.png|frame|k1]]
| [[Image:k2.png|frame|k2]]
| [[Image:k3.png|frame|k3]]
|-
| [[Image:k4.png|frame|k4]]
| [[Image:k5.png|frame|k5]]
|
|}

''Rätsel'' 
Auf einer Party sind Leute. Alle stoßen miteinander an. Es hat 78 mal "Pling" gemacht.
Wieviele Leute waren da? Antwort: Jede Person ist ein Knoten des Graphen, jedes Antoßen eine Kante.
Da alle miteinander angestoßen haben, handelt es sich um einen vollständigen Graphen. Mit
|V|(|V|-1)/2 = 78 folgt, dass es 13 Personen waren.

 

;Gewichteter Graph: Ein Graph heißt ''gewichtet'', wenn jeder Kante eine reelle Zahl zugeordnet ist. Bei vielen Anwendungen beschränkt man sich auch auf nichtnegative reelle Gewichte. In einem gerichteten Graphen können die Gewichte der Kanten (u,v) und (v,u) unterschiedlich sein.

Die Gewichte kodieren Eigenschaften der Kanten, die für die jeweilige Anwendung interessant sind. Bei der Berechnung des maximalen Flusses in einem Netzwerk sind die Gewichte z.B. die Durchflusskapazitäten jeder Kante, bei der Suche nach kürzesten Weges kodieren Sie den Abstand zwischen den Endknoten der Kante, bei Währungsnetzwerken (jeder Knoten ist eine Währung) geben sie die Wechselkurse an, usw..

 

;Teilgraphen: Ein Graph G' = (V',E') ist ein Teilgraph eines Graphen G, wenn gilt:
:* V' &sube; V
:* E' ⊂ E
:Er heißt ''(auf)spannender Teilgraph'', wenn gilt:
:* V' = V
:Er heißt ''induzierter Teilgraph'', wenn gilt:
:* e = (u,v) ∈ E' ⊂ E ⇔ u ∈ V' und v ∈ V'
:Den von V' induzierten Teilgraphen erhält man also, indem man aus G alle Knoten löscht, die nicht in V' sind, sowie alle Kanten (und nur diese Kanten), die einen der gelöschten Knoten als Endknoten haben.

 

;Wege, Pfade, Zyklen, Kreise, Erreichbarkeit: Sei G = (V,E) ein Graph (ungerichtet oder gerichteter) Graph. Dann gilt folgende rekursive Definition:
:* Für v ∈ V ist (v) ein Weg der Länge 0 in G
:* Falls <math>(v_0, v_1, ..., v_{n-1})</math> ein Weg ist, und eine Kante <math>(v_{n-1}, v_n)\in E</math> existiert, dann ist auch <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ein Weg, und er hat die Länge n.
: Ein Weg ist also eine nichtleere Folge von Knoten, so dass aufeinander folgende Knoten stets durch eine Kante verbunden sind. Die Länge des Weges entspricht der Anzahl der Kanten im Weg (= Anzahl der Knoten - 1).
:* Ein ''Pfad'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, bei dem alle Knoten vi verschieden sind.
:* ''Ein Zyklus'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, der zum Ausgangspunkt zurückkehrt, wenn also v0 = vn gilt.
:* Ein ''Kreis'' ist ein Zyklus ohne Überkreuzungen. Das heisst, es gilt v0 = vn und <math>(v_0, v_1, ..., v_{n-1})</math> ist ein Pfad.
:* Ein Knoten w ∈ V ist von einem anderen Knoten v ∈ V aus ''erreichbar'' genau dann, wenn ein Weg (v, ..., w) existiert. Wir schreiben dann <math>v \rightsquigarrow w</math>.
In einem ungerichteten Graph ist die Erreichbarkeits-Relation stets symmetrisch, das heisst aus <math>v \rightsquigarrow w</math> folgt <math>w \rightsquigarrow v</math>. In einem gerichteten Graphen ist dies im allgemeinen nicht der Fall.

Bestimmte Wege haben spezielle Namen

;Eulerweg: Ein Eulerweg ist ein Weg, der alle '''Kanten''' genau einmal enthält.

Die eingangs erwähnte Frage des Königsberger Brückenproblems ist equivalent zu der Frage, ob der dazugehörige Graph einen Eulerweg besitzt (daher der Name). Ein anderes bekanntes Beispiel ist das "Haus vom Nikolaus": Wenn man diesen Graphen in üblicher Weise in einem Zug zeichnet, erhält man gerade den Eulerweg.

O
/ \
O----O
| \/ |
| /\ | "Das Haus vom Nikolaus": Alle ''Kanten'' werden nur ''einmal'' passiert
O----O

;Hamiltonweg: Ein Hamiltonweg ist ein Weg, der alle '''Knoten''' genau einmal enthält. Das "Haus vom Nikolaus" besitzt auch einen Hamiltonweg:

O
/
O----O
/
/ Alle ''Knoten'' werden nur ''einmal'' passiert
O----O

;Hamiltonkreis: Ein Hamiltonkreis ist ein Kreis, der alle '''Knoten''' genau einmal enthält. Auch ein solches Gebilde ist im Haus von Nilolaus enthalten:

O
/ \
O O
| | v0 = vn
| | vi != vj Für Alle i,j i !=j; i,j >0; i,j < n
O----O

Die folgende Skizze zeigt hingegen einen Zyklus: Der Knoten rechts unten sowie die untere Kante sind zweimal enthalten (die Kante einmal von links nach rechts und einmal von rechts nach links):

O
/ \
O O
\ |
\ | Zyklus
O====O

 

;Zusammenhang, Zusammenhangskomponenten: Ein ungerichteter Graph G heißt ''zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math>
:Ein gerichteter Graph G ist zusammenhängend, wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''oder''' <math>w \rightsquigarrow v</math>.
:Er ist ''stark zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''und''' <math>w \rightsquigarrow v</math>.
:Entsprechende Definitionen gelten für Teilgraphen G'. Ein Teilgraph G' heisst ''Zusammenhangskomponente'' von G, wenn er ein ''maximaler'' zusammenhängender Teilgraph ist, d.h. wenn G' zusammenhängend ist, und man keine Knoten und Kanten aus G mehr zu G' hinzufügen kann, so dass G' immer noch zusammenhängend bleibt. Entsprechend definiert man ''starke Zusammenhangskomponenten'' in einem gerichteten Graphen.

 

;Planarer Graph, ebener Graph: Ein Graph heißt ''planar'', wenn er so in einer Ebene gezeichnet werden ''kann'', dass sich die Kanten nicht schneiden (außer an den Knoten). Ein Graph heißt ''eben'', wenn er tatsächlich so gezeichnet ''ist'', dass sich die Kanten nicht schneiden. Die Einbettung in die Ebene ist im allgemeinen nicht eindeutig.

'''Beispiele:'''

Der folgende Graph ist planar und eben:

O
/|\
/ O \
/ / \ \
O O

Das "Haus vom Nikolaus" ist ebenfalls planar, wird aber üblicherweise nicht als ebener Graph gezeichnet, weil sich die Diagonalen auf der Wand überkreuzen:

O
/ \
O----O
| \/ |
| /\ |
O----O

Eine ebene Einbettung dieses Graphen wird erreicht, wenn man eine der Diagonalen ausserhalb des Hauses zeichnet. Der Graph (also die Menge der Knoten und Kanten) ändert sich dadurch nicht.

O
/ \
--O----O
/ | / |
| | / |
| O----O Das "Haus vom Nikolaus" als ebener Graph gezeichnet.
\ /
-----

Eine alternative Einbettung erhalten wir, wenn wir die andere Diagonale außerhalb des Hauses zeichnen:

O
/ \
O----O--|
| \ | |
| \ | |
O----O | Alternative Einbettung des "Haus vom Nikolaus".
| |
|-------|

Jede Einbettung eines planaren Graphen (also jeder ebene Graph) definiert eine eindeutige Menge von ''Regionen'':

|----O @
| /@ \
| O----O
| |@ / |
| | / @|
| O----O @ entspricht jeweils einer ''Region''. Auch ausserhalb der Figur ist eine Region (die sogenannte ''unendliche'' Region).
|@ |
|-------|

Der vollständige Graph K5 ist kein planarer Graph, da sich zwangsweise Kanten schneiden, wenn man diesen Graphen in der Ebene zeichnet.

 
;Dualer Graph: Jeder ebene Graph G = (V, E) hat einen ''dualen Graphen'' D = (VD, ED), dessen Knoten und Kanten wie folgt definiert sind:
:* VD enthält einen Knoten für jede Region des Graphen G
:* Für jede Kante e ∈ E gibt es eine duale Kante eD ∈ ED, die die an e angrenzenden Regionen (genauer: die entsprechenden Knoten in D) verbindet.

Die folgende Abbildung zeigt einen Graphen (grau) und seinen dualen Graphen (schwarz). Die Knoten des dualen Graphen sind mit Zahlen gekennzeichnet und entsprechen den Regionen des Originalgraphen. Jeder (grauen) Kante des Originalgraphen entspricht eine (schwarze) Kante des dualen Graphen.

 
[[Image:dual-graphs.png]]
 

Für duale Graphen gilt: Wenn der Originalgraph zusammenhängend ist, enthält jede Region des dualen Graphen genau einen Knoten des Originalgraphen. Deshalb ist der duale Graph des dualen Graphen wieder der Originalgraph. Bei nicht-zusammenhängenden Graphen gilt dies nicht (vgl. das Fenster bei obigem Bild). In diesem Fall hat der duale Graph mehrere mögliche Einbettungen in die Ebene (man kann z.B. die rechte Kante zwischen Knoten 2 und 4 auch links vom Fenster einzeichnen), und man erhält nicht notwendigerweise den Originalgraphen, wenn man den dualen Graphen des dualen berechnet.

;Baum: Ein ''Baum'' ist ein zusammenhängender, kreisfreier Graph.

Beispiel: Binärer Suchbaum

;Spannbaum: Ein ''Spannbaum'' eines zusammenhängenden Graphen G ist ein zusammenhängender, kreisfreier Teilgraph von G, der alle Knoten von G enthält

Beispiel: Spannbaum für das "Haus des Nikolaus"

O
/
O O
| /
| /
O----O

Der Spannbaum eines Graphen mit |V| Knoten hat stets |V| - 1 Kanten.

;Wald: Ein ''Wald'' ist ein unzusammenhängender, kreisfreier Graph.
: Jede Zusammenhangskomponente eines Waldes ist ein Baum.

=== Repräsentation von Graphen ===

Sei G = ( V, E ) gegeben und liege V in einer linearen Sortierung vor. 
:::<math>V = \{ v_1, ...., v_n \}</math>

;Adjazenzmatrix: Ein Graph kann durch eine Adjazenzmatrix repräsentiert werden, die soviele Zeilen und Spalten enthält, wie der Graph Knoten hat. Die Elemente der Adjazenzmatrix sind "1", falls eine Kante zwischen den zugehörigen Knoten existiert:
:::<math>\mathrm{\bold A} = a_{ij} =
\begin{cases}
1 & \mathrm{falls}\quad (v_i, v_j) \in E \\
0 & \mathrm{sonst}
\end{cases}
</math>
:Die Indizes der Matrix entsprechen also den Indizes der Knoten gemäß der gegebenen Sortierung. Im Falle eines ungerichteten Graphen ist die Adjazenzmatrix stets symmetrisch (d.h. es gilt <math>a_{ij}=a_{ji}</math>), bei einem gerichteten Graphen ist sie im allgemeinen unsymmetrisch.

Beispiel für einen ungerichteten Graphen:

v = { a,b,c,d } b d
| \ / |
| \/ |
| /\ |
| / \ |
a c

a b c d
-----------
(0 1 0 1) |a
A = (1 0 1 0) |b
(0 1 0 1) |c
(1 0 1 0) |d

Die Adjazenzmatrixdarstellung eignet sich besonders für dichte Graphen (d.h. wenn die Zahl der Kanten in O(|V|2) ist.

;Adjazenzlisten: In der Adjazenzlistendarstellung wird der Graph als Liste von Knoten repräsentiert, die für jeden Knoten einen Eintrag enthält. Der Eintrag für jeden Knoten ist wiederum eine Liste, die die Nachbarknoten dieses Knotens enthält:
:* graph = {adjazencyList(v) | v ∈ V}
:* adjazencyList(v) = {v' ∈ V | (v, v') ∈ E}

In Python implementieren wir Adjazenzlisten zweckmäßig als Array von Arrays:

graph = [[...],[...],...,[...]]
Adjazenzliste für Knoten => 0 1 n

Wenn wir bei dem Graphen oben die Knoten wie bei der Adjazenzmatrix indizieren (also <tt>a => 0</tt>, <tt>b => 1</tt>, <tt>c => 2</tt>, <tt>d => 3</tt>), erhalten wir die Adjazenzlistendarstellung:

graph = [[b, d], [a, c],[b, d], [a, c]]

Auf die Nachbarknoten eines durch seinen Index <tt>node</tt> gegebenen Knotens können wir also wie folgt zugreifen:

for neighbors in graph[node]:
... # do something with neighbor

Die Adjazenzlistendarstellung ist effizienter, wenn der Graph nicht dicht ist, so dass viele Einträge der Adjazenzmatrix Null wären. In der Vorlesung werden wir nur diese Darstellung verwenden.

;<div id="transposed_graph">Transponierter Graph</div>: Den ''transponierten Graphen'' GT eines gerichteten Graphen G erhält man, wenn man alle Kantenrichtungen umkehrt.

Bei ungerichteten Graphen hat die Transposition offensichtlich keinen Effekt, weil alle Kanten bereits in beiden Richtungen vorhanden sind, so dass GT = G gilt. Bei gerichteten Graphen ist die Transposition einfach, wenn der Graph als Adjazenzmatrix implementiert ist, weil man einfach die transponierte Adjazenzmatrix verwenden muss (beachte, dass sich die Reihenfolge der Indizes umkehrt):
:::AT = aji
Ist der Graph hingegen durch eine Adjazenzliste repräsentiert, muss etwas mehr Aufwand getrieben werden:

def transposeGraph(graph):
gt = [[] for k in graph] # zunächst leere Adjazenzlisten von GT
for node in range(len(graph)):
for neighbor in graph[node]:
gt[neighbor].append(node) # füge die umgekehrte Kante in GT ein
return gt

== Durchlaufen von Graphen (Graph Traversal) ==

Wir betrachten zunächst ungerichtete Graphen mit V Knoten und E Kanten. Eine grundlegende Aufgabe in diesen Graphen besteht darin, alle Knoten in einer bestimmten Reihenfolge genau einmal zu besuchen. Hierbei darf man sich von einem gegebenen Startknoten aus nur entlang der Kanten des Graphen bewegen. Die beim Traversieren benutzen Kanten bilden einen Baum, dessen Wurzel der Startknoten ist und der den gesamten Graphen aufspannt, falls der Graph zusammenhängend ist. (Beweis: Da jeder Knoten nur einmal besucht wird, gibt es für jeden besuchten Knoten [mit Ausnahme des Startknotens] genau eine eingehende Kante. Ist der Graph zusammenhängend, wird jeder Knoten tatsächlich erreicht und es gibt genau (V-1) Kanten, exakt soviele wie für einen Baum mit V Knoten notwendig sind.) Ist der Graph nicht zusammenhängend, wird jeder zusammenhängende Teilgraph (jede Zusammenhangskomponente) getrennt traversiert, und man erhält einen sogenannten Wald mit einem Baum pro Zusammenhangskomponente. Die beiden grundlegenden Traversierungsmethoden Tiefensuche und Breitensuche werden im folgenden vorgestellt.

=== Tiefensuche in Graphen (Depth First Search, DFS) ===

Die Idee der Tiefensuche besteht darin, jeden besuchten Knoten sofort über die erste Kante wieder zu verlassen, die zu einem noch nicht besuchten Knoten führt. Man findet dadurch schnell einen möglichst langen Pfad durch den Graphen, und der Traversierungs-Baum wird zunächst in die Tiefe verfolgt, daher der Name des Verfahrens. Hat ein Knoten keine unbesuchten Nachbarknoten mehr, geht man im Baum zurück (sogenanntes back tracking), bis man einen Knoten findet, der noch eine unbesuchte Nachbarn besitzt, und traversiert diese nach dem gleichen Muster. Gibt es gar keine unbesuchten Knoten mehr, kehrt die Suche zum Startknoten zurück und endet dort.

WDie folgende rekursive Implementation der Tiefensuche erwartet den Graphen in Adjazenzlistendarstellung und beginnt die Suche beim Knoten <tt>startnode</tt>. Die Information, ob ein Knoten bereits besucht wurde, wird im Array <tt>visited</tt> gespeichert. Ein solches Array, das zusätzliche Informationen über die Knoten des Graphen bereitstellt, wir häufig property map genannt.

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
print node # Ausgabe der Knotennummer - pre-order
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)

visit(startnode)

[[Image:Tiefens.jpg]]

Ausgabe für den Graphen in diesem Bild (es handelt sich um einen ungerichteten Graphen, die Pfeile symbolisieren nur die Suchrichtung beim Traversal):

>>> dfs(graph, 1)
1
2
4
3
6
7
5

<div id="pre_and_post_order">In dieser Version des Algorithmus werden die Knotennummern ausgegeben, bevor die Nachbarknoten besucht werden. Man bezeichnet die resultierende Sortierung der Knoten als pre-order oder als discovery order. Alternativ kann man die Knotennummern erst ausgeben, nachdem alle Nachbarn besucht wurden, also auf dem Rückweg der Rekursion. In diesem Fall spricht man von post-order oder finishing order:</div>

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)
print node # Ausgabe der Knotennummer - post-order

visit(startnode)

Es ergibt sich jetzt die Ausgabe:

>>> dfs(graph, 1)
6
7
3
4
5
2
1

In realem Code ersetzt man die print-Ausgaben natürlich durch anwendungsspezifische Aktionen und Berechnungen. Einige Anwendungen sind uns im Kapitel [[Suchen]] bereits begegnet.
; Anwendungen der Pre-Order Traversierung
* Kopieren eines Graphen: kopiere zuerst den besuchten Knoten, dann seine Nachbarn und die dazugehörigen Kanten (sowie die Kanten zu bereits besuchten Knoten, die in der Grundversion der Tiefensuche ignoriert werden).
* Bestimmen der Zusammenhangskomponenten eines Graphen (siehe unten)
* In einem Zeichenprogramm: fülle eine Region mit einer Farbe ("flood fill"). Dabei ist jedes Pixel ein Knoten des Graphen und wird mit seinen 4 Nachbarpixceln verbunden. Die Tiefensuche startet bei der Mausposition und endet am Rand des betreffendcen Gebiets.
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von der Wurzel
* Falls der Graph ein Parse-Baum ist, wobei innere Knoten Funktionsaufrufe, Kindknoten Funktionsargumente, und Blattknoten Werte repräsentieren: drucke den zugehörigen Ausdruck aus (also immer zuerst den Funktionsnamen, dann die Argumente, die wiederum geschachtelte Funktionsaufrufe sein können).
; Anwendungen der Post-Order Traversierung
* Löschen eines Graphen: lösche zuerst die Nachbarn, dann den Knoten selbst
* Bestimmen einer topologischen Sortierung eines azyklischen gerichteten Graphens (siehe unten)
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von den Blättern (also die Tiefe des Baumes, siehe Übung 5)
* Falls der Graph ein Parse-Baum ist: führe die zugehörige Berechnung aus (d.h. berechne zuerst die geschachtelten inneren Funktionen, dann mit diesen Ergebnissen die nächst äußeren usw., siehe Übung 5).
; Anwendungen, die Pre- und Post-Order benötigen
* Weg aus einem Labyrinth: die Pre-Order dokumentiert die Suche nach dem Weg, die Post-Order zeigt den Rückweg aus Sackgassen (siehe Übung 9).
Im Spezialfall, wenn der Graph ein Binärbaum ist, unterscheidet man noch eine dritte Variante der Traversierung, nämlich die in-order Traversierung. In diesem Fall behandelt man den Vaterknoten nach den linken, aber vor den rechten Kindern. Diese Reihenfolge wird beim [[Suchen#Beziehungen zwischen dem Suchproblem und dem Sortierproblem|Tree Sort Algorithmus]] verwendet. Diese Sortierung verwendet man auch, wenn man einen Parse-Baum mit binären Operatoren (statt Funktionsaufrufen) ausgeben will, siehe Übung 5.

Eine nützliche Erweiterung der Tiefensuche besteht darin, in der property map <tt>visited</tt> nicht nur zu dokumentieren, dass ein Knoten bereits besucht wurde, sondern auch, von welchem Knoten aus man den jeweiligen Knoten zuerst erreicht hat. Im entstehenden Tiefensuchbaum ist dies gerade der Vaterknoten, weshalb wir die verbesserte property map zweckmäßigerweise in <tt>parents</tt> umbenennen. Für den Startknoten, also die Wurzel des Baumes, wählen wir die Konvention, dass er sein eigener Vaterknoten ist (die Konvention, dafür den Wert <tt>None</tt> zu verwenden, scheidet aus, weil dies bereits die Tatsache signalisiert, dass ein Knoten noch nicht besucht wurde):

def dfs(graph, startnode):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Tiefensuchbaum

def visit(node, parent): # rekursive Hilfsfunktion
if parents[node] is None: # Besuche node, wenn er noch nicht besucht wurde
parents[node] = parent # Markiere node als besucht und speichere seinen Vaterknoten
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn ...
visit(neighbor, node) # ... wobei node zu deren Vaterknoten wird

visit(startnode, startnode) # Konvention für Wurzel: startnode ist sein eigener Vater

return parents # Rückgabe des berechneten Tiefensuch-Baums

Die Ausgabe für den obigen Beispielgraphen lautet:
Knotennummer | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
--------------+-----+-----+-----+-----+-----+-----+-----+-----
Vaterknoten | None| 1 | 1 | 4 | 2 | 2 | 3 | 3

Dabei ist die Knotennummer der Index im Array <tt>parents</tt>, und der Vaterknoten ist der dazugehörige Arrayeintrag. Beachte, dass Knoten 0 in diesem Graphen nicht existiert, daher ist sein Eintrag <tt>None</tt>. Per Konvention hat der Wurzelknoten 1 sich selbst als Vater.

=== Breitensuche in Graphen (Breadth First Search, BFS) ===

Im Gegensatz zur Tiefensuche werden bei der Breitensuche alle Nachbarnknoten abgearbeitet, bevor man rekursiv deren Nachbarn besucht. Man betrachtet somit zuerst alle Knoten, die den Abstand 1 von Startknoten haben, dann diejenigen mit dem Abstand 2 usw. Diese Reihenfolge bezeichnet man als level-order. Wir sind ihr beispielsweise in Übung 6 begegnet, als die ersten 7 Ebenen eines Treap ausgegeben werden sollten. Man implementiert Breitensuche zweckmäßig mit Hilfe einer Queue, die die Knoten in First In - First Out - Reihenfolge bearbeitet. Eine geeignete Datenstruktur hierfür ist die Klasse <tt>[http://docs.python.org/library/collections.html#collections.deque deque]</tt> aus dem Python-Modul <tt>[http://docs.python.org/library/collections.html collections]</tt> (eine Deque implementiert sowohl die Funktionalität einer Queue wie auch die eines Stacks, siehe Übung 3):

from collections import deque

def bfs(graph, startnode)
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if not visited[node]: # Falls node noch nicht (auf einem anderen Weg) besucht wurde
visited[node] = True # Markiere node als besucht
print node # Drucke Knotennummer
for neighbor in graph[node]: # Füge Nachbarn in die Queue ein
q.append(neighbor)

[[Image:Breitens.jpg]]

Der Aufruf dieser Funktion liefert die Knoten des obigen Graphens ebenenweise, also zufällig genau in der Reihenfolge der Knotennummern:
>>> bfs(graph, 1)
1
2
3
4
5
6
7

Neben der ebenenweisen Ausgabe hat die Breitensuche viele weitere wichtige Anwendungen, z.B. beim Testen, ob ein gegebener Graph bi-partit ist (siehe [http://en.wikipedia.org/wiki/Breadth-first_search#Testing_bipartiteness WikiPedia]), sowie bei der Suche nach kürzesten Wegen (siehe unten) und kürzesten Zyklen.

== Weitere Anwendungen der Tiefensuche ==

Die Tiefensuche hat zahlreiche Anwendungen, wobei der grundlegende Algorithmus immer wieder leicht modifiziert und an die jeweilige Aufgabe angepasst wird. Wir beschreiben im folgenden einige Beispiele.

=== Damenproblem ===

Tiefensuche wird häufig verwendet, um systematisch nach der Lösung eines logischen Rätsels (oder allgemeiner nach der Lösung eines diskreten Optimierungsproblems) zu suchen. Besonders anschaulich hierfür ist das Damenproblem. Die Aufgabe besteht darin, <math>k</math> Damen auf einem Schachbrett der Größe <math>k \times k</math> so zu platzieren, dass sie sich (nach den üblichen Schach-Regeln) nicht gegenseitig schlagen können. Das folgende Diagramm zeigt eine Lösung für den Fall <math>k=4</math>. Die Positionen der Damen werden dabei wie üblich durch die Angabe der Spalte (Linie) mit Buchstaben und der Zeile (Reihe) mit Zahlen kodiert, hier also A2, B4, C1, D3:

---------------
| | X | | | 4
|---|---|---|---|
| | | | X | 3
|---|---|---|---|
| X | | | | 2
|---|---|---|---|
| | | X | | 1
---------------
A B C D

Um das Problem systematisch zu lösen, konstruieren wir einen gerichteten Graphen, dessen Knoten die möglichen Positionen der Damen kodieren. Wir verbinden Knoten, die zu benachbarten Linien gehören, genau dann mit einer Kante, wenn die zugehörigen Positionen kompatibel sind, also wenn sich die dort positionierten Damen nicht schlagen können. Der resultierende Graph für <math>k=4</math> hat folgende Gestalt:

[[Image:damenproblem-graph.png|500px|center]]

Knoten, die zur selben Reihe oder Linie gehören, sind beispielsweise nicht direkt verbunden, weil zwei Damen niemals in derselben Linie oder Reihe stehen dürfen. Um eine erlaubte Konfiguration zu finden, verwenden wir nun eine angepasste Version der Tiefensuche: Wir beginnen die Suche beim Knoten <tt>START</tt>. Sobald wir den Knoten <tt>STOP</tt> erreichen, beenden wir die Suche und lesen die Lösung am gerade gefundenen Weg von Start nach Stop ab. Zwei kleine Modifikationen des Grundalgorithmus stellen sicher, dass die Bedingungen der Aufgabe eingehalten werden: Wir dürfen bei der Tiefensuche nur dann zu einem Nachbarn weitergehen, wenn die betreffende Position mit allen im Pfad bereits gesetzten Positionen kompatibel ist, andernfalls ist diese Kante tabu. Landen wir aufgrund dieser Regel in einer Sackgasse (also in einem Knoten, wo keine der ausgehenden Kanten erlaubt ist), müssen wir zur nächsten erlaubten Abzweigung zurückgehen (Backtracking). Beim Zurückgehen müssen wir das <tt>parent</tt>-Flag wieder auf <tt>None</tt> zurücksetzen, weil der betreffende Knoten ja möglicherweise auf einem anderen erlaubten Weg erreichbar ist.

Der folgende Graph zeigt einen solchen Fall: Wir haben zwei Damen auf die Felder A1 und B3 positioniert (grüne Pfeile). Die einzig ausgehende Kante von B3 führt zum Knoten C1, welcher aber mit der Position A1 inkompatibel ist, so dass diese Kante nicht verwendet werden darf (roter Pfeil). Das Backtracking muss jetzt zu Knoten A1 zurückgehen (dabei wird das <tt>parent</tt>-Flag von B3 wieder auf <tt>None</tt> gesetzt), weil A1 mit der Kante nach B4 eine weitere Option hat, die geprüft werden muss (die allerdings hier auch nicht zum Ziel führt).

[[Image:damenproblem-graph-failure.png|500px|center]]

Nach einigen weiteren Sackgassen findet man schließlich den Pfad A2, B4, C1, D3, der im folgenden Graphen grün markiert ist und der obigen Lösung entspricht:

[[Image:damenproblem-graph-success.png|500px|center]]

=== Test, ob ein ungerichteter Graph azyklisch ist ===

Ein zusammenhängender ungerichteter Graph ist azyklisch (also ein Baum) genau dann, wenn es nur einen möglichen Weg von jedem Knoten zu jedem anderen gibt. (Bei gerichteten Graphen sind die Verhältnisse komplizierter. Wir behandeln dies weiter unten.) Das kann man mittels Tiefensuche leicht feststellen: Die Kante, über die wir einen Knoten erstmals erreichen, ist eine Baumkante des Tiefensuchbaums. Erreichen wir einen bereits besuchten Knoten nochmals über eine andere Kante, haben wir einen Zyklus gefunden. Dabei müssen wir allerdings beachten, dass in einem ungerichteten Graphen jede Baumkante zweimal gefunden wird, einmal in Richtung vom Vater zum Kind und einmal in umgekehrter Richtung. Im zweiten Fall endet die Kante zwar in einem bereits besuchten Knoten (dem Vater), aber es entsteht dadurch kein Zyklus. Den Vaterknoten müssen wir deshalb überspringen, wenn wir über die Nachbarn iterieren:

def undirected_cycle_test(graph): # Annahme: der Graph ist zusammenhängend
# (andernfalls führe den Algorithmus für jede Zusammenhangskomponente aus)
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node, from_node): # rekursive Hilfsfunktion: gibt True zurück, wenn Zyklus gefunden wurde
if not visited[node]: # wenn node noch nicht besucht wurde
visited[node] = True # markiere node als besucht
for neighbor in graph[node]: # besuche die Nachbarn ...
if neighbor == from_node: # ... aber überspringe den Vaterknoten
continue
if visit(neighbor, node): # ... signalisiere, wenn rekursiv ein Zyklus gefunden wurde
return True
return False # kein Zyklus gefunden
else:
return True # Knoten schon besucht => Zyklus

startnode = 0 # starte bei beliebigem Knoten (hier: Knoten 0)
return visit(startnode, startnode) # gebe True zurück, wenn ein Zyklus gefunden wurde

Wenn wir einen Zyklus finden, wird das weitere Traversieren das Graphen abgebrochen, denn ein Graph, der einmal zyklisch war, kann später nicht wieder azyklisch werden. Die notwendige Modifikation für unzusammenhängende Graphen erfolgt analog zum Algorithmus für die Detektion von Zusammenhangskomponenten, der im nächsten Abschnitt beschrieben wird.

=== Finden von Zusammenhangskomponenten ===

Das Auffinden und Markieren von Zusammenhangskomponenten (also maximalen zusammenhängenden Teilgraphen) ist eine grundlegende Aufgabe in ungerichteten, unzusammenhängenden Graphen (bei gerichteten Graphen sind die Verhältnisse wiederum komplizierter, siehe unten). Zwei Knoten u und v gehören zur selben Zusammenhangskomponente genau dann, wenn es einen Pfad von u nach v gibt (da der Graph ungerichtet ist, gibt es dann auch einen Pfad von v nach u). Man sagt auch, dass "v von u aus erreichbar" ist. Unzusammenhängende Graphen entstehen in der Praxis häufig, wenn die Kanten gewisse Relationen zwischen den Knoten kodieren:
* Wenn die Knoten Städte sind und die Kanten Straßen, sind diejenigen Städte in einer Zusammenhangskomponente, die per Auto von einander erreichbar sind. Unzusammenhängende Graphen entstehen hier beispielsweise, wenn eine Insel nicht durch eine Brücke erschlossen ist, wenn Grenzen gesperrt sind oder wenn ein Gebirge zu unwegsam ist, um Straßen zu bauen.
* Wenn Knoten Personen sind, und Kanten die Eltern-Kind-Relation beschreiben, so umfasst jede Zusammenhangskomponenten die Verwandten (auch wenn sie nur über viele "Ecken" verwandt sind).
* In der Bildverarbeitung entsprechen Knoten den Pixeln, und dieselben werden durch eine Kante verbunden, wenn sie zum selben Objekt gehören. Die Zusammenhangskomponenten entsprechen somit den Objekten im Bild (siehe Übungsaufgabe).
Die Zusammenhangskomponenten bilden eine Äquivalenzrelation. Folglich kann für jede Komponente ein Reprässentant bestimmt werden, der sogenannte "Anker". Kennt jeder Knoten seinen Anker, ist das Problem der Zusammenhangskomponenten gelöst.

==== Lösung mittels Tiefensuche ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden. Anstelle der property map <tt>visited</tt> verwenden wir diesmal eine property map <tt>anchors</tt>, die für jeden Knoten die Knotennummer des zugehörigen Ankers angibt, oder <tt>None</tt>, wenn der Knoten noch nicht besucht wurde. Dabei verwenden wir wieder die Konvention, dass Anker auf sich selbst zeigen. Für viele Anwendungen ist es außerdem (oder stattdessen) zweckmäßig, die Zusammenhangskomponenten mit einer laufenden Nummer, einem sogenannten Label, durchzuzählen. Dann kann man zusätzliche Informationen zu jeder Komponente (beispielsweise deren Größe) einfach in einem Array speichern, das über die Labels indexiert wird. Die folgende Version der Tiefensuche bestimmt sowohl die Anker als auch die Labels für jeden Knoten:

def connectedComponents(graph):
anchors = [None] * len(graph) # property map für Anker jedes Knotens
labels = [None] * len(graph) # property map für Label jedes Knotens

def visit(node, anchor):
"""anchor ist der Anker der aktuellen ZK"""
if anchors[node] is None: # wenn node noch nicht besucht wurde:
anchors[node] = anchor # setze seinen Anker
labels[node] = labels[anchor] # und sein Label
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor, anchor)

current_label = 0 # Zählung der ZK beginnt bei 0
for node in xrange(len(graph)):
if anchors[node] is None: # Anker noch nicht bekannt => neue ZK gefunden
labels[node] = current_label # Label des Ankers setzen
visit(node, node) # Knoten der neuen ZK rekursiv suchen
current_label += 1 # Label für die nächste ZK hochzählen
return anchors, labels
Interessant ist hier die Schleife über alle Knoten des Graphen am Ende des Algorithmus, die bei den bisherigen Versionen der Tiefensuche nicht vorhanden war. Um ihre Funktionsweise zu verstehen, nehmen wir für den Moment an, dass der Graph zusammenhängend ist. Dann findet diese Schleife den ersten Knoten des Graphen und führt die Tiefensuche mit diesem Knoten als Startknoten aus. Sobald die Rekursion zurückkehrt, sind alle Knoten des Graphen besucht (weil der Graph ja zusammenhängend war), so dass die Schleife alle weiteren Knoten überspringt (die if-Anweisung liefert für keinen weiteren Knoten True). Bei unzusammenhängenden Graphen dagegen erreicht die Tiefensuche nur die Knoten derselben Komponente, die im weiteren Verlauf der Schleife übersprungen werden. Findet die if-Anweisung jetzt einen noch nicht besuchten Knoten, muss dieser folglich in einer neuen Komponente liegen. Wir verwenden diesen Knoten als Anker und bestimmen die übrigen Knoten dieser Komponente wiederum mit Tiefensuche.

* Beispiel: ... under construction 

Man erkennt, dass die Tiefensuche nach dem Anlagerungsprinzip vorgeht: Beginnend vom einem Startknoten (dem Anker) werden die Knoten der aktuellen Komponente nach und nach an den Tiefensuchbaum angehangen. Erst, wenn nichts mehr angelagert werden kann, geht der Algorithmus zur nächsten Komponente über.

==== Lösung mittels Union-Find-Algorithmus ====

Im Gegensatz zum Anlagerungsprinzip sucht der Union-Find-Algorithmus die Zusammenhangskomponenten mit dem Verschmelzungsprinzip: Eingangs wird jeder Knoten als ein Teilgraph für sich betrachtet. Dann iteriert man über alle Kanten und verbindet deren Endknoten jeweils zu einem gemeinsamen Teilgraphen (falls die beiden Enden einer Kante bereits im selben Teilgraphen liegen, wird diese Kante ignoriert). Solange noch Kanten vorhanden sind, werden dadurch immer wieder Teilgraphen in größere Teilgraphen verschmolzen. Am Ende bleiben die maximalen zusammenhängenden Teilgraphen (also gerade die Zusammenhangskomponenten) übrig. Dieser Algorithmus kommt ohne Tiefensuche aus und ist daher in der Praxis oft schneller, allerdings auch etwas komplizierter zu implementieren.

Der Schlüssel des Algorithmus ist eine Funktion <tt>findAnchor()</tt>, die zu jedem Knoten den aktuellen Anker sucht. Der Anker existiert immer, da jeder Knoten von Anfang an zu einem Teilgraphen gehört (anfangs ist jeder Teilgraph trivial und besteht nur aus dem Knoten selbst). Die Verschmelzung wird realisiert, indem der Anker des einen Teilgraphen seine Rolle verliert und stattdessen der Anker des anderen Teilgraphen eingesetzt wird.

Zur Verwaltung der Anker verwenden wir wieder eine property map <tt>anchors</tt> mit der Konvention, dass die Anker auf sich selbst verweisen. Es wäre jedoch zu teuer, wenn man bei jeder Verschmelzung alle Anker-Einträge der beteiligten Knoten aktualisieren müsste, da jeder Knoten im Laufe des Algorithmus mehrmals seinen Anker wechseln kann. Statt dessen definiert man Anker rekursiv: Verweist ein Knoten auf einen Anker, der mittlerweile diese Rolle verloren hat, folgt man dem Verweis von diesem Knoten (dem ehemaligen Anker) weiter, bis man einen tatsächlichen Anker gefunden hat - erkennbar daran, dass er auf sich selbst verweist. Diese Suchfunktion kann folgendermassen implementiert werden:

def findAnchor(anchors, node):
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
return node

Allerdings kann diese Kette im Laufe vieler Verschmelzungen sehr lang werden, so dass das Verfolgen der Kette teuer wird. Man vermeidet dies durch die sogenannte Pfadkompression: Immer, wenn man den Anker gefunden hat, aktualisiert man den Eintrag am Anfang der Kette. Die Funktion <tt>findAnchor()</tt> wird dadurch nur wenig komplizierter:

def findAnchor(anchors, node):
start = node # wir merken uns den Anfang der Kette
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
anchors[start] = node # Pfadkompression: aktualisiere den Eintrag am Anfang der Kette
return node

Man kann zeigen, dass die Ankersuche mit Pfadkompression zu einer fast konstanten amortisierten Laufzeit pro Aufruf führt.

Um mit jeder Kante des (ungerichteten) Graphen nur maximal einmal eine Verschmelzung durchzuführen, betrachten wir jede Kante nur in der Richtung von der kleineren zur größeren Knotennummer, die umgekehrte Richtung wird ignoriert. Außerdem ist es zweckmäßig, bei jeder Verschmelzung denjenigen Anker mit der kleineren Knotennummer als neuen Anker zu übernehmen. Dann gilt für jede Zusammenhangskomponente, dass gerade der Knoten mit der kleinsten Knotennummer der Anker ist (genau wie bei der Lösung mittels Tiefensuche), was die weitere Analyse vereinfacht, z.B. die Zuordnung der Labels zu den Komponenten am Ende des Algorithmus.

def unionFindConnectedComponents(graph):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker

for node in xrange(len(graph)): # iteriere über alle Knoten
for neighbor in graph[node]: # ... und über deren ausgehende Kanten
if neighbor < node: # ignoriere Kanten, die in falscher Richtung verlaufen
continue
# hier landen wir für jede Kante des Graphen genau einmal
a1 = findAnchor(anchors, node) # finde Anker ...
a2 = findAnchor(anchors, neighbor) # ... der beiden Endknoten
if a1 < a2: # Verschmelze die beiden Teilgraphen
anchors[a2] = a1 # (verwende den kleineren der beiden Anker als Anker des
elif a2 < a1: # entstehenden Teilgraphen. Falls node und neighbor
anchors[a1] = a2 # den gleichen Anker haben, waren sie bereits im gleichen
# Teilgraphen, und es passiert hier nichts.)
# Bestimme jetzt noch die Labels der Komponenten
labels = [None]*len(graph) # Initialisierung der property map für Labels
current_label = 0 # die Zählung beginnt bei 0
for node in xrange(len(graph)):
a = findAnchor(anchors, node) # wegen der Pfadkompression zeigt jeder Knoten jetzt direkt auf seinen Anker
if a == node: # node ist ein Anker
labels[a] = current_label # => beginne eine neue Komponente
current_label += 1 # und zähle Label für die nächste ZK hoch
else:
labels[node] = labels[a] # node ist kein Anker => setzte das Label des Ankers
# (wir wissen, dass labels[a] bereits gesetzt ist, weil
# der Anker immer der Knoten mit der kleinsten Nummer ist)
return anchors, labels

* Beispiel: ... under construction

== Kürzeste Wege (Pfade) ==

Eine weitere grundlegende Aufgabe in Graphen ist die Bestimmung eines kürzesten Weges zwischen zwei gegebenen Knoten. Dies hat offensichtliche Anwendungen bei Routenplanern und Navigationssystemen und ist darüber hinaus wichtiger Bestandteil anderer Algorithmen, z.B. bei der Berechnung eines maximalen Flusses mit der [http://en.wikipedia.org/wiki/Edmonds%E2%80%93Karp_algorithm Methode von Edmonds und Karp].

=== Kürzeste Wege in ungewichteten Graphen mittels Breitensuche ===

Im Fall eines ungewichteten Graphen ist die Länge eines Weges einfach durch die Anzahl der durchlaufenen Kanten definiert. Daraus folgt, dass kürzeste Pfade mit einer leicht angepassten Version der Breitensuche gefunden werden können: Aufgrund des first in-first out-Verhaltens der Queue betrachtet die Breitensuche alle (erreichbaren) Knoten in der Reihenfolge ihres Abstandes vom Startknoten. Wenn wir den Zielknoten zum ersten Mal erreichen, und der gerade gefundene Weg vom Start zum Ziel hat die Länge L, muss dies der kürzeste Weg sein: Alle möglichen Wege der Länge L' < L hat die Breitensuche ja bereits betrachtet, ohne dass dabei der Zielknoten erreicht wurde. Daraus folgt übrigens eine allgemeine Eigenschaft aller Algorithmen für kürzeste Wege: Wenn der kürzeste Weg vom Start zum Ziel die Länge L hat, finden diese Algorithmen als Nebenprodukt auch die kürzesten Wege zu allen Knoten, für die L' < L gilt.

Um den Algorithmus zu implementieren, passen wir die Breitensuche so an, dass anstelle der property map <tt>visited</tt> eine property map <tt>parents</tt> verwendet wird, die für jeden besuchten Knoten den Vaterknoten im Breitensuchbaum speichert. Durch Rückverfolgen der <tt>parent</tt>-Kette können wir den Pfad vom Ziel zum Start rekonstruieren, und durch Umdrehen der Reihenfolge erhalten wir den gesuchten Pfad vom Start zum Ziel. Sobald der Zielknoten erreicht wurde, können wir die Breitensuche abbrechen (<tt>break</tt>-Befehl in der ersten <tt>while</tt>-Schleife). Falls der gegebene Graph unzusammenhängend ist, kann es passieren, dass gar kein Weg gefunden wird, weil Start und Ziel in verschiedenen Zusammenhangskomponenten liegen. Dies erkennen wir daran, dass die Breitensuche beendet wurde, ohne den Zielknoten zu besuchen. Dann gibt die Funktion statt eines Pfades dern Wert <tt>None</tt> zurück:

from collections import deque

def shortestPath(graph, startnode, destination):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Breitensuchbaum
parents[startnode] = startnode # startnode ist die Wurzel des Baums => verweist auf sich selbst

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # Besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn sie noch nicht besucht wurden
parents[neighbor] = node # setze node als Vaterknoten
q.append(neighbor) # und füge neighbor in die Queue ein

if parents[destination] is None: # Breitensuche wurde beendet ohne den Zielknoten zu besuchen
return None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path # gefundenen Pfad zurückgeben

=== Gewichtete Graphen ===

Das Problem der Suche nach kürzesten Wegen wird wesentlich interessanter und realistischer, wenn wir zu gewichteten Graphen übergehen:

; Definition - kantengewichteter Graph
: Jeder Kante (s,t) des Graphen ist eine reelle oder natürliche Zahl wst zugeordnet, die üblicherweise als ''Kantengewicht'' bezeichnet wird.

; Definition - knotengewichteter Graph
: Jedem Knoten v des Graphen ist eine reelle oder natürliche Zahl wv zugeordnet, die üblicherweise als ''Knotengewicht'' bezeichnet wird.

Je nach Anwendung benötigt man Knoten- oder Kantengewichte oder auch beides zugleich. Wir beschränken uns in der Vorlesung auf kantengewichtete Graphen. Beispiele für die Informationen, die man durch Kantengewichte ausdrücken kann, sind
* wenn die Knoten Orte sind: Abstand von Anfangs- und Endknoten jeder Kante (z.B. Luftline oder Straßenentfernung), Fahrzeit zwischen den Orten
* wenn der Knoten ein Rohrnetzwerk beschreibt: Durchflusskapazität der einzelnen Rohre (für max-Flussprobleme), analog bei elektrischen Netzwerken: elektrischer Widerstand
* wenn die Knoten Währungen repräsentieren, können deren Wechselkurse durch Kantengewichte angegeben werden.
Bei einigen Beispielen ergeben sich unterschiedliche Kantengewichte, wenn eine Kante von s nach t anstatt von t nach s durchlaufen wird. Beispielsweise können sich die Fahrzeiten erheblich unterscheiden, wenn es in einer Richtung bergauf, in der anderen bergab geht, obwohl die Entfernung in beiden Fällen gleich ist. Hier ergibt sich natürlicherweise ein gerichteter Graph. In anderen Beispielen (z.B. bei Luftlinienentfernungen, in guter Näherung auch bei Straßenentfernungen) sind die Gewichte von der Richtung unabhängig, so dass wir ungerichtete Graphen verwenden können.

Die Repräsentation der Kantengewichte im Programm richtet sich nach der Repräsentation des Graphen selbst. Am einfachsten ist wiederum die Adjazenzmatrix, die aber nur für dichte Graphen (<math>E = O(V^2)</math>, mit E als Anzahl der Kanten und V als Anzahl der Knoten) effizient ist. Bei gewichteten Graphen gibt das Matrixelement aij das Gewicht der Kante i ⇒ j (wobei aij = 0 gesetzt wird, wenn diese Kante nicht existiert). Wie zuvor gilt für ungerichtete Graphen aij = aji (symmetrische Matrix), während dies für gerichtete Graphen nicht gelten muss.

Bei Graphen in Adjazenzlistendarstellung hat es sich bewährt, die Gewichte in einer property map zu speichern. Weiter oben haben wir bereits property maps für Knoteneigenschaften (z.B. <tt>visited</tt> und <tt>anchors</tt>) gesehen. Property maps für Kanten funktionieren ganz analog, allerdings muss man jetzt Paare von Knoten (nämlich Anfangs- und Endknoten der Kante) als Schlüssel verwenden und die Daten entsprechend in einem assoziativen Array ablegen:
w = weights[(i,j)] # Zugriff auf das Gewicht der Kante i ⇒ j
Alternativ könnte man auch die Graph-Datenstruktur selbst erweitern, aber dies ist weniger zu empfehlen, weil jeder Algorithmus andere Erwiterungen benötigt und damit die Datenstruktur sehr unübersichtlich würde.

Der kürzeste Weg ist nun definiert als der Weg, bei dem die Summe der Kantengewichte minimal ist:
;Definition - Problem des kürzesten Weges
: Sei P die Menge aller Wege von u nach v, und <math>p \in P</math> einer dieser Wege. Wenn der Grpah einfach ist (es also keine Mehrfachkanten zwischen denselben Knoten und keine Schleifen gibt), ist der Weg p durch die Folge der besuchten Knoten eindeutig bestimmt:
: <math>p : \ \ u = x_0 \rightarrow x_1 \rightarrow x_2 \rightarrow ... \rightarrow v = x_{n_p}</math>
:wo <math>n_p</math> die Anzahl der Kanten im Weg p ist. Seine Kosten Wp ergeben sich als Summer der Gewichte der einzelnen Kanten
: <math>W_p = \sum_{k=1}^{n_p} w_{x_{k-1}x_k}</math>
: und ein kürzester Weg <math>p^* \in P</math> ist ein Weg mit minimalen Kosten
: <math>p^* = \textrm{argmin}_{p\in P}\ \ W_p</math>
: Das Problem des kürzesten Weges besteht darin, einen optimalen Weg p* zwischen gegebenen Knoten u und v zu finden.
Die Lösung dieses Problems hängt davon ab, ob alle Kantengewichte positiv sind, oder ob es auch negative Kantengewichte gibt. In letzeren Fall ist es möglich, durch eine Verlängerung des Weges die Kosten zu redizieren, während sich im ersteren Fall die Kosten immer erhöhen, wenn man den Weg verlängert.

Negative Gewichte treten z.B. bei den Währungsgraphen auf. Auf den ersten Blick entsprechen diese Graphen nicht den Anforderungen an das Problem des kürzesten Weges, weil Wechselkurse miteinander (und mit Geldbeträgen) multipliziert anstatt addiert werden. Man beseitigt diese Schwierigkeit aber leicht, indem man die Logarithmen der Wechselkurse als Kantengewichte verwendet, wodurch sich die Multiplikation in eine Addition der Logarithmen verwandelt. Wechselkurse < 1 führen nun zu negativen Gewichten.

Interessant werden negative Gewichte vor allem in Graphen mit Zyklen. Dann kann es nämlich passieren, dass die Gesamtkosten eines Zyklus ebenfalls negativ sind. Jeder Weg, der den Zyklus enthält, hat dann Kosten von <math>-\infty</math>, weil man den Zyklus beliebig oft durchlaufen und dadurch die Gesamtkosten immer weiter verkleinern kann:

/\ 1. Durchlauf: Kosten -1
1 / \ -4 2. Durchlauf: Kosten -2
/____\ etc.
2

Um hier nicht in einer Endlosschleife zu landen, benötigt man spezielle Algorithmen, die mit dieser Situation umgehen können. Der [http://de.wikipedia.org/wiki/Bellman-Ford-Algorithmus Algorithmus von Bellmann und Ford] beispielsweise bricht die Suche nach dem kürzesten Weg ab, sobald er einen negativen Zyklus entdeckt, aber andernfalls kann er negative Gewichte problemlos verarbeiten.

Die Detektion negativer Zyklen hat wiederum eine interessante Anwendung bei Währungsgraphen: Ein Zyklus bedeutet hier, dass man Geld über mehrere Stufen von einer Währung in die nächste und am Schluß wieder in die Originalwährung umtauscht, und ein negativer Zyklus führt dazu, dass man am Ende mehr Geld besitzt als am Anfang (damit negative Zyklen wirklich einen Gewinn bedeuten und keinen Verlust, müssen die Wechselkurse vor der Logarithmierung in [http://de.wikipedia.org/wiki/Wechselkurs#Nominaler_Wechselkurs Preisnotierung] angegeben sein). Bei Privatpersonen ist dies ausgeschlossen, weil die Umtauschgebühren den möglichen Gewinn mehr als aufzehren. Banken mit direktem weltweitem Börsenzugang hingegen unternehmen große Anstrengungen, um solche negativen Zyklen möglichst schnell (nämlich vor der Konkurrenz) zu entdecken und auszunutzen. Diese Geschäftsmethode bezeichnet man als [http://de.wikipedia.org/wiki/Arbitrage Arbitrage] und die Existenz eines negativen Zyklus als Arbitragegelegenheit. Durch die Kursschwankungen (und durch die ausgleichende Wirkung der Arbitragegeschäfte selbst) existieren die Arbitragegelegenheiten nur für kurze Zeit, und ihre Detektion erfordert leistungsfähige Echtzeitalgorithmen.

In dieser Vorlesung beschränken wir uns hingegen auf Graphen mit ausschließlich positiven Gewichten. In diesem Fall ist der Algorithmus von Dijkstra die Methode der Wahl, weil er wesentlich schneller arbeitet als der Bellmann-Ford-Algorithmus.

=== Algorithmus von Dijkstra ===

==== Edsger Wybe Dijkstra ====

geb. 11. Mai 1930 in Rotterdam

ges. 06. August 2002

Dijkstra war ein niederländischer Informatiker und Wegbereiter der strukturierten Programmierung. 1972 erhielt er für seine Leistung in der Technik und Kunst der Programmiersprachen den Turing Award, der jährlich von der Association for Computing Machinery (ACM) an Personen verliehen wird, die sich besonders um die Entwicklung der Informatik verdient gemacht haben. Zu seinen Beiträgen zur Informatik gehören unter anderem der Dijkstra-Algorithmus zur Berechnung des kürzesten Weges in einem Graphen sowie eine Abhandlung über den go-to-Befehl und warum er nicht benutzt werden sollte. Der go-to-Befehl war in den 60er und 70er Jahren weit verbreitet, führte aber zu Spaghetti-Code. In seinem berühmten Paper "A Case against the GO TO Statement"[http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF], das als Brief mit dem Titel "Go-to statement considered harmful" veröffentlicht wurde, argumentiert Dijkstra, dass es umso schwieriger ist, dem Quellcode eines Programmes zu folgen, je mehr go-to-Befehle darin enthalten sind und zeigt, dass man auch ohne diesen Befehl gute Programme schreiben kann.

==== Algorithmus ====

Der Dijkstra-Algorithmus für kürzeste Wege ist dem oben vorgestellten Algorithmus <tt>shortestPath()</tt> auf der Basis von Breitensuche sehr ähnlich. Insbesondere gilt auch hier, dass neben dem kürzesten Weg vom Start zum Ziel auch alle kürzesten Wege gefunden werden, deren Endknoten dem Start näher sind als der Zielknoten. Aufgrund der Kantengewichte gibt es aber einen wichtigen Unterschied: Der erste gefundene Weg zu einem Knoten ist nicht mehr notwendigerweise der kürzeste. Wir bestimmen deshalb für jeden Knoten mehrere Kandidatenwege und verwenden eine Prioritätswarteschlange (statt einer einfachen First in - First out - Queue), um diese Wege nach ihrer Länge zu sortieren. Die Kandidatenwege für einen gegebenen Knoten werden unterschieden, indem wir auch den Vorgängerknoten im jeweiligen Weg speichern. Wenn ein Knoten erstmals an die Spitze der Prioritätswarteschlange gelangt, haben wir den kürzesten Weg zu diesem Knoten gefunden (das wird weiter unten formal bewiesen), und der Vorgänger des Knotens in diesem Weg wird zu seinem Vaterknoten. Erscheint derselbe Knoten später nochmals an der Spitze der Prioritätswarteschlange, handelt es sich um einen Kandidatenweg, der sich nicht als kürzester erwiesen hat und deshalb ignoriert werden kann. Wir erkennen dies leicht daran, dass der Vaterknoten in der property map <tt>parents</tt> bereits gesetzt ist.

Eine geeignete Datenstruktur für die Prioritätswarteschlange wird durch das Python-Modul [http://docs.python.org/library/heapq.html heapq] realisiert. Es verwendet ein normales Pythonarray als unterliegende Repräsentation für einen Heap und stellt effiziente <tt>heappush</tt> und <tt>heappop</tt>-Funktionen zur Verfügung. Dies entspricht genau unserer Vorgehensweise im Kapitel [[Prioritätswarteschlangen]]. Als Datenelement erwartet die Funktion <tt>heappush</tt> ein Tupel, dessen erstes Element die Priorität sein muss. Die übrigen Elemente des Tupels (und damit auch deren Anzahl) können je nach Anwendung frei festgelegt werden. Wir legen fest, dass das zweite Element den Endknoten des betrachteten Weges und das dritte den Vorgängerknoten speichert.

Die Kantengewichte werden dem Algorithmus in der property map <tt>weights</tt> übergeben:

<code python>
import heapq # heapq implementiert die Funktionen für Heaps

def dijkstra(graph, weights, startnode, destination):
parents = [None]*len(graph) # registriere für jeden Knoten den Vaterknoten im Pfadbaum

q = [] # Array q wird als Heap verwendet
heapq.heappush(q, (0.0, startnode, startnode)) # Startknoten in Heap einfügen

while len(q) > 0: # solange es noch Knoten im Heap gibt:
length, node, predecessor = heapq.heappop(q) # Knoten aus dem Heap nehmen
if parents[node] is not None: # parent ist schon gesetzt => es gab einen anderen, kürzeren Weg
continue # => wir können diesen Weg ignorieren
parents[node] = predecessor # parent setzen
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # die Nachbarn von node besuchen,
if parents[neighbor] is None: # aber nur, wenn ihr kürzester Weg noch nicht bekannt ist
newLength = length + weights[(node,neighbor)] # berechne Pfadlänge zu neighbor
heapq.heappush(q, (newLength, neighbor, node)) # und füge neighbor in den Heap ein

if parents[destination] is None: # Suche wurde beendet ohne den Zielknoten zu besuchen
return None, None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path, length # gefundenen Pfad und dessen Länge zurückgeben
</code>
Die wesentlichen Unterschiede zur Breitensuche sind im Code rot markiert: Anstelle der Queue verwenden wir jetzt einen Heap, und der Startknoten wird mit Pfadlänge 0 als erstes eingefügt. In der Schleife <tt>while len(q) > 0:</tt> wird jeweils der Knoten <tt>node</tt> mit der aktuell kürzesten Pfadlänge aus dem Heap entfernt. Die Pfadlänge vom Start zu diesem Knoten wird in der Variable <tt>length</tt> gespeichert, sein Vorgänger in der Variable <tt>predecessor</tt>. Wenn der aktuelle Weg nicht der kürzeste ist (<tt>parents[node]</tt> war bereits gesetzt), wird dieser Weg ignoriert. Andernfalls werden die property map <tt>parents</tt> aktualisiert und die Nachbarn von <tt>node</tt> besucht. Beim Scannen der Nachbarn berechnen wir zunächst die Länge <tt>newLength</tt> das Weges <tt>startnode => node => neighbor</tt> als Summe von <tt>length</tt> und dem Gewicht der Kante <tt>(node, neighbode)</tt>. Diese Länge wird beim Einfügen des Nachbarknotens in den Heap zur Priorität des aktuellen Weges.

Die wichtigsten Prinzipien des Dijkstra-Algorithmus noch einmal im Überblick:
* Der Dijkstra-Algorithmus ist Breitensuche mit Prioritätswarteschlange (Heap) statt einer einfache Warteschlange (Queue).
* Die Prioritätswarteschlange speichert alle Wege, die bereits gefunden worden sind und ordnet sie aufsteigend nach ihrer Länge.
* Das Sortieren (und damit der ganze Algorithmus) funktioniert nur mit positiven Kantengewichten korrekt.
* Da ein Knoten auf mehreren Wegen erreichbar sein kann, kann er auch mehrmals im Heap sein.
* Wenn ein Knoten erstmals aus der Prioritätswarteschlange entnommen wird, ist der gefundene Weg der kürzeste zu diesem Knoten. Andernfalls wird der Weg ignoriert.
* Wenn der Knoten <tt>destination</tt> aus dem Heap entnommen wird, ist der kürzeste Weg von Start nach Ziel gefunden, und die Suche kann beendet werden.
In unserer Implementation können, wie gesagt, mehrere Wege zum selben Knoten gleichzeitig in der Prioritätswarteschlange sein. Im Prinzip wäre es auch möglich, immer nur den besten zur Zeit bekannten Weg zu jedem Enknoten in der Prioritätswarteschlange zu halten - sobald ein besserer Kandidat gefunden wird, ersetzt er den bisherigen Kandidaten, anstatt zusätzlich eingefügt zu werden. Dies erfordert aber eine wesentlich kompliziertere Prioritätswarteschlange, die eine effiziente <tt>updatePriority</tt>-Funktion anbietet, ohne dass dadurch eine signifikante Beschleunigung erreicht wird. Deshalb verfolgen wir diesen Ansatz nicht.

==== Beispiel ====

under construction

[[Image:Bsp.jpg]]

==== Komplexität von Dijkstra ====

Zur Analyse der Komplexität nehmen wir an, dass der Graph V Knoten und E Kanten hat. Die Initialisierung der property map <tt>parents</tt> am Anfang der Funktion hat offensichtlich Komplexität O(V), weil Speicher für V Knoten allokiert wird. Der Code am Ende der Funktion, der aus der property map <tt>parents</tt> den Pfad extrahiert, hat ebenfalls die Komplexität O(V), weil der Pfad im ungünstigen Fall sämtliche Knoten des Graphen umfasst. Beides wird durch die Komplexität der Hauptschleife dominiert, zu deren Analyse wir den folgenden Codeausschnitt genauer anschauen wollen:

while len(q) > 0:
... # 1
if parents[node] is not None:
continue
parents[node] = predecessor
... # 2
Wir erkennen, dass der Codeabschnitt <tt># 2</tt> für jeden Knoten höchstens einmal erreicht werden kann: Da <tt>parents[node]</tt> beim ersten Durchlauf gesetzt wird, kann die <tt>if</tt>-Abfrage beim gleichen Knoten nie wieder <tt>False</tt> liefern, und das nachfolgende <tt>continue</tt> bewirkt, dass der Abschnitt <tt># 2</tt> dann übersprungen wird. Man sagt auch, dass jeder Knoten höchstens einmal expandiert wird, auch wenn er mehrmals im Heap war.

Der Codeabschnitt <tt># 2</tt> selbst enthält eine Schleife über alle ausgehenden Kanten des Knotens <tt>node</tt>. Im ungünstigsten Fall iterieren wir bei allen Knoten über alle ausgehenden Kanten, aber das sind gerade alle Kanten des Graphen je einmal in den beiden möglichen Richtungen. Die Funktion <tt>heappush</tt> wird sogar höchstens E Mal aufgerufen, weil eine Kante nur in den Heap eingefügt wird, wenn der kürzeste Weg der jeweiligen Endknotens noch nicht bekannt ist (siehe die <tt>if</tt>-Abfrage in der <tt>for</tt>-Schleife), und das ist nur ein einer Richtung möglich. Dies hat zwei Konsequenzen:
* Die Schleife <tt>while len(q) > 0:</tt> wird nur so oft ausgeführt, wie Elemente im Heap sind, also höchstens E Mal. Das gleiche gilt für den Codeabschnitt <tt># 1</tt>, der das <tt>heappop</tt> enthält.
* Die Operationen <tt>heappush</tt> und <tt>heappop</tt> haben logarithmische Komplexität in der Größe des Heaps, sind also in <math>O(\log\,E)</math>. In einfachen Graphen gilt aber <math>E = O(V^2)</math>, so dass sich die Komplexität der Heapoperationen vereinfacht zu <math>O(\log\,E)=O(\log\,V^2)=O(2\log\,V)=O(\log\,V)</math>.
Zusammenfassend gilt: <tt>heappush</tt> und <tt>heappop</tt> werden maximal E Mal aufgerufen und haben eine Komplexität in <math>O(\log\,V)</math>. Folglich hat der Algorithmus von Dijkstra die Komplexität:
:<math>O(E\,\log\,V)</math>

==== Vergleich mit Breitensuche und Tiefensuche ====

Der Dijkstra-Algorithmus ist eng mit der Breiten- und Tiefensuche verwandt - man kann diese Algorithmen aus dem Dijkstra-Algorithmus gewinnen, indem man einfach die Regel zur Festlegung der Prioritäten ändert. Anstelle der Länge des Pfades verwenden wir als Priorität den Wert eine Zählvariable <tt>count</tt>, die nach jeder Einfügung in den Heap (also nach jedem Aufruf von <tt>heappush</tt>) aktualisiert wird. Zählen wir die Variable hoch, haben die zuerst eingefügten Kanten die höchste Priorität, der Heap verhält sich also wie eine Queue (First in-First out), und wir erhalten eine Breitensuche. Zählen wir die Variable hingegen (von E beginnend) herunter, haben die zuletzt eingefügten Kanten höchste Priorität. Der Heap verhält sich dann wie ein Stack (Last in-First out), und wir bekommen Tiefensuche. Statt eines Heaps plus Zählvariable kann man jetzt natürlich direkt eine Queue bzw. einen Stack verwenden. Dadurch fällt der Aufwand <math>O(\log\,V)</math> für die Heapoperationen weg und wird durch die effizienten O(1)-Operationen von Queue bzw. Stack ersetzt. Damit erhalten wir für Breiten- und Tiefensuche die schon bekannte Komplexität O(E).

==== Korrektheit von Dijkstra ====

Wir beweisen mittels vollständiger Induktion die Schleifen-Invariante: Falls <tt>parents[node]</tt> gesetzt (also ungleich <tt>None</tt>) ist, dann liefert das Zurückverfolgen des Weges von <tt>node</tt> nach <tt>startnode</tt> den kürzesten Weg.
;Induktionsanfang: <tt>parents[startnode]</tt> ist als einziges gesetzt. Zurückverfolgen liefert den trivialen Weg <tt>[startnode]</tt>, der mit Länge 0 offensichtlich der kürzeste Pfad ist → die Bedingung ist erfüllt.
;Induktionsschritt: Wir zeigen mit einem indirektem Beweis, dass wir immer einen kürzesten Weg bekommen, wenn <tt>parents[node]</tt> gesetzt wird.
:Sei <math>S</math> = <tt>{v | parents[v] is not None}</tt> die Menge aller Knoten, von denen wir den kürzesten Weg schon kennen (Induktionsvoraussetzung), und <tt>node</tt> der Knoten, der sich gerade an der Spitze des Heaps befindet. Dann ist <tt>predecessor</tt> der Vorgänger von <tt>node</tt> im aktuellen Weg, und es muss <tt>predecessor</tt><math>\in S</math> gelten, weil die Nachbarn von <tt>predecessor</tt> (und damit auch der aktuelle <tt>node</tt>) erst in den Heap eingefügt werden, wenn der kürzeste Weg für <tt>predecessor</tt> gefunden wurde. Man beachte auch, dass alle Knoten, die noch nicht in <math>S</math> enthalten sind, weiter vom Start entfernt sind als alle Knoten in <math>S</math>, weil alle neu in den Heap eingefügten Wege länger sind als der kürzeste Weg des jeweiligen Vorgängers.
:Der indirekte Beweis nimmt jetzt an, dass der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> nicht der kürzeste Weg ist. Dann muss es einen anderen, kürzeren Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> geben. Für den Vorgänger <tt>x</tt> in diesem Weg unterscheiden wir zwei Fälle:
:* <tt>x</tt><math>\in S</math>: In diesem Fall ist die Länge des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> bereits bekannt, und dieser Weg ist in der Prioritätswarteschlange enthalten. Dann kann er aber nicht der kürzeste sein, denn an der Spitze der Warteschlange war nach Voraussetzung der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt>.
:* <tt>x</tt><math>\notin S</math>: Die Kosten des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> berechnen sich als <tt>Kosten(x → startnode) + weight[(x, node)]</tt>, und die Kosten des Weges <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> sind analog <tt>Kosten(predecessor → startnode) + weight[(predecessor, node)]</tt>. Aufgrund der Induktionsvoraussetzung gilt aber <tt>predecessor</tt><math>\in S</math>, und somit <tt>Kosten(predecessor → startnode) < Kosten(x → startnode)</tt>, weil <tt>x</tt> andernfalls vor <tt>predecessor</tt> an der Spitze des Heaps gewesen wäre, was mit der Annahme <tt>x</tt><math>\notin S</math> unverträglich ist. Damit der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> trotzdem der kürzeste Weg sein kann, müsste <tt>Kosten(x → startnode) < Kosten(node → startnode)</tt> gelten, denn durch die Kante <tt>(x, node)</tt> kommen ja noch Kosten hinzu. Das wäre aber nur möglich, wenn der Knoten <tt>x</tt> vor dem Knoten <tt>node</tt> an die Spitze des Heaps gelangt, im Widerspruch zur Annahme, dass <tt>node</tt> sich gerade an der Spitze des Heaps befindet. Somit kann die Behauptung, dass der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> der kürzeste Weg ist, nicht stimmen.
In beiden Fällen erhalten wir einen Widerspruch, und die Behauptung ist somit bewiesen. Da die Invariante insbesondere für den Weg zum Zielknoten <tt>destination</tt> erfüllt ist, folgt daraus auch die Korrektheit des Algorithmus von Dijkstra.

=== A*-Algorithmus - Wie kann man Dijkstra noch verbessern? ===

Eine wichtige Eigenschaft des Dijkstra-Algorithmus ist, dass neben dem kürzesten Weg vom Start zum Ziel auch die kürzesten Wege zu allen Knoten berechnet werden, die näher am Startknoten liegen als das Ziel, obwohl uns diese Wege gar nicht interessieren. Sucht man beispielsweise in einem Graphen mit den Straßenverbindungen in Deutschland den kürzesten Weg von Frankfurt (Main) nach Dresden (ca. 460 km), werden auch die kürzesten Wege von Frankfurt nach Köln (190 km), Dortmund (220 km) und Stuttgart (210 km) und vielen anderen Städten gefunden. Aufgrund der geographischen Lage dieser Städte ist eigentlich von vornherein klar, dass sie mit dem kürzesten Weg nach Dresden nicht das geringste zu tun haben. Anders sieht es mit Erfurt (260 km) oder Suhl (210 km) aus - diese Städte liegen zwischen Frankfurt und Dresden und kommen deshalb als Zwischenstationen des gesuchten Weges in Frage.

Damit Dijkstra korrekt funktioniert, würde es im Prinzip ausreichen, wenn man die kürzesten Wege nur für diejenigen Knoten ausrechnet, die auf dem kürzesten Weg vom Start zum Ziel liegen, denn nur diese Knoten braucht man, um den gesuchten Weg über die <tt>parent</tt>-Kette zurückzuverfolgen. Das Problem ist nur, dass man diese Knoten erst kennt, wenn der Algorithmus fertig durchgelaufen ist. Schließt man Knoten zu früh von der Betrachtung aus, kommt am Ende möglicherweise nicht der korrekte kürzeste Weg heraus.

Der A*-Algorithmus löst dieses Dilemma mit folgender Idee: Ändere die Prioritäten für den Heap so ab, dass unwichtige Knoten nur mit geringerer Wahscheinlichkeit expandiert werden, aber stelle gleichzeitig sicher, dass alle wichtigen Knoten (also diejenigen auf dem korrekten kürzesten Weg) auf jeden Fall expandiert werden. Es zeigt sich, dass man diese Idee umsetzen kann, wenn eine Schätzung für den Restweg (also für die noch verbleibende Entfernung von jedem Knoten zum Ziel) verfügbar ist:
rest = guess(neighbor, destination)
Diese Schätzung addiert man einfach zur wahren Länge des Weges <tt>startnode → node</tt> dazu, um die verbesserte Priorität zu erhalten:
priority = newLength + guess(neighbor, destination)
(Im originalen Dijkstra-Algorithmus wird als Priorität nur <tt>newLength</tt> allein verwendet. Man beachte, dass man <tt>newLength</tt> jetzt zusätzlich im Heap speichern muss, weil man es für die Expansion des Knotens später noch benötigt.)

Damit sicher gestellt ist, dass der A*-Algorithmus immer noch die korrekten kürzesten Wege findet, darf die Schätzung den wahren Restweg niemals überschätzen. Es muss immer gelten:
0 <= guess(node, destination) <= trueDistance(node, destination)
Damit gilt insbesondere <tt>guess(destination, destination) = trueDistance(destination, destination) = 0</tt>, an der Priorität des Knotens <tt>destination</tt> ändert sich also nichts. Die Prioritäten aller anderen Knoten veschlechtern sich hingegen, weil zur bisherigen Priorität noch atwas addiert wird. Für die wichtigen Knoten auf dem kürzesten Weg vom Start nach Ziel gilt jedoch, dass deren neue Priorität immer noch besser ist als die Priorität des Zielknotens selbst. Für diese Knoten gilt nämlich
falls node auf dem kürzesten Weg von startnode nach destination liegt:
trueDistance(startnode, node) + guess(node, destination) <= trueDistance(startnode, destination)
weil der Weg von Start nach <tt>node</tt> ein Teil des kürzesten Wegs von Start nach Ziel ist und die Restschätzung die wahre Entfernung immer unterschätzt. Diese Knoten werden deshalb stets vor dem Zielknoten expandiert, so dass wir die <tt>parent</tt>-Kette immer noch korrekt zurückverfolgen können. Für alle anderen Knoten gilt idealerweise, dass die neue Priorität schlechter ist als die Priorität von <tt>destination</tt>, so dass man sich diese irrelevanten Knotenexpansionen sparen kann.

Für das Beispiel eines Straßennetzwerks bietet sich als Schätzung die Luftlinienentfernung an, weil Straßen nie kürzer sein können als die Luftlinie. Damit erreicht man in der Praxis deutliche Einsparungen. Generell gilt, dass der A*-Algorithmus im typischen Fall schneller ist als der Algorithmus von Dijkstra, aber man kann immer pathologische Fälle konstruieren, wo die Änderung der Prioritäten nichts bringt. Die Komplexität des A*-Algorithmus im ungünstigen Fall ist deshalb nach wie vor <math>O(E\,\log\,V)</math>.

=='''Minimaler Spannbaum'''==
'''(engl.: minimum spanning tree; abgekürzt: MST)'''

[[Image:Minimum_spanning_tree.png‎ |thumb|200px|right|Ein minimal aufspannender Baum verbindet alle Punkte eines Graphen bei minimaler Kantenlänge ([http://de.wikipedia.org/wiki/Spannbaum Quelle])]]

:''gegeben'': gewichteter Graph G, zusammenhängend 
:''gesucht'': Untermenge <math>E'\subseteq E</math> der Kanten, so dass die Summe der Kantengewichte <math>\sum_{e\in E'} w_e</math> minimal und der entstehende Graph G' zusammenhängend ist. 
* G' definiert immer einen Baum, denn andernfalls könnte man eine Kante weglassen und dadurch die Summe <math>\sum_{e\in E'} w_e</math> verringern, ohne dass sich am Zusammenhang von G' etwas ändert. 
* Wenn der Graph G nicht zusammenhängend ist, kann man den Spannbaum für jede Zusammenhangskomponente getrennt ausrechnen. Man erhält dann einen aufspannenden Wald.
* Der MST ist ähnlich wie der Dijkstra-Algorithmus: Dort ist ein Pfad gesucht, bei dem die Summe der Gewichte über den Pfad minimal ist. Beim MST suchen wir eine Lösung, bei der die Summe der Gewichte über den ganzen Graphen minimal ist.
* Das Problem des MST ist nahe verwandt mit der Bestimmung der Zusammenhangskomponente, z.B. über den Tiefensuchbaum. Für die Zusammenhangskomponenten genügt allerdings ein beliebiger Baum, während beim MST ein minimaler Baum gesucht ist.

=== Anwendungen ===
==== Wie verbindet man n gegebene Punkte mit möglichst kurzen Straßen (Eisenbahnen, Drähten [bei Schaltungen] usw.)?====

 
{| class="wikitable" style="text-align:center" border="0" cellpadding="5" cellspacing="0"
|MST minimale Verbindung (Abb.1)
|MST = 2 (Länge = Kantengewicht)(Abb.2)
|- valign="top"
| [[Image:mst.png]]
| [[Image:Gleichseitigesdreieck.png]]
|}
*In der Praxis: Die Festlegung, dass man nur die gegebenen Punkte verwenden darf, ist eine ziemliche starke Einschränkung.

* Wenn man sich vorstellt, es sind drei Punkte gegeben, die als gleichseitiges Dreieck angeordnet sind, dann ist der MST (siehe Abb.2, schwarz gezeichnet) und hat die Länge 2. Man kann hier die Länge als Kantengewicht verwenden.

* Wenn es erlaubt ist zusätzliche Punkte einzufügen, dann kann man in der Mitte einen neuen Punkt setzen <math>\rightarrow</math> neuer MST (siehe Abb.2, orange gezeichnet). 

* Höhe = <math>\frac{1}{2}\sqrt{3}</math>, Schwerpunkt: teilt die Höhe des Dreiecks im Verhältnis 2:1; der Abstand von obersten Punkt bis zum neu eingeführten Punkt: <math>\frac{2}{3}h = \frac{\sqrt{3}}{3}</math>, davon insgesamt 3 Stück, damit (gilt für den MST in orange eingezeichnet): MST = <math>3\left(\frac{1}{3}\right) \sqrt{3} = \sqrt{3} \approx 1,7</math><br\>

* Damit ist der MST in orange kürzer als der schwarz gezeichnete MST. <br\>
<math>\Rightarrow</math>Folgerung: MST kann kürzer werden, wenn man einen Punkt dazu nimmt.
* Umgekehrt kann der MST auch kürzer werden, wenn man einen Punkt aus dem Graphen entfernt, aber wie das Beipiel des gleichseitigen Dreiecks zeigt, ist dies nicht immer der Fall.

[[Image: bahn.png|Bahnstrecke Verbindung (Abb.3)]]

* Methode der zusätzlichen Punkteinfügung hat man früher beim Bahnstreckenbau verwendet. Durch Einführung eines Knotenpunktes kann die Streckenlänge verkürzt werden (Dreiecksungleichung).

==== Bestimmung von Datenclustern ====

[[Image:cluster.png]]

* Daten (in der Abb.: Punkte) bilden Gruppen.

* In der Abbildung hat man 2 verschiedene Messungen gemacht (als x- und y-Achse aufgetragen), bspw. Größe und Gewicht von Personen. Für jede Person i wird ein Punkt an der Koordinate (Größei, Gewichti) gezeichnet (siehe Bild a). Dies bezeichnet man als ''Scatter Plot''. Wenn bestimmte Wertkombinationen häufiger auftreten als andere, bilden sich mitunter Gruppen aus, bspw. eine Gruppe für "klein und schwer" etc.

* Durch Verbinden der Punkte mittels eines MST (siehe Abbildung (b)) sieht man, dass es kurze (innerhalb der Gruppen) und lange Kanten (zwischen den Gruppen) gibt.

* Wenn man geschickt eine Schwelle einführt und alle Kanten löscht, die länger sind als die Schwelle, dann bekommt man als Zusammenhangskomponente die einzelnen Gruppen.

=== Algorithmen ===

Genau wie bei der Bestimmung von Zusammenhangskomponenten kann man auch das MST-Problem entweder nach dem Anlagerungsprinzip oder nach dem Verschmelzungsprinzip lösen (dazu gibt es noch weitere Möglichkeiten, z.B. den [http://de.wikipedia.org/wiki/Algorithmus_von_Bor%C5%AFvka Algorithmus von Boruvka]). Der Anlagerungsalgorithmus für MST wurde zuerst von Prim beschrieben und trägt deshalb seinen Namen, der Verschmelzungsalgorithmus stammt von Kruskal. Im Vergleich zu den Algorithmen für Zusammenhangskomponenten ändert sich im wesentlichen nur die Reihenfolge, in der die Kanten betrachtet werden: Eine Prioritätswarteschlange stellt jetzt sicher, dass am Ende wirklich der Baum mit den geringstmöglichen Kosten herauskommt.

====Algorithmus von Prim====
[http://de.wikipedia.org/wiki/Algorithmus_von_Prim Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]

Der Algorithmus von Prim geht nach dem Anlagerungsprinzip vor (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Tiefensuche|Zusammenhangskomponenten mit Tiefensuche]]): Starte an der Wurzel (ein willkürlich gewählter Knoten) und füge jeweils die günstigste Kante an die aktuellen Teillösung an, die keinen Zyklus verursacht. Die Sortierung der Kanten nach Priorität erfolgt analog zum Dijsktra-Algorithmus, aber die Definitionen, welche Kante die günstigste ist, unterscheiden sich. Die Konvention für die Bedeutung der Elemente des Heaps ist ebenfalls identisch: ein Tupel mit <tt>(priority, node, predecessor)</tt>. Die folgende Implementation verdeutlicht sehr schön die Ähnlichkeit der beiden Algorithmen. Das Ergebnis wird als property map <tt>parents</tt> zurückgegeben, in der für jeden Knoten sein Vorgänger im MST steht, wobei die Wurzel wie üblich auf sich selbst verweist.

import heapq

def prim(graph, weights): # Kantengewichte wie bei Dijkstra als property map
sum = 0.0 # wird später das Gewicht des Spannbaums sein
start = 0 # Knoten 0 wird willkürlich als Wurzel gewählt

parents = [None]*len(graph) # property map, die den resultierenden Baum kodiert
parents[start] = start # Wurzel zeigt auf sich selbst

heap = [] # Heap für die Kanten des Graphen
for neighbor in graph[start]: # besuche die Nachbarn von start
heapq.heappush(heap, (weights[(start, neighbor)], neighbor, start)) # und fülle Heap

while len(heap) > 0:
w, node, predecessor = heapq.heappop(heap) # hole billigste Kante aus dem Heap
if parents[node] is not None: # die Kante würde einen Zyklus verursachen
continue # => ignoriere diese Kante
parents[node] = predecessor # füge Kante in den MST ein
sum += w # und aktualisiere das Gesamtgewicht
for neighbor in graph[node]: # besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn kein Zyklus entsteht
heapq.heappush(heap, (weights[(node,neighbor)], neighbor, node)) # füge Kandidaten in Heap ein

return parents, sum # MST und Gesamtgewicht zurückgeben

====Algorithmus von Kruskal====
[http://de.wikipedia.org/wiki/Algorithmus_von_Kruskal Wikipedia (de)]
[http://en.wikipedia.org/wiki/Kruskal%27s_algorithm (en)]

Die alternative Vorgehensweise ist das Verschmelzungsprinzip (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]]), das der Algorithmus von Kruskal verwendet. Jeder Knoten wird zunächst als trivialer Baum mit nur einem Knoten betrachtet, und alle Kanten werden aufsteigend nach Gewicht sortiert. Dann wird die billigste noch nicht betrachtete Kante in den MST eingefügt, falls sich dadurch kein Zyklus bildet (erkennbar daran, dass die Endknoten in verschiedenen Zusammenhangskomponenten liegen, das heisst verschiedene Anker haben). Da der fertige Baum (V-1) Kanten haben muss, wird dies (V-1) Mal zutreffen. Andernfalls wird diese Kante ignoriert. Anders ausgedrückt: Der Algorithmus beginnt mit ''V'' Bäumen; in (''V''-1) Verschmelzungsschritten kombiniert er jeweils zwei Bäume (unter Verwendung der kürzesten möglichen Kante), bis nur noch ein Baum übrig bleibt. Der einzige Unterschied zum einfachen Union-Find besteht darin, dass die Kanten in aufsteigender Reihenfolge betrachtet werden müssen, was wir hier durch eine Prioritätswarteschlange realisieren. Der Algorithmus von J.Kruskal ist seit 1956 bekannt.

def kruskal(graph, weights):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker
results = [] # result wird später die Kanten des MST enthalten

heap = [] # Heap zum Sortieren der Kanten nach Gewicht
for edge, w in weights.iteritems(): # alle Kanten einfügen
heapq.heappush(heap, (w, edge))

while len(heap) > 0: # solange noch Kanten vorhanden sind
w, edge = heapq.heappop(heap) # billigste Kante aus dem Heap nehmen
a1 = findAnchor(anchors, edge[0]) # Anker von Startknoten der Kante
a2 = findAnchor(anchors, edge[1]) # ... und Endknoten bestimmen
if a1 != a2: # wenn die Knoten in verschiedenen Komponenten sind
anchors[a2] = a1 # Komponenten verschmelzen
result.append(edge) # ... und Kante in MST einfügen

return result # Kanten des MST zurückgeben

Die Funktion <tt>findAnchor()</tt> wurde im Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]] implementiert. Im Unterschied zum Algorithmus von Prim geben wir hier nicht die property map <tt>parents</tt> zurück, sondern einfach eine Liste der Kanten im MST.

Der Algorithmus eignet sich insbesondere für das Clusteringproblem, da der Schwellwert von vornerein als maximales Kantengewicht an den Algorithmus übergeben werden kann. Man hört mit dem Vereinigen auf, wenn das Gewicht der billigste Kante im Heap den Schwellwert überschreitet. Beim Algorithmus von Kruskal kann dann keine bessere Kante als der Schwellwert mehr kommen, da die Kanten vorher sortiert worden sind.

Komplexität: wie beim Dijkstra-Algorithmus, weil jede Kante genau einmal in den Heap kommt. Der Aufwand für das Sortieren ist somit <math>O\left(E\log E\right)</math>, was sich zu <math>O \left(E\,\log\,V\right)</math> reduziert, falls keine Mehrfachkanten vorhanden sind.

=> geeignet für Übungsaufgabe

====Verwendung einer BucketPriorityQueue====

Beide Algorithmen zur Bestimmung des minimalen Spannbaums benötigen eine Prioritätswarteschlange. Wenn die Kantengewichte ganze Zahlen im Bereich <tt>0...(m-1)</tt> sind, kann man die MST-Algorithmen deutlich beschleunigen, wenn man anstelle des Heaps eine [[Prioritätswarteschlangen#Prioritätssuche mit dem Bucket-Prinzip|<tt>BucketPriorityQueue</tt>]] verwendet. Die Operationen zum Einfügen einer Kante in die Queue und zum Entfernen der billibsten Kante aus der Queue beschleunigen sich dadurch auf O(1) statt O(log V) (außer wenn die Gewichte sehr ungünstig auf die Kanten verteilt sind). In der Praxis erreicht man durch diese Änderung typischerweise deutliche Verbesserungen. In der Bildverarbeitung können die Prioritäten beispielsweise die Wahrscheinlichkeit kodieren, dass zwei benachbarte Pixel zu verschiedenen Objekten gehören. Bildet man jetzt den MST, und bricht bei einer bestimmten Wahrscheinlichkeit ab, erhält man Cluster von Pixeln, die wahrscheinlich zum selben Objekt gehören (weil der MST ja die Kanten mit minimalem Gewicht bevorzugt, und kleine Gewichte bedeuten kleine Wahrscheinlichkeit, dass benachbarte Pixel von einander getrennt werden). Da man die Wahrscheinlichkeiten nur mit einer Genauigkeit von ca. 1% berechnen kann, reichen hiefür 100 bis 200 Quantisierungstufen aus. Durch Verwendung der schnellen <tt>BucketPriorityQueue</tt> kann man jetzt wesentlich größere Bilder in akzeptabler Zeit bearbeiten als dies mit einem Heap möglich wäre.

== Algorithmen für gerichtete Graphen ==

Zur Erinnerung: in einem gerichteten Graphen sind die Kanten (i → j) und (j → i) voneinander verschieden, und eventuell existiert nur eine der beiden Richtungen. Im allgemeinen unterscheidet sich der [[Graphen_und_Graphenalgorithmen#transposed_graph|transponierte Graph]] GT also vom Originalgraphen G. Beim Traversieren des Graphen und bei der Pfadsuche dürfen Kanten nur in passender Richtung verwendet werden. Bei gewichteten Graphen tritt häufig der Fall auf, dass zwar Kanten in beiden Richtungen existieren, diese aber unterschiedliche Gewichte haben.

Gerichtete Graphen ergeben sich in natürlicher Weise aus vielen Anwendungsproblemen:
* Routenplanung
** Bei Straßennetzwerken enstehen gerichtete Graphen, sobald es Einbahnstraßen gibt.
** Verwendet man Gewichte, um die erwarteten Fahrzeiten entlang einer Straße zu kodieren, gibt es Asymmetrien z.B. dann, wenn Straßen in einer Richtung bergab, in der anderen bergauf befahren werden. Hier existieren zwar Kanten in beiden Richtungen, sie haben aber unterschiedliche Gewichte. Ähnliches gilt für Flüge: Durch den Gegenwind des Jetstreams braucht man von Frankfurt nach New York länger als umgekehrt von New York nach Frankfurt.
* zeitliche oder kausale Abhängigkeiten
** Wenn die Knoten Ereignisse repräsentieren, von denen einige die Ursache von anderen sind, diese wiederum die Ursache der nächsten usw., verbindet man die Knoten zweckmäßig durch gerichtete Kanten, die die Kausalitätsbeziehungen kodieren. Handelt es sich um logische "wenn-dann"-Regeln, erhält man einen [[Graphen_und_Graphenalgorithmen#Anwendung:_Das_Erf.C3.BCllbarkeitsproblem_in_Implikationengraphen|Implikationengraph]] (siehe unten). Handelt es sich hingegen um Wahrscheinlichkeitsaussagen ("Wenn das Wetter schön ist, haben Studenten tendenziell gute Laune, wenn eine Prüfung bevorsteht eher schlechte usw."), erhält man ein [http://de.wikipedia.org/wiki/Bayessches_Netz Bayessches Netz].
** Wenn bestimmte Aufgaben erst begonnen werden können, nachdem andere Aufgaben erledigt sind, erhält man einen Abhängigkeitsgraphen. Beispielsweise dürfen Sie erst an der Klausur teilnehmen, nachdem Sie die Übungsaufgaben gelöst haben, und Sie dürfen erst die Abschlussarbeit beginnen, nachdem Sie bestimmte Prüfungen bestanden haben. Ein anderes schönes Beispiel liefern die Regeln für das [[Graphen_und_Graphenalgorithmen#Anwendung:_Abh.C3.A4ngigkeitsgraph|Ankleiden]] weiter unten.
** Gerichtete Graphen kodieren die Abhängigkeiten zwischen Programmbibliotheken. Beispielsweise benötigt das Pythonmodul <tt>json</tt> die internen Submodule <tt>json.encoder</tt> und <tt>json.decode</tt> sowie das externe Modul <tt>decimal</tt>. Die Submodule benötigen wiederum die externen Module <tt>re</tt> und <tt>sys</tt>, das Modul <tt>decimal</tt> braucht <tt>copy</tt> und <tt>collections</tt> usw.
** Das Internet kann als gerichteter Graph dargestellt werden, wobei die Webseiten die Knoten, und die Hyperlinks die Kanten sind.
* Sequence Alignment
** Eine gute Rechtschreibprüfung markiert nicht nur fehlerhafte Wörter, sondern macht auch plausible Vorschläge, was eigentlich gemeint gewesen sein könnte. Dazu muss sie das gegebene Wort mit den Wörtern eines Wörterbuchs vergleichen und die Ähnlichkeit bewerten. Ein analoges Problem ergibt sich, wenn man DNA Fragmente mit der Information in einer Genomdatenbank abgleichen will.

=== Anwendung: Sequence Alignment / Edit Distance ===

:gegeben: zwei Wörter (allgemein: beliebige Zeichenfolgen)
:gesucht: Wie kann man die Buchstaben am besten in Übereinstimmung bringen?

:Beispiel: WORTE – NORDEN

Zwei mögliche Alignments sind

WORTE. W.ORTE
NORDEN NORDEN

wobei der Punkt anzeigt, dass der untere Buchstabe keinen Partner hat, und rote Buchstaben oben und unten übereinstimmen. Jede Nicht-Übereinstimmung verursacht nun gewisse Kosten. Dabei unterscheiden wir zwei Fälle:
# Matche a[i] mit b[j]. Falls a[i] == b[j], ist das gut (rote Buchstaben), und es entstehen keine Kosten. Andernfalls entstehen Kosten U (schwarze Buchstaben).
# Wir überspringen a[i] oder b[j] (Buchstabe vs. Punkt). Dann entstehen Kosten V. (Manchmal unterscheidet man auch noch Kosten Va und Vb, wenn das Überspringen bei a und b unterschieldiche Signifikanz hat.)

Gesucht ist nun das Alignment mit minimalen Kosten

Diese Aufgabe kann man sehr schön als gerichteten Graphen darstellen: Wir definieren ein rechteckiges Gitter und schreiben das erste Wort über das Gitter und das andere links davon. Die Gitterpunkte verbinden wir mit Pfeilen (gerichteten Kanten), wobei ein Pfeil nach rechts bedeutet, dass wir beim oberen Wort einen Buchstaben überspringen, ein Pfeil nach unten, dass wir beim linken Wort einen Buchstaben überspringen, und ein diagonaler Pfeil, dass wir zwei Buchstaben matchen (und zwar die am Pfeilende). Die Farben der Pfeile symbolisieren die Kosten: rot für das Überspringen eines Buchstabens (Kosten V), blau für das Matchen, wenn die Buchstaben nicht übereinstimmen (Kosten U), und grün, wenn die Buchstaben übereinstimmen (keine Kosten).

[[Image:sequence-alignment.png|300px]]

Lösung:
:Suche den kürzesten Pfad vom Knoten "START" (oben links) nach unten rechts. Dazu kann der [[Graphen und Graphenalgorithmen#Algorithmus von Dijkstra|Algorithmus von Dijkstra]] verwendet werden, der auf gerichteten Graphen genauso funktioniert wie auf ungerichteten.

Für unser Beispiel von oben erhalten wir die folgenden Pfade:

[[Image:sequence-alignment-weg1.png|400px]]     [[Image:sequence-alignment-weg2.png|400px]]

Durch Addieren der Kosten entsprechend der Farben sieht man, dass der erste Weg die Kosten 2U+V und der zweite die Kosten 5U+V hat. Der erste Weg ist offensichtlich günstiger und entspricht dem besten Alignment.

=== Anwendung: Abhängigkeitsgraph ===

Beispiel: Wie erklärt man einem zerstreuten Professor, wie er sich morgens anziehen soll? Der folgende Graph enthält einen Knoten für jede Aktion, und eine Kante (i → j) bedeutet, dass die Aktion i vor der Aktion j abgeschlossen werden muss.

[[Image:anziehen-graph.png|600px]]

In derartigen Abhängigkeitsgraphen ist die wichtigste Frage immer, ob der Graph azyklisch ist. Wäre dies nämlich nicht der Fall, kann es keine Reihenfolge der Aktionen geben, die alle Abhängigkeiten erfüllt. Dies sieht man leicht, wenn man den einfachsten möglichen Zyklus betrachtet: es gibt sowohl eine Kante (i → j) als auch eine (j → i). Dann müsste man i vor j erledigen, aber ebenso j vor i, was offensichtlich unmöglich ist - das im Graph kodierte Problem ist dann unlösbar. Wegen ihrer Wichtigkeit wird für gerichtete azyklische Graphen oft die Abkürzung DAG (von directed acyclic graph) verwendet. Ein Graph ist genau dann ein DAG, wenn es eine topologische Sortierung gibt:
;topologische Sortierung: Zeichne die Knoten so auf eine Gerade, dass alle Kanten (Pfeile) nach rechts zeigen.
Arbeitet man die Aktionen nach einer (beliebigen) topologischen Sortierung ab, werden automatisch alle Abhängigkeiten eingehalten: Da alle Pfeile nach rechts zeigen, werden abhängige Aktionen immer später ausgeführt. Die topologische Sortierung ist im allgemeinen nicht eindeutig. Die folgende Skizze zeigt eine mögliche topologische Sortierung für das Anziehen:

[[Image:anziehen-topologische-sortierung.png|600px]]

Eine solche fest vorgegebene Reihenfolge ist für den zerstreuten Professor sicherlich eine größere Hilfe als der ursprüngliche Graph. Man erkennt, dass die Sortierung nicht eindeutig ist, beispielsweise bei der Uhr: Da für die Uhr keine Abhängigkeiten definiert sind, kann man diese Aktion an beliebiger Stelle einsortieren. Hier wurde willkürlich die letzte Stelle gewählt.

==== Zwei Algorithmen zum Finden der topologischen Sortierung ====

Die folgenden Algorithmen finden entweder eine topologische Sortierung, oder signalisieren, dass der Graph zyklisch ist.

===== Algorithmus 1 =====
# Suche einen Knoten mit Eingangsgrad 0 (ohne eingehende Pfeile) => in einem gerichteten azyklischen Graphen gibt es immer einen solchen Knoten
# Platziere diesen Knoten auf der Geraden (beliebig)
# Entferne den Knoten aus dem Graphen zusammen mit den ausgehenden Kanten
# Gehe zu 1., aber platziere in 2. immer rechts der Knoten, die schon auf der Geraden vorhanden sind.
: => Wenn noch Knoten übrig sind, aber keiner Eingangsgrad 0 hat, muss der Graph zyklisch sein.

[[Image:bild6.JPG]]

Beispiel für einen zyklischen Graphen: kein Knoten hat Eingangsgrad 0.

Um den Algorithmus zu implementieren, verwenden wir eine property map <tt>in_degree</tt>, die wir in einem ersten Durchlauf durch den Graphen füllen und die dann für jeden Knoten die Anzahl der eingehenden Kanten speichert. Dann gehen wir sukzessive zu allen Knoten mit <tt>in_degree == 0</tt>. Anstatt sie aber tatsächlich aus dem Graphen zu entfernen wie im obigen Pseudocode, dekrementieren wir nur den <tt>in_degree</tt> ihrer Nachbarn. Wird der <tt>in_degree</tt> eines Nachbarn dadurch 0, wird er ebenfalls in das Array der zu scannenden Knoten aufgenommen. Wenn der Graph azyklisch ist, enthält das Array am Ende alle Knoten des Graphen, und die Reihenfolge der Einfügungen definiert eine topologische Sortierung. Andernfalls ist das Array zu kurz, und wir signalisieren durch Zurückgeben von <tt>None</tt>, dass der Graph zyklisch ist:

def topological_sort(graph): # ein gerichteter Graph
in_degree = [0]*len(graph) # property map für den Eingangsgrad jeden Knotens
for node in xrange(len(graph)): # besuche alle Knoten
for neighbor in graph[node]: # ... und deren Nachbarn
in_degree[neighbor] += 1 # ... und inkrementiere den Eingangsgrad

result = [] # wird später die topologische Sortierung enthalten
for node in xrange(len(graph)):
if in_degree[node] == 0:
result.append(node) # füge alle Knoten mit Eingangsgrad 0 in result ein

k = 0
while k < len(result): # besuche alle Knoten mit Eingangsgrad 0
node = result[k]
k += 1
for neighbor in graph[node]: # besuche alle Nachbarn
in_degree[neighbor] -= 1 # entferne 'virtuell' die eingehende Kante
if in_degree[neighbor] == 0: # wenn neighbor jetzt Eingangsgrad 0 hat
result.append(neighbor) # ... füge ihn in result ein

if len(result) == len(graph): # wenn alle Knoten jetzt Eingangsgrad 0 haben
return result # ... ist result eine topologische Sortierung
else:
return None # andernfalls ist der Graph zyklisch

===== Algorithmus 2 =====
Der obige Algorithmus hat den Nachteil, dass er jeden Knoten zweimal expandiert. Man kann eine topologische Sortierung stattdessen auch mit Tiefensuche bestimmen. Es gilt nämlich der folgende
;Satz: Wird ein DAG mittels Tiefensuche traversiert, definiert die reverse post-order eine topologische Sortierung.
Zur Erinnerung: die post-order erhält man, indem man jeden Knoten ausgibt, nachdem die Rekursion zu allen seinen Nachbarn beendet ist, siehe unsere [[Graphen_und_Graphenalgorithmen#pre_and_post_order|Diskussion weiter oben]]. Die reverse post-order ist gerade die Umkehrung dieser Reihenfolge. Die folgende Implementation verwendet die rekursive Version der Tiefensuche, in der Praxis wird man meist die iterative Version mit Stack bevorzugen, weil bei großen Graphen die Aufruftiefe sehr groß werden kann:

def reverse_post_order(graph): # gerichteter Graph
result = [] # enthält später die reverse post-order
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node): # besuche node
if not visited[node]: # aber nur, wenn er noch nicht besucht wurde
visited[node] = True # markiere ihn als besucht
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor)
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order

for node in xrange(len(graph)): # besuche alle Knoten
visit(node)

result.reverse() # post-order => reverse post-order
return result

Die Tatsache, dass die reverse post-order tatsächlich eine topologische Sortierung liefert, leuchtet wahrscheinlich nicht unmittelbar ein. Bevor wir diese Tatsache beweisen. wollen wir uns anhand des Ankleidegraphen klar machen, dass die pre-order (die man intuitiv vielleicht eher wählen würde) keine topologische Sortierung ist. Startet man die Tiefensuche beim Knoten "Unterhemd", werden die Knoten in der Reihenfolge "Unterhemd", "Oberhemd", "Schlips", "Jackett", "Gürtel" gefunden. Da dann alle von "Unterhemd" erreichbaren Knoten erschöpft sind, startet man die Tiefensuche als nächstes bei "Unterhose" und erreicht von dort aus "Hose" und "Schuhe". Man erkennt sofort, dass diese Reihenfolge nicht funktioniert: "Hose" kommt nach "Gürtel", und "Jackett" kommt vor "Gürtel". Bei dieser Anordnung gibt es Pfeile nach links, die Abhängigkeitsbedingungen sind somit verletzt.

Damit die reverse post-order eine zulässige Sortierung sein kann, muss stets gelten, dass Knoten u vor Knoten v einsortiert wurde, wenn die Kante (u → v) existiert. Das ist aber äquivalent zur Forderung, dass in der ursprünglichen post-order (vor dem <tt>reverse</tt>) u hinter v stehen muss. Wir betrachten den <tt>visit</tt>-Aufruf, bei dem u expandiert wird. Gelangt man jetzt zu u's Nachbarn v, gibt es zwei Möglichkeiten: Wenn v bereits expandiert wurde, befindet es sich bereits im Array <tt>result</tt> und <tt>visit</tt> kehrt sofort zurück. Andernfalls wird v ebenfalls expandiert und demzufolge in <tt>result</tt> eingetragen, bevor der rekursive Aufruf <tt>visit(v)</tt> zurückkehrt. Knoten u wird aber erst in <tt>result</tt> eingefügt, nachdem alle rekursiven <tt>visit</tt>-Aufrufe seiner Nachbarn zurückgekehrt sind. In beiden Fällen steht u in der post-order wie gefordert hinter v, und daraus folgt die Behauptung.

Der obige Algorithmus liefert natürlich nur dann eine topologische Sortierung, wenn der Graph wirklich azyklisch ist (man kann ihn aber auch anwenden, um die reverse post-order für einen zyklischen Graphen zu bestimmen, siehe Abschnitt "[[Graphen_und_Graphenalgorithmen#Transitive Hülle und stark zusammenhängende Komponenten|Stark zusammenhängende Komponenten]]"). Dieser Fall tritt in der Praxis häufig auf, weil zyklische Graphen bei vielen Anwendungen gar nicht erst entstehen können. Weiß man allerdings nicht, ob der Graph azyklisch ist oder nicht, muss man einen zusätzlichen Test auf Zyklen in den Algorithmus einbauen.

Zyklische Graphen sind dadurch gekennzeichnet, dass es im obigen Beweis eine dritte Möglichkeit gibt: Während der Expansion von u wird rekursiv v expandiert, und es gibt eine Rückwärtskante (v → u). (Es spielt dabei keine Rolle, ob v von u aus direkt oder indirekt erreicht wurde.) Ein Zyklus wird also entdeckt, wenn die Tiefensuche zu u zurückkehrt, solange u noch aktiv ist, d.h. wenn die Rekursion von u aus gestartet und noch nicht beendet wurde. Dies kann man leicht feststellen, wenn man in der property map <tt>visited</tt> drei Werte zulässt: 0 für "noch nicht besucht", 1 für "aktiv" und 2 für "beendet". Wir signalisieren einen Zyklus, sobald <tt>visit</tt> für einen Knoten aufgerufen wird, der gerade aktiv ist:

def topological_sort_DFS(graph): # gerichteter Graph
result = [] # enthält später die topologische Sortierung

not_visited, active, finished = 0, 1, 2 # drei Zustände für visited
visited = [not_visited]*len(graph) # Flags für aktive und bereits besuchte Knoten

def visit(node): # besuche node (gibt "True" zurück, wenn Zyklus gefunden wurde)
if visited[node] == not_visited: # ... aber nur, wenn er noch nicht besucht wurde
visited[node] = active # markiere ihn als aktiv
for neighbor in graph[node]: # und besuche die Nachbarn
if visit(neighbor): # wenn rekursiv ein Zyklus gefunden wurde
return True # ... brechen wir ab und signalisieren den Zyklus
visited[node] = finished # Rekursion beendet, node ist nicht mehr aktiv
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order
return False # kein Zyklus gefunden
elif visited[node] == active: # Rekursion erreicht einen noch aktiven Knoten
return True # => Zyklus gefunden

for node in xrange(len(graph)): # besuche alle Knoten
if visit(node): # wenn Zyklus gefunden wurde
return None # ... gibt es keine topologische Sortierung

result.reverse() # post-order => reverse post-order (=topologische Sortierung)
return result

Man macht sich leicht klar, dass kein Zyklus vorliegt, wenn die Rekursion einen Knoten erreicht, der bereits auf <tt>finished</tt> gesetzt ist. Nehmen wir an, dass u gerade expandiert wird, und sein Nachbar v ist bereits <tt>finished</tt>. Wenn es einen Zyklus gäbe, müsste es einen Weg von v nach u geben. Dann wäre u aber bereits während der Expansion von v gefunden worden. Da v nicht mehr im Zustand <tt>active</tt> ist, muss die Expansion von v schon abgeschlossen gewesen sein, ohne dass u gefunden wurde. Folglich kann es keinen solchen Zyklus geben.

=== Transitive Hülle und stark zusammenhängende Komponenten ===

Auch bei gerichteten Graphen ist die Frage, welche Knoten miteinander zusammenhängen, von großem Interesse. Wir betrachten dazu wieder die Relation "Knoten v ist von Knoten u aus erreichbar", die anzeigt, ob es einen Weg von u nach v gibt oder nicht. In ungerichteten Graphen ist diese Relation immer symmetrisch, weil jeder Weg in beiden Richtungen benutzt werden kann. In gerichteten Graphen gilt dies nicht. Man muss hier zwei Arten von Zusammenhangskomponenten unterscheiden:
;Transitive Hülle: Die transitive Hülle eines Knotens u ist die Menge aller Knoten, die von u aus erreichbar sind:
:<math>T(u) = \{v\ |\ u \rightsquigarrow v\}</math>
;Stark zusammenhängende Komponenten: Die stark zusammenhängende Komponenten <math>C_i</math> eines gerichteten Graphen sind maximale Teilgraphen, so dass alle Knoten innerhalb einer Komponente von jedem anderen Knoten der selben Komponente aus erreichbar sind
:<math>u,v \in C_i\ \ \Leftrightarrow\ \ u \rightsquigarrow v \wedge v \rightsquigarrow u</math>
Die erste Definition betrachtet den Zusammenhang asymmetrisch, ohne Beachtung der Frage, ob es auch einen Rückweg von Knoten v nach u gibt, die zweite hingegen symmetrisch.

Die transitive Hülle benötigt man, wenn man Fragen der Erreichbarkeit besonders effizient beantworten will. Wir hatten bespielsweise oben erwähnt, dass das Python-Modul <tt>json</tt> direkt und indirekt von mehreren anderen Module abhängt, die vorher installiert werden müssen, damit <tt>json</tt> funktioniert. Bittet man den Systemadministrator, das <tt>json</tt>-Paket zu installieren, will er diese Abhängigkeiten wahrscheinlich nicht erst mühsam rekursiv heraussuchen, sondern er verlangt eine Liste aller Pakete, die installiert werden müssen. Dies ist gerade die transitive Hülle von <tt>json</tt> im Abhängigkeitsgraphen. Damit man diese nicht manuell bestimmen muss, verwendet man Installationsprogramme wie z.B. [http://pypi.python.org/pypi/pip/ pip], die die Abhängigkeiten automatisch herausfinden und installieren.

Bei der Bestimmung der transitiven Hülle modifiziert man den gegebenen Graphen, indem man jedesmal eine neue Kante (u → v) einfügt, wenn diese Kante noch nicht existiert, aber v von u aus erreichbar ist. Dies gelingt mit einer sehr einfachen Variation der Tiefensuche: Wir rufen <tt>visit(k)</tt> für jeden Knoten k auf, aber setzen die property map <tt>visited</tt> zuvor auf <tt>False</tt> zurück. Alle Knoten, die während der Rekursion erreicht werden, sind im modifizierten Graphen Nachbarn von k. Ein etwas effizienterer Ansatz ist der [http://de.wikipedia.org/wiki/Algorithmus_von_Floyd_und_Warshall Algorithmus von Floyd und Warshall].

Die Bestimmung der stark zusammenhängenden Komponenten ist etwas schwieriger. Es existieren eine ganze Reihe von effizienten Algorithmen (siehe [http://en.wikipedia.org/wiki/Strongly_connected_component WikiPedia]), deren einfachster der Algorithmus von Kosaraju ist:

gegeben: gerichteter Graph

# Bestimme die reverse post-order (mit der Funktion <tt>reverse_post_order</tt>)
# Bilde den transponierten Graphen <math>G^T</math> (mit der Funktion <tt>transposeGraph</tt>)
# Bestimme die Zusammenhangskomponenten von <math>G^T</math> mittels Tiefensuche, aber betrachte die Knoten dabei in der reverse post-order aus Schritt 1 (dies kann mit einer minimalen Modifikation der Funktion <tt>connectedComponents</tt> geschehen, indem man die Zeile <tt>for node in xrange(len(graph)):</tt> einfach nach <tt>for node in ordered:</tt> abändert, wobei <tt>ordered</tt> das Ergebnis der Funktion <tt>reverse_post_order</tt> ist, also ein Array, das die Knoten in der gewünschten Reihenfolge enthält).
Die Zusammenhangskomponenten, die man in Schritt 3 findet, sind gerade die stark zusammenhängenden Komponenten des Originalgraphen G. Die folgende Skizze zeigt diese in grün für den schwarz gezeichneten gerichteten Graphen.

[[Image:strongly-connected-components.png|400px]]

Zum Beweis der Korrektheit des Algorithmus von Kosaraju zeigen wir zwei Implikationen: 1. Wenn die Knoten u und v in der selben stark zusammenhängenden Komponente liegen, werden sie in Schritt 3 des Algorithmus auch der selben Komponente zugewiesen. 2. Wenn die Knoten u und v in Schritt 3 der selben Komponente zugewiesen wurden, müssen sie auch in der selben stark zusammenhängenden Komponente liegen.
# Knoten u und v gehören zur selben stark zusammenhängenden Komponente von G. Per Definition gilt, dass u von v aus erreichbar ist und umgekehrt. Dies muss auch im transponierten Graphen GT gelten (der Weg <math>u \rightsquigarrow v</math> wird jetzt zum Weg <math>v \rightsquigarrow u</math> und umgekehrt). Wird u bei der Tiefensuche in Schritt 3 vor v expandiert, ist v von u aus erreichbar und gehört somit zur selben Komponente. Das umgekehrte gilt, wenn v vor u expandiert wird. Daraus folgt die Behauptung 1.
# Knoten u und v werden in Schritt 3 der selben Komponente zugewiesen: Sei x der Anker dieser Komponente. Da u in der gleichen Komponente wie x liegt, muss es in GT einen Weg <math>x \rightsquigarrow u</math>, und demnach in G einen Weg <math>u \rightsquigarrow x</math> geben. Da x der Anker seiner Komponente ist, wissen wir aber auch, dass x in der reverse post-order vor u liegt (denn der Anker ist der Knoten, mit dem eine neue Komponente gestartet wird; er muss deshalb im Array <tt>ordered</tt> als erster Konten seiner Komponente gefunden worden sein). Wir unterscheiden jetzt im Schritt 1 des Algorithmus zwei Fälle:
## u wurde bei der Bestimmung der post-order vor x expandiert. Dann kann x nur dann in der reverse post-order vor u liegen (oder, einfacher ausgedrückt, x kann nur dann in der post-order hinter u liegen), wenn x im Graphen G nicht von u aus erreichbar war. Das ist aber unmöglich, weil wir ja schon wissen, dass es in G einen Weg <math>u \rightsquigarrow x</math> gibt.
## Folglich wurde u bei der Bestimmung der post-order nach x expandiert. Da x in der post-order hinter u liegt, muss u während der Expansion von x erreicht worden sein. Deshalb muss es in G auch einen Weg <math>x \rightsquigarrow u</math> geben.
#:Somit sind x und u in der selben stark zusammenhängenden Komponente. Die gleiche Überlegung gilt für x und v. Wegen der Transitivität der Relation "ist erreichbar" folgt daraus, dass auch u und v in der selben Komponente liegen, also die Behauptung 2.

Die folgende Skizze illustriert den Komponentengraphen, den man erhält, indem man für jede Komponente <math>C_i</math> einen Knoten erzeugt (grün), und die Knoten i und j durch eine gerichtete Kante verbindet (rot), wenn es im Originalgraphen eine Kante (u → v) mit <math>u \in C_i</math> und <math>v \in C_j</math> gibt. Man sieht leicht, dass der Komponentengraph stets azyklisch sein muss, denn wären <math>C_i</math> gleichzeitig von <math>C_j</math> aus erreichbar, müssten sie eine gemeinsame stark zusammenhängende Komponente bilden. Daraus folgt auch, dass ein von vornherein azyklischer Graph nur triviale stark verbundene Komponenten haben kann, die aus einzelnen Knoten bestehen.

[[Image:strongly-connected-components-graph.png|400px]]

=== Anwendung: Das Erfüllbarkeitsproblem in Implikationengraphen ===

Das Erfüllbarkeitsproblem hat auf den ersten Blick nichts mit Graphen zu tun, denn es geht um Wahrheitswerte logischer Ausdrücke. Man kann logische Ausdrücke jedoch unter bestimmten Bedingungen in eine Graphendarstellung überführen und somit das ursprüngliche Problem auf ein Problem der Graphentheorie reduzieren, für das bereits ein Lösungsverfahren bekannt ist. In diesem Abschnitt wollen wir dies für die sogenannten Implikationengraphen zeigen, ein weiteres Beispiel findet sich im Kapitel [[NP-Vollständigkeit]].

==== Das Erfüllbarkeitsproblem ====

(vgl. [http://de.wikipedia.org/wiki/Erfüllbarkeitsproblem_der_Aussagenlogik WikiPedia (de)])

Das Erfüllbarkeitsproblem (SAT-Problem, von satisfiability) befasst sich mit logischen (oder Booleschen) Funktionen: Gegeben sei eine Menge <math>\{x_1, ... ,x_n\}</math> Boolscher Variablen (d.h., die <math>x_i</math> können nur die Werte True oder False annehmen), sowie eine logische Formel, in der die Variablen mit den üblichen logischen Operatoren
:<math>\neg\quad</math>: Negation ("nicht", in Python: <tt>not</tt>)
:<math>\vee\quad</math>: Disjunktion ("oder", in Python: <tt>or</tt>)
:<math>\wedge\quad</math>: Konjuktion ("und", in Python: <tt>and</tt>)
:<math>\rightarrow\quad</math>: Implikation ("wenn, dann", in Python nicht als Operator definiert)
:<math>\leftrightarrow\quad</math>: Äquivalenz ("genau dann, wenn", in Python: <tt>==</tt>)
:<math>\neq\quad</math>: exklusive Disjunktion ("entweder oder", in Python: <tt>!=</tt>)
verknüpft sind. Klammern definieren die Reihenfolge der Auswertung der Operationen. Für jede Belegung der Variablen <math>x_i</math> mit True oder False liefert die Formel den Wert der Funktion, der natürlich auch nur True oder False sein kann. Wenn Formel und Belegung gegeben sind, ist die Auswertung der Funktion ein sehr einfaches Problem: Man transformiert die Formel in einen Parse-Baum (siehe Übungsaufgabe "Taschenrechner) und wertet jeden Knoten mit Hilfe der üblichen Wertetabellen für logische Operatoren aus, die wir hier zur Erinnerung noch einmal angeben:
{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>a</math>
|width="70px"| <math>b</math>
|width="70px"| <math>a \vee b </math>
|width="70px"| <math>a \wedge b</math>
|width="70px"| <math>a \rightarrow b</math>
|width="70px"| <math>b \rightarrow a</math>
|width="70px"| <math>a \leftrightarrow b</math>
|width="70px"| <math>a \neq b</math>
|- align="center"
| 0 || 0 || 0 || 0 || 1 || 1 || 1 || 0
|- align="center"
| 0 || 1 || 1 || 0 || 1 || 0 || 0 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 0 || 1 || 0 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1 || 0
|}

Beim Erfüllbarkeitsproblem wird die Frage umgekehrt gestellt:
:Gegeben sei eine logische Funktion. Ist es möglich, dass die Funktion jemals den Wert True annimmt?
Das heisst, kann man die Variablen <math>x_i</math> so mit True oder False belegen, dass die Formel am Ende wahr ist? Im Prinzip kann man diese Frage durch erschöpfende Suche leicht beantworten, indem man die Funktion für alle <math>2^n</math> möglichen Belegungen einfach ausrechnet, aber das dauert für große n (ab ca. <math>n\ge 40</math>) viel zu lange. Erstaunlicherweise ist es aber noch niemanden gelungen, einen Algorithmus zu finden, der für beliebige logische Funktionen schneller funktioniert. Im Gegenteil wurde gezeigt, dass das Erfüllbarkeitsproblem [[NP-Vollständigkeit|NP-vollständig]] ist, so dass wahrscheinlich kein solcher Algorithmus existiert. Trotz (oder gerade wegen) seiner Schwierigkeit hat das Erfüllbarkeitsproblem viele Anwendungen gefunden, vor allem beim Testen logischer Schaltkreise ("Gibt es eine Belegung der Eingänge, so dass am Ausgang der verbotene Wert X entsteht?") und bei der Planerstellung in der künstlichen Intelligenz ("Kann man ausschließen, dass der generierte Plan Konflikte enthält?"). Es ist außerdem ein beliebtes Modellproblem für die Erforschung neuer Ideen und Algorithmen für schwierige Probleme.

==== Normalformen für logische Ausdrücke ====

Um die Beschreibung von Erfüllbarkeitsproblemen zu vereinfachen und zu vereinheitlichen, hat man verschiedene Normalformen für logische Ausdrücke eingeführt. Die wichtigste ist die Konjuktionen-Normalform (CNF - conjunctive normal form). Ein Ausdruck in Konjuktionen-Normalform ist eine UND-Verknüpfung von M Klauseln:
(CLAUSE1) <math>\wedge</math> (CLAUSE2) <math>\wedge</math> ... <math>\wedge</math> (CLAUSEM)
Jede Klausel ist wiederum ein logischer Ausdruck, der aber sehr einfach sein muss: Er darf nur noch k Variablen enthalten, die nur mit den Operatoren NICHT und ODER verknüpft werden dürfen, z.B.
CLAUSE1 := <math>x_1 \vee \neg x_3 \vee x_8</math>
Je nachdem, wie viele Variablen pro Klausel erlaubt sind, spricht man von k-CNF und entsprechend von einem k-SAT Problem. Es ist außerdem üblich, die Menge der Variablen und die Menge der negierten Variablen zusammen als Menge der Literale zu bezeichnen:
LITERALS := <math>\{x_1,...,x_n\} \cup \{\neg x_1,...,\neg x_n\}</math>
Formal definiert man die k-Konjunktionen-Normalform (k-CNF) am besten durch eine Grammatik in [http://de.wikipedia.org/wiki/Backus-Naur-Form Backus-Naur-Form]:
k_CNF ::= CLAUSE | k_CNF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\vee</math> ... <math>\vee</math> LITERAL) # genau k Literale pro Klausel
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
Beispiele:
* 3-CNF: <math>(x_1 \vee \neg x_2 \vee x_4) \wedge (x_2 \vee x_3 \vee \neg x_4) \wedge (\neg x_1 \vee x_4 \vee \neg x_5)</math>
* 2-CNF: <math>(x_1 \vee \neg x_2) \wedge (x_3 \vee x_4)</math> ...
Gesucht ist eine Belegung der Variablen mit True und False, so dass der Ausdruck den Wert True hat. Aus den Eigenschaften der UND- und ODER-Verknüpfungen folgt, dass ein Ausdruck in k-CNF genau dann True ist, wenn jede einzelne Klausel True ist. In jeder Klausel wiederum hat man k Chancen, die Klausel True zu machen, indem man eins der Literale zu True macht. Eventuell werden dadurch aber andere Klauseln wieder zu False, was die Aufgabe so schwierig macht. Die Bedeutung der k-CNF ergibt sich aus folgendem
;Satz: Jeder logische Ausdruck kann effizient nach 3-CNF transformiert werden, jedoch im allgemeinen nicht nach 2-CNF.
Man kann sich also auf Algorithmen für 3-SAT-Probleme konzentrieren, ohne dabei an Ausdrucksmächtigkeit zu verlieren.

Leider gilt der entsprechende Satz nicht für k=2: Ausdrücke in 2-CNF sind weit weniger mächtig, weil man in jeder Klausel nur noch zwei Wahlmöglichkeiten hat. Bestimmte logische Ausdrücke sind aber auch nach 2-CNF transformierbar, beispielsweise die Bedingung, dass zwei Literale u und v immer den entgegegesetzten Wert haben müssen. Dies ergibt ein Paar von ODER-Verknüpfungen:
:<math>(u \leftrightarrow \neg v) \equiv (u \vee \neg v) \wedge (\neg u \vee v)</math>
Die 2-CNF hat den Vorteil, dass es effiziente Algorithmen für das 2-SAT-Problem gibt, die wir jetzt kennenlernen wollen. Es zeigt sich, dass man Ausdrücke in 2-CNF als Graphen repräsentieren kann, indem man sie zunächst in die Implikationen-Normalform (INF für implicative normal form) überführt. Die Implikationen-Normalform besteht ebenfalls aus einer Menge von Klauseln, die durch UND-Operationen verknüpft sind, aber jede Klausel ist jetzt eine Implikation.
Die Grammatik der Implikationen-Normalform (INF) lautet:
INF ::= CLAUSE | INF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\rightarrow</math> LITERAL) # genau 2 Literale pro Implikation
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
und ein gültiger Ausdruck wäre z.B.
:<math>(x_1 \to x_2) \wedge (x_2 \to \neg x_3) \wedge (x_4 \to x_3)</math>
Die Umwandlung von 2-CNF nach INF beruht auf folgender Äquivalenz, die man sich aus der obigen Wahrheitstabelle leicht herleitet:
:<math>(x \vee y) \equiv (\neg x \rightarrow y) \equiv (\neg y \rightarrow x)</math>
Aus dieser Äquivalenz folgt der
;Satz: Ein Ausdruck in 2-CNF kann nach INF transformiert werden, indem man jede Klausel <math>(x \vee y)</math> durch das Klauselpaar <math>(\neg x \rightarrow y) \wedge (\neg y \rightarrow x)</math> ersetzt.
Man beachte, dass man für jede ODER-Klausel des ursprünglichen Ausdrucks zwei Implikationen (eine für jede Richtung des "wenn, dann") einfügen muss, um die Symmetrie des Problems zu erhalten.

==== Lösung des 2-SAT-Problems mit Implikationgraphen ====

Jeder Ausdruck in INF kann als gerichteter Graph dargestellt werden:
# Für jedes Literal wird ein Knoten in den Graphen eingefügt. Es gibt also für jede Variable und für ihre Negation jeweils einen Knoten, d.h. 2n Knoten insgesamt.
# Jede Implikation ist eine gerichtete Kante.
Implikationengraphen eignen sich, um Ursache-Folge-Beziehungen oder Konflikte zwischen Aktionen auszudrücken. Beispielsweise kann man die Klausel <math>(x \rightarrow \neg y)</math> als "wenn man x tut, darf man y nicht tun" interpretieren. Ein anderes schönes Beispiel findet sich in Übung 12.

Für die Implementation eines Implikationengraphen in Python empfiehlt es sich, die Knoten geschickt zu numerieren: Ist die Variable <math>x_i</math> dem Knoten i zugeordnet, so sollte die negierte Variable <math>\neg x_i</math> dem Knoten (i+n) zugeordnet werden. Zu jedem gegebenen Knoten i findet man dann den negierten Partnerknoten j leicht durch die Formel <tt>j = (i + n ) % (2*n)</tt>.

Die Aufgabe besteht jetzt darin, folgende Fragen zu beantworten:
# Ist der durch den Implikationengraphen gegebene Ausdruck erfüllbar?
# Finde eine geeignete Belegung der Variablen, wenn der Ausduck erfüllbar ist.
Die erste Frage beantwortet man leicht, indem man die stark zusammenhängenden Komponenten des Implikationengraphen bildet. Dann gilt folgender
;Satz: Seien u und v zwei Literale, die sich in der selben stark zusammenhängenden Komponente befinden. Dann müssen u und v stets den selben Wert haben, damit der Ausdruck erfüllt sein kann.
Die Korrektheit des Satzes folgt aus der Definition der stark zusammenhängenden Komponenten: Da u und v in der selben Komponente liegen, gibt es im Implikationengraphen einen Weg <math>u \rightsquigarrow v</math> sowie einen Weg <math>v \rightsquigarrow u</math>. Wegen der Transitivität der "wenn, dann" Relation kann man die Wege zu zwei Implikationen verkürzen, die gleichzeitig gelten müssen: <math>(u \rightarrow v) \wedge (v \rightarrow u)</math> (die Verkürzung von Wegen zu direkten Kanten entspricht gerade der Bildung der transitiven Hülle für die Knoten u und v). In der obigen Wertetabelle für logische Operatoren erkennt mann, dass dies äquivalent zur Bedingung <math>(u \leftrightarrow v)</math> ist. Dies ist aber gerade die Behauptung des Satzes.

Die Erfüllbarkeit des Ausdrucks ist nun ein einfacher Spezialfall dieses Satzes.
;Korrolar: Der gegebene Ausdruck ist genau dann erfüllbar, wenn die Literale <math>x_i</math> und <math>\neg x_i</math> sich für kein i in derselben stark zusammenhängenden Komponente befinden.
Setzt man nämlich im Satz <math>u = x_i</math> und <math>v = \neg x_i</math>, und beide Knoten befinden sich in der selben Komponente, dann müsste gelten <math>x_i \leftrightarrow\neg x_i</math>, was offensichtlich ein Widerspruch ist. Damit kann der Ausdruck nicht erfüllbar sein. Umgekehrt gilt, dass der Ausdruck immer erfüllbar ist, wenn <math>x_i</math> und <math>\neg x_i</math> stets in verschiedenen Komponenten liegen, weil der folgende Algorithmus von Aspvall, Plass und Tarjan in diesem Fall stets eine gültige Belegung aller Variablen liefert:
# Bestimme die stark zusammenhängenden Komponenten und bilde den Komponentengraphen. Ordne die Knoten des Komponentengraphen (also die stark zusammenhängenden Komponenten des Originalgraphen) in topologische Sortierung an.
# Betrachte die Komponenten in der topologischen Sortierung von hinten nach vorn und weise ihnen einen Wert nach folgenden Regeln zu (zur Erinnerung: alle Literale in der selben Komponente haben den selben Wert):
#* Wenn die Komponente noch nicht betrachtet wurde, setze ihren Wert auf True, und den Wert der komplementären Komponente (derjenigen, die die negierten Literale enthält) auf False.
#* Andernfalls, gehe zur nächsten Komponente weiter.
Der Algorithmus beruht auf der Symmetrie des Implikationengraphen: Weil Kanten immer paarweise <math>(\neg u \rightarrow v) \wedge (\neg v \rightarrow u)</math> eingefügt werden, ist der Graph schiefsymmetrisch (skew symmetric): die eine Hälfte das Graphen ist die transponierte Spiegelung der anderen Hälfte. Enthält eine stark zusammenhängende Komponente <math>C_i</math> die Knoten <tt>i1, i2, ...</tt>, so gibt es stets eine komplementäre Komponente <math>C_j = \neg C_i</math>, die die komplementären Knoten <tt>j1 = (i1 + n) % (2*n), j2 = (i2 + n) % (2*n), ...</tt> enthält. Gilt <math>C_i = \neg C_i</math> für irgendein i, so ist der Ausdruck nicht erfüllbar. Den Beweis für die Korrektheit des Algorithmus findet man im [http://www.math.ucsd.edu/~sbuss/CourseWeb/Math268_2007WS/2SAT.pdf Originalartikel]. Leider funktioniert dies nicht für k-SAT-Probleme mit <math>k > 2</math>.

Will man nur die Erfüllbarkeit prüfen, vereinfacht sich der Algorithmus zu:
# Bestimme die stark zusammenhängenden Komponenten.
# Teste für alle <tt>i = 0,...,n-1</tt>, dass Knoten <tt>i</tt> und Knoten <tt>(i+n)</tt> in unterschiedlichen Komponenten liegen.
Ist der Ausdruck erfüllbar, kann man eine gültige Belegung der Variablen jetzt mit dem randomisierten Algorithmus bestimmen, den wir im Kapitel [[Randomisierte Algorithmen]] behandeln.

== Weitere wichtige Graphenalgorithmen ==

Eins der wichtigsten Einsatzgebiete für Graphen ist die Optimierung, also die Suche nach der besten Lösung für ein gegebenes Problem:
* Das interval scheduling befasst sich damit, aus einer gegebenen Menge von Aufträgen die richtigen auszuwählen und sie geschickt auf die zur Verfügung stehenden Ressourcen aufzuteilen. Damit beschäftigen wir uns im Kapitel [[Greedy-Algorithmen und Dynamische Programmierung]].
* Beim Problem des Handlungsreisenden sucht man nach der kürzesten Rundreise, die alle gegebenen Städte genau einmal besucht. Dieses Problem behandeln wir im Kapitel [[NP-Vollständigkeit]].
* Viele weitere Anwendungen können wir leider in der Vorlesung nicht mehr behandeln, z.B.
** Algorithmen für den [http://en.wikipedia.org/wiki/Maximum_flow_problem maximalen Fluss] beantworten die Frage, wie man die Durchflussmenge durch ein Netzwerk (z.B. von Ölpipelines) maximiert.
** Beim [http://en.wikipedia.org/wiki/Assignment_problem Problem der optimalen Paarung] ("matching problem" oder "assignment problem") sucht man nach einer Teilmenge der Kanten (also nach einem Teilgraphen), so dass jeder Knoten in diesem Teilgraphen höchstens den Grad 1 hat. Im neuen Graphen gruppieren die Kanten also je zwei Knoten zu einem Paar, und die Paarung soll nach jeweils anwendungsspezifischen Kriterien optimal sein. Dies benötigt man z.B. bei der optimalen Zuordnung von Gruppen, etwas beim Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot) und in der Universität (Zuordnung Studenten - Übungsgruppen).
** In Statistik und maschinellem Lernen haben in den letzten Jahren die [http://en.wikipedia.org/wiki/Graphical_model graphischen Modelle] große Bedeutung erlangt.
* usw. usf.

[[Randomisierte Algorithmen|Nächstes Thema]]

Graphen und Graphenalgorithmen

2012-07-25T17:16:32Z

Ukoethe: /* Transitive Hülle und stark zusammenhängende Komponenten */

== Einführung zu Graphen ==

=== Motivation -- Königsberger Brückenproblem ===
Leonhard Euler [http://de.wikipedia.org/wiki/Leonhard_Euler] erfand den Graphen-Formalismus 1736, um eine scheinbar banale Frage zu beantworten: Ist es möglich, in Königsberg (siehe Stadtplan von 1809 und die schematische Darstellung) einen Spaziergang zu unternehmen, bei dem jede der 7 Brücken genau einmal überquert wird?

[[Image:Koenigsberg1809.png]] 
[[Image:Koenigsberg.jpg]]

Ein Graph abstrahiert von der Geometrie des Problems und repräsentiert nur die Topologie. Jeder Stadtteil von Königsberg ist ein Knoten des Graphen, jede Brücke eine Kante. Der zum Brückenproblem gehörende Graph sieht also so aus:

O
/| \
\| \
O---O
/| /
\| /
O

Der gesuchte Spaziergang würde existieren, wenn es maximal 2 Knoten gäbe, an denen sich eine ungerade Zahl von Kanten trifft. Die Frage muss für Königsberg also verneint werden, denn hier gibt es vier solche Knoten. Ein leicht modifiziertes Problem ist allerdings lösbar: Im obigen Stadtplan erkennt man eine Fähre, die die Stadtteile Kneiphof und Altstadt verbindet. Bezieht man dieselbe in den Spaziergang ein, ergibt sich folgender Graph, bei dem nur noch zwei Knoten mit ungerader Kantenzahl existieren:

--O
/ /| \
\ \| \
--O---O
/| /
\| /
O

Inzwischen haben Graphen eine riesige Zahl weiterer Anwendungen gefunden. Einige Beispiele:

* Landkarten:
** Knoten: Länder
** Kanten: gemeinsame Grenzen

* Logische Schaltkreise:
** Knoten: Gatter
** Kanten: Verbindungen

* Chemie (Summenformeln):
** Knoten: chemische Elemente
** Kanten: Bindungen

* Soziologie (StudiVZ)
** Soziogramm
*** Knoten: Personen
*** Kanten: Freund von ...

=== Definitionen ===

;Ungerichteter Graph: Ein ungerichteter Graph G = ( V, E ) besteht aus
:* einer endliche Menge V von Knoten (vertices)
:* einer endlichen Menge <math>E \subset V \times V</math> von Kanten (edges)
:Die Paare (u,v) und (v,u) gelten dabei als nur ''eine'' Kante (somit gilt die Symmetriebeziehung: (u,v) ∈ E => (v,u) ∈ E ). Die Anzahl der Kanten, die sich an einem Knoten treffen, wird als ''Grad'' (engl. ''degree'') dieses Knotens bezeichnet:
:::degree(v) = |{v' ∈ V | (v,v') ∈ E}|
:(Die Syntax |{...}| bezeichnet dabei die Mächtigkeit der angegebenen Menge, also die Anzahl der Elemente in der Menge.)

Der Graph des Königsberger Brückenproblems ist ungerichtet. Bezeichnet man die Knoten entsprechend des folgenden Bildes
c
/| \
\| \
b---d
/| /
\| /
a

gilt für die Knotengrade: <tt>degree(a) == degree(c) == degree(d) == 3</tt> und <tt>degree(b) == 5</tt>. Genauer muss man bei diesem Graphen von einem ''Multigraphen'' sprechen, weil es zwischen einigen Knotenpaaren (nämlich (a, b) sowie (b, c)) mehrere Kanten ("Mehrfachkanten") gibt. Wir werden in dieser Vorlesung nicht näher auf Multigraphen eingehen.

;Gerichteter Graph: Ein Graph heißt ''gerichtet'', wenn die Kanten (u,v) und (v,u) unterschieden werden. Die Kante (u,v) ∈ E wird nun als Kante von u nach v (aber nicht umgekehrt) interpretiert. Entsprechend unterscheidet man jetzt den ''eingehenden'' und den ''ausgehenden Grad'' jedes Knotens:
:*out_degree(v) = |{v' ∈ V | (v,v') ∈ E}| 
:*in_degree(v) = |{v' ∈ V| (v',v) ∈ E}|

Das folgende Bild zeigt einen gerichteten Graphen. Hier gilt <tt>out_degree(1) == out_degree(3) == in_degree(2) == in_degree(4) == 2</tt> und
<tt>in_degree(1) == in_degree(3) == out_degree(2) == out_degree(4) == 0</tt>:

[[Image:digraph.png|gerichteter Graph]]

 

;Vollständiger Graph: Ein vollständiger Graph ist ein ungerichteter Graph, bei dem jeder Knoten mit allen anderen Knoten verbunden ist.
:::<math>E = \{ (v,w) | v \in V, w \in V, v \ne w \}</math>
:Ein vollständiger Graph mit |V| Knoten hat <math>|E| = \frac{|V|(|V|-1)}{2}</math> Kanten.

Die folgenden Abbildungen zeigen die vollständigen Graphen mit einem bis fünf Knoten (auch als K1 bis K5 bezeichnet).

{| border="0" cellspacing="0" cellpadding="0" style="margin: 1em auto 1em auto"
|-
| [[Image:k1.png|frame|k1]]
| [[Image:k2.png|frame|k2]]
| [[Image:k3.png|frame|k3]]
|-
| [[Image:k4.png|frame|k4]]
| [[Image:k5.png|frame|k5]]
|
|}

''Rätsel'' 
Auf einer Party sind Leute. Alle stoßen miteinander an. Es hat 78 mal "Pling" gemacht.
Wieviele Leute waren da? Antwort: Jede Person ist ein Knoten des Graphen, jedes Antoßen eine Kante.
Da alle miteinander angestoßen haben, handelt es sich um einen vollständigen Graphen. Mit
|V|(|V|-1)/2 = 78 folgt, dass es 13 Personen waren.

 

;Gewichteter Graph: Ein Graph heißt ''gewichtet'', wenn jeder Kante eine reelle Zahl zugeordnet ist. Bei vielen Anwendungen beschränkt man sich auch auf nichtnegative reelle Gewichte. In einem gerichteten Graphen können die Gewichte der Kanten (u,v) und (v,u) unterschiedlich sein.

Die Gewichte kodieren Eigenschaften der Kanten, die für die jeweilige Anwendung interessant sind. Bei der Berechnung des maximalen Flusses in einem Netzwerk sind die Gewichte z.B. die Durchflusskapazitäten jeder Kante, bei der Suche nach kürzesten Weges kodieren Sie den Abstand zwischen den Endknoten der Kante, bei Währungsnetzwerken (jeder Knoten ist eine Währung) geben sie die Wechselkurse an, usw..

 

;Teilgraphen: Ein Graph G' = (V',E') ist ein Teilgraph eines Graphen G, wenn gilt:
:* V' &sube; V
:* E' ⊂ E
:Er heißt ''(auf)spannender Teilgraph'', wenn gilt:
:* V' = V
:Er heißt ''induzierter Teilgraph'', wenn gilt:
:* e = (u,v) ∈ E' ⊂ E ⇔ u ∈ V' und v ∈ V'
:Den von V' induzierten Teilgraphen erhält man also, indem man aus G alle Knoten löscht, die nicht in V' sind, sowie alle Kanten (und nur diese Kanten), die einen der gelöschten Knoten als Endknoten haben.

 

;Wege, Pfade, Zyklen, Kreise, Erreichbarkeit: Sei G = (V,E) ein Graph (ungerichtet oder gerichteter) Graph. Dann gilt folgende rekursive Definition:
:* Für v ∈ V ist (v) ein Weg der Länge 0 in G
:* Falls <math>(v_0, v_1, ..., v_{n-1})</math> ein Weg ist, und eine Kante <math>(v_{n-1}, v_n)\in E</math> existiert, dann ist auch <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ein Weg, und er hat die Länge n.
: Ein Weg ist also eine nichtleere Folge von Knoten, so dass aufeinander folgende Knoten stets durch eine Kante verbunden sind. Die Länge des Weges entspricht der Anzahl der Kanten im Weg (= Anzahl der Knoten - 1).
:* Ein ''Pfad'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, bei dem alle Knoten vi verschieden sind.
:* ''Ein Zyklus'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, der zum Ausgangspunkt zurückkehrt, wenn also v0 = vn gilt.
:* Ein ''Kreis'' ist ein Zyklus ohne Überkreuzungen. Das heisst, es gilt v0 = vn und <math>(v_0, v_1, ..., v_{n-1})</math> ist ein Pfad.
:* Ein Knoten w ∈ V ist von einem anderen Knoten v ∈ V aus ''erreichbar'' genau dann, wenn ein Weg (v, ..., w) existiert. Wir schreiben dann <math>v \rightsquigarrow w</math>.
In einem ungerichteten Graph ist die Erreichbarkeits-Relation stets symmetrisch, das heisst aus <math>v \rightsquigarrow w</math> folgt <math>w \rightsquigarrow v</math>. In einem gerichteten Graphen ist dies im allgemeinen nicht der Fall.

Bestimmte Wege haben spezielle Namen

;Eulerweg: Ein Eulerweg ist ein Weg, der alle '''Kanten''' genau einmal enthält.

Die eingangs erwähnte Frage des Königsberger Brückenproblems ist equivalent zu der Frage, ob der dazugehörige Graph einen Eulerweg besitzt (daher der Name). Ein anderes bekanntes Beispiel ist das "Haus vom Nikolaus": Wenn man diesen Graphen in üblicher Weise in einem Zug zeichnet, erhält man gerade den Eulerweg.

O
/ \
O----O
| \/ |
| /\ | "Das Haus vom Nikolaus": Alle ''Kanten'' werden nur ''einmal'' passiert
O----O

;Hamiltonweg: Ein Hamiltonweg ist ein Weg, der alle '''Knoten''' genau einmal enthält. Das "Haus vom Nikolaus" besitzt auch einen Hamiltonweg:

O
/
O----O
/
/ Alle ''Knoten'' werden nur ''einmal'' passiert
O----O

;Hamiltonkreis: Ein Hamiltonkreis ist ein Kreis, der alle '''Knoten''' genau einmal enthält. Auch ein solches Gebilde ist im Haus von Nilolaus enthalten:

O
/ \
O O
| | v0 = vn
| | vi != vj Für Alle i,j i !=j; i,j >0; i,j < n
O----O

Die folgende Skizze zeigt hingegen einen Zyklus: Der Knoten rechts unten sowie die untere Kante sind zweimal enthalten (die Kante einmal von links nach rechts und einmal von rechts nach links):

O
/ \
O O
\ |
\ | Zyklus
O====O

 

;Zusammenhang, Zusammenhangskomponenten: Ein ungerichteter Graph G heißt ''zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math>
:Ein gerichteter Graph G ist zusammenhängend, wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''oder''' <math>w \rightsquigarrow v</math>.
:Er ist ''stark zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''und''' <math>w \rightsquigarrow v</math>.
:Entsprechende Definitionen gelten für Teilgraphen G'. Ein Teilgraph G' heisst ''Zusammenhangskomponente'' von G, wenn er ein ''maximaler'' zusammenhängender Teilgraph ist, d.h. wenn G' zusammenhängend ist, und man keine Knoten und Kanten aus G mehr zu G' hinzufügen kann, so dass G' immer noch zusammenhängend bleibt. Entsprechend definiert man ''starke Zusammenhangskomponenten'' in einem gerichteten Graphen.

 

;Planarer Graph, ebener Graph: Ein Graph heißt ''planar'', wenn er so in einer Ebene gezeichnet werden ''kann'', dass sich die Kanten nicht schneiden (außer an den Knoten). Ein Graph heißt ''eben'', wenn er tatsächlich so gezeichnet ''ist'', dass sich die Kanten nicht schneiden. Die Einbettung in die Ebene ist im allgemeinen nicht eindeutig.

'''Beispiele:'''

Der folgende Graph ist planar und eben:

O
/|\
/ O \
/ / \ \
O O

Das "Haus vom Nikolaus" ist ebenfalls planar, wird aber üblicherweise nicht als ebener Graph gezeichnet, weil sich die Diagonalen auf der Wand überkreuzen:

O
/ \
O----O
| \/ |
| /\ |
O----O

Eine ebene Einbettung dieses Graphen wird erreicht, wenn man eine der Diagonalen ausserhalb des Hauses zeichnet. Der Graph (also die Menge der Knoten und Kanten) ändert sich dadurch nicht.

O
/ \
--O----O
/ | / |
| | / |
| O----O Das "Haus vom Nikolaus" als ebener Graph gezeichnet.
\ /
-----

Eine alternative Einbettung erhalten wir, wenn wir die andere Diagonale außerhalb des Hauses zeichnen:

O
/ \
O----O--|
| \ | |
| \ | |
O----O | Alternative Einbettung des "Haus vom Nikolaus".
| |
|-------|

Jede Einbettung eines planaren Graphen (also jeder ebene Graph) definiert eine eindeutige Menge von ''Regionen'':

|----O @
| /@ \
| O----O
| |@ / |
| | / @|
| O----O @ entspricht jeweils einer ''Region''. Auch ausserhalb der Figur ist eine Region (die sogenannte ''unendliche'' Region).
|@ |
|-------|

Der vollständige Graph K5 ist kein planarer Graph, da sich zwangsweise Kanten schneiden, wenn man diesen Graphen in der Ebene zeichnet.

 
;Dualer Graph: Jeder ebene Graph G = (V, E) hat einen ''dualen Graphen'' D = (VD, ED), dessen Knoten und Kanten wie folgt definiert sind:
:* VD enthält einen Knoten für jede Region des Graphen G
:* Für jede Kante e ∈ E gibt es eine duale Kante eD ∈ ED, die die an e angrenzenden Regionen (genauer: die entsprechenden Knoten in D) verbindet.

Die folgende Abbildung zeigt einen Graphen (grau) und seinen dualen Graphen (schwarz). Die Knoten des dualen Graphen sind mit Zahlen gekennzeichnet und entsprechen den Regionen des Originalgraphen. Jeder (grauen) Kante des Originalgraphen entspricht eine (schwarze) Kante des dualen Graphen.

 
[[Image:dual-graphs.png]]
 

Für duale Graphen gilt: Wenn der Originalgraph zusammenhängend ist, enthält jede Region des dualen Graphen genau einen Knoten des Originalgraphen. Deshalb ist der duale Graph des dualen Graphen wieder der Originalgraph. Bei nicht-zusammenhängenden Graphen gilt dies nicht (vgl. das Fenster bei obigem Bild). In diesem Fall hat der duale Graph mehrere mögliche Einbettungen in die Ebene (man kann z.B. die rechte Kante zwischen Knoten 2 und 4 auch links vom Fenster einzeichnen), und man erhält nicht notwendigerweise den Originalgraphen, wenn man den dualen Graphen des dualen berechnet.

;Baum: Ein ''Baum'' ist ein zusammenhängender, kreisfreier Graph.

Beispiel: Binärer Suchbaum

;Spannbaum: Ein ''Spannbaum'' eines zusammenhängenden Graphen G ist ein zusammenhängender, kreisfreier Teilgraph von G, der alle Knoten von G enthält

Beispiel: Spannbaum für das "Haus des Nikolaus"

O
/
O O
| /
| /
O----O

Der Spannbaum eines Graphen mit |V| Knoten hat stets |V| - 1 Kanten.

;Wald: Ein ''Wald'' ist ein unzusammenhängender, kreisfreier Graph.
: Jede Zusammenhangskomponente eines Waldes ist ein Baum.

=== Repräsentation von Graphen ===

Sei G = ( V, E ) gegeben und liege V in einer linearen Sortierung vor. 
:::<math>V = \{ v_1, ...., v_n \}</math>

;Adjazenzmatrix: Ein Graph kann durch eine Adjazenzmatrix repräsentiert werden, die soviele Zeilen und Spalten enthält, wie der Graph Knoten hat. Die Elemente der Adjazenzmatrix sind "1", falls eine Kante zwischen den zugehörigen Knoten existiert:
:::<math>\mathrm{\bold A} = a_{ij} =
\begin{cases}
1 & \mathrm{falls}\quad (v_i, v_j) \in E \\
0 & \mathrm{sonst}
\end{cases}
</math>
:Die Indizes der Matrix entsprechen also den Indizes der Knoten gemäß der gegebenen Sortierung. Im Falle eines ungerichteten Graphen ist die Adjazenzmatrix stets symmetrisch (d.h. es gilt <math>a_{ij}=a_{ji}</math>), bei einem gerichteten Graphen ist sie im allgemeinen unsymmetrisch.

Beispiel für einen ungerichteten Graphen:

v = { a,b,c,d } b d
| \ / |
| \/ |
| /\ |
| / \ |
a c

a b c d
-----------
(0 1 0 1) |a
A = (1 0 1 0) |b
(0 1 0 1) |c
(1 0 1 0) |d

Die Adjazenzmatrixdarstellung eignet sich besonders für dichte Graphen (d.h. wenn die Zahl der Kanten in O(|V|2) ist.

;Adjazenzlisten: In der Adjazenzlistendarstellung wird der Graph als Liste von Knoten repräsentiert, die für jeden Knoten einen Eintrag enthält. Der Eintrag für jeden Knoten ist wiederum eine Liste, die die Nachbarknoten dieses Knotens enthält:
:* graph = {adjazencyList(v) | v ∈ V}
:* adjazencyList(v) = {v' ∈ V | (v, v') ∈ E}

In Python implementieren wir Adjazenzlisten zweckmäßig als Array von Arrays:

graph = [[...],[...],...,[...]]
Adjazenzliste für Knoten => 0 1 n

Wenn wir bei dem Graphen oben die Knoten wie bei der Adjazenzmatrix indizieren (also <tt>a => 0</tt>, <tt>b => 1</tt>, <tt>c => 2</tt>, <tt>d => 3</tt>), erhalten wir die Adjazenzlistendarstellung:

graph = [[b, d], [a, c],[b, d], [a, c]]

Auf die Nachbarknoten eines durch seinen Index <tt>node</tt> gegebenen Knotens können wir also wie folgt zugreifen:

for neighbors in graph[node]:
... # do something with neighbor

Die Adjazenzlistendarstellung ist effizienter, wenn der Graph nicht dicht ist, so dass viele Einträge der Adjazenzmatrix Null wären. In der Vorlesung werden wir nur diese Darstellung verwenden.

;<div id="transposed_graph">Transponierter Graph</div>: Den ''transponierten Graphen'' GT eines gerichteten Graphen G erhält man, wenn man alle Kantenrichtungen umkehrt.

Bei ungerichteten Graphen hat die Transposition offensichtlich keinen Effekt, weil alle Kanten bereits in beiden Richtungen vorhanden sind, so dass GT = G gilt. Bei gerichteten Graphen ist die Transposition einfach, wenn der Graph als Adjazenzmatrix implementiert ist, weil man einfach die transponierte Adjazenzmatrix verwenden muss (beachte, dass sich die Reihenfolge der Indizes umkehrt):
:::AT = aji
Ist der Graph hingegen durch eine Adjazenzliste repräsentiert, muss etwas mehr Aufwand getrieben werden:

def transposeGraph(graph):
gt = [[] for k in graph] # zunächst leere Adjazenzlisten von GT
for node in range(len(graph)):
for neighbor in graph[node]:
gt[neighbor].append(node) # füge die umgekehrte Kante in GT ein
return gt

== Durchlaufen von Graphen (Graph Traversal) ==

Wir betrachten zunächst ungerichtete Graphen mit V Knoten und E Kanten. Eine grundlegende Aufgabe in diesen Graphen besteht darin, alle Knoten in einer bestimmten Reihenfolge genau einmal zu besuchen. Hierbei darf man sich von einem gegebenen Startknoten aus nur entlang der Kanten des Graphen bewegen. Die beim Traversieren benutzen Kanten bilden einen Baum, dessen Wurzel der Startknoten ist und der den gesamten Graphen aufspannt, falls der Graph zusammenhängend ist. (Beweis: Da jeder Knoten nur einmal besucht wird, gibt es für jeden besuchten Knoten [mit Ausnahme des Startknotens] genau eine eingehende Kante. Ist der Graph zusammenhängend, wird jeder Knoten tatsächlich erreicht und es gibt genau (V-1) Kanten, exakt soviele wie für einen Baum mit V Knoten notwendig sind.) Ist der Graph nicht zusammenhängend, wird jeder zusammenhängende Teilgraph (jede Zusammenhangskomponente) getrennt traversiert, und man erhält einen sogenannten Wald mit einem Baum pro Zusammenhangskomponente. Die beiden grundlegenden Traversierungsmethoden Tiefensuche und Breitensuche werden im folgenden vorgestellt.

=== Tiefensuche in Graphen (Depth First Search, DFS) ===

Die Idee der Tiefensuche besteht darin, jeden besuchten Knoten sofort über die erste Kante wieder zu verlassen, die zu einem noch nicht besuchten Knoten führt. Man findet dadurch schnell einen möglichst langen Pfad durch den Graphen, und der Traversierungs-Baum wird zunächst in die Tiefe verfolgt, daher der Name des Verfahrens. Hat ein Knoten keine unbesuchten Nachbarknoten mehr, geht man im Baum zurück (sogenanntes back tracking), bis man einen Knoten findet, der noch eine unbesuchte Nachbarn besitzt, und traversiert diese nach dem gleichen Muster. Gibt es gar keine unbesuchten Knoten mehr, kehrt die Suche zum Startknoten zurück und endet dort.

WDie folgende rekursive Implementation der Tiefensuche erwartet den Graphen in Adjazenzlistendarstellung und beginnt die Suche beim Knoten <tt>startnode</tt>. Die Information, ob ein Knoten bereits besucht wurde, wird im Array <tt>visited</tt> gespeichert. Ein solches Array, das zusätzliche Informationen über die Knoten des Graphen bereitstellt, wir häufig property map genannt.

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
print node # Ausgabe der Knotennummer - pre-order
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)

visit(startnode)

[[Image:Tiefens.jpg]]

Ausgabe für den Graphen in diesem Bild (es handelt sich um einen ungerichteten Graphen, die Pfeile symbolisieren nur die Suchrichtung beim Traversal):

>>> dfs(graph, 1)
1
2
4
3
6
7
5

<div id="pre_and_post_order">In dieser Version des Algorithmus werden die Knotennummern ausgegeben, bevor die Nachbarknoten besucht werden. Man bezeichnet die resultierende Sortierung der Knoten als pre-order oder als discovery order. Alternativ kann man die Knotennummern erst ausgeben, nachdem alle Nachbarn besucht wurden, also auf dem Rückweg der Rekursion. In diesem Fall spricht man von post-order oder finishing order:</div>

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)
print node # Ausgabe der Knotennummer - post-order

visit(startnode)

Es ergibt sich jetzt die Ausgabe:

>>> dfs(graph, 1)
6
7
3
4
5
2
1

In realem Code ersetzt man die print-Ausgaben natürlich durch anwendungsspezifische Aktionen und Berechnungen. Einige Anwendungen sind uns im Kapitel [[Suchen]] bereits begegnet.
; Anwendungen der Pre-Order Traversierung
* Kopieren eines Graphen: kopiere zuerst den besuchten Knoten, dann seine Nachbarn und die dazugehörigen Kanten (sowie die Kanten zu bereits besuchten Knoten, die in der Grundversion der Tiefensuche ignoriert werden).
* Bestimmen der Zusammenhangskomponenten eines Graphen (siehe unten)
* In einem Zeichenprogramm: fülle eine Region mit einer Farbe ("flood fill"). Dabei ist jedes Pixel ein Knoten des Graphen und wird mit seinen 4 Nachbarpixceln verbunden. Die Tiefensuche startet bei der Mausposition und endet am Rand des betreffendcen Gebiets.
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von der Wurzel
* Falls der Graph ein Parse-Baum ist, wobei innere Knoten Funktionsaufrufe, Kindknoten Funktionsargumente, und Blattknoten Werte repräsentieren: drucke den zugehörigen Ausdruck aus (also immer zuerst den Funktionsnamen, dann die Argumente, die wiederum geschachtelte Funktionsaufrufe sein können).
; Anwendungen der Post-Order Traversierung
* Löschen eines Graphen: lösche zuerst die Nachbarn, dann den Knoten selbst
* Bestimmen einer topologischen Sortierung eines azyklischen gerichteten Graphens (siehe unten)
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von den Blättern (also die Tiefe des Baumes, siehe Übung 5)
* Falls der Graph ein Parse-Baum ist: führe die zugehörige Berechnung aus (d.h. berechne zuerst die geschachtelten inneren Funktionen, dann mit diesen Ergebnissen die nächst äußeren usw., siehe Übung 5).
; Anwendungen, die Pre- und Post-Order benötigen
* Weg aus einem Labyrinth: die Pre-Order dokumentiert die Suche nach dem Weg, die Post-Order zeigt den Rückweg aus Sackgassen (siehe Übung 9).
Im Spezialfall, wenn der Graph ein Binärbaum ist, unterscheidet man noch eine dritte Variante der Traversierung, nämlich die in-order Traversierung. In diesem Fall behandelt man den Vaterknoten nach den linken, aber vor den rechten Kindern. Diese Reihenfolge wird beim [[Suchen#Beziehungen zwischen dem Suchproblem und dem Sortierproblem|Tree Sort Algorithmus]] verwendet. Diese Sortierung verwendet man auch, wenn man einen Parse-Baum mit binären Operatoren (statt Funktionsaufrufen) ausgeben will, siehe Übung 5.

Eine nützliche Erweiterung der Tiefensuche besteht darin, in der property map <tt>visited</tt> nicht nur zu dokumentieren, dass ein Knoten bereits besucht wurde, sondern auch, von welchem Knoten aus man den jeweiligen Knoten zuerst erreicht hat. Im entstehenden Tiefensuchbaum ist dies gerade der Vaterknoten, weshalb wir die verbesserte property map zweckmäßigerweise in <tt>parents</tt> umbenennen. Für den Startknoten, also die Wurzel des Baumes, wählen wir die Konvention, dass er sein eigener Vaterknoten ist (die Konvention, dafür den Wert <tt>None</tt> zu verwenden, scheidet aus, weil dies bereits die Tatsache signalisiert, dass ein Knoten noch nicht besucht wurde):

def dfs(graph, startnode):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Tiefensuchbaum

def visit(node, parent): # rekursive Hilfsfunktion
if parents[node] is None: # Besuche node, wenn er noch nicht besucht wurde
parents[node] = parent # Markiere node als besucht und speichere seinen Vaterknoten
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn ...
visit(neighbor, node) # ... wobei node zu deren Vaterknoten wird

visit(startnode, startnode) # Konvention für Wurzel: startnode ist sein eigener Vater

return parents # Rückgabe des berechneten Tiefensuch-Baums

Die Ausgabe für den obigen Beispielgraphen lautet:
Knotennummer | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
--------------+-----+-----+-----+-----+-----+-----+-----+-----
Vaterknoten | None| 1 | 1 | 4 | 2 | 2 | 3 | 3

Dabei ist die Knotennummer der Index im Array <tt>parents</tt>, und der Vaterknoten ist der dazugehörige Arrayeintrag. Beachte, dass Knoten 0 in diesem Graphen nicht existiert, daher ist sein Eintrag <tt>None</tt>. Per Konvention hat der Wurzelknoten 1 sich selbst als Vater.

=== Breitensuche in Graphen (Breadth First Search, BFS) ===

Im Gegensatz zur Tiefensuche werden bei der Breitensuche alle Nachbarnknoten abgearbeitet, bevor man rekursiv deren Nachbarn besucht. Man betrachtet somit zuerst alle Knoten, die den Abstand 1 von Startknoten haben, dann diejenigen mit dem Abstand 2 usw. Diese Reihenfolge bezeichnet man als level-order. Wir sind ihr beispielsweise in Übung 6 begegnet, als die ersten 7 Ebenen eines Treap ausgegeben werden sollten. Man implementiert Breitensuche zweckmäßig mit Hilfe einer Queue, die die Knoten in First In - First Out - Reihenfolge bearbeitet. Eine geeignete Datenstruktur hierfür ist die Klasse <tt>[http://docs.python.org/library/collections.html#collections.deque deque]</tt> aus dem Python-Modul <tt>[http://docs.python.org/library/collections.html collections]</tt> (eine Deque implementiert sowohl die Funktionalität einer Queue wie auch die eines Stacks, siehe Übung 3):

from collections import deque

def bfs(graph, startnode)
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if not visited[node]: # Falls node noch nicht (auf einem anderen Weg) besucht wurde
visited[node] = True # Markiere node als besucht
print node # Drucke Knotennummer
for neighbor in graph[node]: # Füge Nachbarn in die Queue ein
q.append(neighbor)

[[Image:Breitens.jpg]]

Der Aufruf dieser Funktion liefert die Knoten des obigen Graphens ebenenweise, also zufällig genau in der Reihenfolge der Knotennummern:
>>> bfs(graph, 1)
1
2
3
4
5
6
7

Neben der ebenenweisen Ausgabe hat die Breitensuche viele weitere wichtige Anwendungen, z.B. beim Testen, ob ein gegebener Graph bi-partit ist (siehe [http://en.wikipedia.org/wiki/Breadth-first_search#Testing_bipartiteness WikiPedia]), sowie bei der Suche nach kürzesten Wegen (siehe unten) und kürzesten Zyklen.

== Weitere Anwendungen der Tiefensuche ==

Die Tiefensuche hat zahlreiche Anwendungen, wobei der grundlegende Algorithmus immer wieder leicht modifiziert und an die jeweilige Aufgabe angepasst wird. Wir beschreiben im folgenden einige Beispiele.

=== Damenproblem ===

Tiefensuche wird häufig verwendet, um systematisch nach der Lösung eines logischen Rätsels (oder allgemeiner nach der Lösung eines diskreten Optimierungsproblems) zu suchen. Besonders anschaulich hierfür ist das Damenproblem. Die Aufgabe besteht darin, <math>k</math> Damen auf einem Schachbrett der Größe <math>k \times k</math> so zu platzieren, dass sie sich (nach den üblichen Schach-Regeln) nicht gegenseitig schlagen können. Das folgende Diagramm zeigt eine Lösung für den Fall <math>k=4</math>. Die Positionen der Damen werden dabei wie üblich durch die Angabe der Spalte (Linie) mit Buchstaben und der Zeile (Reihe) mit Zahlen kodiert, hier also A2, B4, C1, D3:

---------------
| | X | | | 4
|---|---|---|---|
| | | | X | 3
|---|---|---|---|
| X | | | | 2
|---|---|---|---|
| | | X | | 1
---------------
A B C D

Um das Problem systematisch zu lösen, konstruieren wir einen gerichteten Graphen, dessen Knoten die möglichen Positionen der Damen kodieren. Wir verbinden Knoten, die zu benachbarten Linien gehören, genau dann mit einer Kante, wenn die zugehörigen Positionen kompatibel sind, also wenn sich die dort positionierten Damen nicht schlagen können. Der resultierende Graph für <math>k=4</math> hat folgende Gestalt:

[[Image:damenproblem-graph.png|500px|center]]

Knoten, die zur selben Reihe oder Linie gehören, sind beispielsweise nicht direkt verbunden, weil zwei Damen niemals in derselben Linie oder Reihe stehen dürfen. Um eine erlaubte Konfiguration zu finden, verwenden wir nun eine angepasste Version der Tiefensuche: Wir beginnen die Suche beim Knoten <tt>START</tt>. Sobald wir den Knoten <tt>STOP</tt> erreichen, beenden wir die Suche und lesen die Lösung am gerade gefundenen Weg von Start nach Stop ab. Zwei kleine Modifikationen des Grundalgorithmus stellen sicher, dass die Bedingungen der Aufgabe eingehalten werden: Wir dürfen bei der Tiefensuche nur dann zu einem Nachbarn weitergehen, wenn die betreffende Position mit allen im Pfad bereits gesetzten Positionen kompatibel ist, andernfalls ist diese Kante tabu. Landen wir aufgrund dieser Regel in einer Sackgasse (also in einem Knoten, wo keine der ausgehenden Kanten erlaubt ist), müssen wir zur nächsten erlaubten Abzweigung zurückgehen (Backtracking). Beim Zurückgehen müssen wir das <tt>parent</tt>-Flag wieder auf <tt>None</tt> zurücksetzen, weil der betreffende Knoten ja möglicherweise auf einem anderen erlaubten Weg erreichbar ist.

Der folgende Graph zeigt einen solchen Fall: Wir haben zwei Damen auf die Felder A1 und B3 positioniert (grüne Pfeile). Die einzig ausgehende Kante von B3 führt zum Knoten C1, welcher aber mit der Position A1 inkompatibel ist, so dass diese Kante nicht verwendet werden darf (roter Pfeil). Das Backtracking muss jetzt zu Knoten A1 zurückgehen (dabei wird das <tt>parent</tt>-Flag von B3 wieder auf <tt>None</tt> gesetzt), weil A1 mit der Kante nach B4 eine weitere Option hat, die geprüft werden muss (die allerdings hier auch nicht zum Ziel führt).

[[Image:damenproblem-graph-failure.png|500px|center]]

Nach einigen weiteren Sackgassen findet man schließlich den Pfad A2, B4, C1, D3, der im folgenden Graphen grün markiert ist und der obigen Lösung entspricht:

[[Image:damenproblem-graph-success.png|500px|center]]

=== Test, ob ein ungerichteter Graph azyklisch ist ===

Ein zusammenhängender ungerichteter Graph ist azyklisch (also ein Baum) genau dann, wenn es nur einen möglichen Weg von jedem Knoten zu jedem anderen gibt. (Bei gerichteten Graphen sind die Verhältnisse komplizierter. Wir behandeln dies weiter unten.) Das kann man mittels Tiefensuche leicht feststellen: Die Kante, über die wir einen Knoten erstmals erreichen, ist eine Baumkante des Tiefensuchbaums. Erreichen wir einen bereits besuchten Knoten nochmals über eine andere Kante, haben wir einen Zyklus gefunden. Dabei müssen wir allerdings beachten, dass in einem ungerichteten Graphen jede Baumkante zweimal gefunden wird, einmal in Richtung vom Vater zum Kind und einmal in umgekehrter Richtung. Im zweiten Fall endet die Kante zwar in einem bereits besuchten Knoten (dem Vater), aber es entsteht dadurch kein Zyklus. Den Vaterknoten müssen wir deshalb überspringen, wenn wir über die Nachbarn iterieren:

def undirected_cycle_test(graph): # Annahme: der Graph ist zusammenhängend
# (andernfalls führe den Algorithmus für jede Zusammenhangskomponente aus)
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node, from_node): # rekursive Hilfsfunktion: gibt True zurück, wenn Zyklus gefunden wurde
if not visited[node]: # wenn node noch nicht besucht wurde
visited[node] = True # markiere node als besucht
for neighbor in graph[node]: # besuche die Nachbarn ...
if neighbor == from_node: # ... aber überspringe den Vaterknoten
continue
if visit(neighbor, node): # ... signalisiere, wenn rekursiv ein Zyklus gefunden wurde
return True
return False # kein Zyklus gefunden
else:
return True # Knoten schon besucht => Zyklus

startnode = 0 # starte bei beliebigem Knoten (hier: Knoten 0)
return visit(startnode, startnode) # gebe True zurück, wenn ein Zyklus gefunden wurde

Wenn wir einen Zyklus finden, wird das weitere Traversieren das Graphen abgebrochen, denn ein Graph, der einmal zyklisch war, kann später nicht wieder azyklisch werden. Die notwendige Modifikation für unzusammenhängende Graphen erfolgt analog zum Algorithmus für die Detektion von Zusammenhangskomponenten, der im nächsten Abschnitt beschrieben wird.

=== Finden von Zusammenhangskomponenten ===

Das Auffinden und Markieren von Zusammenhangskomponenten (also maximalen zusammenhängenden Teilgraphen) ist eine grundlegende Aufgabe in ungerichteten, unzusammenhängenden Graphen (bei gerichteten Graphen sind die Verhältnisse wiederum komplizierter, siehe unten). Zwei Knoten u und v gehören zur selben Zusammenhangskomponente genau dann, wenn es einen Pfad von u nach v gibt (da der Graph ungerichtet ist, gibt es dann auch einen Pfad von v nach u). Man sagt auch, dass "v von u aus erreichbar" ist. Unzusammenhängende Graphen entstehen in der Praxis häufig, wenn die Kanten gewisse Relationen zwischen den Knoten kodieren:
* Wenn die Knoten Städte sind und die Kanten Straßen, sind diejenigen Städte in einer Zusammenhangskomponente, die per Auto von einander erreichbar sind. Unzusammenhängende Graphen entstehen hier beispielsweise, wenn eine Insel nicht durch eine Brücke erschlossen ist, wenn Grenzen gesperrt sind oder wenn ein Gebirge zu unwegsam ist, um Straßen zu bauen.
* Wenn Knoten Personen sind, und Kanten die Eltern-Kind-Relation beschreiben, so umfasst jede Zusammenhangskomponenten die Verwandten (auch wenn sie nur über viele "Ecken" verwandt sind).
* In der Bildverarbeitung entsprechen Knoten den Pixeln, und dieselben werden durch eine Kante verbunden, wenn sie zum selben Objekt gehören. Die Zusammenhangskomponenten entsprechen somit den Objekten im Bild (siehe Übungsaufgabe).
Die Zusammenhangskomponenten bilden eine Äquivalenzrelation. Folglich kann für jede Komponente ein Reprässentant bestimmt werden, der sogenannte "Anker". Kennt jeder Knoten seinen Anker, ist das Problem der Zusammenhangskomponenten gelöst.

==== Lösung mittels Tiefensuche ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden. Anstelle der property map <tt>visited</tt> verwenden wir diesmal eine property map <tt>anchors</tt>, die für jeden Knoten die Knotennummer des zugehörigen Ankers angibt, oder <tt>None</tt>, wenn der Knoten noch nicht besucht wurde. Dabei verwenden wir wieder die Konvention, dass Anker auf sich selbst zeigen. Für viele Anwendungen ist es außerdem (oder stattdessen) zweckmäßig, die Zusammenhangskomponenten mit einer laufenden Nummer, einem sogenannten Label, durchzuzählen. Dann kann man zusätzliche Informationen zu jeder Komponente (beispielsweise deren Größe) einfach in einem Array speichern, das über die Labels indexiert wird. Die folgende Version der Tiefensuche bestimmt sowohl die Anker als auch die Labels für jeden Knoten:

def connectedComponents(graph):
anchors = [None] * len(graph) # property map für Anker jedes Knotens
labels = [None] * len(graph) # property map für Label jedes Knotens

def visit(node, anchor):
"""anchor ist der Anker der aktuellen ZK"""
if anchors[node] is None: # wenn node noch nicht besucht wurde:
anchors[node] = anchor # setze seinen Anker
labels[node] = labels[anchor] # und sein Label
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor, anchor)

current_label = 0 # Zählung der ZK beginnt bei 0
for node in xrange(len(graph)):
if anchors[node] is None: # Anker noch nicht bekannt => neue ZK gefunden
labels[node] = current_label # Label des Ankers setzen
visit(node, node) # Knoten der neuen ZK rekursiv suchen
current_label += 1 # Label für die nächste ZK hochzählen
return anchors, labels
Interessant ist hier die Schleife über alle Knoten des Graphen am Ende des Algorithmus, die bei den bisherigen Versionen der Tiefensuche nicht vorhanden war. Um ihre Funktionsweise zu verstehen, nehmen wir für den Moment an, dass der Graph zusammenhängend ist. Dann findet diese Schleife den ersten Knoten des Graphen und führt die Tiefensuche mit diesem Knoten als Startknoten aus. Sobald die Rekursion zurückkehrt, sind alle Knoten des Graphen besucht (weil der Graph ja zusammenhängend war), so dass die Schleife alle weiteren Knoten überspringt (die if-Anweisung liefert für keinen weiteren Knoten True). Bei unzusammenhängenden Graphen dagegen erreicht die Tiefensuche nur die Knoten derselben Komponente, die im weiteren Verlauf der Schleife übersprungen werden. Findet die if-Anweisung jetzt einen noch nicht besuchten Knoten, muss dieser folglich in einer neuen Komponente liegen. Wir verwenden diesen Knoten als Anker und bestimmen die übrigen Knoten dieser Komponente wiederum mit Tiefensuche.

* Beispiel: ... under construction 

Man erkennt, dass die Tiefensuche nach dem Anlagerungsprinzip vorgeht: Beginnend vom einem Startknoten (dem Anker) werden die Knoten der aktuellen Komponente nach und nach an den Tiefensuchbaum angehangen. Erst, wenn nichts mehr angelagert werden kann, geht der Algorithmus zur nächsten Komponente über.

==== Lösung mittels Union-Find-Algorithmus ====

Im Gegensatz zum Anlagerungsprinzip sucht der Union-Find-Algorithmus die Zusammenhangskomponenten mit dem Verschmelzungsprinzip: Eingangs wird jeder Knoten als ein Teilgraph für sich betrachtet. Dann iteriert man über alle Kanten und verbindet deren Endknoten jeweils zu einem gemeinsamen Teilgraphen (falls die beiden Enden einer Kante bereits im selben Teilgraphen liegen, wird diese Kante ignoriert). Solange noch Kanten vorhanden sind, werden dadurch immer wieder Teilgraphen in größere Teilgraphen verschmolzen. Am Ende bleiben die maximalen zusammenhängenden Teilgraphen (also gerade die Zusammenhangskomponenten) übrig. Dieser Algorithmus kommt ohne Tiefensuche aus und ist daher in der Praxis oft schneller, allerdings auch etwas komplizierter zu implementieren.

Der Schlüssel des Algorithmus ist eine Funktion <tt>findAnchor()</tt>, die zu jedem Knoten den aktuellen Anker sucht. Der Anker existiert immer, da jeder Knoten von Anfang an zu einem Teilgraphen gehört (anfangs ist jeder Teilgraph trivial und besteht nur aus dem Knoten selbst). Die Verschmelzung wird realisiert, indem der Anker des einen Teilgraphen seine Rolle verliert und stattdessen der Anker des anderen Teilgraphen eingesetzt wird.

Zur Verwaltung der Anker verwenden wir wieder eine property map <tt>anchors</tt> mit der Konvention, dass die Anker auf sich selbst verweisen. Es wäre jedoch zu teuer, wenn man bei jeder Verschmelzung alle Anker-Einträge der beteiligten Knoten aktualisieren müsste, da jeder Knoten im Laufe des Algorithmus mehrmals seinen Anker wechseln kann. Statt dessen definiert man Anker rekursiv: Verweist ein Knoten auf einen Anker, der mittlerweile diese Rolle verloren hat, folgt man dem Verweis von diesem Knoten (dem ehemaligen Anker) weiter, bis man einen tatsächlichen Anker gefunden hat - erkennbar daran, dass er auf sich selbst verweist. Diese Suchfunktion kann folgendermassen implementiert werden:

def findAnchor(anchors, node):
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
return node

Allerdings kann diese Kette im Laufe vieler Verschmelzungen sehr lang werden, so dass das Verfolgen der Kette teuer wird. Man vermeidet dies durch die sogenannte Pfadkompression: Immer, wenn man den Anker gefunden hat, aktualisiert man den Eintrag am Anfang der Kette. Die Funktion <tt>findAnchor()</tt> wird dadurch nur wenig komplizierter:

def findAnchor(anchors, node):
start = node # wir merken uns den Anfang der Kette
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
anchors[start] = node # Pfadkompression: aktualisiere den Eintrag am Anfang der Kette
return node

Man kann zeigen, dass die Ankersuche mit Pfadkompression zu einer fast konstanten amortisierten Laufzeit pro Aufruf führt.

Um mit jeder Kante des (ungerichteten) Graphen nur maximal einmal eine Verschmelzung durchzuführen, betrachten wir jede Kante nur in der Richtung von der kleineren zur größeren Knotennummer, die umgekehrte Richtung wird ignoriert. Außerdem ist es zweckmäßig, bei jeder Verschmelzung denjenigen Anker mit der kleineren Knotennummer als neuen Anker zu übernehmen. Dann gilt für jede Zusammenhangskomponente, dass gerade der Knoten mit der kleinsten Knotennummer der Anker ist (genau wie bei der Lösung mittels Tiefensuche), was die weitere Analyse vereinfacht, z.B. die Zuordnung der Labels zu den Komponenten am Ende des Algorithmus.

def unionFindConnectedComponents(graph):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker

for node in xrange(len(graph)): # iteriere über alle Knoten
for neighbor in graph[node]: # ... und über deren ausgehende Kanten
if neighbor < node: # ignoriere Kanten, die in falscher Richtung verlaufen
continue
# hier landen wir für jede Kante des Graphen genau einmal
a1 = findAnchor(anchors, node) # finde Anker ...
a2 = findAnchor(anchors, neighbor) # ... der beiden Endknoten
if a1 < a2: # Verschmelze die beiden Teilgraphen
anchors[a2] = a1 # (verwende den kleineren der beiden Anker als Anker des
elif a2 < a1: # entstehenden Teilgraphen. Falls node und neighbor
anchors[a1] = a2 # den gleichen Anker haben, waren sie bereits im gleichen
# Teilgraphen, und es passiert hier nichts.)
# Bestimme jetzt noch die Labels der Komponenten
labels = [None]*len(graph) # Initialisierung der property map für Labels
current_label = 0 # die Zählung beginnt bei 0
for node in xrange(len(graph)):
a = findAnchor(anchors, node) # wegen der Pfadkompression zeigt jeder Knoten jetzt direkt auf seinen Anker
if a == node: # node ist ein Anker
labels[a] = current_label # => beginne eine neue Komponente
current_label += 1 # und zähle Label für die nächste ZK hoch
else:
labels[node] = labels[a] # node ist kein Anker => setzte das Label des Ankers
# (wir wissen, dass labels[a] bereits gesetzt ist, weil
# der Anker immer der Knoten mit der kleinsten Nummer ist)
return anchors, labels

* Beispiel: ... under construction

== Kürzeste Wege (Pfade) ==

Eine weitere grundlegende Aufgabe in Graphen ist die Bestimmung eines kürzesten Weges zwischen zwei gegebenen Knoten. Dies hat offensichtliche Anwendungen bei Routenplanern und Navigationssystemen und ist darüber hinaus wichtiger Bestandteil anderer Algorithmen, z.B. bei der Berechnung eines maximalen Flusses mit der [http://en.wikipedia.org/wiki/Edmonds%E2%80%93Karp_algorithm Methode von Edmonds und Karp].

=== Kürzeste Wege in ungewichteten Graphen mittels Breitensuche ===

Im Fall eines ungewichteten Graphen ist die Länge eines Weges einfach durch die Anzahl der durchlaufenen Kanten definiert. Daraus folgt, dass kürzeste Pfade mit einer leicht angepassten Version der Breitensuche gefunden werden können: Aufgrund des first in-first out-Verhaltens der Queue betrachtet die Breitensuche alle (erreichbaren) Knoten in der Reihenfolge ihres Abstandes vom Startknoten. Wenn wir den Zielknoten zum ersten Mal erreichen, und der gerade gefundene Weg vom Start zum Ziel hat die Länge L, muss dies der kürzeste Weg sein: Alle möglichen Wege der Länge L' < L hat die Breitensuche ja bereits betrachtet, ohne dass dabei der Zielknoten erreicht wurde. Daraus folgt übrigens eine allgemeine Eigenschaft aller Algorithmen für kürzeste Wege: Wenn der kürzeste Weg vom Start zum Ziel die Länge L hat, finden diese Algorithmen als Nebenprodukt auch die kürzesten Wege zu allen Knoten, für die L' < L gilt.

Um den Algorithmus zu implementieren, passen wir die Breitensuche so an, dass anstelle der property map <tt>visited</tt> eine property map <tt>parents</tt> verwendet wird, die für jeden besuchten Knoten den Vaterknoten im Breitensuchbaum speichert. Durch Rückverfolgen der <tt>parent</tt>-Kette können wir den Pfad vom Ziel zum Start rekonstruieren, und durch Umdrehen der Reihenfolge erhalten wir den gesuchten Pfad vom Start zum Ziel. Sobald der Zielknoten erreicht wurde, können wir die Breitensuche abbrechen (<tt>break</tt>-Befehl in der ersten <tt>while</tt>-Schleife). Falls der gegebene Graph unzusammenhängend ist, kann es passieren, dass gar kein Weg gefunden wird, weil Start und Ziel in verschiedenen Zusammenhangskomponenten liegen. Dies erkennen wir daran, dass die Breitensuche beendet wurde, ohne den Zielknoten zu besuchen. Dann gibt die Funktion statt eines Pfades dern Wert <tt>None</tt> zurück:

from collections import deque

def shortestPath(graph, startnode, destination):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Breitensuchbaum
parents[startnode] = startnode # startnode ist die Wurzel des Baums => verweist auf sich selbst

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # Besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn sie noch nicht besucht wurden
parents[neighbor] = node # setze node als Vaterknoten
q.append(neighbor) # und füge neighbor in die Queue ein

if parents[destination] is None: # Breitensuche wurde beendet ohne den Zielknoten zu besuchen
return None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path # gefundenen Pfad zurückgeben

=== Gewichtete Graphen ===

Das Problem der Suche nach kürzesten Wegen wird wesentlich interessanter und realistischer, wenn wir zu gewichteten Graphen übergehen:

; Definition - kantengewichteter Graph
: Jeder Kante (s,t) des Graphen ist eine reelle oder natürliche Zahl wst zugeordnet, die üblicherweise als ''Kantengewicht'' bezeichnet wird.

; Definition - knotengewichteter Graph
: Jedem Knoten v des Graphen ist eine reelle oder natürliche Zahl wv zugeordnet, die üblicherweise als ''Knotengewicht'' bezeichnet wird.

Je nach Anwendung benötigt man Knoten- oder Kantengewichte oder auch beides zugleich. Wir beschränken uns in der Vorlesung auf kantengewichtete Graphen. Beispiele für die Informationen, die man durch Kantengewichte ausdrücken kann, sind
* wenn die Knoten Orte sind: Abstand von Anfangs- und Endknoten jeder Kante (z.B. Luftline oder Straßenentfernung), Fahrzeit zwischen den Orten
* wenn der Knoten ein Rohrnetzwerk beschreibt: Durchflusskapazität der einzelnen Rohre (für max-Flussprobleme), analog bei elektrischen Netzwerken: elektrischer Widerstand
* wenn die Knoten Währungen repräsentieren, können deren Wechselkurse durch Kantengewichte angegeben werden.
Bei einigen Beispielen ergeben sich unterschiedliche Kantengewichte, wenn eine Kante von s nach t anstatt von t nach s durchlaufen wird. Beispielsweise können sich die Fahrzeiten erheblich unterscheiden, wenn es in einer Richtung bergauf, in der anderen bergab geht, obwohl die Entfernung in beiden Fällen gleich ist. Hier ergibt sich natürlicherweise ein gerichteter Graph. In anderen Beispielen (z.B. bei Luftlinienentfernungen, in guter Näherung auch bei Straßenentfernungen) sind die Gewichte von der Richtung unabhängig, so dass wir ungerichtete Graphen verwenden können.

Die Repräsentation der Kantengewichte im Programm richtet sich nach der Repräsentation des Graphen selbst. Am einfachsten ist wiederum die Adjazenzmatrix, die aber nur für dichte Graphen (<math>E = O(V^2)</math>, mit E als Anzahl der Kanten und V als Anzahl der Knoten) effizient ist. Bei gewichteten Graphen gibt das Matrixelement aij das Gewicht der Kante i ⇒ j (wobei aij = 0 gesetzt wird, wenn diese Kante nicht existiert). Wie zuvor gilt für ungerichtete Graphen aij = aji (symmetrische Matrix), während dies für gerichtete Graphen nicht gelten muss.

Bei Graphen in Adjazenzlistendarstellung hat es sich bewährt, die Gewichte in einer property map zu speichern. Weiter oben haben wir bereits property maps für Knoteneigenschaften (z.B. <tt>visited</tt> und <tt>anchors</tt>) gesehen. Property maps für Kanten funktionieren ganz analog, allerdings muss man jetzt Paare von Knoten (nämlich Anfangs- und Endknoten der Kante) als Schlüssel verwenden und die Daten entsprechend in einem assoziativen Array ablegen:
w = weights[(i,j)] # Zugriff auf das Gewicht der Kante i ⇒ j
Alternativ könnte man auch die Graph-Datenstruktur selbst erweitern, aber dies ist weniger zu empfehlen, weil jeder Algorithmus andere Erwiterungen benötigt und damit die Datenstruktur sehr unübersichtlich würde.

Der kürzeste Weg ist nun definiert als der Weg, bei dem die Summe der Kantengewichte minimal ist:
;Definition - Problem des kürzesten Weges
: Sei P die Menge aller Wege von u nach v, und <math>p \in P</math> einer dieser Wege. Wenn der Grpah einfach ist (es also keine Mehrfachkanten zwischen denselben Knoten und keine Schleifen gibt), ist der Weg p durch die Folge der besuchten Knoten eindeutig bestimmt:
: <math>p : \ \ u = x_0 \rightarrow x_1 \rightarrow x_2 \rightarrow ... \rightarrow v = x_{n_p}</math>
:wo <math>n_p</math> die Anzahl der Kanten im Weg p ist. Seine Kosten Wp ergeben sich als Summer der Gewichte der einzelnen Kanten
: <math>W_p = \sum_{k=1}^{n_p} w_{x_{k-1}x_k}</math>
: und ein kürzester Weg <math>p^* \in P</math> ist ein Weg mit minimalen Kosten
: <math>p^* = \textrm{argmin}_{p\in P}\ \ W_p</math>
: Das Problem des kürzesten Weges besteht darin, einen optimalen Weg p* zwischen gegebenen Knoten u und v zu finden.
Die Lösung dieses Problems hängt davon ab, ob alle Kantengewichte positiv sind, oder ob es auch negative Kantengewichte gibt. In letzeren Fall ist es möglich, durch eine Verlängerung des Weges die Kosten zu redizieren, während sich im ersteren Fall die Kosten immer erhöhen, wenn man den Weg verlängert.

Negative Gewichte treten z.B. bei den Währungsgraphen auf. Auf den ersten Blick entsprechen diese Graphen nicht den Anforderungen an das Problem des kürzesten Weges, weil Wechselkurse miteinander (und mit Geldbeträgen) multipliziert anstatt addiert werden. Man beseitigt diese Schwierigkeit aber leicht, indem man die Logarithmen der Wechselkurse als Kantengewichte verwendet, wodurch sich die Multiplikation in eine Addition der Logarithmen verwandelt. Wechselkurse < 1 führen nun zu negativen Gewichten.

Interessant werden negative Gewichte vor allem in Graphen mit Zyklen. Dann kann es nämlich passieren, dass die Gesamtkosten eines Zyklus ebenfalls negativ sind. Jeder Weg, der den Zyklus enthält, hat dann Kosten von <math>-\infty</math>, weil man den Zyklus beliebig oft durchlaufen und dadurch die Gesamtkosten immer weiter verkleinern kann:

/\ 1. Durchlauf: Kosten -1
1 / \ -4 2. Durchlauf: Kosten -2
/____\ etc.
2

Um hier nicht in einer Endlosschleife zu landen, benötigt man spezielle Algorithmen, die mit dieser Situation umgehen können. Der [http://de.wikipedia.org/wiki/Bellman-Ford-Algorithmus Algorithmus von Bellmann und Ford] beispielsweise bricht die Suche nach dem kürzesten Weg ab, sobald er einen negativen Zyklus entdeckt, aber andernfalls kann er negative Gewichte problemlos verarbeiten.

Die Detektion negativer Zyklen hat wiederum eine interessante Anwendung bei Währungsgraphen: Ein Zyklus bedeutet hier, dass man Geld über mehrere Stufen von einer Währung in die nächste und am Schluß wieder in die Originalwährung umtauscht, und ein negativer Zyklus führt dazu, dass man am Ende mehr Geld besitzt als am Anfang (damit negative Zyklen wirklich einen Gewinn bedeuten und keinen Verlust, müssen die Wechselkurse vor der Logarithmierung in [http://de.wikipedia.org/wiki/Wechselkurs#Nominaler_Wechselkurs Preisnotierung] angegeben sein). Bei Privatpersonen ist dies ausgeschlossen, weil die Umtauschgebühren den möglichen Gewinn mehr als aufzehren. Banken mit direktem weltweitem Börsenzugang hingegen unternehmen große Anstrengungen, um solche negativen Zyklen möglichst schnell (nämlich vor der Konkurrenz) zu entdecken und auszunutzen. Diese Geschäftsmethode bezeichnet man als [http://de.wikipedia.org/wiki/Arbitrage Arbitrage] und die Existenz eines negativen Zyklus als Arbitragegelegenheit. Durch die Kursschwankungen (und durch die ausgleichende Wirkung der Arbitragegeschäfte selbst) existieren die Arbitragegelegenheiten nur für kurze Zeit, und ihre Detektion erfordert leistungsfähige Echtzeitalgorithmen.

In dieser Vorlesung beschränken wir uns hingegen auf Graphen mit ausschließlich positiven Gewichten. In diesem Fall ist der Algorithmus von Dijkstra die Methode der Wahl, weil er wesentlich schneller arbeitet als der Bellmann-Ford-Algorithmus.

=== Algorithmus von Dijkstra ===

==== Edsger Wybe Dijkstra ====

geb. 11. Mai 1930 in Rotterdam

ges. 06. August 2002

Dijkstra war ein niederländischer Informatiker und Wegbereiter der strukturierten Programmierung. 1972 erhielt er für seine Leistung in der Technik und Kunst der Programmiersprachen den Turing Award, der jährlich von der Association for Computing Machinery (ACM) an Personen verliehen wird, die sich besonders um die Entwicklung der Informatik verdient gemacht haben. Zu seinen Beiträgen zur Informatik gehören unter anderem der Dijkstra-Algorithmus zur Berechnung des kürzesten Weges in einem Graphen sowie eine Abhandlung über den go-to-Befehl und warum er nicht benutzt werden sollte. Der go-to-Befehl war in den 60er und 70er Jahren weit verbreitet, führte aber zu Spaghetti-Code. In seinem berühmten Paper "A Case against the GO TO Statement"[http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF], das als Brief mit dem Titel "Go-to statement considered harmful" veröffentlicht wurde, argumentiert Dijkstra, dass es umso schwieriger ist, dem Quellcode eines Programmes zu folgen, je mehr go-to-Befehle darin enthalten sind und zeigt, dass man auch ohne diesen Befehl gute Programme schreiben kann.

==== Algorithmus ====

Der Dijkstra-Algorithmus für kürzeste Wege ist dem oben vorgestellten Algorithmus <tt>shortestPath()</tt> auf der Basis von Breitensuche sehr ähnlich. Insbesondere gilt auch hier, dass neben dem kürzesten Weg vom Start zum Ziel auch alle kürzesten Wege gefunden werden, deren Endknoten dem Start näher sind als der Zielknoten. Aufgrund der Kantengewichte gibt es aber einen wichtigen Unterschied: Der erste gefundene Weg zu einem Knoten ist nicht mehr notwendigerweise der kürzeste. Wir bestimmen deshalb für jeden Knoten mehrere Kandidatenwege und verwenden eine Prioritätswarteschlange (statt einer einfachen First in - First out - Queue), um diese Wege nach ihrer Länge zu sortieren. Die Kandidatenwege für einen gegebenen Knoten werden unterschieden, indem wir auch den Vorgängerknoten im jeweiligen Weg speichern. Wenn ein Knoten erstmals an die Spitze der Prioritätswarteschlange gelangt, haben wir den kürzesten Weg zu diesem Knoten gefunden (das wird weiter unten formal bewiesen), und der Vorgänger des Knotens in diesem Weg wird zu seinem Vaterknoten. Erscheint derselbe Knoten später nochmals an der Spitze der Prioritätswarteschlange, handelt es sich um einen Kandidatenweg, der sich nicht als kürzester erwiesen hat und deshalb ignoriert werden kann. Wir erkennen dies leicht daran, dass der Vaterknoten in der property map <tt>parents</tt> bereits gesetzt ist.

Eine geeignete Datenstruktur für die Prioritätswarteschlange wird durch das Python-Modul [http://docs.python.org/library/heapq.html heapq] realisiert. Es verwendet ein normales Pythonarray als unterliegende Repräsentation für einen Heap und stellt effiziente <tt>heappush</tt> und <tt>heappop</tt>-Funktionen zur Verfügung. Dies entspricht genau unserer Vorgehensweise im Kapitel [[Prioritätswarteschlangen]]. Als Datenelement erwartet die Funktion <tt>heappush</tt> ein Tupel, dessen erstes Element die Priorität sein muss. Die übrigen Elemente des Tupels (und damit auch deren Anzahl) können je nach Anwendung frei festgelegt werden. Wir legen fest, dass das zweite Element den Endknoten des betrachteten Weges und das dritte den Vorgängerknoten speichert.

Die Kantengewichte werden dem Algorithmus in der property map <tt>weights</tt> übergeben:

<code python>
import heapq # heapq implementiert die Funktionen für Heaps

def dijkstra(graph, weights, startnode, destination):
parents = [None]*len(graph) # registriere für jeden Knoten den Vaterknoten im Pfadbaum

q = [] # Array q wird als Heap verwendet
heapq.heappush(q, (0.0, startnode, startnode)) # Startknoten in Heap einfügen

while len(q) > 0: # solange es noch Knoten im Heap gibt:
length, node, predecessor = heapq.heappop(q) # Knoten aus dem Heap nehmen
if parents[node] is not None: # parent ist schon gesetzt => es gab einen anderen, kürzeren Weg
continue # => wir können diesen Weg ignorieren
parents[node] = predecessor # parent setzen
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # die Nachbarn von node besuchen,
if parents[neighbor] is None: # aber nur, wenn ihr kürzester Weg noch nicht bekannt ist
newLength = length + weights[(node,neighbor)] # berechne Pfadlänge zu neighbor
heapq.heappush(q, (newLength, neighbor, node)) # und füge neighbor in den Heap ein

if parents[destination] is None: # Suche wurde beendet ohne den Zielknoten zu besuchen
return None, None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path, length # gefundenen Pfad und dessen Länge zurückgeben
</code>
Die wesentlichen Unterschiede zur Breitensuche sind im Code rot markiert: Anstelle der Queue verwenden wir jetzt einen Heap, und der Startknoten wird mit Pfadlänge 0 als erstes eingefügt. In der Schleife <tt>while len(q) > 0:</tt> wird jeweils der Knoten <tt>node</tt> mit der aktuell kürzesten Pfadlänge aus dem Heap entfernt. Die Pfadlänge vom Start zu diesem Knoten wird in der Variable <tt>length</tt> gespeichert, sein Vorgänger in der Variable <tt>predecessor</tt>. Wenn der aktuelle Weg nicht der kürzeste ist (<tt>parents[node]</tt> war bereits gesetzt), wird dieser Weg ignoriert. Andernfalls werden die property map <tt>parents</tt> aktualisiert und die Nachbarn von <tt>node</tt> besucht. Beim Scannen der Nachbarn berechnen wir zunächst die Länge <tt>newLength</tt> das Weges <tt>startnode => node => neighbor</tt> als Summe von <tt>length</tt> und dem Gewicht der Kante <tt>(node, neighbode)</tt>. Diese Länge wird beim Einfügen des Nachbarknotens in den Heap zur Priorität des aktuellen Weges.

Die wichtigsten Prinzipien des Dijkstra-Algorithmus noch einmal im Überblick:
* Der Dijkstra-Algorithmus ist Breitensuche mit Prioritätswarteschlange (Heap) statt einer einfache Warteschlange (Queue).
* Die Prioritätswarteschlange speichert alle Wege, die bereits gefunden worden sind und ordnet sie aufsteigend nach ihrer Länge.
* Das Sortieren (und damit der ganze Algorithmus) funktioniert nur mit positiven Kantengewichten korrekt.
* Da ein Knoten auf mehreren Wegen erreichbar sein kann, kann er auch mehrmals im Heap sein.
* Wenn ein Knoten erstmals aus der Prioritätswarteschlange entnommen wird, ist der gefundene Weg der kürzeste zu diesem Knoten. Andernfalls wird der Weg ignoriert.
* Wenn der Knoten <tt>destination</tt> aus dem Heap entnommen wird, ist der kürzeste Weg von Start nach Ziel gefunden, und die Suche kann beendet werden.
In unserer Implementation können, wie gesagt, mehrere Wege zum selben Knoten gleichzeitig in der Prioritätswarteschlange sein. Im Prinzip wäre es auch möglich, immer nur den besten zur Zeit bekannten Weg zu jedem Enknoten in der Prioritätswarteschlange zu halten - sobald ein besserer Kandidat gefunden wird, ersetzt er den bisherigen Kandidaten, anstatt zusätzlich eingefügt zu werden. Dies erfordert aber eine wesentlich kompliziertere Prioritätswarteschlange, die eine effiziente <tt>updatePriority</tt>-Funktion anbietet, ohne dass dadurch eine signifikante Beschleunigung erreicht wird. Deshalb verfolgen wir diesen Ansatz nicht.

==== Beispiel ====

under construction

[[Image:Bsp.jpg]]

==== Komplexität von Dijkstra ====

Zur Analyse der Komplexität nehmen wir an, dass der Graph V Knoten und E Kanten hat. Die Initialisierung der property map <tt>parents</tt> am Anfang der Funktion hat offensichtlich Komplexität O(V), weil Speicher für V Knoten allokiert wird. Der Code am Ende der Funktion, der aus der property map <tt>parents</tt> den Pfad extrahiert, hat ebenfalls die Komplexität O(V), weil der Pfad im ungünstigen Fall sämtliche Knoten des Graphen umfasst. Beides wird durch die Komplexität der Hauptschleife dominiert, zu deren Analyse wir den folgenden Codeausschnitt genauer anschauen wollen:

while len(q) > 0:
... # 1
if parents[node] is not None:
continue
parents[node] = predecessor
... # 2
Wir erkennen, dass der Codeabschnitt <tt># 2</tt> für jeden Knoten höchstens einmal erreicht werden kann: Da <tt>parents[node]</tt> beim ersten Durchlauf gesetzt wird, kann die <tt>if</tt>-Abfrage beim gleichen Knoten nie wieder <tt>False</tt> liefern, und das nachfolgende <tt>continue</tt> bewirkt, dass der Abschnitt <tt># 2</tt> dann übersprungen wird. Man sagt auch, dass jeder Knoten höchstens einmal expandiert wird, auch wenn er mehrmals im Heap war.

Der Codeabschnitt <tt># 2</tt> selbst enthält eine Schleife über alle ausgehenden Kanten des Knotens <tt>node</tt>. Im ungünstigsten Fall iterieren wir bei allen Knoten über alle ausgehenden Kanten, aber das sind gerade alle Kanten des Graphen je einmal in den beiden möglichen Richtungen. Die Funktion <tt>heappush</tt> wird sogar höchstens E Mal aufgerufen, weil eine Kante nur in den Heap eingefügt wird, wenn der kürzeste Weg der jeweiligen Endknotens noch nicht bekannt ist (siehe die <tt>if</tt>-Abfrage in der <tt>for</tt>-Schleife), und das ist nur ein einer Richtung möglich. Dies hat zwei Konsequenzen:
* Die Schleife <tt>while len(q) > 0:</tt> wird nur so oft ausgeführt, wie Elemente im Heap sind, also höchstens E Mal. Das gleiche gilt für den Codeabschnitt <tt># 1</tt>, der das <tt>heappop</tt> enthält.
* Die Operationen <tt>heappush</tt> und <tt>heappop</tt> haben logarithmische Komplexität in der Größe des Heaps, sind also in <math>O(\log\,E)</math>. In einfachen Graphen gilt aber <math>E = O(V^2)</math>, so dass sich die Komplexität der Heapoperationen vereinfacht zu <math>O(\log\,E)=O(\log\,V^2)=O(2\log\,V)=O(\log\,V)</math>.
Zusammenfassend gilt: <tt>heappush</tt> und <tt>heappop</tt> werden maximal E Mal aufgerufen und haben eine Komplexität in <math>O(\log\,V)</math>. Folglich hat der Algorithmus von Dijkstra die Komplexität:
:<math>O(E\,\log\,V)</math>

==== Vergleich mit Breitensuche und Tiefensuche ====

Der Dijkstra-Algorithmus ist eng mit der Breiten- und Tiefensuche verwandt - man kann diese Algorithmen aus dem Dijkstra-Algorithmus gewinnen, indem man einfach die Regel zur Festlegung der Prioritäten ändert. Anstelle der Länge des Pfades verwenden wir als Priorität den Wert eine Zählvariable <tt>count</tt>, die nach jeder Einfügung in den Heap (also nach jedem Aufruf von <tt>heappush</tt>) aktualisiert wird. Zählen wir die Variable hoch, haben die zuerst eingefügten Kanten die höchste Priorität, der Heap verhält sich also wie eine Queue (First in-First out), und wir erhalten eine Breitensuche. Zählen wir die Variable hingegen (von E beginnend) herunter, haben die zuletzt eingefügten Kanten höchste Priorität. Der Heap verhält sich dann wie ein Stack (Last in-First out), und wir bekommen Tiefensuche. Statt eines Heaps plus Zählvariable kann man jetzt natürlich direkt eine Queue bzw. einen Stack verwenden. Dadurch fällt der Aufwand <math>O(\log\,V)</math> für die Heapoperationen weg und wird durch die effizienten O(1)-Operationen von Queue bzw. Stack ersetzt. Damit erhalten wir für Breiten- und Tiefensuche die schon bekannte Komplexität O(E).

==== Korrektheit von Dijkstra ====

Wir beweisen mittels vollständiger Induktion die Schleifen-Invariante: Falls <tt>parents[node]</tt> gesetzt (also ungleich <tt>None</tt>) ist, dann liefert das Zurückverfolgen des Weges von <tt>node</tt> nach <tt>startnode</tt> den kürzesten Weg.
;Induktionsanfang: <tt>parents[startnode]</tt> ist als einziges gesetzt. Zurückverfolgen liefert den trivialen Weg <tt>[startnode]</tt>, der mit Länge 0 offensichtlich der kürzeste Pfad ist → die Bedingung ist erfüllt.
;Induktionsschritt: Wir zeigen mit einem indirektem Beweis, dass wir immer einen kürzesten Weg bekommen, wenn <tt>parents[node]</tt> gesetzt wird.
:Sei <math>S</math> = <tt>{v | parents[v] is not None}</tt> die Menge aller Knoten, von denen wir den kürzesten Weg schon kennen (Induktionsvoraussetzung), und <tt>node</tt> der Knoten, der sich gerade an der Spitze des Heaps befindet. Dann ist <tt>predecessor</tt> der Vorgänger von <tt>node</tt> im aktuellen Weg, und es muss <tt>predecessor</tt><math>\in S</math> gelten, weil die Nachbarn von <tt>predecessor</tt> (und damit auch der aktuelle <tt>node</tt>) erst in den Heap eingefügt werden, wenn der kürzeste Weg für <tt>predecessor</tt> gefunden wurde. Man beachte auch, dass alle Knoten, die noch nicht in <math>S</math> enthalten sind, weiter vom Start entfernt sind als alle Knoten in <math>S</math>, weil alle neu in den Heap eingefügten Wege länger sind als der kürzeste Weg des jeweiligen Vorgängers.
:Der indirekte Beweis nimmt jetzt an, dass der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> nicht der kürzeste Weg ist. Dann muss es einen anderen, kürzeren Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> geben. Für den Vorgänger <tt>x</tt> in diesem Weg unterscheiden wir zwei Fälle:
:* <tt>x</tt><math>\in S</math>: In diesem Fall ist die Länge des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> bereits bekannt, und dieser Weg ist in der Prioritätswarteschlange enthalten. Dann kann er aber nicht der kürzeste sein, denn an der Spitze der Warteschlange war nach Voraussetzung der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt>.
:* <tt>x</tt><math>\notin S</math>: Die Kosten des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> berechnen sich als <tt>Kosten(x → startnode) + weight[(x, node)]</tt>, und die Kosten des Weges <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> sind analog <tt>Kosten(predecessor → startnode) + weight[(predecessor, node)]</tt>. Aufgrund der Induktionsvoraussetzung gilt aber <tt>predecessor</tt><math>\in S</math>, und somit <tt>Kosten(predecessor → startnode) < Kosten(x → startnode)</tt>, weil <tt>x</tt> andernfalls vor <tt>predecessor</tt> an der Spitze des Heaps gewesen wäre, was mit der Annahme <tt>x</tt><math>\notin S</math> unverträglich ist. Damit der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> trotzdem der kürzeste Weg sein kann, müsste <tt>Kosten(x → startnode) < Kosten(node → startnode)</tt> gelten, denn durch die Kante <tt>(x, node)</tt> kommen ja noch Kosten hinzu. Das wäre aber nur möglich, wenn der Knoten <tt>x</tt> vor dem Knoten <tt>node</tt> an die Spitze des Heaps gelangt, im Widerspruch zur Annahme, dass <tt>node</tt> sich gerade an der Spitze des Heaps befindet. Somit kann die Behauptung, dass der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> der kürzeste Weg ist, nicht stimmen.
In beiden Fällen erhalten wir einen Widerspruch, und die Behauptung ist somit bewiesen. Da die Invariante insbesondere für den Weg zum Zielknoten <tt>destination</tt> erfüllt ist, folgt daraus auch die Korrektheit des Algorithmus von Dijkstra.

=== A*-Algorithmus - Wie kann man Dijkstra noch verbessern? ===

Eine wichtige Eigenschaft des Dijkstra-Algorithmus ist, dass neben dem kürzesten Weg vom Start zum Ziel auch die kürzesten Wege zu allen Knoten berechnet werden, die näher am Startknoten liegen als das Ziel, obwohl uns diese Wege gar nicht interessieren. Sucht man beispielsweise in einem Graphen mit den Straßenverbindungen in Deutschland den kürzesten Weg von Frankfurt (Main) nach Dresden (ca. 460 km), werden auch die kürzesten Wege von Frankfurt nach Köln (190 km), Dortmund (220 km) und Stuttgart (210 km) und vielen anderen Städten gefunden. Aufgrund der geographischen Lage dieser Städte ist eigentlich von vornherein klar, dass sie mit dem kürzesten Weg nach Dresden nicht das geringste zu tun haben. Anders sieht es mit Erfurt (260 km) oder Suhl (210 km) aus - diese Städte liegen zwischen Frankfurt und Dresden und kommen deshalb als Zwischenstationen des gesuchten Weges in Frage.

Damit Dijkstra korrekt funktioniert, würde es im Prinzip ausreichen, wenn man die kürzesten Wege nur für diejenigen Knoten ausrechnet, die auf dem kürzesten Weg vom Start zum Ziel liegen, denn nur diese Knoten braucht man, um den gesuchten Weg über die <tt>parent</tt>-Kette zurückzuverfolgen. Das Problem ist nur, dass man diese Knoten erst kennt, wenn der Algorithmus fertig durchgelaufen ist. Schließt man Knoten zu früh von der Betrachtung aus, kommt am Ende möglicherweise nicht der korrekte kürzeste Weg heraus.

Der A*-Algorithmus löst dieses Dilemma mit folgender Idee: Ändere die Prioritäten für den Heap so ab, dass unwichtige Knoten nur mit geringerer Wahscheinlichkeit expandiert werden, aber stelle gleichzeitig sicher, dass alle wichtigen Knoten (also diejenigen auf dem korrekten kürzesten Weg) auf jeden Fall expandiert werden. Es zeigt sich, dass man diese Idee umsetzen kann, wenn eine Schätzung für den Restweg (also für die noch verbleibende Entfernung von jedem Knoten zum Ziel) verfügbar ist:
rest = guess(neighbor, destination)
Diese Schätzung addiert man einfach zur wahren Länge des Weges <tt>startnode → node</tt> dazu, um die verbesserte Priorität zu erhalten:
priority = newLength + guess(neighbor, destination)
(Im originalen Dijkstra-Algorithmus wird als Priorität nur <tt>newLength</tt> allein verwendet. Man beachte, dass man <tt>newLength</tt> jetzt zusätzlich im Heap speichern muss, weil man es für die Expansion des Knotens später noch benötigt.)

Damit sicher gestellt ist, dass der A*-Algorithmus immer noch die korrekten kürzesten Wege findet, darf die Schätzung den wahren Restweg niemals überschätzen. Es muss immer gelten:
0 <= guess(node, destination) <= trueDistance(node, destination)
Damit gilt insbesondere <tt>guess(destination, destination) = trueDistance(destination, destination) = 0</tt>, an der Priorität des Knotens <tt>destination</tt> ändert sich also nichts. Die Prioritäten aller anderen Knoten veschlechtern sich hingegen, weil zur bisherigen Priorität noch atwas addiert wird. Für die wichtigen Knoten auf dem kürzesten Weg vom Start nach Ziel gilt jedoch, dass deren neue Priorität immer noch besser ist als die Priorität des Zielknotens selbst. Für diese Knoten gilt nämlich
falls node auf dem kürzesten Weg von startnode nach destination liegt:
trueDistance(startnode, node) + guess(node, destination) <= trueDistance(startnode, destination)
weil der Weg von Start nach <tt>node</tt> ein Teil des kürzesten Wegs von Start nach Ziel ist und die Restschätzung die wahre Entfernung immer unterschätzt. Diese Knoten werden deshalb stets vor dem Zielknoten expandiert, so dass wir die <tt>parent</tt>-Kette immer noch korrekt zurückverfolgen können. Für alle anderen Knoten gilt idealerweise, dass die neue Priorität schlechter ist als die Priorität von <tt>destination</tt>, so dass man sich diese irrelevanten Knotenexpansionen sparen kann.

Für das Beispiel eines Straßennetzwerks bietet sich als Schätzung die Luftlinienentfernung an, weil Straßen nie kürzer sein können als die Luftlinie. Damit erreicht man in der Praxis deutliche Einsparungen. Generell gilt, dass der A*-Algorithmus im typischen Fall schneller ist als der Algorithmus von Dijkstra, aber man kann immer pathologische Fälle konstruieren, wo die Änderung der Prioritäten nichts bringt. Die Komplexität des A*-Algorithmus im ungünstigen Fall ist deshalb nach wie vor <math>O(E\,\log\,V)</math>.

=='''Minimaler Spannbaum'''==
'''(engl.: minimum spanning tree; abgekürzt: MST)'''

[[Image:Minimum_spanning_tree.png‎ |thumb|200px|right|Ein minimal aufspannender Baum verbindet alle Punkte eines Graphen bei minimaler Kantenlänge ([http://de.wikipedia.org/wiki/Spannbaum Quelle])]]

:''gegeben'': gewichteter Graph G, zusammenhängend 
:''gesucht'': Untermenge <math>E'\subseteq E</math> der Kanten, so dass die Summe der Kantengewichte <math>\sum_{e\in E'} w_e</math> minimal und der entstehende Graph G' zusammenhängend ist. 
* G' definiert immer einen Baum, denn andernfalls könnte man eine Kante weglassen und dadurch die Summe <math>\sum_{e\in E'} w_e</math> verringern, ohne dass sich am Zusammenhang von G' etwas ändert. 
* Wenn der Graph G nicht zusammenhängend ist, kann man den Spannbaum für jede Zusammenhangskomponente getrennt ausrechnen. Man erhält dann einen aufspannenden Wald.
* Der MST ist ähnlich wie der Dijkstra-Algorithmus: Dort ist ein Pfad gesucht, bei dem die Summe der Gewichte über den Pfad minimal ist. Beim MST suchen wir eine Lösung, bei der die Summe der Gewichte über den ganzen Graphen minimal ist.
* Das Problem des MST ist nahe verwandt mit der Bestimmung der Zusammenhangskomponente, z.B. über den Tiefensuchbaum. Für die Zusammenhangskomponenten genügt allerdings ein beliebiger Baum, während beim MST ein minimaler Baum gesucht ist.

=== Anwendungen ===
==== Wie verbindet man n gegebene Punkte mit möglichst kurzen Straßen (Eisenbahnen, Drähten [bei Schaltungen] usw.)?====

 
{| class="wikitable" style="text-align:center" border="0" cellpadding="5" cellspacing="0"
|MST minimale Verbindung (Abb.1)
|MST = 2 (Länge = Kantengewicht)(Abb.2)
|- valign="top"
| [[Image:mst.png]]
| [[Image:Gleichseitigesdreieck.png]]
|}
*In der Praxis: Die Festlegung, dass man nur die gegebenen Punkte verwenden darf, ist eine ziemliche starke Einschränkung.

* Wenn man sich vorstellt, es sind drei Punkte gegeben, die als gleichseitiges Dreieck angeordnet sind, dann ist der MST (siehe Abb.2, schwarz gezeichnet) und hat die Länge 2. Man kann hier die Länge als Kantengewicht verwenden.

* Wenn es erlaubt ist zusätzliche Punkte einzufügen, dann kann man in der Mitte einen neuen Punkt setzen <math>\rightarrow</math> neuer MST (siehe Abb.2, orange gezeichnet). 

* Höhe = <math>\frac{1}{2}\sqrt{3}</math>, Schwerpunkt: teilt die Höhe des Dreiecks im Verhältnis 2:1; der Abstand von obersten Punkt bis zum neu eingeführten Punkt: <math>\frac{2}{3}h = \frac{\sqrt{3}}{3}</math>, davon insgesamt 3 Stück, damit (gilt für den MST in orange eingezeichnet): MST = <math>3\left(\frac{1}{3}\right) \sqrt{3} = \sqrt{3} \approx 1,7</math><br\>

* Damit ist der MST in orange kürzer als der schwarz gezeichnete MST. <br\>
<math>\Rightarrow</math>Folgerung: MST kann kürzer werden, wenn man einen Punkt dazu nimmt.
* Umgekehrt kann der MST auch kürzer werden, wenn man einen Punkt aus dem Graphen entfernt, aber wie das Beipiel des gleichseitigen Dreiecks zeigt, ist dies nicht immer der Fall.

[[Image: bahn.png|Bahnstrecke Verbindung (Abb.3)]]

* Methode der zusätzlichen Punkteinfügung hat man früher beim Bahnstreckenbau verwendet. Durch Einführung eines Knotenpunktes kann die Streckenlänge verkürzt werden (Dreiecksungleichung).

==== Bestimmung von Datenclustern ====

[[Image:cluster.png]]

* Daten (in der Abb.: Punkte) bilden Gruppen.

* In der Abbildung hat man 2 verschiedene Messungen gemacht (als x- und y-Achse aufgetragen), bspw. Größe und Gewicht von Personen. Für jede Person i wird ein Punkt an der Koordinate (Größei, Gewichti) gezeichnet (siehe Bild a). Dies bezeichnet man als ''Scatter Plot''. Wenn bestimmte Wertkombinationen häufiger auftreten als andere, bilden sich mitunter Gruppen aus, bspw. eine Gruppe für "klein und schwer" etc.

* Durch Verbinden der Punkte mittels eines MST (siehe Abbildung (b)) sieht man, dass es kurze (innerhalb der Gruppen) und lange Kanten (zwischen den Gruppen) gibt.

* Wenn man geschickt eine Schwelle einführt und alle Kanten löscht, die länger sind als die Schwelle, dann bekommt man als Zusammenhangskomponente die einzelnen Gruppen.

=== Algorithmen ===

Genau wie bei der Bestimmung von Zusammenhangskomponenten kann man auch das MST-Problem entweder nach dem Anlagerungsprinzip oder nach dem Verschmelzungsprinzip lösen (dazu gibt es noch weitere Möglichkeiten, z.B. den [http://de.wikipedia.org/wiki/Algorithmus_von_Bor%C5%AFvka Algorithmus von Boruvka]). Der Anlagerungsalgorithmus für MST wurde zuerst von Prim beschrieben und trägt deshalb seinen Namen, der Verschmelzungsalgorithmus stammt von Kruskal. Im Vergleich zu den Algorithmen für Zusammenhangskomponenten ändert sich im wesentlichen nur die Reihenfolge, in der die Kanten betrachtet werden: Eine Prioritätswarteschlange stellt jetzt sicher, dass am Ende wirklich der Baum mit den geringstmöglichen Kosten herauskommt.

====Algorithmus von Prim====
[http://de.wikipedia.org/wiki/Algorithmus_von_Prim Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]

Der Algorithmus von Prim geht nach dem Anlagerungsprinzip vor (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Tiefensuche|Zusammenhangskomponenten mit Tiefensuche]]): Starte an der Wurzel (ein willkürlich gewählter Knoten) und füge jeweils die günstigste Kante an die aktuellen Teillösung an, die keinen Zyklus verursacht. Die Sortierung der Kanten nach Priorität erfolgt analog zum Dijsktra-Algorithmus, aber die Definitionen, welche Kante die günstigste ist, unterscheiden sich. Die Konvention für die Bedeutung der Elemente des Heaps ist ebenfalls identisch: ein Tupel mit <tt>(priority, node, predecessor)</tt>. Die folgende Implementation verdeutlicht sehr schön die Ähnlichkeit der beiden Algorithmen. Das Ergebnis wird als property map <tt>parents</tt> zurückgegeben, in der für jeden Knoten sein Vorgänger im MST steht, wobei die Wurzel wie üblich auf sich selbst verweist.

import heapq

def prim(graph, weights): # Kantengewichte wie bei Dijkstra als property map
sum = 0.0 # wird später das Gewicht des Spannbaums sein
start = 0 # Knoten 0 wird willkürlich als Wurzel gewählt

parents = [None]*len(graph) # property map, die den resultierenden Baum kodiert
parents[start] = start # Wurzel zeigt auf sich selbst

heap = [] # Heap für die Kanten des Graphen
for neighbor in graph[start]: # besuche die Nachbarn von start
heapq.heappush(heap, (weights[(start, neighbor)], neighbor, start)) # und fülle Heap

while len(heap) > 0:
w, node, predecessor = heapq.heappop(heap) # hole billigste Kante aus dem Heap
if parents[node] is not None: # die Kante würde einen Zyklus verursachen
continue # => ignoriere diese Kante
parents[node] = predecessor # füge Kante in den MST ein
sum += w # und aktualisiere das Gesamtgewicht
for neighbor in graph[node]: # besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn kein Zyklus entsteht
heapq.heappush(heap, (weights[(node,neighbor)], neighbor, node)) # füge Kandidaten in Heap ein

return parents, sum # MST und Gesamtgewicht zurückgeben

====Algorithmus von Kruskal====
[http://de.wikipedia.org/wiki/Algorithmus_von_Kruskal Wikipedia (de)]
[http://en.wikipedia.org/wiki/Kruskal%27s_algorithm (en)]

Die alternative Vorgehensweise ist das Verschmelzungsprinzip (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]]), das der Algorithmus von Kruskal verwendet. Jeder Knoten wird zunächst als trivialer Baum mit nur einem Knoten betrachtet, und alle Kanten werden aufsteigend nach Gewicht sortiert. Dann wird die billigste noch nicht betrachtete Kante in den MST eingefügt, falls sich dadurch kein Zyklus bildet (erkennbar daran, dass die Endknoten in verschiedenen Zusammenhangskomponenten liegen, das heisst verschiedene Anker haben). Da der fertige Baum (V-1) Kanten haben muss, wird dies (V-1) Mal zutreffen. Andernfalls wird diese Kante ignoriert. Anders ausgedrückt: Der Algorithmus beginnt mit ''V'' Bäumen; in (''V''-1) Verschmelzungsschritten kombiniert er jeweils zwei Bäume (unter Verwendung der kürzesten möglichen Kante), bis nur noch ein Baum übrig bleibt. Der einzige Unterschied zum einfachen Union-Find besteht darin, dass die Kanten in aufsteigender Reihenfolge betrachtet werden müssen, was wir hier durch eine Prioritätswarteschlange realisieren. Der Algorithmus von J.Kruskal ist seit 1956 bekannt.

def kruskal(graph, weights):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker
results = [] # result wird später die Kanten des MST enthalten

heap = [] # Heap zum Sortieren der Kanten nach Gewicht
for edge, w in weights.iteritems(): # alle Kanten einfügen
heapq.heappush(heap, (w, edge))

while len(heap) > 0: # solange noch Kanten vorhanden sind
w, edge = heapq.heappop(heap) # billigste Kante aus dem Heap nehmen
a1 = findAnchor(anchors, edge[0]) # Anker von Startknoten der Kante
a2 = findAnchor(anchors, edge[1]) # ... und Endknoten bestimmen
if a1 != a2: # wenn die Knoten in verschiedenen Komponenten sind
anchors[a2] = a1 # Komponenten verschmelzen
result.append(edge) # ... und Kante in MST einfügen

return result # Kanten des MST zurückgeben

Die Funktion <tt>findAnchor()</tt> wurde im Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]] implementiert. Im Unterschied zum Algorithmus von Prim geben wir hier nicht die property map <tt>parents</tt> zurück, sondern einfach eine Liste der Kanten im MST.

Der Algorithmus eignet sich insbesondere für das Clusteringproblem, da der Schwellwert von vornerein als maximales Kantengewicht an den Algorithmus übergeben werden kann. Man hört mit dem Vereinigen auf, wenn das Gewicht der billigste Kante im Heap den Schwellwert überschreitet. Beim Algorithmus von Kruskal kann dann keine bessere Kante als der Schwellwert mehr kommen, da die Kanten vorher sortiert worden sind.

Komplexität: wie beim Dijkstra-Algorithmus, weil jede Kante genau einmal in den Heap kommt. Der Aufwand für das Sortieren ist somit <math>O\left(E\log E\right)</math>, was sich zu <math>O \left(E\,\log\,V\right)</math> reduziert, falls keine Mehrfachkanten vorhanden sind.

=> geeignet für Übungsaufgabe

====Verwendung einer BucketPriorityQueue====

Beide Algorithmen zur Bestimmung des minimalen Spannbaums benötigen eine Prioritätswarteschlange. Wenn die Kantengewichte ganze Zahlen im Bereich <tt>0...(m-1)</tt> sind, kann man die MST-Algorithmen deutlich beschleunigen, wenn man anstelle des Heaps eine [[Prioritätswarteschlangen#Prioritätssuche mit dem Bucket-Prinzip|<tt>BucketPriorityQueue</tt>]] verwendet. Die Operationen zum Einfügen einer Kante in die Queue und zum Entfernen der billibsten Kante aus der Queue beschleunigen sich dadurch auf O(1) statt O(log V) (außer wenn die Gewichte sehr ungünstig auf die Kanten verteilt sind). In der Praxis erreicht man durch diese Änderung typischerweise deutliche Verbesserungen. In der Bildverarbeitung können die Prioritäten beispielsweise die Wahrscheinlichkeit kodieren, dass zwei benachbarte Pixel zu verschiedenen Objekten gehören. Bildet man jetzt den MST, und bricht bei einer bestimmten Wahrscheinlichkeit ab, erhält man Cluster von Pixeln, die wahrscheinlich zum selben Objekt gehören (weil der MST ja die Kanten mit minimalem Gewicht bevorzugt, und kleine Gewichte bedeuten kleine Wahrscheinlichkeit, dass benachbarte Pixel von einander getrennt werden). Da man die Wahrscheinlichkeiten nur mit einer Genauigkeit von ca. 1% berechnen kann, reichen hiefür 100 bis 200 Quantisierungstufen aus. Durch Verwendung der schnellen <tt>BucketPriorityQueue</tt> kann man jetzt wesentlich größere Bilder in akzeptabler Zeit bearbeiten als dies mit einem Heap möglich wäre.

== Algorithmen für gerichtete Graphen ==

Zur Erinnerung: in einem gerichteten Graphen sind die Kanten (i → j) und (j → i) voneinander verschieden, und eventuell existiert nur eine der beiden Richtungen. Im allgemeinen unterscheidet sich der [[Graphen_und_Graphenalgorithmen#transposed_graph|transponierte Graph]] GT also vom Originalgraphen G. Beim Traversieren des Graphen und bei der Pfadsuche dürfen Kanten nur in passender Richtung verwendet werden. Bei gewichteten Graphen tritt häufig der Fall auf, dass zwar Kanten in beiden Richtungen existieren, diese aber unterschiedliche Gewichte haben.

Gerichtete Graphen ergeben sich in natürlicher Weise aus vielen Anwendungsproblemen:
* Routenplanung
** Bei Straßennetzwerken enstehen gerichtete Graphen, sobald es Einbahnstraßen gibt.
** Verwendet man Gewichte, um die erwarteten Fahrzeiten entlang einer Straße zu kodieren, gibt es Asymmetrien z.B. dann, wenn Straßen in einer Richtung bergab, in der anderen bergauf befahren werden. Hier existieren zwar Kanten in beiden Richtungen, sie haben aber unterschiedliche Gewichte. Ähnliches gilt für Flüge: Durch den Gegenwind des Jetstreams braucht man von Frankfurt nach New York länger als umgekehrt von New York nach Frankfurt.
* zeitliche oder kausale Abhängigkeiten
** Wenn die Knoten Ereignisse repräsentieren, von denen einige die Ursache von anderen sind, diese wiederum die Ursache der nächsten usw., verbindet man die Knoten zweckmäßig durch gerichtete Kanten, die die Kausalitätsbeziehungen kodieren. Handelt es sich um logische "wenn-dann"-Regeln, erhält man einen [[Graphen_und_Graphenalgorithmen#Anwendung:_Das_Erf.C3.BCllbarkeitsproblem_in_Implikationengraphen|Implikationengraph]] (siehe unten). Handelt es sich hingegen um Wahrscheinlichkeitsaussagen ("Wenn das Wetter schön ist, haben Studenten tendenziell gute Laune, wenn eine Prüfung bevorsteht eher schlechte usw."), erhält man ein [http://de.wikipedia.org/wiki/Bayessches_Netz Bayessches Netz].
** Wenn bestimmte Aufgaben erst begonnen werden können, nachdem andere Aufgaben erledigt sind, erhält man einen Abhängigkeitsgraphen. Beispielsweise dürfen Sie erst an der Klausur teilnehmen, nachdem Sie die Übungsaufgaben gelöst haben, und Sie dürfen erst die Abschlussarbeit beginnen, nachdem Sie bestimmte Prüfungen bestanden haben. Ein anderes schönes Beispiel liefern die Regeln für das [[Graphen_und_Graphenalgorithmen#Anwendung:_Abh.C3.A4ngigkeitsgraph|Ankleiden]] weiter unten.
** Gerichtete Graphen kodieren die Abhängigkeiten zwischen Programmbibliotheken. Beispielsweise benötigt das Pythonmodul <tt>json</tt> die internen Submodule <tt>json.encoder</tt> und <tt>json.decode</tt> sowie das externe Modul <tt>decimal</tt>. Die Submodule benötigen wiederum die externen Module <tt>re</tt> und <tt>sys</tt>, das Modul <tt>decimal</tt> braucht <tt>copy</tt> und <tt>collections</tt> usw.
** Das Internet kann als gerichteter Graph dargestellt werden, wobei die Webseiten die Knoten, und die Hyperlinks die Kanten sind.
* Sequence Alignment
** Eine gute Rechtschreibprüfung markiert nicht nur fehlerhafte Wörter, sondern macht auch plausible Vorschläge, was eigentlich gemeint gewesen sein könnte. Dazu muss sie das gegebene Wort mit den Wörtern eines Wörterbuchs vergleichen und die Ähnlichkeit bewerten. Ein analoges Problem ergibt sich, wenn man DNA Fragmente mit der Information in einer Genomdatenbank abgleichen will.

=== Anwendung: Sequence Alignment / Edit Distance ===

:gegeben: zwei Wörter (allgemein: beliebige Zeichenfolgen)
:gesucht: Wie kann man die Buchstaben am besten in Übereinstimmung bringen?

:Beispiel: WORTE – NORDEN

Zwei mögliche Alignments sind

WORTE. W.ORTE
NORDEN NORDEN

wobei der Punkt anzeigt, dass der untere Buchstabe keinen Partner hat, und rote Buchstaben oben und unten übereinstimmen. Jede Nicht-Übereinstimmung verursacht nun gewisse Kosten. Dabei unterscheiden wir zwei Fälle:
# Matche a[i] mit b[j]. Falls a[i] == b[j], ist das gut (rote Buchstaben), und es entstehen keine Kosten. Andernfalls entstehen Kosten U (schwarze Buchstaben).
# Wir überspringen a[i] oder b[j] (Buchstabe vs. Punkt). Dann entstehen Kosten V. (Manchmal unterscheidet man auch noch Kosten Va und Vb, wenn das Überspringen bei a und b unterschieldiche Signifikanz hat.)

Gesucht ist nun das Alignment mit minimalen Kosten

Diese Aufgabe kann man sehr schön als gerichteten Graphen darstellen: Wir definieren ein rechteckiges Gitter und schreiben das erste Wort über das Gitter und das andere links davon. Die Gitterpunkte verbinden wir mit Pfeilen (gerichteten Kanten), wobei ein Pfeil nach rechts bedeutet, dass wir beim oberen Wort einen Buchstaben überspringen, ein Pfeil nach unten, dass wir beim linken Wort einen Buchstaben überspringen, und ein diagonaler Pfeil, dass wir zwei Buchstaben matchen (und zwar die am Pfeilende). Die Farben der Pfeile symbolisieren die Kosten: rot für das Überspringen eines Buchstabens (Kosten V), blau für das Matchen, wenn die Buchstaben nicht übereinstimmen (Kosten U), und grün, wenn die Buchstaben übereinstimmen (keine Kosten).

[[Image:sequence-alignment.png|300px]]

Lösung:
:Suche den kürzesten Pfad vom Knoten "START" (oben links) nach unten rechts. Dazu kann der [[Graphen und Graphenalgorithmen#Algorithmus von Dijkstra|Algorithmus von Dijkstra]] verwendet werden, der auf gerichteten Graphen genauso funktioniert wie auf ungerichteten.

Für unser Beispiel von oben erhalten wir die folgenden Pfade:

[[Image:sequence-alignment-weg1.png|400px]]     [[Image:sequence-alignment-weg2.png|400px]]

Durch Addieren der Kosten entsprechend der Farben sieht man, dass der erste Weg die Kosten 2U+V und der zweite die Kosten 5U+V hat. Der erste Weg ist offensichtlich günstiger und entspricht dem besten Alignment.

=== Anwendung: Abhängigkeitsgraph ===

Beispiel: Wie erklärt man einem zerstreuten Professor, wie er sich morgens anziehen soll? Der folgende Graph enthält einen Knoten für jede Aktion, und eine Kante (i → j) bedeutet, dass die Aktion i vor der Aktion j abgeschlossen werden muss.

[[Image:anziehen-graph.png|600px]]

In derartigen Abhängigkeitsgraphen ist die wichtigste Frage immer, ob der Graph azyklisch ist. Wäre dies nämlich nicht der Fall, kann es keine Reihenfolge der Aktionen geben, die alle Abhängigkeiten erfüllt. Dies sieht man leicht, wenn man den einfachsten möglichen Zyklus betrachtet: es gibt sowohl eine Kante (i → j) als auch eine (j → i). Dann müsste man i vor j erledigen, aber ebenso j vor i, was offensichtlich unmöglich ist - das im Graph kodierte Problem ist dann unlösbar. Wegen ihrer Wichtigkeit wird für gerichtete azyklische Graphen oft die Abkürzung DAG (von directed acyclic graph) verwendet. Ein Graph ist genau dann ein DAG, wenn es eine topologische Sortierung gibt:
;topologische Sortierung: Zeichne die Knoten so auf eine Gerade, dass alle Kanten (Pfeile) nach rechts zeigen.
Arbeitet man die Aktionen nach einer (beliebigen) topologischen Sortierung ab, werden automatisch alle Abhängigkeiten eingehalten: Da alle Pfeile nach rechts zeigen, werden abhängige Aktionen immer später ausgeführt. Die topologische Sortierung ist im allgemeinen nicht eindeutig. Die folgende Skizze zeigt eine mögliche topologische Sortierung für das Anziehen:

[[Image:anziehen-topologische-sortierung.png|600px]]

Eine solche fest vorgegebene Reihenfolge ist für den zerstreuten Professor sicherlich eine größere Hilfe als der ursprüngliche Graph. Man erkennt, dass die Sortierung nicht eindeutig ist, beispielsweise bei der Uhr: Da für die Uhr keine Abhängigkeiten definiert sind, kann man diese Aktion an beliebiger Stelle einsortieren. Hier wurde willkürlich die letzte Stelle gewählt.

==== Zwei Algorithmen zum Finden der topologischen Sortierung ====

Die folgenden Algorithmen finden entweder eine topologische Sortierung, oder signalisieren, dass der Graph zyklisch ist.

===== Algorithmus 1 =====
# Suche einen Knoten mit Eingangsgrad 0 (ohne eingehende Pfeile) => in einem gerichteten azyklischen Graphen gibt es immer einen solchen Knoten
# Platziere diesen Knoten auf der Geraden (beliebig)
# Entferne den Knoten aus dem Graphen zusammen mit den ausgehenden Kanten
# Gehe zu 1., aber platziere in 2. immer rechts der Knoten, die schon auf der Geraden vorhanden sind.
: => Wenn noch Knoten übrig sind, aber keiner Eingangsgrad 0 hat, muss der Graph zyklisch sein.

[[Image:bild6.JPG]]

Beispiel für einen zyklischen Graphen: kein Knoten hat Eingangsgrad 0.

Um den Algorithmus zu implementieren, verwenden wir eine property map <tt>in_degree</tt>, die wir in einem ersten Durchlauf durch den Graphen füllen und die dann für jeden Knoten die Anzahl der eingehenden Kanten speichert. Dann gehen wir sukzessive zu allen Knoten mit <tt>in_degree == 0</tt>. Anstatt sie aber tatsächlich aus dem Graphen zu entfernen wie im obigen Pseudocode, dekrementieren wir nur den <tt>in_degree</tt> ihrer Nachbarn. Wird der <tt>in_degree</tt> eines Nachbarn dadurch 0, wird er ebenfalls in das Array der zu scannenden Knoten aufgenommen. Wenn der Graph azyklisch ist, enthält das Array am Ende alle Knoten des Graphen, und die Reihenfolge der Einfügungen definiert eine topologische Sortierung. Andernfalls ist das Array zu kurz, und wir signalisieren durch Zurückgeben von <tt>None</tt>, dass der Graph zyklisch ist:

def topological_sort(graph): # ein gerichteter Graph
in_degree = [0]*len(graph) # property map für den Eingangsgrad jeden Knotens
for node in xrange(len(graph)): # besuche alle Knoten
for neighbor in graph[node]: # ... und deren Nachbarn
in_degree[neighbor] += 1 # ... und inkrementiere den Eingangsgrad

result = [] # wird später die topologische Sortierung enthalten
for node in xrange(len(graph)):
if in_degree[node] == 0:
result.append(node) # füge alle Knoten mit Eingangsgrad 0 in result ein

k = 0
while k < len(result): # besuche alle Knoten mit Eingangsgrad 0
node = result[k]
k += 1
for neighbor in graph[node]: # besuche alle Nachbarn
in_degree[neighbor] -= 1 # entferne 'virtuell' die eingehende Kante
if in_degree[neighbor] == 0: # wenn neighbor jetzt Eingangsgrad 0 hat
result.append(neighbor) # ... füge ihn in result ein

if len(result) == len(graph): # wenn alle Knoten jetzt Eingangsgrad 0 haben
return result # ... ist result eine topologische Sortierung
else:
return None # andernfalls ist der Graph zyklisch

===== Algorithmus 2 =====
Der obige Algorithmus hat den Nachteil, dass er jeden Knoten zweimal expandiert. Man kann eine topologische Sortierung stattdessen auch mit Tiefensuche bestimmen. Es gilt nämlich der folgende
;Satz: Wird ein DAG mittels Tiefensuche traversiert, definiert die reverse post-order eine topologische Sortierung.
Zur Erinnerung: die post-order erhält man, indem man jeden Knoten ausgibt, nachdem die Rekursion zu allen seinen Nachbarn beendet ist, siehe unsere [[Graphen_und_Graphenalgorithmen#pre_and_post_order|Diskussion weiter oben]]. Die reverse post-order ist gerade die Umkehrung dieser Reihenfolge. Die folgende Implementation verwendet die rekursive Version der Tiefensuche, in der Praxis wird man meist die iterative Version mit Stack bevorzugen, weil bei großen Graphen die Aufruftiefe sehr groß werden kann:

def reverse_post_order(graph): # gerichteter Graph
result = [] # enthält später die reverse post-order
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node): # besuche node
if not visited[node]: # aber nur, wenn er noch nicht besucht wurde
visited[node] = True # markiere ihn als besucht
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor)
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order

for node in xrange(len(graph)): # besuche alle Knoten
visit(node)

result.reverse() # post-order => reverse post-order
return result

Die Tatsache, dass die reverse post-order tatsächlich eine topologische Sortierung liefert, leuchtet wahrscheinlich nicht unmittelbar ein. Bevor wir diese Tatsache beweisen. wollen wir uns anhand des Ankleidegraphen klar machen, dass die pre-order (die man intuitiv vielleicht eher wählen würde) keine topologische Sortierung ist. Startet man die Tiefensuche beim Knoten "Unterhemd", werden die Knoten in der Reihenfolge "Unterhemd", "Oberhemd", "Schlips", "Jackett", "Gürtel" gefunden. Da dann alle von "Unterhemd" erreichbaren Knoten erschöpft sind, startet man die Tiefensuche als nächstes bei "Unterhose" und erreicht von dort aus "Hose" und "Schuhe". Man erkennt sofort, dass diese Reihenfolge nicht funktioniert: "Hose" kommt nach "Gürtel", und "Jackett" kommt vor "Gürtel". Bei dieser Anordnung gibt es Pfeile nach links, die Abhängigkeitsbedingungen sind somit verletzt.

Damit die reverse post-order eine zulässige Sortierung sein kann, muss stets gelten, dass Knoten u vor Knoten v einsortiert wurde, wenn die Kante (u → v) existiert. Das ist aber äquivalent zur Forderung, dass in der ursprünglichen post-order (vor dem <tt>reverse</tt>) u hinter v stehen muss. Wir betrachten den <tt>visit</tt>-Aufruf, bei dem u expandiert wird. Gelangt man jetzt zu u's Nachbarn v, gibt es zwei Möglichkeiten: Wenn v bereits expandiert wurde, befindet es sich bereits im Array <tt>result</tt> und <tt>visit</tt> kehrt sofort zurück. Andernfalls wird v ebenfalls expandiert und demzufolge in <tt>result</tt> eingetragen, bevor der rekursive Aufruf <tt>visit(v)</tt> zurückkehrt. Knoten u wird aber erst in <tt>result</tt> eingefügt, nachdem alle rekursiven <tt>visit</tt>-Aufrufe seiner Nachbarn zurückgekehrt sind. In beiden Fällen steht u in der post-order wie gefordert hinter v, und daraus folgt die Behauptung.

Der obige Algorithmus liefert natürlich nur dann eine topologische Sortierung, wenn der Graph wirklich azyklisch ist (man kann ihn aber auch anwenden, um die reverse post-order für einen zyklischen Graphen zu bestimmen, siehe Abschnitt "[[Graphen_und_Graphenalgorithmen#Transitive Hülle und stark zusammenhängende Komponenten|Stark zusammenhängende Komponenten]]"). Dieser Fall tritt in der Praxis häufig auf, weil zyklische Graphen bei vielen Anwendungen gar nicht erst entstehen können. Weiß man allerdings nicht, ob der Graph azyklisch ist oder nicht, muss man einen zusätzlichen Test auf Zyklen in den Algorithmus einbauen.

Zyklische Graphen sind dadurch gekennzeichnet, dass es im obigen Beweis eine dritte Möglichkeit gibt: Während der Expansion von u wird rekursiv v expandiert, und es gibt eine Rückwärtskante (v → u). (Es spielt dabei keine Rolle, ob v von u aus direkt oder indirekt erreicht wurde.) Ein Zyklus wird also entdeckt, wenn die Tiefensuche zu u zurückkehrt, solange u noch aktiv ist, d.h. wenn die Rekursion von u aus gestartet und noch nicht beendet wurde. Dies kann man leicht feststellen, wenn man in der property map <tt>visited</tt> drei Werte zulässt: 0 für "noch nicht besucht", 1 für "aktiv" und 2 für "beendet". Wir signalisieren einen Zyklus, sobald <tt>visit</tt> für einen Knoten aufgerufen wird, der gerade aktiv ist:

def topological_sort_DFS(graph): # gerichteter Graph
result = [] # enthält später die topologische Sortierung

not_visited, active, finished = 0, 1, 2 # drei Zustände für visited
visited = [not_visited]*len(graph) # Flags für aktive und bereits besuchte Knoten

def visit(node): # besuche node (gibt "True" zurück, wenn Zyklus gefunden wurde)
if visited[node] == not_visited: # ... aber nur, wenn er noch nicht besucht wurde
visited[node] = active # markiere ihn als aktiv
for neighbor in graph[node]: # und besuche die Nachbarn
if visit(neighbor): # wenn rekursiv ein Zyklus gefunden wurde
return True # ... brechen wir ab und signalisieren den Zyklus
visited[node] = finished # Rekursion beendet, node ist nicht mehr aktiv
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order
return False # kein Zyklus gefunden
elif visited[node] == active: # Rekursion erreicht einen noch aktiven Knoten
return True # => Zyklus gefunden

for node in xrange(len(graph)): # besuche alle Knoten
if visit(node): # wenn Zyklus gefunden wurde
return None # ... gibt es keine topologische Sortierung

result.reverse() # post-order => reverse post-order (=topologische Sortierung)
return result

Man macht sich leicht klar, dass kein Zyklus vorliegt, wenn die Rekursion einen Knoten erreicht, der bereits auf <tt>finished</tt> gesetzt ist. Nehmen wir an, dass u gerade expandiert wird, und sein Nachbar v ist bereits <tt>finished</tt>. Wenn es einen Zyklus gäbe, müsste es einen Weg von v nach u geben. Dann wäre u aber bereits während der Expansion von v gefunden worden. Da v nicht mehr im Zustand <tt>active</tt> ist, muss die Expansion von v schon abgeschlossen gewesen sein, ohne dass u gefunden wurde. Folglich kann es keinen solchen Zyklus geben.

=== Transitive Hülle und stark zusammenhängende Komponenten ===

Auch bei gerichteten Graphen ist die Frage, welche Knoten miteinander zusammenhängen, von großem Interesse. Wir betrachten dazu wieder die Relation "Knoten v ist von Knoten u aus erreichbar", die anzeigt, ob es einen Weg von u nach v gibt oder nicht. In ungerichteten Graphen ist diese Relation immer symmetrisch, weil jeder Weg in beiden Richtungen benutzt werden kann. In gerichteten Graphen gilt dies nicht. Man muss hier zwei Arten von Zusammenhangskomponenten unterscheiden:
;Transitive Hülle: Die transitive Hülle eines Knotens u ist die Menge aller Knoten, die von u aus erreichbar sind:
:<math>T(u) = \{v\ |\ u \rightsquigarrow v\}</math>
;Stark zusammenhängende Komponenten: Die stark zusammenhängende Komponenten <math>C_i</math> eines gerichteten Graphen sind maximale Teilgraphen, so dass alle Knoten innerhalb einer Komponente von jedem anderen Knoten der selben Komponente aus erreichbar sind
:<math>u,v \in C_i\ \ \Leftrightarrow\ \ u \rightsquigarrow v \wedge v \rightsquigarrow u</math>
Die erste Definition betrachtet den Zusammenhang asymmetrisch, ohne Beachtung der Frage, ob es auch einen Rückweg von Knoten v nach u gibt, die zweite hingegen symmetrisch.

Die transitive Hülle benötigt man, wenn man Fragen der Erreichbarkeit besonders effizient beantworten will. Wir hatten bespielsweise oben erwähnt, dass das Python-Modul <tt>json</tt> direkt und indirekt von mehreren anderen Module abhängt, die vorher installiert werden müssen, damit <tt>json</tt> funktioniert. Bittet man den Systemadministrator, das <tt>json</tt>-Paket zu installieren, will er diese Abhängigkeiten wahrscheinlich nicht erst mühsam rekursiv heraussuchen, sondern er verlangt eine Liste aller Pakete, die installiert werden müssen. Dies ist gerade die transitive Hülle von <tt>json</tt> im Abhängigkeitsgraphen. Damit man diese nicht manuell bestimmen muss, verwendet man Installationsprogramme wie z.B. [http://pypi.python.org/pypi/pip/ pip], die die Abhängigkeiten automatisch herausfinden und installieren.

Bei der Bestimmung der transitiven Hülle modifiziert man den gegebenen Graphen, indem man jedesmal eine neue Kante (u → v) einfügt, wenn diese Kante noch nicht existiert, aber v von u aus erreichbar ist. Dies gelingt mit einer sehr einfachen Variation der Tiefensuche: Wir rufen <tt>visit(k)</tt> für jeden Knoten k auf, aber setzen die property map <tt>visited</tt> zuvor auf <tt>False</tt> zurück. Alle Knoten, die während der Rekursion erreicht werden, sind im modifizierten Graphen Nachbarn von k. Ein etwas effizienterer Ansatz ist der [http://de.wikipedia.org/wiki/Algorithmus_von_Floyd_und_Warshall Algorithmus von Floyd und Warshall].

Die Bestimmung der stark zusammenhängenden Komponenten ist etwas schwieriger. Es existieren eine ganze Reihe von effizienten Algorithmen (siehe [http://en.wikipedia.org/wiki/Strongly_connected_component WikiPedia]), deren einfachster der Algorithmus von Kosaraju ist:

gegeben: gerichteter Graph

# Bestimme die reverse post-order (mit der Funktion <tt>reverse_post_order</tt>)
# Bilde den transponierten Graphen <math>G^T</math> (mit der Funktion <tt>transposeGraph</tt>)
# Bestimme die Zusammenhangskomponenten von <math>G^T</math> mittels Tiefensuche, aber betrachte die Knoten dabei in der reverse post-order aus Schritt 1 (dies kann mit einer minimalen Modifikation der Funktion <tt>connectedComponents</tt> geschehen, indem man die Zeile <tt>for node in xrange(len(graph)):</tt> einfach nach <tt>for node in ordered:</tt> abändert, wobei <tt>ordered</tt> das Ergebnis der Funktion <tt>reverse_post_order</tt> ist, also ein Array, das die Knoten in der gewünschten Reihenfolge enthält).
Die Zusammenhangskomponenten, die man in Schritt 3 findet, sind gerade die stark zusammenhängenden Komponenten des Originalgraphen G. Die folgende Skizze zeigt diese in grün für den schwarz gezeichneten gerichteten Graphen.

[[Image:strongly-connected-components.png|400px]]

Zum Beweis der Korrektheit des Algorithmus von Kosaraju zeigen wir zwei Implikationen: 1. Wenn die Knoten u und v in der selben stark zusammenhängenden Komponente liegen, werden sie in Schritt 3 des Algorithmus auch der selben Komponente zugewiesen. 2. Wenn die Knoten u und v in Schritt 3 der selben Komponente zugewiesen wurden, müssen sie auch in der selben stark zusammenhängenden Komponente liegen.
# Knoten u und v gehören zur selben stark zusammenhängenden Komponente von G. Per Definition gilt, dass u von v aus erreichbar ist und umgekehrt. Dies muss auch im transponierten Graphen GT gelten (der Weg <math>u \rightsquigarrow v</math> wird jetzt zum Weg <math>v \rightsquigarrow u</math> und umgekehrt). Wird u bei der Tiefensuche in Schritt 3 vor v expandiert, ist v von u aus erreichbar und gehört somit zur selben Komponente. Das umgekehrte gilt, wenn v vor u expandiert wird. Daraus folgt die Behauptung 1.
# Knoten u und v werden in Schritt 3 der selben Komponente zugewiesen: Sei x der Anker dieser Komponente. Da u in der gleichen Komponente wie x liegt, muss es in GT einen Weg <math>x \rightsquigarrow u</math>, und demnach in G einen Weg <math>u \rightsquigarrow x</math> geben. Da x der Anker seiner Komponente ist, wissen wir aber auch, dass x in der reverse post-order vor u liegt (denn der Anker ist der Knoten, mit dem eine neue Komponente gestartet wird; er muss deshalb im Array <tt>ordered</tt> als erster Konten seiner Komponente gefunden worden sein). Wir unterscheiden jetzt im Schritt 1 des Algorithmus zwei Fälle:
## u wurde bei der Bestimmung der post-order vor x expandiert. Dann kann x nur dann in der reverse post-order vor u liegen (oder, einfacher ausgedrückt, x kann nur dann in der post-order hinter u liegen), wenn x im Graphen G nicht von u aus erreichbar war. Das ist aber unmöglich, weil wir ja schon wissen, dass es in G einen Weg <math>u \rightsquigarrow x</math> gibt.
## Folglich wurde u bei der Bestimmung der post-order nach x expandiert. Da x in der post-order hinter u liegt, muss u während der Expansion von x erreicht worden sein. Deshalb muss es in G auch einen Weg <math>x \rightsquigarrow u</math> geben.
#:Somit sind x und u in der selben stark zusammenhängenden Komponente. Die gleiche Überlegung gilt für x und v. Wegen der Transitivität der Relation "ist erreichbar" folgt daraus, dass auch u und v in der selben Komponente liegen, also die Behauptung 2.

Die folgende Skizze illustriert, dass der Komponentengraph stets azyklisch ist. Den Komponentengraph erhält man, indem man für jede Komponente <math>C_i</math> einen Knoten erzeugt (grün), und die Knoten i und j durch eine gerichtete Kante verbindet (rot), wenn es im Originalgraphen eine Kante (u → v) mit <math>u \in C_i</math> und <math>v \in C_j</math> gibt. Es ist dann garantiert, dass es keine Kante in umgekehrter Richtung geben kann. Daraus folgt insbesondere, dass ein DAG nur triviale stark verbundene Komponenten haben kann, die aus einzelnen Knoten bestehen.

[[Image:strongly-connected-components-graph.png|400px]]

=== Anwendung: Das Erfüllbarkeitsproblem in Implikationengraphen ===

Das Erfüllbarkeitsproblem hat auf den ersten Blick nichts mit Graphen zu tun, denn es geht um Wahrheitswerte logischer Ausdrücke. Man kann logische Ausdrücke jedoch unter bestimmten Bedingungen in eine Graphendarstellung überführen und somit das ursprüngliche Problem auf ein Problem der Graphentheorie reduzieren, für das bereits ein Lösungsverfahren bekannt ist. In diesem Abschnitt wollen wir dies für die sogenannten Implikationengraphen zeigen, ein weiteres Beispiel findet sich im Kapitel [[NP-Vollständigkeit]].

==== Das Erfüllbarkeitsproblem ====

(vgl. [http://de.wikipedia.org/wiki/Erfüllbarkeitsproblem_der_Aussagenlogik WikiPedia (de)])

Das Erfüllbarkeitsproblem (SAT-Problem, von satisfiability) befasst sich mit logischen (oder Booleschen) Funktionen: Gegeben sei eine Menge <math>\{x_1, ... ,x_n\}</math> Boolscher Variablen (d.h., die <math>x_i</math> können nur die Werte True oder False annehmen), sowie eine logische Formel, in der die Variablen mit den üblichen logischen Operatoren
:<math>\neg\quad</math>: Negation ("nicht", in Python: <tt>not</tt>)
:<math>\vee\quad</math>: Disjunktion ("oder", in Python: <tt>or</tt>)
:<math>\wedge\quad</math>: Konjuktion ("und", in Python: <tt>and</tt>)
:<math>\rightarrow\quad</math>: Implikation ("wenn, dann", in Python nicht als Operator definiert)
:<math>\leftrightarrow\quad</math>: Äquivalenz ("genau dann, wenn", in Python: <tt>==</tt>)
:<math>\neq\quad</math>: exklusive Disjunktion ("entweder oder", in Python: <tt>!=</tt>)
verknüpft sind. Klammern definieren die Reihenfolge der Auswertung der Operationen. Für jede Belegung der Variablen <math>x_i</math> mit True oder False liefert die Formel den Wert der Funktion, der natürlich auch nur True oder False sein kann. Wenn Formel und Belegung gegeben sind, ist die Auswertung der Funktion ein sehr einfaches Problem: Man transformiert die Formel in einen Parse-Baum (siehe Übungsaufgabe "Taschenrechner) und wertet jeden Knoten mit Hilfe der üblichen Wertetabellen für logische Operatoren aus, die wir hier zur Erinnerung noch einmal angeben:
{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>a</math>
|width="70px"| <math>b</math>
|width="70px"| <math>a \vee b </math>
|width="70px"| <math>a \wedge b</math>
|width="70px"| <math>a \rightarrow b</math>
|width="70px"| <math>b \rightarrow a</math>
|width="70px"| <math>a \leftrightarrow b</math>
|width="70px"| <math>a \neq b</math>
|- align="center"
| 0 || 0 || 0 || 0 || 1 || 1 || 1 || 0
|- align="center"
| 0 || 1 || 1 || 0 || 1 || 0 || 0 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 0 || 1 || 0 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1 || 0
|}

Beim Erfüllbarkeitsproblem wird die Frage umgekehrt gestellt:
:Gegeben sei eine logische Funktion. Ist es möglich, dass die Funktion jemals den Wert True annimmt?
Das heisst, kann man die Variablen <math>x_i</math> so mit True oder False belegen, dass die Formel am Ende wahr ist? Im Prinzip kann man diese Frage durch erschöpfende Suche leicht beantworten, indem man die Funktion für alle <math>2^n</math> möglichen Belegungen einfach ausrechnet, aber das dauert für große n (ab ca. <math>n\ge 40</math>) viel zu lange. Erstaunlicherweise ist es aber noch niemanden gelungen, einen Algorithmus zu finden, der für beliebige logische Funktionen schneller funktioniert. Im Gegenteil wurde gezeigt, dass das Erfüllbarkeitsproblem [[NP-Vollständigkeit|NP-vollständig]] ist, so dass wahrscheinlich kein solcher Algorithmus existiert. Trotz (oder gerade wegen) seiner Schwierigkeit hat das Erfüllbarkeitsproblem viele Anwendungen gefunden, vor allem beim Testen logischer Schaltkreise ("Gibt es eine Belegung der Eingänge, so dass am Ausgang der verbotene Wert X entsteht?") und bei der Planerstellung in der künstlichen Intelligenz ("Kann man ausschließen, dass der generierte Plan Konflikte enthält?"). Es ist außerdem ein beliebtes Modellproblem für die Erforschung neuer Ideen und Algorithmen für schwierige Probleme.

==== Normalformen für logische Ausdrücke ====

Um die Beschreibung von Erfüllbarkeitsproblemen zu vereinfachen und zu vereinheitlichen, hat man verschiedene Normalformen für logische Ausdrücke eingeführt. Die wichtigste ist die Konjuktionen-Normalform (CNF - conjunctive normal form). Ein Ausdruck in Konjuktionen-Normalform ist eine UND-Verknüpfung von M Klauseln:
(CLAUSE1) <math>\wedge</math> (CLAUSE2) <math>\wedge</math> ... <math>\wedge</math> (CLAUSEM)
Jede Klausel ist wiederum ein logischer Ausdruck, der aber sehr einfach sein muss: Er darf nur noch k Variablen enthalten, die nur mit den Operatoren NICHT und ODER verknüpft werden dürfen, z.B.
CLAUSE1 := <math>x_1 \vee \neg x_3 \vee x_8</math>
Je nachdem, wie viele Variablen pro Klausel erlaubt sind, spricht man von k-CNF und entsprechend von einem k-SAT Problem. Es ist außerdem üblich, die Menge der Variablen und die Menge der negierten Variablen zusammen als Menge der Literale zu bezeichnen:
LITERALS := <math>\{x_1,...,x_n\} \cup \{\neg x_1,...,\neg x_n\}</math>
Formal definiert man die k-Konjunktionen-Normalform (k-CNF) am besten durch eine Grammatik in [http://de.wikipedia.org/wiki/Backus-Naur-Form Backus-Naur-Form]:
k_CNF ::= CLAUSE | k_CNF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\vee</math> ... <math>\vee</math> LITERAL) # genau k Literale pro Klausel
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
Beispiele:
* 3-CNF: <math>(x_1 \vee \neg x_2 \vee x_4) \wedge (x_2 \vee x_3 \vee \neg x_4) \wedge (\neg x_1 \vee x_4 \vee \neg x_5)</math>
* 2-CNF: <math>(x_1 \vee \neg x_2) \wedge (x_3 \vee x_4)</math> ...
Gesucht ist eine Belegung der Variablen mit True und False, so dass der Ausdruck den Wert True hat. Aus den Eigenschaften der UND- und ODER-Verknüpfungen folgt, dass ein Ausdruck in k-CNF genau dann True ist, wenn jede einzelne Klausel True ist. In jeder Klausel wiederum hat man k Chancen, die Klausel True zu machen, indem man eins der Literale zu True macht. Eventuell werden dadurch aber andere Klauseln wieder zu False, was die Aufgabe so schwierig macht. Die Bedeutung der k-CNF ergibt sich aus folgendem
;Satz: Jeder logische Ausdruck kann effizient nach 3-CNF transformiert werden, jedoch im allgemeinen nicht nach 2-CNF.
Man kann sich also auf Algorithmen für 3-SAT-Probleme konzentrieren, ohne dabei an Ausdrucksmächtigkeit zu verlieren.

Leider gilt der entsprechende Satz nicht für k=2: Ausdrücke in 2-CNF sind weit weniger mächtig, weil man in jeder Klausel nur noch zwei Wahlmöglichkeiten hat. Bestimmte logische Ausdrücke sind aber auch nach 2-CNF transformierbar, beispielsweise die Bedingung, dass zwei Literale u und v immer den entgegegesetzten Wert haben müssen. Dies ergibt ein Paar von ODER-Verknüpfungen:
:<math>(u \leftrightarrow \neg v) \equiv (u \vee \neg v) \wedge (\neg u \vee v)</math>
Die 2-CNF hat den Vorteil, dass es effiziente Algorithmen für das 2-SAT-Problem gibt, die wir jetzt kennenlernen wollen. Es zeigt sich, dass man Ausdrücke in 2-CNF als Graphen repräsentieren kann, indem man sie zunächst in die Implikationen-Normalform (INF für implicative normal form) überführt. Die Implikationen-Normalform besteht ebenfalls aus einer Menge von Klauseln, die durch UND-Operationen verknüpft sind, aber jede Klausel ist jetzt eine Implikation.
Die Grammatik der Implikationen-Normalform (INF) lautet:
INF ::= CLAUSE | INF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\rightarrow</math> LITERAL) # genau 2 Literale pro Implikation
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
und ein gültiger Ausdruck wäre z.B.
:<math>(x_1 \to x_2) \wedge (x_2 \to \neg x_3) \wedge (x_4 \to x_3)</math>
Die Umwandlung von 2-CNF nach INF beruht auf folgender Äquivalenz, die man sich aus der obigen Wahrheitstabelle leicht herleitet:
:<math>(x \vee y) \equiv (\neg x \rightarrow y) \equiv (\neg y \rightarrow x)</math>
Aus dieser Äquivalenz folgt der
;Satz: Ein Ausdruck in 2-CNF kann nach INF transformiert werden, indem man jede Klausel <math>(x \vee y)</math> durch das Klauselpaar <math>(\neg x \rightarrow y) \wedge (\neg y \rightarrow x)</math> ersetzt.
Man beachte, dass man für jede ODER-Klausel des ursprünglichen Ausdrucks zwei Implikationen (eine für jede Richtung des "wenn, dann") einfügen muss, um die Symmetrie des Problems zu erhalten.

==== Lösung des 2-SAT-Problems mit Implikationgraphen ====

Jeder Ausdruck in INF kann als gerichteter Graph dargestellt werden:
# Für jedes Literal wird ein Knoten in den Graphen eingefügt. Es gibt also für jede Variable und für ihre Negation jeweils einen Knoten, d.h. 2n Knoten insgesamt.
# Jede Implikation ist eine gerichtete Kante.
Implikationengraphen eignen sich, um Ursache-Folge-Beziehungen oder Konflikte zwischen Aktionen auszudrücken. Beispielsweise kann man die Klausel <math>(x \rightarrow \neg y)</math> als "wenn man x tut, darf man y nicht tun" interpretieren. Ein anderes schönes Beispiel findet sich in Übung 12.

Für die Implementation eines Implikationengraphen in Python empfiehlt es sich, die Knoten geschickt zu numerieren: Ist die Variable <math>x_i</math> dem Knoten i zugeordnet, so sollte die negierte Variable <math>\neg x_i</math> dem Knoten (i+n) zugeordnet werden. Zu jedem gegebenen Knoten i findet man dann den negierten Partnerknoten j leicht durch die Formel <tt>j = (i + n ) % (2*n)</tt>.

Die Aufgabe besteht jetzt darin, folgende Fragen zu beantworten:
# Ist der durch den Implikationengraphen gegebene Ausdruck erfüllbar?
# Finde eine geeignete Belegung der Variablen, wenn der Ausduck erfüllbar ist.
Die erste Frage beantwortet man leicht, indem man die stark zusammenhängenden Komponenten des Implikationengraphen bildet. Dann gilt folgender
;Satz: Seien u und v zwei Literale, die sich in der selben stark zusammenhängenden Komponente befinden. Dann müssen u und v stets den selben Wert haben, damit der Ausdruck erfüllt sein kann.
Die Korrektheit des Satzes folgt aus der Definition der stark zusammenhängenden Komponenten: Da u und v in der selben Komponente liegen, gibt es im Implikationengraphen einen Weg <math>u \rightsquigarrow v</math> sowie einen Weg <math>v \rightsquigarrow u</math>. Wegen der Transitivität der "wenn, dann" Relation kann man die Wege zu zwei Implikationen verkürzen, die gleichzeitig gelten müssen: <math>(u \rightarrow v) \wedge (v \rightarrow u)</math> (die Verkürzung von Wegen zu direkten Kanten entspricht gerade der Bildung der transitiven Hülle für die Knoten u und v). In der obigen Wertetabelle für logische Operatoren erkennt mann, dass dies äquivalent zur Bedingung <math>(u \leftrightarrow v)</math> ist. Dies ist aber gerade die Behauptung des Satzes.

Die Erfüllbarkeit des Ausdrucks ist nun ein einfacher Spezialfall dieses Satzes.
;Korrolar: Der gegebene Ausdruck ist genau dann erfüllbar, wenn die Literale <math>x_i</math> und <math>\neg x_i</math> sich für kein i in derselben stark zusammenhängenden Komponente befinden.
Setzt man nämlich im Satz <math>u = x_i</math> und <math>v = \neg x_i</math>, und beide Knoten befinden sich in der selben Komponente, dann müsste gelten <math>x_i \leftrightarrow\neg x_i</math>, was offensichtlich ein Widerspruch ist. Damit kann der Ausdruck nicht erfüllbar sein. Umgekehrt gilt, dass der Ausdruck immer erfüllbar ist, wenn <math>x_i</math> und <math>\neg x_i</math> stets in verschiedenen Komponenten liegen, weil der folgende Algorithmus von Aspvall, Plass und Tarjan in diesem Fall stets eine gültige Belegung aller Variablen liefert:
# Bestimme die stark zusammenhängenden Komponenten und bilde den Komponentengraphen. Ordne die Knoten des Komponentengraphen (also die stark zusammenhängenden Komponenten des Originalgraphen) in topologische Sortierung an.
# Betrachte die Komponenten in der topologischen Sortierung von hinten nach vorn und weise ihnen einen Wert nach folgenden Regeln zu (zur Erinnerung: alle Literale in der selben Komponente haben den selben Wert):
#* Wenn die Komponente noch nicht betrachtet wurde, setze ihren Wert auf True, und den Wert der komplementären Komponente (derjenigen, die die negierten Literale enthält) auf False.
#* Andernfalls, gehe zur nächsten Komponente weiter.
Der Algorithmus beruht auf der Symmetrie des Implikationengraphen: Weil Kanten immer paarweise <math>(\neg u \rightarrow v) \wedge (\neg v \rightarrow u)</math> eingefügt werden, ist der Graph schiefsymmetrisch (skew symmetric): die eine Hälfte das Graphen ist die transponierte Spiegelung der anderen Hälfte. Enthält eine stark zusammenhängende Komponente <math>C_i</math> die Knoten <tt>i1, i2, ...</tt>, so gibt es stets eine komplementäre Komponente <math>C_j = \neg C_i</math>, die die komplementären Knoten <tt>j1 = (i1 + n) % (2*n), j2 = (i2 + n) % (2*n), ...</tt> enthält. Gilt <math>C_i = \neg C_i</math> für irgendein i, so ist der Ausdruck nicht erfüllbar. Den Beweis für die Korrektheit des Algorithmus findet man im [http://www.math.ucsd.edu/~sbuss/CourseWeb/Math268_2007WS/2SAT.pdf Originalartikel]. Leider funktioniert dies nicht für k-SAT-Probleme mit <math>k > 2</math>.

Will man nur die Erfüllbarkeit prüfen, vereinfacht sich der Algorithmus zu:
# Bestimme die stark zusammenhängenden Komponenten.
# Teste für alle <tt>i = 0,...,n-1</tt>, dass Knoten <tt>i</tt> und Knoten <tt>(i+n)</tt> in unterschiedlichen Komponenten liegen.
Ist der Ausdruck erfüllbar, kann man eine gültige Belegung der Variablen jetzt mit dem randomisierten Algorithmus bestimmen, den wir im Kapitel [[Randomisierte Algorithmen]] behandeln.

== Weitere wichtige Graphenalgorithmen ==

Eins der wichtigsten Einsatzgebiete für Graphen ist die Optimierung, also die Suche nach der besten Lösung für ein gegebenes Problem:
* Das interval scheduling befasst sich damit, aus einer gegebenen Menge von Aufträgen die richtigen auszuwählen und sie geschickt auf die zur Verfügung stehenden Ressourcen aufzuteilen. Damit beschäftigen wir uns im Kapitel [[Greedy-Algorithmen und Dynamische Programmierung]].
* Beim Problem des Handlungsreisenden sucht man nach der kürzesten Rundreise, die alle gegebenen Städte genau einmal besucht. Dieses Problem behandeln wir im Kapitel [[NP-Vollständigkeit]].
* Viele weitere Anwendungen können wir leider in der Vorlesung nicht mehr behandeln, z.B.
** Algorithmen für den [http://en.wikipedia.org/wiki/Maximum_flow_problem maximalen Fluss] beantworten die Frage, wie man die Durchflussmenge durch ein Netzwerk (z.B. von Ölpipelines) maximiert.
** Beim [http://en.wikipedia.org/wiki/Assignment_problem Problem der optimalen Paarung] ("matching problem" oder "assignment problem") sucht man nach einer Teilmenge der Kanten (also nach einem Teilgraphen), so dass jeder Knoten in diesem Teilgraphen höchstens den Grad 1 hat. Im neuen Graphen gruppieren die Kanten also je zwei Knoten zu einem Paar, und die Paarung soll nach jeweils anwendungsspezifischen Kriterien optimal sein. Dies benötigt man z.B. bei der optimalen Zuordnung von Gruppen, etwas beim Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot) und in der Universität (Zuordnung Studenten - Übungsgruppen).
** In Statistik und maschinellem Lernen haben in den letzten Jahren die [http://en.wikipedia.org/wiki/Graphical_model graphischen Modelle] große Bedeutung erlangt.
* usw. usf.

[[Randomisierte Algorithmen|Nächstes Thema]]

Graphen und Graphenalgorithmen

2012-07-25T17:12:11Z

Ukoethe: /* Transitive Hülle und stark zusammenhängende Komponenten */

== Einführung zu Graphen ==

=== Motivation -- Königsberger Brückenproblem ===
Leonhard Euler [http://de.wikipedia.org/wiki/Leonhard_Euler] erfand den Graphen-Formalismus 1736, um eine scheinbar banale Frage zu beantworten: Ist es möglich, in Königsberg (siehe Stadtplan von 1809 und die schematische Darstellung) einen Spaziergang zu unternehmen, bei dem jede der 7 Brücken genau einmal überquert wird?

[[Image:Koenigsberg1809.png]] 
[[Image:Koenigsberg.jpg]]

Ein Graph abstrahiert von der Geometrie des Problems und repräsentiert nur die Topologie. Jeder Stadtteil von Königsberg ist ein Knoten des Graphen, jede Brücke eine Kante. Der zum Brückenproblem gehörende Graph sieht also so aus:

O
/| \
\| \
O---O
/| /
\| /
O

Der gesuchte Spaziergang würde existieren, wenn es maximal 2 Knoten gäbe, an denen sich eine ungerade Zahl von Kanten trifft. Die Frage muss für Königsberg also verneint werden, denn hier gibt es vier solche Knoten. Ein leicht modifiziertes Problem ist allerdings lösbar: Im obigen Stadtplan erkennt man eine Fähre, die die Stadtteile Kneiphof und Altstadt verbindet. Bezieht man dieselbe in den Spaziergang ein, ergibt sich folgender Graph, bei dem nur noch zwei Knoten mit ungerader Kantenzahl existieren:

--O
/ /| \
\ \| \
--O---O
/| /
\| /
O

Inzwischen haben Graphen eine riesige Zahl weiterer Anwendungen gefunden. Einige Beispiele:

* Landkarten:
** Knoten: Länder
** Kanten: gemeinsame Grenzen

* Logische Schaltkreise:
** Knoten: Gatter
** Kanten: Verbindungen

* Chemie (Summenformeln):
** Knoten: chemische Elemente
** Kanten: Bindungen

* Soziologie (StudiVZ)
** Soziogramm
*** Knoten: Personen
*** Kanten: Freund von ...

=== Definitionen ===

;Ungerichteter Graph: Ein ungerichteter Graph G = ( V, E ) besteht aus
:* einer endliche Menge V von Knoten (vertices)
:* einer endlichen Menge <math>E \subset V \times V</math> von Kanten (edges)
:Die Paare (u,v) und (v,u) gelten dabei als nur ''eine'' Kante (somit gilt die Symmetriebeziehung: (u,v) ∈ E => (v,u) ∈ E ). Die Anzahl der Kanten, die sich an einem Knoten treffen, wird als ''Grad'' (engl. ''degree'') dieses Knotens bezeichnet:
:::degree(v) = |{v' ∈ V | (v,v') ∈ E}|
:(Die Syntax |{...}| bezeichnet dabei die Mächtigkeit der angegebenen Menge, also die Anzahl der Elemente in der Menge.)

Der Graph des Königsberger Brückenproblems ist ungerichtet. Bezeichnet man die Knoten entsprechend des folgenden Bildes
c
/| \
\| \
b---d
/| /
\| /
a

gilt für die Knotengrade: <tt>degree(a) == degree(c) == degree(d) == 3</tt> und <tt>degree(b) == 5</tt>. Genauer muss man bei diesem Graphen von einem ''Multigraphen'' sprechen, weil es zwischen einigen Knotenpaaren (nämlich (a, b) sowie (b, c)) mehrere Kanten ("Mehrfachkanten") gibt. Wir werden in dieser Vorlesung nicht näher auf Multigraphen eingehen.

;Gerichteter Graph: Ein Graph heißt ''gerichtet'', wenn die Kanten (u,v) und (v,u) unterschieden werden. Die Kante (u,v) ∈ E wird nun als Kante von u nach v (aber nicht umgekehrt) interpretiert. Entsprechend unterscheidet man jetzt den ''eingehenden'' und den ''ausgehenden Grad'' jedes Knotens:
:*out_degree(v) = |{v' ∈ V | (v,v') ∈ E}| 
:*in_degree(v) = |{v' ∈ V| (v',v) ∈ E}|

Das folgende Bild zeigt einen gerichteten Graphen. Hier gilt <tt>out_degree(1) == out_degree(3) == in_degree(2) == in_degree(4) == 2</tt> und
<tt>in_degree(1) == in_degree(3) == out_degree(2) == out_degree(4) == 0</tt>:

[[Image:digraph.png|gerichteter Graph]]

 

;Vollständiger Graph: Ein vollständiger Graph ist ein ungerichteter Graph, bei dem jeder Knoten mit allen anderen Knoten verbunden ist.
:::<math>E = \{ (v,w) | v \in V, w \in V, v \ne w \}</math>
:Ein vollständiger Graph mit |V| Knoten hat <math>|E| = \frac{|V|(|V|-1)}{2}</math> Kanten.

Die folgenden Abbildungen zeigen die vollständigen Graphen mit einem bis fünf Knoten (auch als K1 bis K5 bezeichnet).

{| border="0" cellspacing="0" cellpadding="0" style="margin: 1em auto 1em auto"
|-
| [[Image:k1.png|frame|k1]]
| [[Image:k2.png|frame|k2]]
| [[Image:k3.png|frame|k3]]
|-
| [[Image:k4.png|frame|k4]]
| [[Image:k5.png|frame|k5]]
|
|}

''Rätsel'' 
Auf einer Party sind Leute. Alle stoßen miteinander an. Es hat 78 mal "Pling" gemacht.
Wieviele Leute waren da? Antwort: Jede Person ist ein Knoten des Graphen, jedes Antoßen eine Kante.
Da alle miteinander angestoßen haben, handelt es sich um einen vollständigen Graphen. Mit
|V|(|V|-1)/2 = 78 folgt, dass es 13 Personen waren.

 

;Gewichteter Graph: Ein Graph heißt ''gewichtet'', wenn jeder Kante eine reelle Zahl zugeordnet ist. Bei vielen Anwendungen beschränkt man sich auch auf nichtnegative reelle Gewichte. In einem gerichteten Graphen können die Gewichte der Kanten (u,v) und (v,u) unterschiedlich sein.

Die Gewichte kodieren Eigenschaften der Kanten, die für die jeweilige Anwendung interessant sind. Bei der Berechnung des maximalen Flusses in einem Netzwerk sind die Gewichte z.B. die Durchflusskapazitäten jeder Kante, bei der Suche nach kürzesten Weges kodieren Sie den Abstand zwischen den Endknoten der Kante, bei Währungsnetzwerken (jeder Knoten ist eine Währung) geben sie die Wechselkurse an, usw..

 

;Teilgraphen: Ein Graph G' = (V',E') ist ein Teilgraph eines Graphen G, wenn gilt:
:* V' &sube; V
:* E' ⊂ E
:Er heißt ''(auf)spannender Teilgraph'', wenn gilt:
:* V' = V
:Er heißt ''induzierter Teilgraph'', wenn gilt:
:* e = (u,v) ∈ E' ⊂ E ⇔ u ∈ V' und v ∈ V'
:Den von V' induzierten Teilgraphen erhält man also, indem man aus G alle Knoten löscht, die nicht in V' sind, sowie alle Kanten (und nur diese Kanten), die einen der gelöschten Knoten als Endknoten haben.

 

;Wege, Pfade, Zyklen, Kreise, Erreichbarkeit: Sei G = (V,E) ein Graph (ungerichtet oder gerichteter) Graph. Dann gilt folgende rekursive Definition:
:* Für v ∈ V ist (v) ein Weg der Länge 0 in G
:* Falls <math>(v_0, v_1, ..., v_{n-1})</math> ein Weg ist, und eine Kante <math>(v_{n-1}, v_n)\in E</math> existiert, dann ist auch <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ein Weg, und er hat die Länge n.
: Ein Weg ist also eine nichtleere Folge von Knoten, so dass aufeinander folgende Knoten stets durch eine Kante verbunden sind. Die Länge des Weges entspricht der Anzahl der Kanten im Weg (= Anzahl der Knoten - 1).
:* Ein ''Pfad'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, bei dem alle Knoten vi verschieden sind.
:* ''Ein Zyklus'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, der zum Ausgangspunkt zurückkehrt, wenn also v0 = vn gilt.
:* Ein ''Kreis'' ist ein Zyklus ohne Überkreuzungen. Das heisst, es gilt v0 = vn und <math>(v_0, v_1, ..., v_{n-1})</math> ist ein Pfad.
:* Ein Knoten w ∈ V ist von einem anderen Knoten v ∈ V aus ''erreichbar'' genau dann, wenn ein Weg (v, ..., w) existiert. Wir schreiben dann <math>v \rightsquigarrow w</math>.
In einem ungerichteten Graph ist die Erreichbarkeits-Relation stets symmetrisch, das heisst aus <math>v \rightsquigarrow w</math> folgt <math>w \rightsquigarrow v</math>. In einem gerichteten Graphen ist dies im allgemeinen nicht der Fall.

Bestimmte Wege haben spezielle Namen

;Eulerweg: Ein Eulerweg ist ein Weg, der alle '''Kanten''' genau einmal enthält.

Die eingangs erwähnte Frage des Königsberger Brückenproblems ist equivalent zu der Frage, ob der dazugehörige Graph einen Eulerweg besitzt (daher der Name). Ein anderes bekanntes Beispiel ist das "Haus vom Nikolaus": Wenn man diesen Graphen in üblicher Weise in einem Zug zeichnet, erhält man gerade den Eulerweg.

O
/ \
O----O
| \/ |
| /\ | "Das Haus vom Nikolaus": Alle ''Kanten'' werden nur ''einmal'' passiert
O----O

;Hamiltonweg: Ein Hamiltonweg ist ein Weg, der alle '''Knoten''' genau einmal enthält. Das "Haus vom Nikolaus" besitzt auch einen Hamiltonweg:

O
/
O----O
/
/ Alle ''Knoten'' werden nur ''einmal'' passiert
O----O

;Hamiltonkreis: Ein Hamiltonkreis ist ein Kreis, der alle '''Knoten''' genau einmal enthält. Auch ein solches Gebilde ist im Haus von Nilolaus enthalten:

O
/ \
O O
| | v0 = vn
| | vi != vj Für Alle i,j i !=j; i,j >0; i,j < n
O----O

Die folgende Skizze zeigt hingegen einen Zyklus: Der Knoten rechts unten sowie die untere Kante sind zweimal enthalten (die Kante einmal von links nach rechts und einmal von rechts nach links):

O
/ \
O O
\ |
\ | Zyklus
O====O

 

;Zusammenhang, Zusammenhangskomponenten: Ein ungerichteter Graph G heißt ''zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math>
:Ein gerichteter Graph G ist zusammenhängend, wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''oder''' <math>w \rightsquigarrow v</math>.
:Er ist ''stark zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''und''' <math>w \rightsquigarrow v</math>.
:Entsprechende Definitionen gelten für Teilgraphen G'. Ein Teilgraph G' heisst ''Zusammenhangskomponente'' von G, wenn er ein ''maximaler'' zusammenhängender Teilgraph ist, d.h. wenn G' zusammenhängend ist, und man keine Knoten und Kanten aus G mehr zu G' hinzufügen kann, so dass G' immer noch zusammenhängend bleibt. Entsprechend definiert man ''starke Zusammenhangskomponenten'' in einem gerichteten Graphen.

 

;Planarer Graph, ebener Graph: Ein Graph heißt ''planar'', wenn er so in einer Ebene gezeichnet werden ''kann'', dass sich die Kanten nicht schneiden (außer an den Knoten). Ein Graph heißt ''eben'', wenn er tatsächlich so gezeichnet ''ist'', dass sich die Kanten nicht schneiden. Die Einbettung in die Ebene ist im allgemeinen nicht eindeutig.

'''Beispiele:'''

Der folgende Graph ist planar und eben:

O
/|\
/ O \
/ / \ \
O O

Das "Haus vom Nikolaus" ist ebenfalls planar, wird aber üblicherweise nicht als ebener Graph gezeichnet, weil sich die Diagonalen auf der Wand überkreuzen:

O
/ \
O----O
| \/ |
| /\ |
O----O

Eine ebene Einbettung dieses Graphen wird erreicht, wenn man eine der Diagonalen ausserhalb des Hauses zeichnet. Der Graph (also die Menge der Knoten und Kanten) ändert sich dadurch nicht.

O
/ \
--O----O
/ | / |
| | / |
| O----O Das "Haus vom Nikolaus" als ebener Graph gezeichnet.
\ /
-----

Eine alternative Einbettung erhalten wir, wenn wir die andere Diagonale außerhalb des Hauses zeichnen:

O
/ \
O----O--|
| \ | |
| \ | |
O----O | Alternative Einbettung des "Haus vom Nikolaus".
| |
|-------|

Jede Einbettung eines planaren Graphen (also jeder ebene Graph) definiert eine eindeutige Menge von ''Regionen'':

|----O @
| /@ \
| O----O
| |@ / |
| | / @|
| O----O @ entspricht jeweils einer ''Region''. Auch ausserhalb der Figur ist eine Region (die sogenannte ''unendliche'' Region).
|@ |
|-------|

Der vollständige Graph K5 ist kein planarer Graph, da sich zwangsweise Kanten schneiden, wenn man diesen Graphen in der Ebene zeichnet.

 
;Dualer Graph: Jeder ebene Graph G = (V, E) hat einen ''dualen Graphen'' D = (VD, ED), dessen Knoten und Kanten wie folgt definiert sind:
:* VD enthält einen Knoten für jede Region des Graphen G
:* Für jede Kante e ∈ E gibt es eine duale Kante eD ∈ ED, die die an e angrenzenden Regionen (genauer: die entsprechenden Knoten in D) verbindet.

Die folgende Abbildung zeigt einen Graphen (grau) und seinen dualen Graphen (schwarz). Die Knoten des dualen Graphen sind mit Zahlen gekennzeichnet und entsprechen den Regionen des Originalgraphen. Jeder (grauen) Kante des Originalgraphen entspricht eine (schwarze) Kante des dualen Graphen.

 
[[Image:dual-graphs.png]]
 

Für duale Graphen gilt: Wenn der Originalgraph zusammenhängend ist, enthält jede Region des dualen Graphen genau einen Knoten des Originalgraphen. Deshalb ist der duale Graph des dualen Graphen wieder der Originalgraph. Bei nicht-zusammenhängenden Graphen gilt dies nicht (vgl. das Fenster bei obigem Bild). In diesem Fall hat der duale Graph mehrere mögliche Einbettungen in die Ebene (man kann z.B. die rechte Kante zwischen Knoten 2 und 4 auch links vom Fenster einzeichnen), und man erhält nicht notwendigerweise den Originalgraphen, wenn man den dualen Graphen des dualen berechnet.

;Baum: Ein ''Baum'' ist ein zusammenhängender, kreisfreier Graph.

Beispiel: Binärer Suchbaum

;Spannbaum: Ein ''Spannbaum'' eines zusammenhängenden Graphen G ist ein zusammenhängender, kreisfreier Teilgraph von G, der alle Knoten von G enthält

Beispiel: Spannbaum für das "Haus des Nikolaus"

O
/
O O
| /
| /
O----O

Der Spannbaum eines Graphen mit |V| Knoten hat stets |V| - 1 Kanten.

;Wald: Ein ''Wald'' ist ein unzusammenhängender, kreisfreier Graph.
: Jede Zusammenhangskomponente eines Waldes ist ein Baum.

=== Repräsentation von Graphen ===

Sei G = ( V, E ) gegeben und liege V in einer linearen Sortierung vor. 
:::<math>V = \{ v_1, ...., v_n \}</math>

;Adjazenzmatrix: Ein Graph kann durch eine Adjazenzmatrix repräsentiert werden, die soviele Zeilen und Spalten enthält, wie der Graph Knoten hat. Die Elemente der Adjazenzmatrix sind "1", falls eine Kante zwischen den zugehörigen Knoten existiert:
:::<math>\mathrm{\bold A} = a_{ij} =
\begin{cases}
1 & \mathrm{falls}\quad (v_i, v_j) \in E \\
0 & \mathrm{sonst}
\end{cases}
</math>
:Die Indizes der Matrix entsprechen also den Indizes der Knoten gemäß der gegebenen Sortierung. Im Falle eines ungerichteten Graphen ist die Adjazenzmatrix stets symmetrisch (d.h. es gilt <math>a_{ij}=a_{ji}</math>), bei einem gerichteten Graphen ist sie im allgemeinen unsymmetrisch.

Beispiel für einen ungerichteten Graphen:

v = { a,b,c,d } b d
| \ / |
| \/ |
| /\ |
| / \ |
a c

a b c d
-----------
(0 1 0 1) |a
A = (1 0 1 0) |b
(0 1 0 1) |c
(1 0 1 0) |d

Die Adjazenzmatrixdarstellung eignet sich besonders für dichte Graphen (d.h. wenn die Zahl der Kanten in O(|V|2) ist.

;Adjazenzlisten: In der Adjazenzlistendarstellung wird der Graph als Liste von Knoten repräsentiert, die für jeden Knoten einen Eintrag enthält. Der Eintrag für jeden Knoten ist wiederum eine Liste, die die Nachbarknoten dieses Knotens enthält:
:* graph = {adjazencyList(v) | v ∈ V}
:* adjazencyList(v) = {v' ∈ V | (v, v') ∈ E}

In Python implementieren wir Adjazenzlisten zweckmäßig als Array von Arrays:

graph = [[...],[...],...,[...]]
Adjazenzliste für Knoten => 0 1 n

Wenn wir bei dem Graphen oben die Knoten wie bei der Adjazenzmatrix indizieren (also <tt>a => 0</tt>, <tt>b => 1</tt>, <tt>c => 2</tt>, <tt>d => 3</tt>), erhalten wir die Adjazenzlistendarstellung:

graph = [[b, d], [a, c],[b, d], [a, c]]

Auf die Nachbarknoten eines durch seinen Index <tt>node</tt> gegebenen Knotens können wir also wie folgt zugreifen:

for neighbors in graph[node]:
... # do something with neighbor

Die Adjazenzlistendarstellung ist effizienter, wenn der Graph nicht dicht ist, so dass viele Einträge der Adjazenzmatrix Null wären. In der Vorlesung werden wir nur diese Darstellung verwenden.

;<div id="transposed_graph">Transponierter Graph</div>: Den ''transponierten Graphen'' GT eines gerichteten Graphen G erhält man, wenn man alle Kantenrichtungen umkehrt.

Bei ungerichteten Graphen hat die Transposition offensichtlich keinen Effekt, weil alle Kanten bereits in beiden Richtungen vorhanden sind, so dass GT = G gilt. Bei gerichteten Graphen ist die Transposition einfach, wenn der Graph als Adjazenzmatrix implementiert ist, weil man einfach die transponierte Adjazenzmatrix verwenden muss (beachte, dass sich die Reihenfolge der Indizes umkehrt):
:::AT = aji
Ist der Graph hingegen durch eine Adjazenzliste repräsentiert, muss etwas mehr Aufwand getrieben werden:

def transposeGraph(graph):
gt = [[] for k in graph] # zunächst leere Adjazenzlisten von GT
for node in range(len(graph)):
for neighbor in graph[node]:
gt[neighbor].append(node) # füge die umgekehrte Kante in GT ein
return gt

== Durchlaufen von Graphen (Graph Traversal) ==

Wir betrachten zunächst ungerichtete Graphen mit V Knoten und E Kanten. Eine grundlegende Aufgabe in diesen Graphen besteht darin, alle Knoten in einer bestimmten Reihenfolge genau einmal zu besuchen. Hierbei darf man sich von einem gegebenen Startknoten aus nur entlang der Kanten des Graphen bewegen. Die beim Traversieren benutzen Kanten bilden einen Baum, dessen Wurzel der Startknoten ist und der den gesamten Graphen aufspannt, falls der Graph zusammenhängend ist. (Beweis: Da jeder Knoten nur einmal besucht wird, gibt es für jeden besuchten Knoten [mit Ausnahme des Startknotens] genau eine eingehende Kante. Ist der Graph zusammenhängend, wird jeder Knoten tatsächlich erreicht und es gibt genau (V-1) Kanten, exakt soviele wie für einen Baum mit V Knoten notwendig sind.) Ist der Graph nicht zusammenhängend, wird jeder zusammenhängende Teilgraph (jede Zusammenhangskomponente) getrennt traversiert, und man erhält einen sogenannten Wald mit einem Baum pro Zusammenhangskomponente. Die beiden grundlegenden Traversierungsmethoden Tiefensuche und Breitensuche werden im folgenden vorgestellt.

=== Tiefensuche in Graphen (Depth First Search, DFS) ===

Die Idee der Tiefensuche besteht darin, jeden besuchten Knoten sofort über die erste Kante wieder zu verlassen, die zu einem noch nicht besuchten Knoten führt. Man findet dadurch schnell einen möglichst langen Pfad durch den Graphen, und der Traversierungs-Baum wird zunächst in die Tiefe verfolgt, daher der Name des Verfahrens. Hat ein Knoten keine unbesuchten Nachbarknoten mehr, geht man im Baum zurück (sogenanntes back tracking), bis man einen Knoten findet, der noch eine unbesuchte Nachbarn besitzt, und traversiert diese nach dem gleichen Muster. Gibt es gar keine unbesuchten Knoten mehr, kehrt die Suche zum Startknoten zurück und endet dort.

WDie folgende rekursive Implementation der Tiefensuche erwartet den Graphen in Adjazenzlistendarstellung und beginnt die Suche beim Knoten <tt>startnode</tt>. Die Information, ob ein Knoten bereits besucht wurde, wird im Array <tt>visited</tt> gespeichert. Ein solches Array, das zusätzliche Informationen über die Knoten des Graphen bereitstellt, wir häufig property map genannt.

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
print node # Ausgabe der Knotennummer - pre-order
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)

visit(startnode)

[[Image:Tiefens.jpg]]

Ausgabe für den Graphen in diesem Bild (es handelt sich um einen ungerichteten Graphen, die Pfeile symbolisieren nur die Suchrichtung beim Traversal):

>>> dfs(graph, 1)
1
2
4
3
6
7
5

<div id="pre_and_post_order">In dieser Version des Algorithmus werden die Knotennummern ausgegeben, bevor die Nachbarknoten besucht werden. Man bezeichnet die resultierende Sortierung der Knoten als pre-order oder als discovery order. Alternativ kann man die Knotennummern erst ausgeben, nachdem alle Nachbarn besucht wurden, also auf dem Rückweg der Rekursion. In diesem Fall spricht man von post-order oder finishing order:</div>

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)
print node # Ausgabe der Knotennummer - post-order

visit(startnode)

Es ergibt sich jetzt die Ausgabe:

>>> dfs(graph, 1)
6
7
3
4
5
2
1

In realem Code ersetzt man die print-Ausgaben natürlich durch anwendungsspezifische Aktionen und Berechnungen. Einige Anwendungen sind uns im Kapitel [[Suchen]] bereits begegnet.
; Anwendungen der Pre-Order Traversierung
* Kopieren eines Graphen: kopiere zuerst den besuchten Knoten, dann seine Nachbarn und die dazugehörigen Kanten (sowie die Kanten zu bereits besuchten Knoten, die in der Grundversion der Tiefensuche ignoriert werden).
* Bestimmen der Zusammenhangskomponenten eines Graphen (siehe unten)
* In einem Zeichenprogramm: fülle eine Region mit einer Farbe ("flood fill"). Dabei ist jedes Pixel ein Knoten des Graphen und wird mit seinen 4 Nachbarpixceln verbunden. Die Tiefensuche startet bei der Mausposition und endet am Rand des betreffendcen Gebiets.
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von der Wurzel
* Falls der Graph ein Parse-Baum ist, wobei innere Knoten Funktionsaufrufe, Kindknoten Funktionsargumente, und Blattknoten Werte repräsentieren: drucke den zugehörigen Ausdruck aus (also immer zuerst den Funktionsnamen, dann die Argumente, die wiederum geschachtelte Funktionsaufrufe sein können).
; Anwendungen der Post-Order Traversierung
* Löschen eines Graphen: lösche zuerst die Nachbarn, dann den Knoten selbst
* Bestimmen einer topologischen Sortierung eines azyklischen gerichteten Graphens (siehe unten)
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von den Blättern (also die Tiefe des Baumes, siehe Übung 5)
* Falls der Graph ein Parse-Baum ist: führe die zugehörige Berechnung aus (d.h. berechne zuerst die geschachtelten inneren Funktionen, dann mit diesen Ergebnissen die nächst äußeren usw., siehe Übung 5).
; Anwendungen, die Pre- und Post-Order benötigen
* Weg aus einem Labyrinth: die Pre-Order dokumentiert die Suche nach dem Weg, die Post-Order zeigt den Rückweg aus Sackgassen (siehe Übung 9).
Im Spezialfall, wenn der Graph ein Binärbaum ist, unterscheidet man noch eine dritte Variante der Traversierung, nämlich die in-order Traversierung. In diesem Fall behandelt man den Vaterknoten nach den linken, aber vor den rechten Kindern. Diese Reihenfolge wird beim [[Suchen#Beziehungen zwischen dem Suchproblem und dem Sortierproblem|Tree Sort Algorithmus]] verwendet. Diese Sortierung verwendet man auch, wenn man einen Parse-Baum mit binären Operatoren (statt Funktionsaufrufen) ausgeben will, siehe Übung 5.

Eine nützliche Erweiterung der Tiefensuche besteht darin, in der property map <tt>visited</tt> nicht nur zu dokumentieren, dass ein Knoten bereits besucht wurde, sondern auch, von welchem Knoten aus man den jeweiligen Knoten zuerst erreicht hat. Im entstehenden Tiefensuchbaum ist dies gerade der Vaterknoten, weshalb wir die verbesserte property map zweckmäßigerweise in <tt>parents</tt> umbenennen. Für den Startknoten, also die Wurzel des Baumes, wählen wir die Konvention, dass er sein eigener Vaterknoten ist (die Konvention, dafür den Wert <tt>None</tt> zu verwenden, scheidet aus, weil dies bereits die Tatsache signalisiert, dass ein Knoten noch nicht besucht wurde):

def dfs(graph, startnode):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Tiefensuchbaum

def visit(node, parent): # rekursive Hilfsfunktion
if parents[node] is None: # Besuche node, wenn er noch nicht besucht wurde
parents[node] = parent # Markiere node als besucht und speichere seinen Vaterknoten
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn ...
visit(neighbor, node) # ... wobei node zu deren Vaterknoten wird

visit(startnode, startnode) # Konvention für Wurzel: startnode ist sein eigener Vater

return parents # Rückgabe des berechneten Tiefensuch-Baums

Die Ausgabe für den obigen Beispielgraphen lautet:
Knotennummer | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
--------------+-----+-----+-----+-----+-----+-----+-----+-----
Vaterknoten | None| 1 | 1 | 4 | 2 | 2 | 3 | 3

Dabei ist die Knotennummer der Index im Array <tt>parents</tt>, und der Vaterknoten ist der dazugehörige Arrayeintrag. Beachte, dass Knoten 0 in diesem Graphen nicht existiert, daher ist sein Eintrag <tt>None</tt>. Per Konvention hat der Wurzelknoten 1 sich selbst als Vater.

=== Breitensuche in Graphen (Breadth First Search, BFS) ===

Im Gegensatz zur Tiefensuche werden bei der Breitensuche alle Nachbarnknoten abgearbeitet, bevor man rekursiv deren Nachbarn besucht. Man betrachtet somit zuerst alle Knoten, die den Abstand 1 von Startknoten haben, dann diejenigen mit dem Abstand 2 usw. Diese Reihenfolge bezeichnet man als level-order. Wir sind ihr beispielsweise in Übung 6 begegnet, als die ersten 7 Ebenen eines Treap ausgegeben werden sollten. Man implementiert Breitensuche zweckmäßig mit Hilfe einer Queue, die die Knoten in First In - First Out - Reihenfolge bearbeitet. Eine geeignete Datenstruktur hierfür ist die Klasse <tt>[http://docs.python.org/library/collections.html#collections.deque deque]</tt> aus dem Python-Modul <tt>[http://docs.python.org/library/collections.html collections]</tt> (eine Deque implementiert sowohl die Funktionalität einer Queue wie auch die eines Stacks, siehe Übung 3):

from collections import deque

def bfs(graph, startnode)
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if not visited[node]: # Falls node noch nicht (auf einem anderen Weg) besucht wurde
visited[node] = True # Markiere node als besucht
print node # Drucke Knotennummer
for neighbor in graph[node]: # Füge Nachbarn in die Queue ein
q.append(neighbor)

[[Image:Breitens.jpg]]

Der Aufruf dieser Funktion liefert die Knoten des obigen Graphens ebenenweise, also zufällig genau in der Reihenfolge der Knotennummern:
>>> bfs(graph, 1)
1
2
3
4
5
6
7

Neben der ebenenweisen Ausgabe hat die Breitensuche viele weitere wichtige Anwendungen, z.B. beim Testen, ob ein gegebener Graph bi-partit ist (siehe [http://en.wikipedia.org/wiki/Breadth-first_search#Testing_bipartiteness WikiPedia]), sowie bei der Suche nach kürzesten Wegen (siehe unten) und kürzesten Zyklen.

== Weitere Anwendungen der Tiefensuche ==

Die Tiefensuche hat zahlreiche Anwendungen, wobei der grundlegende Algorithmus immer wieder leicht modifiziert und an die jeweilige Aufgabe angepasst wird. Wir beschreiben im folgenden einige Beispiele.

=== Damenproblem ===

Tiefensuche wird häufig verwendet, um systematisch nach der Lösung eines logischen Rätsels (oder allgemeiner nach der Lösung eines diskreten Optimierungsproblems) zu suchen. Besonders anschaulich hierfür ist das Damenproblem. Die Aufgabe besteht darin, <math>k</math> Damen auf einem Schachbrett der Größe <math>k \times k</math> so zu platzieren, dass sie sich (nach den üblichen Schach-Regeln) nicht gegenseitig schlagen können. Das folgende Diagramm zeigt eine Lösung für den Fall <math>k=4</math>. Die Positionen der Damen werden dabei wie üblich durch die Angabe der Spalte (Linie) mit Buchstaben und der Zeile (Reihe) mit Zahlen kodiert, hier also A2, B4, C1, D3:

---------------
| | X | | | 4
|---|---|---|---|
| | | | X | 3
|---|---|---|---|
| X | | | | 2
|---|---|---|---|
| | | X | | 1
---------------
A B C D

Um das Problem systematisch zu lösen, konstruieren wir einen gerichteten Graphen, dessen Knoten die möglichen Positionen der Damen kodieren. Wir verbinden Knoten, die zu benachbarten Linien gehören, genau dann mit einer Kante, wenn die zugehörigen Positionen kompatibel sind, also wenn sich die dort positionierten Damen nicht schlagen können. Der resultierende Graph für <math>k=4</math> hat folgende Gestalt:

[[Image:damenproblem-graph.png|500px|center]]

Knoten, die zur selben Reihe oder Linie gehören, sind beispielsweise nicht direkt verbunden, weil zwei Damen niemals in derselben Linie oder Reihe stehen dürfen. Um eine erlaubte Konfiguration zu finden, verwenden wir nun eine angepasste Version der Tiefensuche: Wir beginnen die Suche beim Knoten <tt>START</tt>. Sobald wir den Knoten <tt>STOP</tt> erreichen, beenden wir die Suche und lesen die Lösung am gerade gefundenen Weg von Start nach Stop ab. Zwei kleine Modifikationen des Grundalgorithmus stellen sicher, dass die Bedingungen der Aufgabe eingehalten werden: Wir dürfen bei der Tiefensuche nur dann zu einem Nachbarn weitergehen, wenn die betreffende Position mit allen im Pfad bereits gesetzten Positionen kompatibel ist, andernfalls ist diese Kante tabu. Landen wir aufgrund dieser Regel in einer Sackgasse (also in einem Knoten, wo keine der ausgehenden Kanten erlaubt ist), müssen wir zur nächsten erlaubten Abzweigung zurückgehen (Backtracking). Beim Zurückgehen müssen wir das <tt>parent</tt>-Flag wieder auf <tt>None</tt> zurücksetzen, weil der betreffende Knoten ja möglicherweise auf einem anderen erlaubten Weg erreichbar ist.

Der folgende Graph zeigt einen solchen Fall: Wir haben zwei Damen auf die Felder A1 und B3 positioniert (grüne Pfeile). Die einzig ausgehende Kante von B3 führt zum Knoten C1, welcher aber mit der Position A1 inkompatibel ist, so dass diese Kante nicht verwendet werden darf (roter Pfeil). Das Backtracking muss jetzt zu Knoten A1 zurückgehen (dabei wird das <tt>parent</tt>-Flag von B3 wieder auf <tt>None</tt> gesetzt), weil A1 mit der Kante nach B4 eine weitere Option hat, die geprüft werden muss (die allerdings hier auch nicht zum Ziel führt).

[[Image:damenproblem-graph-failure.png|500px|center]]

Nach einigen weiteren Sackgassen findet man schließlich den Pfad A2, B4, C1, D3, der im folgenden Graphen grün markiert ist und der obigen Lösung entspricht:

[[Image:damenproblem-graph-success.png|500px|center]]

=== Test, ob ein ungerichteter Graph azyklisch ist ===

Ein zusammenhängender ungerichteter Graph ist azyklisch (also ein Baum) genau dann, wenn es nur einen möglichen Weg von jedem Knoten zu jedem anderen gibt. (Bei gerichteten Graphen sind die Verhältnisse komplizierter. Wir behandeln dies weiter unten.) Das kann man mittels Tiefensuche leicht feststellen: Die Kante, über die wir einen Knoten erstmals erreichen, ist eine Baumkante des Tiefensuchbaums. Erreichen wir einen bereits besuchten Knoten nochmals über eine andere Kante, haben wir einen Zyklus gefunden. Dabei müssen wir allerdings beachten, dass in einem ungerichteten Graphen jede Baumkante zweimal gefunden wird, einmal in Richtung vom Vater zum Kind und einmal in umgekehrter Richtung. Im zweiten Fall endet die Kante zwar in einem bereits besuchten Knoten (dem Vater), aber es entsteht dadurch kein Zyklus. Den Vaterknoten müssen wir deshalb überspringen, wenn wir über die Nachbarn iterieren:

def undirected_cycle_test(graph): # Annahme: der Graph ist zusammenhängend
# (andernfalls führe den Algorithmus für jede Zusammenhangskomponente aus)
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node, from_node): # rekursive Hilfsfunktion: gibt True zurück, wenn Zyklus gefunden wurde
if not visited[node]: # wenn node noch nicht besucht wurde
visited[node] = True # markiere node als besucht
for neighbor in graph[node]: # besuche die Nachbarn ...
if neighbor == from_node: # ... aber überspringe den Vaterknoten
continue
if visit(neighbor, node): # ... signalisiere, wenn rekursiv ein Zyklus gefunden wurde
return True
return False # kein Zyklus gefunden
else:
return True # Knoten schon besucht => Zyklus

startnode = 0 # starte bei beliebigem Knoten (hier: Knoten 0)
return visit(startnode, startnode) # gebe True zurück, wenn ein Zyklus gefunden wurde

Wenn wir einen Zyklus finden, wird das weitere Traversieren das Graphen abgebrochen, denn ein Graph, der einmal zyklisch war, kann später nicht wieder azyklisch werden. Die notwendige Modifikation für unzusammenhängende Graphen erfolgt analog zum Algorithmus für die Detektion von Zusammenhangskomponenten, der im nächsten Abschnitt beschrieben wird.

=== Finden von Zusammenhangskomponenten ===

Das Auffinden und Markieren von Zusammenhangskomponenten (also maximalen zusammenhängenden Teilgraphen) ist eine grundlegende Aufgabe in ungerichteten, unzusammenhängenden Graphen (bei gerichteten Graphen sind die Verhältnisse wiederum komplizierter, siehe unten). Zwei Knoten u und v gehören zur selben Zusammenhangskomponente genau dann, wenn es einen Pfad von u nach v gibt (da der Graph ungerichtet ist, gibt es dann auch einen Pfad von v nach u). Man sagt auch, dass "v von u aus erreichbar" ist. Unzusammenhängende Graphen entstehen in der Praxis häufig, wenn die Kanten gewisse Relationen zwischen den Knoten kodieren:
* Wenn die Knoten Städte sind und die Kanten Straßen, sind diejenigen Städte in einer Zusammenhangskomponente, die per Auto von einander erreichbar sind. Unzusammenhängende Graphen entstehen hier beispielsweise, wenn eine Insel nicht durch eine Brücke erschlossen ist, wenn Grenzen gesperrt sind oder wenn ein Gebirge zu unwegsam ist, um Straßen zu bauen.
* Wenn Knoten Personen sind, und Kanten die Eltern-Kind-Relation beschreiben, so umfasst jede Zusammenhangskomponenten die Verwandten (auch wenn sie nur über viele "Ecken" verwandt sind).
* In der Bildverarbeitung entsprechen Knoten den Pixeln, und dieselben werden durch eine Kante verbunden, wenn sie zum selben Objekt gehören. Die Zusammenhangskomponenten entsprechen somit den Objekten im Bild (siehe Übungsaufgabe).
Die Zusammenhangskomponenten bilden eine Äquivalenzrelation. Folglich kann für jede Komponente ein Reprässentant bestimmt werden, der sogenannte "Anker". Kennt jeder Knoten seinen Anker, ist das Problem der Zusammenhangskomponenten gelöst.

==== Lösung mittels Tiefensuche ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden. Anstelle der property map <tt>visited</tt> verwenden wir diesmal eine property map <tt>anchors</tt>, die für jeden Knoten die Knotennummer des zugehörigen Ankers angibt, oder <tt>None</tt>, wenn der Knoten noch nicht besucht wurde. Dabei verwenden wir wieder die Konvention, dass Anker auf sich selbst zeigen. Für viele Anwendungen ist es außerdem (oder stattdessen) zweckmäßig, die Zusammenhangskomponenten mit einer laufenden Nummer, einem sogenannten Label, durchzuzählen. Dann kann man zusätzliche Informationen zu jeder Komponente (beispielsweise deren Größe) einfach in einem Array speichern, das über die Labels indexiert wird. Die folgende Version der Tiefensuche bestimmt sowohl die Anker als auch die Labels für jeden Knoten:

def connectedComponents(graph):
anchors = [None] * len(graph) # property map für Anker jedes Knotens
labels = [None] * len(graph) # property map für Label jedes Knotens

def visit(node, anchor):
"""anchor ist der Anker der aktuellen ZK"""
if anchors[node] is None: # wenn node noch nicht besucht wurde:
anchors[node] = anchor # setze seinen Anker
labels[node] = labels[anchor] # und sein Label
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor, anchor)

current_label = 0 # Zählung der ZK beginnt bei 0
for node in xrange(len(graph)):
if anchors[node] is None: # Anker noch nicht bekannt => neue ZK gefunden
labels[node] = current_label # Label des Ankers setzen
visit(node, node) # Knoten der neuen ZK rekursiv suchen
current_label += 1 # Label für die nächste ZK hochzählen
return anchors, labels
Interessant ist hier die Schleife über alle Knoten des Graphen am Ende des Algorithmus, die bei den bisherigen Versionen der Tiefensuche nicht vorhanden war. Um ihre Funktionsweise zu verstehen, nehmen wir für den Moment an, dass der Graph zusammenhängend ist. Dann findet diese Schleife den ersten Knoten des Graphen und führt die Tiefensuche mit diesem Knoten als Startknoten aus. Sobald die Rekursion zurückkehrt, sind alle Knoten des Graphen besucht (weil der Graph ja zusammenhängend war), so dass die Schleife alle weiteren Knoten überspringt (die if-Anweisung liefert für keinen weiteren Knoten True). Bei unzusammenhängenden Graphen dagegen erreicht die Tiefensuche nur die Knoten derselben Komponente, die im weiteren Verlauf der Schleife übersprungen werden. Findet die if-Anweisung jetzt einen noch nicht besuchten Knoten, muss dieser folglich in einer neuen Komponente liegen. Wir verwenden diesen Knoten als Anker und bestimmen die übrigen Knoten dieser Komponente wiederum mit Tiefensuche.

* Beispiel: ... under construction 

Man erkennt, dass die Tiefensuche nach dem Anlagerungsprinzip vorgeht: Beginnend vom einem Startknoten (dem Anker) werden die Knoten der aktuellen Komponente nach und nach an den Tiefensuchbaum angehangen. Erst, wenn nichts mehr angelagert werden kann, geht der Algorithmus zur nächsten Komponente über.

==== Lösung mittels Union-Find-Algorithmus ====

Im Gegensatz zum Anlagerungsprinzip sucht der Union-Find-Algorithmus die Zusammenhangskomponenten mit dem Verschmelzungsprinzip: Eingangs wird jeder Knoten als ein Teilgraph für sich betrachtet. Dann iteriert man über alle Kanten und verbindet deren Endknoten jeweils zu einem gemeinsamen Teilgraphen (falls die beiden Enden einer Kante bereits im selben Teilgraphen liegen, wird diese Kante ignoriert). Solange noch Kanten vorhanden sind, werden dadurch immer wieder Teilgraphen in größere Teilgraphen verschmolzen. Am Ende bleiben die maximalen zusammenhängenden Teilgraphen (also gerade die Zusammenhangskomponenten) übrig. Dieser Algorithmus kommt ohne Tiefensuche aus und ist daher in der Praxis oft schneller, allerdings auch etwas komplizierter zu implementieren.

Der Schlüssel des Algorithmus ist eine Funktion <tt>findAnchor()</tt>, die zu jedem Knoten den aktuellen Anker sucht. Der Anker existiert immer, da jeder Knoten von Anfang an zu einem Teilgraphen gehört (anfangs ist jeder Teilgraph trivial und besteht nur aus dem Knoten selbst). Die Verschmelzung wird realisiert, indem der Anker des einen Teilgraphen seine Rolle verliert und stattdessen der Anker des anderen Teilgraphen eingesetzt wird.

Zur Verwaltung der Anker verwenden wir wieder eine property map <tt>anchors</tt> mit der Konvention, dass die Anker auf sich selbst verweisen. Es wäre jedoch zu teuer, wenn man bei jeder Verschmelzung alle Anker-Einträge der beteiligten Knoten aktualisieren müsste, da jeder Knoten im Laufe des Algorithmus mehrmals seinen Anker wechseln kann. Statt dessen definiert man Anker rekursiv: Verweist ein Knoten auf einen Anker, der mittlerweile diese Rolle verloren hat, folgt man dem Verweis von diesem Knoten (dem ehemaligen Anker) weiter, bis man einen tatsächlichen Anker gefunden hat - erkennbar daran, dass er auf sich selbst verweist. Diese Suchfunktion kann folgendermassen implementiert werden:

def findAnchor(anchors, node):
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
return node

Allerdings kann diese Kette im Laufe vieler Verschmelzungen sehr lang werden, so dass das Verfolgen der Kette teuer wird. Man vermeidet dies durch die sogenannte Pfadkompression: Immer, wenn man den Anker gefunden hat, aktualisiert man den Eintrag am Anfang der Kette. Die Funktion <tt>findAnchor()</tt> wird dadurch nur wenig komplizierter:

def findAnchor(anchors, node):
start = node # wir merken uns den Anfang der Kette
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
anchors[start] = node # Pfadkompression: aktualisiere den Eintrag am Anfang der Kette
return node

Man kann zeigen, dass die Ankersuche mit Pfadkompression zu einer fast konstanten amortisierten Laufzeit pro Aufruf führt.

Um mit jeder Kante des (ungerichteten) Graphen nur maximal einmal eine Verschmelzung durchzuführen, betrachten wir jede Kante nur in der Richtung von der kleineren zur größeren Knotennummer, die umgekehrte Richtung wird ignoriert. Außerdem ist es zweckmäßig, bei jeder Verschmelzung denjenigen Anker mit der kleineren Knotennummer als neuen Anker zu übernehmen. Dann gilt für jede Zusammenhangskomponente, dass gerade der Knoten mit der kleinsten Knotennummer der Anker ist (genau wie bei der Lösung mittels Tiefensuche), was die weitere Analyse vereinfacht, z.B. die Zuordnung der Labels zu den Komponenten am Ende des Algorithmus.

def unionFindConnectedComponents(graph):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker

for node in xrange(len(graph)): # iteriere über alle Knoten
for neighbor in graph[node]: # ... und über deren ausgehende Kanten
if neighbor < node: # ignoriere Kanten, die in falscher Richtung verlaufen
continue
# hier landen wir für jede Kante des Graphen genau einmal
a1 = findAnchor(anchors, node) # finde Anker ...
a2 = findAnchor(anchors, neighbor) # ... der beiden Endknoten
if a1 < a2: # Verschmelze die beiden Teilgraphen
anchors[a2] = a1 # (verwende den kleineren der beiden Anker als Anker des
elif a2 < a1: # entstehenden Teilgraphen. Falls node und neighbor
anchors[a1] = a2 # den gleichen Anker haben, waren sie bereits im gleichen
# Teilgraphen, und es passiert hier nichts.)
# Bestimme jetzt noch die Labels der Komponenten
labels = [None]*len(graph) # Initialisierung der property map für Labels
current_label = 0 # die Zählung beginnt bei 0
for node in xrange(len(graph)):
a = findAnchor(anchors, node) # wegen der Pfadkompression zeigt jeder Knoten jetzt direkt auf seinen Anker
if a == node: # node ist ein Anker
labels[a] = current_label # => beginne eine neue Komponente
current_label += 1 # und zähle Label für die nächste ZK hoch
else:
labels[node] = labels[a] # node ist kein Anker => setzte das Label des Ankers
# (wir wissen, dass labels[a] bereits gesetzt ist, weil
# der Anker immer der Knoten mit der kleinsten Nummer ist)
return anchors, labels

* Beispiel: ... under construction

== Kürzeste Wege (Pfade) ==

Eine weitere grundlegende Aufgabe in Graphen ist die Bestimmung eines kürzesten Weges zwischen zwei gegebenen Knoten. Dies hat offensichtliche Anwendungen bei Routenplanern und Navigationssystemen und ist darüber hinaus wichtiger Bestandteil anderer Algorithmen, z.B. bei der Berechnung eines maximalen Flusses mit der [http://en.wikipedia.org/wiki/Edmonds%E2%80%93Karp_algorithm Methode von Edmonds und Karp].

=== Kürzeste Wege in ungewichteten Graphen mittels Breitensuche ===

Im Fall eines ungewichteten Graphen ist die Länge eines Weges einfach durch die Anzahl der durchlaufenen Kanten definiert. Daraus folgt, dass kürzeste Pfade mit einer leicht angepassten Version der Breitensuche gefunden werden können: Aufgrund des first in-first out-Verhaltens der Queue betrachtet die Breitensuche alle (erreichbaren) Knoten in der Reihenfolge ihres Abstandes vom Startknoten. Wenn wir den Zielknoten zum ersten Mal erreichen, und der gerade gefundene Weg vom Start zum Ziel hat die Länge L, muss dies der kürzeste Weg sein: Alle möglichen Wege der Länge L' < L hat die Breitensuche ja bereits betrachtet, ohne dass dabei der Zielknoten erreicht wurde. Daraus folgt übrigens eine allgemeine Eigenschaft aller Algorithmen für kürzeste Wege: Wenn der kürzeste Weg vom Start zum Ziel die Länge L hat, finden diese Algorithmen als Nebenprodukt auch die kürzesten Wege zu allen Knoten, für die L' < L gilt.

Um den Algorithmus zu implementieren, passen wir die Breitensuche so an, dass anstelle der property map <tt>visited</tt> eine property map <tt>parents</tt> verwendet wird, die für jeden besuchten Knoten den Vaterknoten im Breitensuchbaum speichert. Durch Rückverfolgen der <tt>parent</tt>-Kette können wir den Pfad vom Ziel zum Start rekonstruieren, und durch Umdrehen der Reihenfolge erhalten wir den gesuchten Pfad vom Start zum Ziel. Sobald der Zielknoten erreicht wurde, können wir die Breitensuche abbrechen (<tt>break</tt>-Befehl in der ersten <tt>while</tt>-Schleife). Falls der gegebene Graph unzusammenhängend ist, kann es passieren, dass gar kein Weg gefunden wird, weil Start und Ziel in verschiedenen Zusammenhangskomponenten liegen. Dies erkennen wir daran, dass die Breitensuche beendet wurde, ohne den Zielknoten zu besuchen. Dann gibt die Funktion statt eines Pfades dern Wert <tt>None</tt> zurück:

from collections import deque

def shortestPath(graph, startnode, destination):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Breitensuchbaum
parents[startnode] = startnode # startnode ist die Wurzel des Baums => verweist auf sich selbst

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # Besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn sie noch nicht besucht wurden
parents[neighbor] = node # setze node als Vaterknoten
q.append(neighbor) # und füge neighbor in die Queue ein

if parents[destination] is None: # Breitensuche wurde beendet ohne den Zielknoten zu besuchen
return None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path # gefundenen Pfad zurückgeben

=== Gewichtete Graphen ===

Das Problem der Suche nach kürzesten Wegen wird wesentlich interessanter und realistischer, wenn wir zu gewichteten Graphen übergehen:

; Definition - kantengewichteter Graph
: Jeder Kante (s,t) des Graphen ist eine reelle oder natürliche Zahl wst zugeordnet, die üblicherweise als ''Kantengewicht'' bezeichnet wird.

; Definition - knotengewichteter Graph
: Jedem Knoten v des Graphen ist eine reelle oder natürliche Zahl wv zugeordnet, die üblicherweise als ''Knotengewicht'' bezeichnet wird.

Je nach Anwendung benötigt man Knoten- oder Kantengewichte oder auch beides zugleich. Wir beschränken uns in der Vorlesung auf kantengewichtete Graphen. Beispiele für die Informationen, die man durch Kantengewichte ausdrücken kann, sind
* wenn die Knoten Orte sind: Abstand von Anfangs- und Endknoten jeder Kante (z.B. Luftline oder Straßenentfernung), Fahrzeit zwischen den Orten
* wenn der Knoten ein Rohrnetzwerk beschreibt: Durchflusskapazität der einzelnen Rohre (für max-Flussprobleme), analog bei elektrischen Netzwerken: elektrischer Widerstand
* wenn die Knoten Währungen repräsentieren, können deren Wechselkurse durch Kantengewichte angegeben werden.
Bei einigen Beispielen ergeben sich unterschiedliche Kantengewichte, wenn eine Kante von s nach t anstatt von t nach s durchlaufen wird. Beispielsweise können sich die Fahrzeiten erheblich unterscheiden, wenn es in einer Richtung bergauf, in der anderen bergab geht, obwohl die Entfernung in beiden Fällen gleich ist. Hier ergibt sich natürlicherweise ein gerichteter Graph. In anderen Beispielen (z.B. bei Luftlinienentfernungen, in guter Näherung auch bei Straßenentfernungen) sind die Gewichte von der Richtung unabhängig, so dass wir ungerichtete Graphen verwenden können.

Die Repräsentation der Kantengewichte im Programm richtet sich nach der Repräsentation des Graphen selbst. Am einfachsten ist wiederum die Adjazenzmatrix, die aber nur für dichte Graphen (<math>E = O(V^2)</math>, mit E als Anzahl der Kanten und V als Anzahl der Knoten) effizient ist. Bei gewichteten Graphen gibt das Matrixelement aij das Gewicht der Kante i ⇒ j (wobei aij = 0 gesetzt wird, wenn diese Kante nicht existiert). Wie zuvor gilt für ungerichtete Graphen aij = aji (symmetrische Matrix), während dies für gerichtete Graphen nicht gelten muss.

Bei Graphen in Adjazenzlistendarstellung hat es sich bewährt, die Gewichte in einer property map zu speichern. Weiter oben haben wir bereits property maps für Knoteneigenschaften (z.B. <tt>visited</tt> und <tt>anchors</tt>) gesehen. Property maps für Kanten funktionieren ganz analog, allerdings muss man jetzt Paare von Knoten (nämlich Anfangs- und Endknoten der Kante) als Schlüssel verwenden und die Daten entsprechend in einem assoziativen Array ablegen:
w = weights[(i,j)] # Zugriff auf das Gewicht der Kante i ⇒ j
Alternativ könnte man auch die Graph-Datenstruktur selbst erweitern, aber dies ist weniger zu empfehlen, weil jeder Algorithmus andere Erwiterungen benötigt und damit die Datenstruktur sehr unübersichtlich würde.

Der kürzeste Weg ist nun definiert als der Weg, bei dem die Summe der Kantengewichte minimal ist:
;Definition - Problem des kürzesten Weges
: Sei P die Menge aller Wege von u nach v, und <math>p \in P</math> einer dieser Wege. Wenn der Grpah einfach ist (es also keine Mehrfachkanten zwischen denselben Knoten und keine Schleifen gibt), ist der Weg p durch die Folge der besuchten Knoten eindeutig bestimmt:
: <math>p : \ \ u = x_0 \rightarrow x_1 \rightarrow x_2 \rightarrow ... \rightarrow v = x_{n_p}</math>
:wo <math>n_p</math> die Anzahl der Kanten im Weg p ist. Seine Kosten Wp ergeben sich als Summer der Gewichte der einzelnen Kanten
: <math>W_p = \sum_{k=1}^{n_p} w_{x_{k-1}x_k}</math>
: und ein kürzester Weg <math>p^* \in P</math> ist ein Weg mit minimalen Kosten
: <math>p^* = \textrm{argmin}_{p\in P}\ \ W_p</math>
: Das Problem des kürzesten Weges besteht darin, einen optimalen Weg p* zwischen gegebenen Knoten u und v zu finden.
Die Lösung dieses Problems hängt davon ab, ob alle Kantengewichte positiv sind, oder ob es auch negative Kantengewichte gibt. In letzeren Fall ist es möglich, durch eine Verlängerung des Weges die Kosten zu redizieren, während sich im ersteren Fall die Kosten immer erhöhen, wenn man den Weg verlängert.

Negative Gewichte treten z.B. bei den Währungsgraphen auf. Auf den ersten Blick entsprechen diese Graphen nicht den Anforderungen an das Problem des kürzesten Weges, weil Wechselkurse miteinander (und mit Geldbeträgen) multipliziert anstatt addiert werden. Man beseitigt diese Schwierigkeit aber leicht, indem man die Logarithmen der Wechselkurse als Kantengewichte verwendet, wodurch sich die Multiplikation in eine Addition der Logarithmen verwandelt. Wechselkurse < 1 führen nun zu negativen Gewichten.

Interessant werden negative Gewichte vor allem in Graphen mit Zyklen. Dann kann es nämlich passieren, dass die Gesamtkosten eines Zyklus ebenfalls negativ sind. Jeder Weg, der den Zyklus enthält, hat dann Kosten von <math>-\infty</math>, weil man den Zyklus beliebig oft durchlaufen und dadurch die Gesamtkosten immer weiter verkleinern kann:

/\ 1. Durchlauf: Kosten -1
1 / \ -4 2. Durchlauf: Kosten -2
/____\ etc.
2

Um hier nicht in einer Endlosschleife zu landen, benötigt man spezielle Algorithmen, die mit dieser Situation umgehen können. Der [http://de.wikipedia.org/wiki/Bellman-Ford-Algorithmus Algorithmus von Bellmann und Ford] beispielsweise bricht die Suche nach dem kürzesten Weg ab, sobald er einen negativen Zyklus entdeckt, aber andernfalls kann er negative Gewichte problemlos verarbeiten.

Die Detektion negativer Zyklen hat wiederum eine interessante Anwendung bei Währungsgraphen: Ein Zyklus bedeutet hier, dass man Geld über mehrere Stufen von einer Währung in die nächste und am Schluß wieder in die Originalwährung umtauscht, und ein negativer Zyklus führt dazu, dass man am Ende mehr Geld besitzt als am Anfang (damit negative Zyklen wirklich einen Gewinn bedeuten und keinen Verlust, müssen die Wechselkurse vor der Logarithmierung in [http://de.wikipedia.org/wiki/Wechselkurs#Nominaler_Wechselkurs Preisnotierung] angegeben sein). Bei Privatpersonen ist dies ausgeschlossen, weil die Umtauschgebühren den möglichen Gewinn mehr als aufzehren. Banken mit direktem weltweitem Börsenzugang hingegen unternehmen große Anstrengungen, um solche negativen Zyklen möglichst schnell (nämlich vor der Konkurrenz) zu entdecken und auszunutzen. Diese Geschäftsmethode bezeichnet man als [http://de.wikipedia.org/wiki/Arbitrage Arbitrage] und die Existenz eines negativen Zyklus als Arbitragegelegenheit. Durch die Kursschwankungen (und durch die ausgleichende Wirkung der Arbitragegeschäfte selbst) existieren die Arbitragegelegenheiten nur für kurze Zeit, und ihre Detektion erfordert leistungsfähige Echtzeitalgorithmen.

In dieser Vorlesung beschränken wir uns hingegen auf Graphen mit ausschließlich positiven Gewichten. In diesem Fall ist der Algorithmus von Dijkstra die Methode der Wahl, weil er wesentlich schneller arbeitet als der Bellmann-Ford-Algorithmus.

=== Algorithmus von Dijkstra ===

==== Edsger Wybe Dijkstra ====

geb. 11. Mai 1930 in Rotterdam

ges. 06. August 2002

Dijkstra war ein niederländischer Informatiker und Wegbereiter der strukturierten Programmierung. 1972 erhielt er für seine Leistung in der Technik und Kunst der Programmiersprachen den Turing Award, der jährlich von der Association for Computing Machinery (ACM) an Personen verliehen wird, die sich besonders um die Entwicklung der Informatik verdient gemacht haben. Zu seinen Beiträgen zur Informatik gehören unter anderem der Dijkstra-Algorithmus zur Berechnung des kürzesten Weges in einem Graphen sowie eine Abhandlung über den go-to-Befehl und warum er nicht benutzt werden sollte. Der go-to-Befehl war in den 60er und 70er Jahren weit verbreitet, führte aber zu Spaghetti-Code. In seinem berühmten Paper "A Case against the GO TO Statement"[http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF], das als Brief mit dem Titel "Go-to statement considered harmful" veröffentlicht wurde, argumentiert Dijkstra, dass es umso schwieriger ist, dem Quellcode eines Programmes zu folgen, je mehr go-to-Befehle darin enthalten sind und zeigt, dass man auch ohne diesen Befehl gute Programme schreiben kann.

==== Algorithmus ====

Der Dijkstra-Algorithmus für kürzeste Wege ist dem oben vorgestellten Algorithmus <tt>shortestPath()</tt> auf der Basis von Breitensuche sehr ähnlich. Insbesondere gilt auch hier, dass neben dem kürzesten Weg vom Start zum Ziel auch alle kürzesten Wege gefunden werden, deren Endknoten dem Start näher sind als der Zielknoten. Aufgrund der Kantengewichte gibt es aber einen wichtigen Unterschied: Der erste gefundene Weg zu einem Knoten ist nicht mehr notwendigerweise der kürzeste. Wir bestimmen deshalb für jeden Knoten mehrere Kandidatenwege und verwenden eine Prioritätswarteschlange (statt einer einfachen First in - First out - Queue), um diese Wege nach ihrer Länge zu sortieren. Die Kandidatenwege für einen gegebenen Knoten werden unterschieden, indem wir auch den Vorgängerknoten im jeweiligen Weg speichern. Wenn ein Knoten erstmals an die Spitze der Prioritätswarteschlange gelangt, haben wir den kürzesten Weg zu diesem Knoten gefunden (das wird weiter unten formal bewiesen), und der Vorgänger des Knotens in diesem Weg wird zu seinem Vaterknoten. Erscheint derselbe Knoten später nochmals an der Spitze der Prioritätswarteschlange, handelt es sich um einen Kandidatenweg, der sich nicht als kürzester erwiesen hat und deshalb ignoriert werden kann. Wir erkennen dies leicht daran, dass der Vaterknoten in der property map <tt>parents</tt> bereits gesetzt ist.

Eine geeignete Datenstruktur für die Prioritätswarteschlange wird durch das Python-Modul [http://docs.python.org/library/heapq.html heapq] realisiert. Es verwendet ein normales Pythonarray als unterliegende Repräsentation für einen Heap und stellt effiziente <tt>heappush</tt> und <tt>heappop</tt>-Funktionen zur Verfügung. Dies entspricht genau unserer Vorgehensweise im Kapitel [[Prioritätswarteschlangen]]. Als Datenelement erwartet die Funktion <tt>heappush</tt> ein Tupel, dessen erstes Element die Priorität sein muss. Die übrigen Elemente des Tupels (und damit auch deren Anzahl) können je nach Anwendung frei festgelegt werden. Wir legen fest, dass das zweite Element den Endknoten des betrachteten Weges und das dritte den Vorgängerknoten speichert.

Die Kantengewichte werden dem Algorithmus in der property map <tt>weights</tt> übergeben:

<code python>
import heapq # heapq implementiert die Funktionen für Heaps

def dijkstra(graph, weights, startnode, destination):
parents = [None]*len(graph) # registriere für jeden Knoten den Vaterknoten im Pfadbaum

q = [] # Array q wird als Heap verwendet
heapq.heappush(q, (0.0, startnode, startnode)) # Startknoten in Heap einfügen

while len(q) > 0: # solange es noch Knoten im Heap gibt:
length, node, predecessor = heapq.heappop(q) # Knoten aus dem Heap nehmen
if parents[node] is not None: # parent ist schon gesetzt => es gab einen anderen, kürzeren Weg
continue # => wir können diesen Weg ignorieren
parents[node] = predecessor # parent setzen
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # die Nachbarn von node besuchen,
if parents[neighbor] is None: # aber nur, wenn ihr kürzester Weg noch nicht bekannt ist
newLength = length + weights[(node,neighbor)] # berechne Pfadlänge zu neighbor
heapq.heappush(q, (newLength, neighbor, node)) # und füge neighbor in den Heap ein

if parents[destination] is None: # Suche wurde beendet ohne den Zielknoten zu besuchen
return None, None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path, length # gefundenen Pfad und dessen Länge zurückgeben
</code>
Die wesentlichen Unterschiede zur Breitensuche sind im Code rot markiert: Anstelle der Queue verwenden wir jetzt einen Heap, und der Startknoten wird mit Pfadlänge 0 als erstes eingefügt. In der Schleife <tt>while len(q) > 0:</tt> wird jeweils der Knoten <tt>node</tt> mit der aktuell kürzesten Pfadlänge aus dem Heap entfernt. Die Pfadlänge vom Start zu diesem Knoten wird in der Variable <tt>length</tt> gespeichert, sein Vorgänger in der Variable <tt>predecessor</tt>. Wenn der aktuelle Weg nicht der kürzeste ist (<tt>parents[node]</tt> war bereits gesetzt), wird dieser Weg ignoriert. Andernfalls werden die property map <tt>parents</tt> aktualisiert und die Nachbarn von <tt>node</tt> besucht. Beim Scannen der Nachbarn berechnen wir zunächst die Länge <tt>newLength</tt> das Weges <tt>startnode => node => neighbor</tt> als Summe von <tt>length</tt> und dem Gewicht der Kante <tt>(node, neighbode)</tt>. Diese Länge wird beim Einfügen des Nachbarknotens in den Heap zur Priorität des aktuellen Weges.

Die wichtigsten Prinzipien des Dijkstra-Algorithmus noch einmal im Überblick:
* Der Dijkstra-Algorithmus ist Breitensuche mit Prioritätswarteschlange (Heap) statt einer einfache Warteschlange (Queue).
* Die Prioritätswarteschlange speichert alle Wege, die bereits gefunden worden sind und ordnet sie aufsteigend nach ihrer Länge.
* Das Sortieren (und damit der ganze Algorithmus) funktioniert nur mit positiven Kantengewichten korrekt.
* Da ein Knoten auf mehreren Wegen erreichbar sein kann, kann er auch mehrmals im Heap sein.
* Wenn ein Knoten erstmals aus der Prioritätswarteschlange entnommen wird, ist der gefundene Weg der kürzeste zu diesem Knoten. Andernfalls wird der Weg ignoriert.
* Wenn der Knoten <tt>destination</tt> aus dem Heap entnommen wird, ist der kürzeste Weg von Start nach Ziel gefunden, und die Suche kann beendet werden.
In unserer Implementation können, wie gesagt, mehrere Wege zum selben Knoten gleichzeitig in der Prioritätswarteschlange sein. Im Prinzip wäre es auch möglich, immer nur den besten zur Zeit bekannten Weg zu jedem Enknoten in der Prioritätswarteschlange zu halten - sobald ein besserer Kandidat gefunden wird, ersetzt er den bisherigen Kandidaten, anstatt zusätzlich eingefügt zu werden. Dies erfordert aber eine wesentlich kompliziertere Prioritätswarteschlange, die eine effiziente <tt>updatePriority</tt>-Funktion anbietet, ohne dass dadurch eine signifikante Beschleunigung erreicht wird. Deshalb verfolgen wir diesen Ansatz nicht.

==== Beispiel ====

under construction

[[Image:Bsp.jpg]]

==== Komplexität von Dijkstra ====

Zur Analyse der Komplexität nehmen wir an, dass der Graph V Knoten und E Kanten hat. Die Initialisierung der property map <tt>parents</tt> am Anfang der Funktion hat offensichtlich Komplexität O(V), weil Speicher für V Knoten allokiert wird. Der Code am Ende der Funktion, der aus der property map <tt>parents</tt> den Pfad extrahiert, hat ebenfalls die Komplexität O(V), weil der Pfad im ungünstigen Fall sämtliche Knoten des Graphen umfasst. Beides wird durch die Komplexität der Hauptschleife dominiert, zu deren Analyse wir den folgenden Codeausschnitt genauer anschauen wollen:

while len(q) > 0:
... # 1
if parents[node] is not None:
continue
parents[node] = predecessor
... # 2
Wir erkennen, dass der Codeabschnitt <tt># 2</tt> für jeden Knoten höchstens einmal erreicht werden kann: Da <tt>parents[node]</tt> beim ersten Durchlauf gesetzt wird, kann die <tt>if</tt>-Abfrage beim gleichen Knoten nie wieder <tt>False</tt> liefern, und das nachfolgende <tt>continue</tt> bewirkt, dass der Abschnitt <tt># 2</tt> dann übersprungen wird. Man sagt auch, dass jeder Knoten höchstens einmal expandiert wird, auch wenn er mehrmals im Heap war.

Der Codeabschnitt <tt># 2</tt> selbst enthält eine Schleife über alle ausgehenden Kanten des Knotens <tt>node</tt>. Im ungünstigsten Fall iterieren wir bei allen Knoten über alle ausgehenden Kanten, aber das sind gerade alle Kanten des Graphen je einmal in den beiden möglichen Richtungen. Die Funktion <tt>heappush</tt> wird sogar höchstens E Mal aufgerufen, weil eine Kante nur in den Heap eingefügt wird, wenn der kürzeste Weg der jeweiligen Endknotens noch nicht bekannt ist (siehe die <tt>if</tt>-Abfrage in der <tt>for</tt>-Schleife), und das ist nur ein einer Richtung möglich. Dies hat zwei Konsequenzen:
* Die Schleife <tt>while len(q) > 0:</tt> wird nur so oft ausgeführt, wie Elemente im Heap sind, also höchstens E Mal. Das gleiche gilt für den Codeabschnitt <tt># 1</tt>, der das <tt>heappop</tt> enthält.
* Die Operationen <tt>heappush</tt> und <tt>heappop</tt> haben logarithmische Komplexität in der Größe des Heaps, sind also in <math>O(\log\,E)</math>. In einfachen Graphen gilt aber <math>E = O(V^2)</math>, so dass sich die Komplexität der Heapoperationen vereinfacht zu <math>O(\log\,E)=O(\log\,V^2)=O(2\log\,V)=O(\log\,V)</math>.
Zusammenfassend gilt: <tt>heappush</tt> und <tt>heappop</tt> werden maximal E Mal aufgerufen und haben eine Komplexität in <math>O(\log\,V)</math>. Folglich hat der Algorithmus von Dijkstra die Komplexität:
:<math>O(E\,\log\,V)</math>

==== Vergleich mit Breitensuche und Tiefensuche ====

Der Dijkstra-Algorithmus ist eng mit der Breiten- und Tiefensuche verwandt - man kann diese Algorithmen aus dem Dijkstra-Algorithmus gewinnen, indem man einfach die Regel zur Festlegung der Prioritäten ändert. Anstelle der Länge des Pfades verwenden wir als Priorität den Wert eine Zählvariable <tt>count</tt>, die nach jeder Einfügung in den Heap (also nach jedem Aufruf von <tt>heappush</tt>) aktualisiert wird. Zählen wir die Variable hoch, haben die zuerst eingefügten Kanten die höchste Priorität, der Heap verhält sich also wie eine Queue (First in-First out), und wir erhalten eine Breitensuche. Zählen wir die Variable hingegen (von E beginnend) herunter, haben die zuletzt eingefügten Kanten höchste Priorität. Der Heap verhält sich dann wie ein Stack (Last in-First out), und wir bekommen Tiefensuche. Statt eines Heaps plus Zählvariable kann man jetzt natürlich direkt eine Queue bzw. einen Stack verwenden. Dadurch fällt der Aufwand <math>O(\log\,V)</math> für die Heapoperationen weg und wird durch die effizienten O(1)-Operationen von Queue bzw. Stack ersetzt. Damit erhalten wir für Breiten- und Tiefensuche die schon bekannte Komplexität O(E).

==== Korrektheit von Dijkstra ====

Wir beweisen mittels vollständiger Induktion die Schleifen-Invariante: Falls <tt>parents[node]</tt> gesetzt (also ungleich <tt>None</tt>) ist, dann liefert das Zurückverfolgen des Weges von <tt>node</tt> nach <tt>startnode</tt> den kürzesten Weg.
;Induktionsanfang: <tt>parents[startnode]</tt> ist als einziges gesetzt. Zurückverfolgen liefert den trivialen Weg <tt>[startnode]</tt>, der mit Länge 0 offensichtlich der kürzeste Pfad ist → die Bedingung ist erfüllt.
;Induktionsschritt: Wir zeigen mit einem indirektem Beweis, dass wir immer einen kürzesten Weg bekommen, wenn <tt>parents[node]</tt> gesetzt wird.
:Sei <math>S</math> = <tt>{v | parents[v] is not None}</tt> die Menge aller Knoten, von denen wir den kürzesten Weg schon kennen (Induktionsvoraussetzung), und <tt>node</tt> der Knoten, der sich gerade an der Spitze des Heaps befindet. Dann ist <tt>predecessor</tt> der Vorgänger von <tt>node</tt> im aktuellen Weg, und es muss <tt>predecessor</tt><math>\in S</math> gelten, weil die Nachbarn von <tt>predecessor</tt> (und damit auch der aktuelle <tt>node</tt>) erst in den Heap eingefügt werden, wenn der kürzeste Weg für <tt>predecessor</tt> gefunden wurde. Man beachte auch, dass alle Knoten, die noch nicht in <math>S</math> enthalten sind, weiter vom Start entfernt sind als alle Knoten in <math>S</math>, weil alle neu in den Heap eingefügten Wege länger sind als der kürzeste Weg des jeweiligen Vorgängers.
:Der indirekte Beweis nimmt jetzt an, dass der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> nicht der kürzeste Weg ist. Dann muss es einen anderen, kürzeren Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> geben. Für den Vorgänger <tt>x</tt> in diesem Weg unterscheiden wir zwei Fälle:
:* <tt>x</tt><math>\in S</math>: In diesem Fall ist die Länge des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> bereits bekannt, und dieser Weg ist in der Prioritätswarteschlange enthalten. Dann kann er aber nicht der kürzeste sein, denn an der Spitze der Warteschlange war nach Voraussetzung der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt>.
:* <tt>x</tt><math>\notin S</math>: Die Kosten des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> berechnen sich als <tt>Kosten(x → startnode) + weight[(x, node)]</tt>, und die Kosten des Weges <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> sind analog <tt>Kosten(predecessor → startnode) + weight[(predecessor, node)]</tt>. Aufgrund der Induktionsvoraussetzung gilt aber <tt>predecessor</tt><math>\in S</math>, und somit <tt>Kosten(predecessor → startnode) < Kosten(x → startnode)</tt>, weil <tt>x</tt> andernfalls vor <tt>predecessor</tt> an der Spitze des Heaps gewesen wäre, was mit der Annahme <tt>x</tt><math>\notin S</math> unverträglich ist. Damit der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> trotzdem der kürzeste Weg sein kann, müsste <tt>Kosten(x → startnode) < Kosten(node → startnode)</tt> gelten, denn durch die Kante <tt>(x, node)</tt> kommen ja noch Kosten hinzu. Das wäre aber nur möglich, wenn der Knoten <tt>x</tt> vor dem Knoten <tt>node</tt> an die Spitze des Heaps gelangt, im Widerspruch zur Annahme, dass <tt>node</tt> sich gerade an der Spitze des Heaps befindet. Somit kann die Behauptung, dass der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> der kürzeste Weg ist, nicht stimmen.
In beiden Fällen erhalten wir einen Widerspruch, und die Behauptung ist somit bewiesen. Da die Invariante insbesondere für den Weg zum Zielknoten <tt>destination</tt> erfüllt ist, folgt daraus auch die Korrektheit des Algorithmus von Dijkstra.

=== A*-Algorithmus - Wie kann man Dijkstra noch verbessern? ===

Eine wichtige Eigenschaft des Dijkstra-Algorithmus ist, dass neben dem kürzesten Weg vom Start zum Ziel auch die kürzesten Wege zu allen Knoten berechnet werden, die näher am Startknoten liegen als das Ziel, obwohl uns diese Wege gar nicht interessieren. Sucht man beispielsweise in einem Graphen mit den Straßenverbindungen in Deutschland den kürzesten Weg von Frankfurt (Main) nach Dresden (ca. 460 km), werden auch die kürzesten Wege von Frankfurt nach Köln (190 km), Dortmund (220 km) und Stuttgart (210 km) und vielen anderen Städten gefunden. Aufgrund der geographischen Lage dieser Städte ist eigentlich von vornherein klar, dass sie mit dem kürzesten Weg nach Dresden nicht das geringste zu tun haben. Anders sieht es mit Erfurt (260 km) oder Suhl (210 km) aus - diese Städte liegen zwischen Frankfurt und Dresden und kommen deshalb als Zwischenstationen des gesuchten Weges in Frage.

Damit Dijkstra korrekt funktioniert, würde es im Prinzip ausreichen, wenn man die kürzesten Wege nur für diejenigen Knoten ausrechnet, die auf dem kürzesten Weg vom Start zum Ziel liegen, denn nur diese Knoten braucht man, um den gesuchten Weg über die <tt>parent</tt>-Kette zurückzuverfolgen. Das Problem ist nur, dass man diese Knoten erst kennt, wenn der Algorithmus fertig durchgelaufen ist. Schließt man Knoten zu früh von der Betrachtung aus, kommt am Ende möglicherweise nicht der korrekte kürzeste Weg heraus.

Der A*-Algorithmus löst dieses Dilemma mit folgender Idee: Ändere die Prioritäten für den Heap so ab, dass unwichtige Knoten nur mit geringerer Wahscheinlichkeit expandiert werden, aber stelle gleichzeitig sicher, dass alle wichtigen Knoten (also diejenigen auf dem korrekten kürzesten Weg) auf jeden Fall expandiert werden. Es zeigt sich, dass man diese Idee umsetzen kann, wenn eine Schätzung für den Restweg (also für die noch verbleibende Entfernung von jedem Knoten zum Ziel) verfügbar ist:
rest = guess(neighbor, destination)
Diese Schätzung addiert man einfach zur wahren Länge des Weges <tt>startnode → node</tt> dazu, um die verbesserte Priorität zu erhalten:
priority = newLength + guess(neighbor, destination)
(Im originalen Dijkstra-Algorithmus wird als Priorität nur <tt>newLength</tt> allein verwendet. Man beachte, dass man <tt>newLength</tt> jetzt zusätzlich im Heap speichern muss, weil man es für die Expansion des Knotens später noch benötigt.)

Damit sicher gestellt ist, dass der A*-Algorithmus immer noch die korrekten kürzesten Wege findet, darf die Schätzung den wahren Restweg niemals überschätzen. Es muss immer gelten:
0 <= guess(node, destination) <= trueDistance(node, destination)
Damit gilt insbesondere <tt>guess(destination, destination) = trueDistance(destination, destination) = 0</tt>, an der Priorität des Knotens <tt>destination</tt> ändert sich also nichts. Die Prioritäten aller anderen Knoten veschlechtern sich hingegen, weil zur bisherigen Priorität noch atwas addiert wird. Für die wichtigen Knoten auf dem kürzesten Weg vom Start nach Ziel gilt jedoch, dass deren neue Priorität immer noch besser ist als die Priorität des Zielknotens selbst. Für diese Knoten gilt nämlich
falls node auf dem kürzesten Weg von startnode nach destination liegt:
trueDistance(startnode, node) + guess(node, destination) <= trueDistance(startnode, destination)
weil der Weg von Start nach <tt>node</tt> ein Teil des kürzesten Wegs von Start nach Ziel ist und die Restschätzung die wahre Entfernung immer unterschätzt. Diese Knoten werden deshalb stets vor dem Zielknoten expandiert, so dass wir die <tt>parent</tt>-Kette immer noch korrekt zurückverfolgen können. Für alle anderen Knoten gilt idealerweise, dass die neue Priorität schlechter ist als die Priorität von <tt>destination</tt>, so dass man sich diese irrelevanten Knotenexpansionen sparen kann.

Für das Beispiel eines Straßennetzwerks bietet sich als Schätzung die Luftlinienentfernung an, weil Straßen nie kürzer sein können als die Luftlinie. Damit erreicht man in der Praxis deutliche Einsparungen. Generell gilt, dass der A*-Algorithmus im typischen Fall schneller ist als der Algorithmus von Dijkstra, aber man kann immer pathologische Fälle konstruieren, wo die Änderung der Prioritäten nichts bringt. Die Komplexität des A*-Algorithmus im ungünstigen Fall ist deshalb nach wie vor <math>O(E\,\log\,V)</math>.

=='''Minimaler Spannbaum'''==
'''(engl.: minimum spanning tree; abgekürzt: MST)'''

[[Image:Minimum_spanning_tree.png‎ |thumb|200px|right|Ein minimal aufspannender Baum verbindet alle Punkte eines Graphen bei minimaler Kantenlänge ([http://de.wikipedia.org/wiki/Spannbaum Quelle])]]

:''gegeben'': gewichteter Graph G, zusammenhängend 
:''gesucht'': Untermenge <math>E'\subseteq E</math> der Kanten, so dass die Summe der Kantengewichte <math>\sum_{e\in E'} w_e</math> minimal und der entstehende Graph G' zusammenhängend ist. 
* G' definiert immer einen Baum, denn andernfalls könnte man eine Kante weglassen und dadurch die Summe <math>\sum_{e\in E'} w_e</math> verringern, ohne dass sich am Zusammenhang von G' etwas ändert. 
* Wenn der Graph G nicht zusammenhängend ist, kann man den Spannbaum für jede Zusammenhangskomponente getrennt ausrechnen. Man erhält dann einen aufspannenden Wald.
* Der MST ist ähnlich wie der Dijkstra-Algorithmus: Dort ist ein Pfad gesucht, bei dem die Summe der Gewichte über den Pfad minimal ist. Beim MST suchen wir eine Lösung, bei der die Summe der Gewichte über den ganzen Graphen minimal ist.
* Das Problem des MST ist nahe verwandt mit der Bestimmung der Zusammenhangskomponente, z.B. über den Tiefensuchbaum. Für die Zusammenhangskomponenten genügt allerdings ein beliebiger Baum, während beim MST ein minimaler Baum gesucht ist.

=== Anwendungen ===
==== Wie verbindet man n gegebene Punkte mit möglichst kurzen Straßen (Eisenbahnen, Drähten [bei Schaltungen] usw.)?====

 
{| class="wikitable" style="text-align:center" border="0" cellpadding="5" cellspacing="0"
|MST minimale Verbindung (Abb.1)
|MST = 2 (Länge = Kantengewicht)(Abb.2)
|- valign="top"
| [[Image:mst.png]]
| [[Image:Gleichseitigesdreieck.png]]
|}
*In der Praxis: Die Festlegung, dass man nur die gegebenen Punkte verwenden darf, ist eine ziemliche starke Einschränkung.

* Wenn man sich vorstellt, es sind drei Punkte gegeben, die als gleichseitiges Dreieck angeordnet sind, dann ist der MST (siehe Abb.2, schwarz gezeichnet) und hat die Länge 2. Man kann hier die Länge als Kantengewicht verwenden.

* Wenn es erlaubt ist zusätzliche Punkte einzufügen, dann kann man in der Mitte einen neuen Punkt setzen <math>\rightarrow</math> neuer MST (siehe Abb.2, orange gezeichnet). 

* Höhe = <math>\frac{1}{2}\sqrt{3}</math>, Schwerpunkt: teilt die Höhe des Dreiecks im Verhältnis 2:1; der Abstand von obersten Punkt bis zum neu eingeführten Punkt: <math>\frac{2}{3}h = \frac{\sqrt{3}}{3}</math>, davon insgesamt 3 Stück, damit (gilt für den MST in orange eingezeichnet): MST = <math>3\left(\frac{1}{3}\right) \sqrt{3} = \sqrt{3} \approx 1,7</math><br\>

* Damit ist der MST in orange kürzer als der schwarz gezeichnete MST. <br\>
<math>\Rightarrow</math>Folgerung: MST kann kürzer werden, wenn man einen Punkt dazu nimmt.
* Umgekehrt kann der MST auch kürzer werden, wenn man einen Punkt aus dem Graphen entfernt, aber wie das Beipiel des gleichseitigen Dreiecks zeigt, ist dies nicht immer der Fall.

[[Image: bahn.png|Bahnstrecke Verbindung (Abb.3)]]

* Methode der zusätzlichen Punkteinfügung hat man früher beim Bahnstreckenbau verwendet. Durch Einführung eines Knotenpunktes kann die Streckenlänge verkürzt werden (Dreiecksungleichung).

==== Bestimmung von Datenclustern ====

[[Image:cluster.png]]

* Daten (in der Abb.: Punkte) bilden Gruppen.

* In der Abbildung hat man 2 verschiedene Messungen gemacht (als x- und y-Achse aufgetragen), bspw. Größe und Gewicht von Personen. Für jede Person i wird ein Punkt an der Koordinate (Größei, Gewichti) gezeichnet (siehe Bild a). Dies bezeichnet man als ''Scatter Plot''. Wenn bestimmte Wertkombinationen häufiger auftreten als andere, bilden sich mitunter Gruppen aus, bspw. eine Gruppe für "klein und schwer" etc.

* Durch Verbinden der Punkte mittels eines MST (siehe Abbildung (b)) sieht man, dass es kurze (innerhalb der Gruppen) und lange Kanten (zwischen den Gruppen) gibt.

* Wenn man geschickt eine Schwelle einführt und alle Kanten löscht, die länger sind als die Schwelle, dann bekommt man als Zusammenhangskomponente die einzelnen Gruppen.

=== Algorithmen ===

Genau wie bei der Bestimmung von Zusammenhangskomponenten kann man auch das MST-Problem entweder nach dem Anlagerungsprinzip oder nach dem Verschmelzungsprinzip lösen (dazu gibt es noch weitere Möglichkeiten, z.B. den [http://de.wikipedia.org/wiki/Algorithmus_von_Bor%C5%AFvka Algorithmus von Boruvka]). Der Anlagerungsalgorithmus für MST wurde zuerst von Prim beschrieben und trägt deshalb seinen Namen, der Verschmelzungsalgorithmus stammt von Kruskal. Im Vergleich zu den Algorithmen für Zusammenhangskomponenten ändert sich im wesentlichen nur die Reihenfolge, in der die Kanten betrachtet werden: Eine Prioritätswarteschlange stellt jetzt sicher, dass am Ende wirklich der Baum mit den geringstmöglichen Kosten herauskommt.

====Algorithmus von Prim====
[http://de.wikipedia.org/wiki/Algorithmus_von_Prim Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]

Der Algorithmus von Prim geht nach dem Anlagerungsprinzip vor (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Tiefensuche|Zusammenhangskomponenten mit Tiefensuche]]): Starte an der Wurzel (ein willkürlich gewählter Knoten) und füge jeweils die günstigste Kante an die aktuellen Teillösung an, die keinen Zyklus verursacht. Die Sortierung der Kanten nach Priorität erfolgt analog zum Dijsktra-Algorithmus, aber die Definitionen, welche Kante die günstigste ist, unterscheiden sich. Die Konvention für die Bedeutung der Elemente des Heaps ist ebenfalls identisch: ein Tupel mit <tt>(priority, node, predecessor)</tt>. Die folgende Implementation verdeutlicht sehr schön die Ähnlichkeit der beiden Algorithmen. Das Ergebnis wird als property map <tt>parents</tt> zurückgegeben, in der für jeden Knoten sein Vorgänger im MST steht, wobei die Wurzel wie üblich auf sich selbst verweist.

import heapq

def prim(graph, weights): # Kantengewichte wie bei Dijkstra als property map
sum = 0.0 # wird später das Gewicht des Spannbaums sein
start = 0 # Knoten 0 wird willkürlich als Wurzel gewählt

parents = [None]*len(graph) # property map, die den resultierenden Baum kodiert
parents[start] = start # Wurzel zeigt auf sich selbst

heap = [] # Heap für die Kanten des Graphen
for neighbor in graph[start]: # besuche die Nachbarn von start
heapq.heappush(heap, (weights[(start, neighbor)], neighbor, start)) # und fülle Heap

while len(heap) > 0:
w, node, predecessor = heapq.heappop(heap) # hole billigste Kante aus dem Heap
if parents[node] is not None: # die Kante würde einen Zyklus verursachen
continue # => ignoriere diese Kante
parents[node] = predecessor # füge Kante in den MST ein
sum += w # und aktualisiere das Gesamtgewicht
for neighbor in graph[node]: # besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn kein Zyklus entsteht
heapq.heappush(heap, (weights[(node,neighbor)], neighbor, node)) # füge Kandidaten in Heap ein

return parents, sum # MST und Gesamtgewicht zurückgeben

====Algorithmus von Kruskal====
[http://de.wikipedia.org/wiki/Algorithmus_von_Kruskal Wikipedia (de)]
[http://en.wikipedia.org/wiki/Kruskal%27s_algorithm (en)]

Die alternative Vorgehensweise ist das Verschmelzungsprinzip (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]]), das der Algorithmus von Kruskal verwendet. Jeder Knoten wird zunächst als trivialer Baum mit nur einem Knoten betrachtet, und alle Kanten werden aufsteigend nach Gewicht sortiert. Dann wird die billigste noch nicht betrachtete Kante in den MST eingefügt, falls sich dadurch kein Zyklus bildet (erkennbar daran, dass die Endknoten in verschiedenen Zusammenhangskomponenten liegen, das heisst verschiedene Anker haben). Da der fertige Baum (V-1) Kanten haben muss, wird dies (V-1) Mal zutreffen. Andernfalls wird diese Kante ignoriert. Anders ausgedrückt: Der Algorithmus beginnt mit ''V'' Bäumen; in (''V''-1) Verschmelzungsschritten kombiniert er jeweils zwei Bäume (unter Verwendung der kürzesten möglichen Kante), bis nur noch ein Baum übrig bleibt. Der einzige Unterschied zum einfachen Union-Find besteht darin, dass die Kanten in aufsteigender Reihenfolge betrachtet werden müssen, was wir hier durch eine Prioritätswarteschlange realisieren. Der Algorithmus von J.Kruskal ist seit 1956 bekannt.

def kruskal(graph, weights):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker
results = [] # result wird später die Kanten des MST enthalten

heap = [] # Heap zum Sortieren der Kanten nach Gewicht
for edge, w in weights.iteritems(): # alle Kanten einfügen
heapq.heappush(heap, (w, edge))

while len(heap) > 0: # solange noch Kanten vorhanden sind
w, edge = heapq.heappop(heap) # billigste Kante aus dem Heap nehmen
a1 = findAnchor(anchors, edge[0]) # Anker von Startknoten der Kante
a2 = findAnchor(anchors, edge[1]) # ... und Endknoten bestimmen
if a1 != a2: # wenn die Knoten in verschiedenen Komponenten sind
anchors[a2] = a1 # Komponenten verschmelzen
result.append(edge) # ... und Kante in MST einfügen

return result # Kanten des MST zurückgeben

Die Funktion <tt>findAnchor()</tt> wurde im Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]] implementiert. Im Unterschied zum Algorithmus von Prim geben wir hier nicht die property map <tt>parents</tt> zurück, sondern einfach eine Liste der Kanten im MST.

Der Algorithmus eignet sich insbesondere für das Clusteringproblem, da der Schwellwert von vornerein als maximales Kantengewicht an den Algorithmus übergeben werden kann. Man hört mit dem Vereinigen auf, wenn das Gewicht der billigste Kante im Heap den Schwellwert überschreitet. Beim Algorithmus von Kruskal kann dann keine bessere Kante als der Schwellwert mehr kommen, da die Kanten vorher sortiert worden sind.

Komplexität: wie beim Dijkstra-Algorithmus, weil jede Kante genau einmal in den Heap kommt. Der Aufwand für das Sortieren ist somit <math>O\left(E\log E\right)</math>, was sich zu <math>O \left(E\,\log\,V\right)</math> reduziert, falls keine Mehrfachkanten vorhanden sind.

=> geeignet für Übungsaufgabe

====Verwendung einer BucketPriorityQueue====

Beide Algorithmen zur Bestimmung des minimalen Spannbaums benötigen eine Prioritätswarteschlange. Wenn die Kantengewichte ganze Zahlen im Bereich <tt>0...(m-1)</tt> sind, kann man die MST-Algorithmen deutlich beschleunigen, wenn man anstelle des Heaps eine [[Prioritätswarteschlangen#Prioritätssuche mit dem Bucket-Prinzip|<tt>BucketPriorityQueue</tt>]] verwendet. Die Operationen zum Einfügen einer Kante in die Queue und zum Entfernen der billibsten Kante aus der Queue beschleunigen sich dadurch auf O(1) statt O(log V) (außer wenn die Gewichte sehr ungünstig auf die Kanten verteilt sind). In der Praxis erreicht man durch diese Änderung typischerweise deutliche Verbesserungen. In der Bildverarbeitung können die Prioritäten beispielsweise die Wahrscheinlichkeit kodieren, dass zwei benachbarte Pixel zu verschiedenen Objekten gehören. Bildet man jetzt den MST, und bricht bei einer bestimmten Wahrscheinlichkeit ab, erhält man Cluster von Pixeln, die wahrscheinlich zum selben Objekt gehören (weil der MST ja die Kanten mit minimalem Gewicht bevorzugt, und kleine Gewichte bedeuten kleine Wahrscheinlichkeit, dass benachbarte Pixel von einander getrennt werden). Da man die Wahrscheinlichkeiten nur mit einer Genauigkeit von ca. 1% berechnen kann, reichen hiefür 100 bis 200 Quantisierungstufen aus. Durch Verwendung der schnellen <tt>BucketPriorityQueue</tt> kann man jetzt wesentlich größere Bilder in akzeptabler Zeit bearbeiten als dies mit einem Heap möglich wäre.

== Algorithmen für gerichtete Graphen ==

Zur Erinnerung: in einem gerichteten Graphen sind die Kanten (i → j) und (j → i) voneinander verschieden, und eventuell existiert nur eine der beiden Richtungen. Im allgemeinen unterscheidet sich der [[Graphen_und_Graphenalgorithmen#transposed_graph|transponierte Graph]] GT also vom Originalgraphen G. Beim Traversieren des Graphen und bei der Pfadsuche dürfen Kanten nur in passender Richtung verwendet werden. Bei gewichteten Graphen tritt häufig der Fall auf, dass zwar Kanten in beiden Richtungen existieren, diese aber unterschiedliche Gewichte haben.

Gerichtete Graphen ergeben sich in natürlicher Weise aus vielen Anwendungsproblemen:
* Routenplanung
** Bei Straßennetzwerken enstehen gerichtete Graphen, sobald es Einbahnstraßen gibt.
** Verwendet man Gewichte, um die erwarteten Fahrzeiten entlang einer Straße zu kodieren, gibt es Asymmetrien z.B. dann, wenn Straßen in einer Richtung bergab, in der anderen bergauf befahren werden. Hier existieren zwar Kanten in beiden Richtungen, sie haben aber unterschiedliche Gewichte. Ähnliches gilt für Flüge: Durch den Gegenwind des Jetstreams braucht man von Frankfurt nach New York länger als umgekehrt von New York nach Frankfurt.
* zeitliche oder kausale Abhängigkeiten
** Wenn die Knoten Ereignisse repräsentieren, von denen einige die Ursache von anderen sind, diese wiederum die Ursache der nächsten usw., verbindet man die Knoten zweckmäßig durch gerichtete Kanten, die die Kausalitätsbeziehungen kodieren. Handelt es sich um logische "wenn-dann"-Regeln, erhält man einen [[Graphen_und_Graphenalgorithmen#Anwendung:_Das_Erf.C3.BCllbarkeitsproblem_in_Implikationengraphen|Implikationengraph]] (siehe unten). Handelt es sich hingegen um Wahrscheinlichkeitsaussagen ("Wenn das Wetter schön ist, haben Studenten tendenziell gute Laune, wenn eine Prüfung bevorsteht eher schlechte usw."), erhält man ein [http://de.wikipedia.org/wiki/Bayessches_Netz Bayessches Netz].
** Wenn bestimmte Aufgaben erst begonnen werden können, nachdem andere Aufgaben erledigt sind, erhält man einen Abhängigkeitsgraphen. Beispielsweise dürfen Sie erst an der Klausur teilnehmen, nachdem Sie die Übungsaufgaben gelöst haben, und Sie dürfen erst die Abschlussarbeit beginnen, nachdem Sie bestimmte Prüfungen bestanden haben. Ein anderes schönes Beispiel liefern die Regeln für das [[Graphen_und_Graphenalgorithmen#Anwendung:_Abh.C3.A4ngigkeitsgraph|Ankleiden]] weiter unten.
** Gerichtete Graphen kodieren die Abhängigkeiten zwischen Programmbibliotheken. Beispielsweise benötigt das Pythonmodul <tt>json</tt> die internen Submodule <tt>json.encoder</tt> und <tt>json.decode</tt> sowie das externe Modul <tt>decimal</tt>. Die Submodule benötigen wiederum die externen Module <tt>re</tt> und <tt>sys</tt>, das Modul <tt>decimal</tt> braucht <tt>copy</tt> und <tt>collections</tt> usw.
** Das Internet kann als gerichteter Graph dargestellt werden, wobei die Webseiten die Knoten, und die Hyperlinks die Kanten sind.
* Sequence Alignment
** Eine gute Rechtschreibprüfung markiert nicht nur fehlerhafte Wörter, sondern macht auch plausible Vorschläge, was eigentlich gemeint gewesen sein könnte. Dazu muss sie das gegebene Wort mit den Wörtern eines Wörterbuchs vergleichen und die Ähnlichkeit bewerten. Ein analoges Problem ergibt sich, wenn man DNA Fragmente mit der Information in einer Genomdatenbank abgleichen will.

=== Anwendung: Sequence Alignment / Edit Distance ===

:gegeben: zwei Wörter (allgemein: beliebige Zeichenfolgen)
:gesucht: Wie kann man die Buchstaben am besten in Übereinstimmung bringen?

:Beispiel: WORTE – NORDEN

Zwei mögliche Alignments sind

WORTE. W.ORTE
NORDEN NORDEN

wobei der Punkt anzeigt, dass der untere Buchstabe keinen Partner hat, und rote Buchstaben oben und unten übereinstimmen. Jede Nicht-Übereinstimmung verursacht nun gewisse Kosten. Dabei unterscheiden wir zwei Fälle:
# Matche a[i] mit b[j]. Falls a[i] == b[j], ist das gut (rote Buchstaben), und es entstehen keine Kosten. Andernfalls entstehen Kosten U (schwarze Buchstaben).
# Wir überspringen a[i] oder b[j] (Buchstabe vs. Punkt). Dann entstehen Kosten V. (Manchmal unterscheidet man auch noch Kosten Va und Vb, wenn das Überspringen bei a und b unterschieldiche Signifikanz hat.)

Gesucht ist nun das Alignment mit minimalen Kosten

Diese Aufgabe kann man sehr schön als gerichteten Graphen darstellen: Wir definieren ein rechteckiges Gitter und schreiben das erste Wort über das Gitter und das andere links davon. Die Gitterpunkte verbinden wir mit Pfeilen (gerichteten Kanten), wobei ein Pfeil nach rechts bedeutet, dass wir beim oberen Wort einen Buchstaben überspringen, ein Pfeil nach unten, dass wir beim linken Wort einen Buchstaben überspringen, und ein diagonaler Pfeil, dass wir zwei Buchstaben matchen (und zwar die am Pfeilende). Die Farben der Pfeile symbolisieren die Kosten: rot für das Überspringen eines Buchstabens (Kosten V), blau für das Matchen, wenn die Buchstaben nicht übereinstimmen (Kosten U), und grün, wenn die Buchstaben übereinstimmen (keine Kosten).

[[Image:sequence-alignment.png|300px]]

Lösung:
:Suche den kürzesten Pfad vom Knoten "START" (oben links) nach unten rechts. Dazu kann der [[Graphen und Graphenalgorithmen#Algorithmus von Dijkstra|Algorithmus von Dijkstra]] verwendet werden, der auf gerichteten Graphen genauso funktioniert wie auf ungerichteten.

Für unser Beispiel von oben erhalten wir die folgenden Pfade:

[[Image:sequence-alignment-weg1.png|400px]]     [[Image:sequence-alignment-weg2.png|400px]]

Durch Addieren der Kosten entsprechend der Farben sieht man, dass der erste Weg die Kosten 2U+V und der zweite die Kosten 5U+V hat. Der erste Weg ist offensichtlich günstiger und entspricht dem besten Alignment.

=== Anwendung: Abhängigkeitsgraph ===

Beispiel: Wie erklärt man einem zerstreuten Professor, wie er sich morgens anziehen soll? Der folgende Graph enthält einen Knoten für jede Aktion, und eine Kante (i → j) bedeutet, dass die Aktion i vor der Aktion j abgeschlossen werden muss.

[[Image:anziehen-graph.png|600px]]

In derartigen Abhängigkeitsgraphen ist die wichtigste Frage immer, ob der Graph azyklisch ist. Wäre dies nämlich nicht der Fall, kann es keine Reihenfolge der Aktionen geben, die alle Abhängigkeiten erfüllt. Dies sieht man leicht, wenn man den einfachsten möglichen Zyklus betrachtet: es gibt sowohl eine Kante (i → j) als auch eine (j → i). Dann müsste man i vor j erledigen, aber ebenso j vor i, was offensichtlich unmöglich ist - das im Graph kodierte Problem ist dann unlösbar. Wegen ihrer Wichtigkeit wird für gerichtete azyklische Graphen oft die Abkürzung DAG (von directed acyclic graph) verwendet. Ein Graph ist genau dann ein DAG, wenn es eine topologische Sortierung gibt:
;topologische Sortierung: Zeichne die Knoten so auf eine Gerade, dass alle Kanten (Pfeile) nach rechts zeigen.
Arbeitet man die Aktionen nach einer (beliebigen) topologischen Sortierung ab, werden automatisch alle Abhängigkeiten eingehalten: Da alle Pfeile nach rechts zeigen, werden abhängige Aktionen immer später ausgeführt. Die topologische Sortierung ist im allgemeinen nicht eindeutig. Die folgende Skizze zeigt eine mögliche topologische Sortierung für das Anziehen:

[[Image:anziehen-topologische-sortierung.png|600px]]

Eine solche fest vorgegebene Reihenfolge ist für den zerstreuten Professor sicherlich eine größere Hilfe als der ursprüngliche Graph. Man erkennt, dass die Sortierung nicht eindeutig ist, beispielsweise bei der Uhr: Da für die Uhr keine Abhängigkeiten definiert sind, kann man diese Aktion an beliebiger Stelle einsortieren. Hier wurde willkürlich die letzte Stelle gewählt.

==== Zwei Algorithmen zum Finden der topologischen Sortierung ====

Die folgenden Algorithmen finden entweder eine topologische Sortierung, oder signalisieren, dass der Graph zyklisch ist.

===== Algorithmus 1 =====
# Suche einen Knoten mit Eingangsgrad 0 (ohne eingehende Pfeile) => in einem gerichteten azyklischen Graphen gibt es immer einen solchen Knoten
# Platziere diesen Knoten auf der Geraden (beliebig)
# Entferne den Knoten aus dem Graphen zusammen mit den ausgehenden Kanten
# Gehe zu 1., aber platziere in 2. immer rechts der Knoten, die schon auf der Geraden vorhanden sind.
: => Wenn noch Knoten übrig sind, aber keiner Eingangsgrad 0 hat, muss der Graph zyklisch sein.

[[Image:bild6.JPG]]

Beispiel für einen zyklischen Graphen: kein Knoten hat Eingangsgrad 0.

Um den Algorithmus zu implementieren, verwenden wir eine property map <tt>in_degree</tt>, die wir in einem ersten Durchlauf durch den Graphen füllen und die dann für jeden Knoten die Anzahl der eingehenden Kanten speichert. Dann gehen wir sukzessive zu allen Knoten mit <tt>in_degree == 0</tt>. Anstatt sie aber tatsächlich aus dem Graphen zu entfernen wie im obigen Pseudocode, dekrementieren wir nur den <tt>in_degree</tt> ihrer Nachbarn. Wird der <tt>in_degree</tt> eines Nachbarn dadurch 0, wird er ebenfalls in das Array der zu scannenden Knoten aufgenommen. Wenn der Graph azyklisch ist, enthält das Array am Ende alle Knoten des Graphen, und die Reihenfolge der Einfügungen definiert eine topologische Sortierung. Andernfalls ist das Array zu kurz, und wir signalisieren durch Zurückgeben von <tt>None</tt>, dass der Graph zyklisch ist:

def topological_sort(graph): # ein gerichteter Graph
in_degree = [0]*len(graph) # property map für den Eingangsgrad jeden Knotens
for node in xrange(len(graph)): # besuche alle Knoten
for neighbor in graph[node]: # ... und deren Nachbarn
in_degree[neighbor] += 1 # ... und inkrementiere den Eingangsgrad

result = [] # wird später die topologische Sortierung enthalten
for node in xrange(len(graph)):
if in_degree[node] == 0:
result.append(node) # füge alle Knoten mit Eingangsgrad 0 in result ein

k = 0
while k < len(result): # besuche alle Knoten mit Eingangsgrad 0
node = result[k]
k += 1
for neighbor in graph[node]: # besuche alle Nachbarn
in_degree[neighbor] -= 1 # entferne 'virtuell' die eingehende Kante
if in_degree[neighbor] == 0: # wenn neighbor jetzt Eingangsgrad 0 hat
result.append(neighbor) # ... füge ihn in result ein

if len(result) == len(graph): # wenn alle Knoten jetzt Eingangsgrad 0 haben
return result # ... ist result eine topologische Sortierung
else:
return None # andernfalls ist der Graph zyklisch

===== Algorithmus 2 =====
Der obige Algorithmus hat den Nachteil, dass er jeden Knoten zweimal expandiert. Man kann eine topologische Sortierung stattdessen auch mit Tiefensuche bestimmen. Es gilt nämlich der folgende
;Satz: Wird ein DAG mittels Tiefensuche traversiert, definiert die reverse post-order eine topologische Sortierung.
Zur Erinnerung: die post-order erhält man, indem man jeden Knoten ausgibt, nachdem die Rekursion zu allen seinen Nachbarn beendet ist, siehe unsere [[Graphen_und_Graphenalgorithmen#pre_and_post_order|Diskussion weiter oben]]. Die reverse post-order ist gerade die Umkehrung dieser Reihenfolge. Die folgende Implementation verwendet die rekursive Version der Tiefensuche, in der Praxis wird man meist die iterative Version mit Stack bevorzugen, weil bei großen Graphen die Aufruftiefe sehr groß werden kann:

def reverse_post_order(graph): # gerichteter Graph
result = [] # enthält später die reverse post-order
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node): # besuche node
if not visited[node]: # aber nur, wenn er noch nicht besucht wurde
visited[node] = True # markiere ihn als besucht
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor)
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order

for node in xrange(len(graph)): # besuche alle Knoten
visit(node)

result.reverse() # post-order => reverse post-order
return result

Die Tatsache, dass die reverse post-order tatsächlich eine topologische Sortierung liefert, leuchtet wahrscheinlich nicht unmittelbar ein. Bevor wir diese Tatsache beweisen. wollen wir uns anhand des Ankleidegraphen klar machen, dass die pre-order (die man intuitiv vielleicht eher wählen würde) keine topologische Sortierung ist. Startet man die Tiefensuche beim Knoten "Unterhemd", werden die Knoten in der Reihenfolge "Unterhemd", "Oberhemd", "Schlips", "Jackett", "Gürtel" gefunden. Da dann alle von "Unterhemd" erreichbaren Knoten erschöpft sind, startet man die Tiefensuche als nächstes bei "Unterhose" und erreicht von dort aus "Hose" und "Schuhe". Man erkennt sofort, dass diese Reihenfolge nicht funktioniert: "Hose" kommt nach "Gürtel", und "Jackett" kommt vor "Gürtel". Bei dieser Anordnung gibt es Pfeile nach links, die Abhängigkeitsbedingungen sind somit verletzt.

Damit die reverse post-order eine zulässige Sortierung sein kann, muss stets gelten, dass Knoten u vor Knoten v einsortiert wurde, wenn die Kante (u → v) existiert. Das ist aber äquivalent zur Forderung, dass in der ursprünglichen post-order (vor dem <tt>reverse</tt>) u hinter v stehen muss. Wir betrachten den <tt>visit</tt>-Aufruf, bei dem u expandiert wird. Gelangt man jetzt zu u's Nachbarn v, gibt es zwei Möglichkeiten: Wenn v bereits expandiert wurde, befindet es sich bereits im Array <tt>result</tt> und <tt>visit</tt> kehrt sofort zurück. Andernfalls wird v ebenfalls expandiert und demzufolge in <tt>result</tt> eingetragen, bevor der rekursive Aufruf <tt>visit(v)</tt> zurückkehrt. Knoten u wird aber erst in <tt>result</tt> eingefügt, nachdem alle rekursiven <tt>visit</tt>-Aufrufe seiner Nachbarn zurückgekehrt sind. In beiden Fällen steht u in der post-order wie gefordert hinter v, und daraus folgt die Behauptung.

Der obige Algorithmus liefert natürlich nur dann eine topologische Sortierung, wenn der Graph wirklich azyklisch ist (man kann ihn aber auch anwenden, um die reverse post-order für einen zyklischen Graphen zu bestimmen, siehe Abschnitt "[[Graphen_und_Graphenalgorithmen#Transitive Hülle und stark zusammenhängende Komponenten|Stark zusammenhängende Komponenten]]"). Dieser Fall tritt in der Praxis häufig auf, weil zyklische Graphen bei vielen Anwendungen gar nicht erst entstehen können. Weiß man allerdings nicht, ob der Graph azyklisch ist oder nicht, muss man einen zusätzlichen Test auf Zyklen in den Algorithmus einbauen.

Zyklische Graphen sind dadurch gekennzeichnet, dass es im obigen Beweis eine dritte Möglichkeit gibt: Während der Expansion von u wird rekursiv v expandiert, und es gibt eine Rückwärtskante (v → u). (Es spielt dabei keine Rolle, ob v von u aus direkt oder indirekt erreicht wurde.) Ein Zyklus wird also entdeckt, wenn die Tiefensuche zu u zurückkehrt, solange u noch aktiv ist, d.h. wenn die Rekursion von u aus gestartet und noch nicht beendet wurde. Dies kann man leicht feststellen, wenn man in der property map <tt>visited</tt> drei Werte zulässt: 0 für "noch nicht besucht", 1 für "aktiv" und 2 für "beendet". Wir signalisieren einen Zyklus, sobald <tt>visit</tt> für einen Knoten aufgerufen wird, der gerade aktiv ist:

def topological_sort_DFS(graph): # gerichteter Graph
result = [] # enthält später die topologische Sortierung

not_visited, active, finished = 0, 1, 2 # drei Zustände für visited
visited = [not_visited]*len(graph) # Flags für aktive und bereits besuchte Knoten

def visit(node): # besuche node (gibt "True" zurück, wenn Zyklus gefunden wurde)
if visited[node] == not_visited: # ... aber nur, wenn er noch nicht besucht wurde
visited[node] = active # markiere ihn als aktiv
for neighbor in graph[node]: # und besuche die Nachbarn
if visit(neighbor): # wenn rekursiv ein Zyklus gefunden wurde
return True # ... brechen wir ab und signalisieren den Zyklus
visited[node] = finished # Rekursion beendet, node ist nicht mehr aktiv
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order
return False # kein Zyklus gefunden
elif visited[node] == active: # Rekursion erreicht einen noch aktiven Knoten
return True # => Zyklus gefunden

for node in xrange(len(graph)): # besuche alle Knoten
if visit(node): # wenn Zyklus gefunden wurde
return None # ... gibt es keine topologische Sortierung

result.reverse() # post-order => reverse post-order (=topologische Sortierung)
return result

Man macht sich leicht klar, dass kein Zyklus vorliegt, wenn die Rekursion einen Knoten erreicht, der bereits auf <tt>finished</tt> gesetzt ist. Nehmen wir an, dass u gerade expandiert wird, und sein Nachbar v ist bereits <tt>finished</tt>. Wenn es einen Zyklus gäbe, müsste es einen Weg von v nach u geben. Dann wäre u aber bereits während der Expansion von v gefunden worden. Da v nicht mehr im Zustand <tt>active</tt> ist, muss die Expansion von v schon abgeschlossen gewesen sein, ohne dass u gefunden wurde. Folglich kann es keinen solchen Zyklus geben.

=== Transitive Hülle und stark zusammenhängende Komponenten ===

Auch bei gerichteten Graphen ist die Frage, welche Knoten miteinander zusammenhängen, von großem Interesse. Wir betrachten dazu wieder die Relation "Knoten v ist von Knoten u aus erreichbar", die anzeigt, ob es einen Weg von u nach v gibt oder nicht. In ungerichteten Graphen ist diese Relation immer symmetrisch, weil jeder Weg in beiden Richtungen benutzt werden kann. In gerichteten Graphen gilt dies nicht. Man muss hier zwei Arten von Zusammenhangskomponenten unterscheiden:
;Transitive Hülle: Die transitive Hülle eines Knotens u ist die Menge aller Knoten, die von u aus erreichbar sind:
:<math>T(u) = \{v\ |\ u \rightsquigarrow v\}</math>
;Stark zusammenhängende Komponenten: Die stark zusammenhängende Komponenten <math>C_i</math> eines gerichteten Graphen sind maximale Teilgraphen, so dass alle Knoten innerhalb einer Komponente von jedem anderen Knoten der selben Komponente aus erreichbar sind
:<math>u,v \in C_i\ \ \Leftrightarrow\ \ u \rightsquigarrow v \wedge v \rightsquigarrow u</math>
Die erste Definition betrachtet den Zusammenhang asymmetrisch, ohne Beachtung der Frage, ob es auch einen Rückweg von Knoten v nach u gibt, die zweite hingegen symmetrisch.

Die transitive Hülle benötigt man, wenn man Fragen der Erreichbarkeit besonders effizient beantworten will. Wir hatten bespielsweise oben erwähnt, dass das Python-Modul <tt>json</tt> direkt und indirekt von mehreren anderen Module abhängt, die vorher installiert werden müssen, damit <tt>json</tt> funktioniert. Bittet man den Systemadministrator, das <tt>json</tt>-Paket zu installieren, will er diese Abhängigkeiten wahrscheinlich nicht erst mühsam rekursiv heraussuchen, sondern er verlangt eine Liste aller Pakete, die installiert werden müssen. Dies ist gerade die transitive Hülle von <tt>json</tt> im Abhängigkeitsgraphen. Damit man diese nicht manuell bestimmen muss, verwendet man Installationsprogramme wie z.B. [http://pypi.python.org/pypi/pip/ pip], die die Abhängigkeiten automatisch herausfinden und installieren.

Bei der Bestimmung der transitiven Hülle modifiziert man den gegebenen Graphen, indem man jedesmal eine neue Kante (u → v) einfügt, wenn diese Kante noch nicht existiert, aber v von u aus erreichbar ist. Dies gelingt mit einer sehr einfachen Variation der Tiefensuche: Wir rufen <tt>visit(k)</tt> für jeden Knoten k auf, aber setzen die property map <tt>visited</tt> zuvor auf <tt>False</tt> zurück. Alle Knoten, die während der Rekursion erreicht werden, sind im modifizierten Graphen Nachbarn von k. Ein etwas effizienterer Ansatz ist der [http://de.wikipedia.org/wiki/Algorithmus_von_Floyd_und_Warshall Algorithmus von Floyd und Warshall].

Die Bestimmung der stark zusammenhängenden Komponenten ist etwas schwieriger. Es existieren eine ganze Reihe von effizienten Algorithmen (siehe [http://en.wikipedia.org/wiki/Strongly_connected_component WikiPedia]), deren einfachster der Algorithmus von Kosaraju ist:

gegeben: gerichteter Graph

# Bestimme die reverse post-order (mit der Funktion <tt>reverse_post_order</tt>)
# Bilde den transponierten Graphen <math>G^T</math> (mit der Funktion <tt>transposeGraph</tt>)
# Bestimme die Zusammenhangskomponenten von <math>G^T</math> mittels Tiefensuche, aber betrachte die Knoten dabei in der reverse post-order aus Schritt 1 (dies kann mit einer minimalen Modifikation der Funktion <tt>connectedComponents</tt> geschehen, indem man die Zeile <tt>for node in xrange(len(graph)):</tt> einfach nach <tt>for node in ordered:</tt> abändert, wobei <tt>ordered</tt> das Ergebnis der Funktion <tt>reverse_post_order</tt> ist, also ein Array, das die Knoten in der gewünschten Reihenfolge enthält).
Die Zusammenhangskomponenten, die man in Schritt 3 findet, sind gerade die stark zusammenhängenden Komponenten des Originalgraphen G. Die folgende Skizze zeigt diese in grün für den schwarz gezeichneten gerichteten Graphen.

[[Image:strongly-connected-components.png|400px]]

Zum Beweis der Korrektheit des Algorithmus von Kosaraju zeigen wir zwei Implikationen: 1. Wenn die Knoten u und v in der selben stark zusammenhängenden Komponente liegen, werden sie in Schritt 3 des Algorithmus auch der selben Komponente zugewiesen. 2. Wenn die Knoten u und v in Schritt 3 der selben Komponente zugewiesen wurden, müssen sie auch in der selben stark zusammenhängenden Komponente liegen.
# Knoten u und v gehören zur selben stark zusammenhängenden Komponente von G. Per Definition gilt, dass u von v aus erreichbar ist und umgekehrt. Dies muss auch im transponierten Graphen GT gelten (der Weg <math>u \rightsquigarrow v</math> wird jetzt zum Weg <math>v \rightsquigarrow u</math> und umgekehrt). Wird u bei der Tiefensuche in Schritt 3 vor v expandiert, ist v von u aus erreichbar und gehört somit zur selben Komponente. Das umgekehrte gilt, wenn v vor u expandiert wird. Daraus folgt die Behauptung 1.
# Knoten u und v werden in Schritt 3 der selben Komponente zugewiesen: Sei x der Anker dieser Komponente. Da u in der gleichen Komponente wie x liegt, muss es in GT einen Weg <math>x \rightsquigarrow u</math>, und demnach in G einen Weg <math>u \rightsquigarrow x</math> geben. Da x der Anker seiner Komponente ist, wissen wir aber auch, dass x in der reverse post-order vor u liegt (denn der Anker ist der Knoten, mit dem eine neue Komponente gestartet wird; er muss deshalb im Array <tt>ordered</tt> als erster Konten seiner Komponente gefunden worden sein). Wir unterscheiden jetzt im Schritt 1 des Algorithmus zwei Fälle:
## u wurde bei der Bestimmung der post-order vor x expandiert. Dann kann x nur dann in der reverse post-order vor u liegen (oder, einfacher ausgedrückt, x kann nur dann in der post-order hinter u liegen), wenn x im Graphen G nicht von u aus erreichbar war. Das ist aber unmöglich, weil wir ja schon wissen, dass es in G einen Weg <math>u \rightsquigarrow x</math> gibt.
## Folglich wurde u bei der Bestimmung der post-order nach x expandiert. Da x in der post-order hinter u liegt, muss u während der Expansion von x erreicht worden sein. Deshalb muss es in G auch einen Weg <math>x \rightsquigarrow u</math> geben.
#:Somit sind x und u in der selben stark zusammenhängenden Komponente. Die gleiche Überlegung gilt für x und v. Wegen der Transitivität der relation "ist erreichbar" folgt daraus, dass auch u und v in der selben Komponente liegen, also die Behauptung 2.

Die folgende Skizze illustriert, dass der Komponentengraph stets azyklisch ist. Den Komponentengraph erhält man, indem man für jede Komponente <math>C_i</math> einen Knoten erzeugt (grün), und die Knoten i und j durch eine gerichtete Kante verbindet (rot), wenn es im Originalgraphen eine Kante (u → v) mit <math>u \in C_i</math> und <math>v \in C_j</math> gibt. Es ist dann garantiert, dass es keine Kante in umgekehrter Richtung geben kann. Daraus folgt insbesondere, dass ein DAG nur triviale stark verbundene Komponenten haben kann, die aus einzelnen Knoten bestehen.

[[Image:strongly-connected-components-graph.png|400px]]

=== Anwendung: Das Erfüllbarkeitsproblem in Implikationengraphen ===

Das Erfüllbarkeitsproblem hat auf den ersten Blick nichts mit Graphen zu tun, denn es geht um Wahrheitswerte logischer Ausdrücke. Man kann logische Ausdrücke jedoch unter bestimmten Bedingungen in eine Graphendarstellung überführen und somit das ursprüngliche Problem auf ein Problem der Graphentheorie reduzieren, für das bereits ein Lösungsverfahren bekannt ist. In diesem Abschnitt wollen wir dies für die sogenannten Implikationengraphen zeigen, ein weiteres Beispiel findet sich im Kapitel [[NP-Vollständigkeit]].

==== Das Erfüllbarkeitsproblem ====

(vgl. [http://de.wikipedia.org/wiki/Erfüllbarkeitsproblem_der_Aussagenlogik WikiPedia (de)])

Das Erfüllbarkeitsproblem (SAT-Problem, von satisfiability) befasst sich mit logischen (oder Booleschen) Funktionen: Gegeben sei eine Menge <math>\{x_1, ... ,x_n\}</math> Boolscher Variablen (d.h., die <math>x_i</math> können nur die Werte True oder False annehmen), sowie eine logische Formel, in der die Variablen mit den üblichen logischen Operatoren
:<math>\neg\quad</math>: Negation ("nicht", in Python: <tt>not</tt>)
:<math>\vee\quad</math>: Disjunktion ("oder", in Python: <tt>or</tt>)
:<math>\wedge\quad</math>: Konjuktion ("und", in Python: <tt>and</tt>)
:<math>\rightarrow\quad</math>: Implikation ("wenn, dann", in Python nicht als Operator definiert)
:<math>\leftrightarrow\quad</math>: Äquivalenz ("genau dann, wenn", in Python: <tt>==</tt>)
:<math>\neq\quad</math>: exklusive Disjunktion ("entweder oder", in Python: <tt>!=</tt>)
verknüpft sind. Klammern definieren die Reihenfolge der Auswertung der Operationen. Für jede Belegung der Variablen <math>x_i</math> mit True oder False liefert die Formel den Wert der Funktion, der natürlich auch nur True oder False sein kann. Wenn Formel und Belegung gegeben sind, ist die Auswertung der Funktion ein sehr einfaches Problem: Man transformiert die Formel in einen Parse-Baum (siehe Übungsaufgabe "Taschenrechner) und wertet jeden Knoten mit Hilfe der üblichen Wertetabellen für logische Operatoren aus, die wir hier zur Erinnerung noch einmal angeben:
{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>a</math>
|width="70px"| <math>b</math>
|width="70px"| <math>a \vee b </math>
|width="70px"| <math>a \wedge b</math>
|width="70px"| <math>a \rightarrow b</math>
|width="70px"| <math>b \rightarrow a</math>
|width="70px"| <math>a \leftrightarrow b</math>
|width="70px"| <math>a \neq b</math>
|- align="center"
| 0 || 0 || 0 || 0 || 1 || 1 || 1 || 0
|- align="center"
| 0 || 1 || 1 || 0 || 1 || 0 || 0 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 0 || 1 || 0 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1 || 0
|}

Beim Erfüllbarkeitsproblem wird die Frage umgekehrt gestellt:
:Gegeben sei eine logische Funktion. Ist es möglich, dass die Funktion jemals den Wert True annimmt?
Das heisst, kann man die Variablen <math>x_i</math> so mit True oder False belegen, dass die Formel am Ende wahr ist? Im Prinzip kann man diese Frage durch erschöpfende Suche leicht beantworten, indem man die Funktion für alle <math>2^n</math> möglichen Belegungen einfach ausrechnet, aber das dauert für große n (ab ca. <math>n\ge 40</math>) viel zu lange. Erstaunlicherweise ist es aber noch niemanden gelungen, einen Algorithmus zu finden, der für beliebige logische Funktionen schneller funktioniert. Im Gegenteil wurde gezeigt, dass das Erfüllbarkeitsproblem [[NP-Vollständigkeit|NP-vollständig]] ist, so dass wahrscheinlich kein solcher Algorithmus existiert. Trotz (oder gerade wegen) seiner Schwierigkeit hat das Erfüllbarkeitsproblem viele Anwendungen gefunden, vor allem beim Testen logischer Schaltkreise ("Gibt es eine Belegung der Eingänge, so dass am Ausgang der verbotene Wert X entsteht?") und bei der Planerstellung in der künstlichen Intelligenz ("Kann man ausschließen, dass der generierte Plan Konflikte enthält?"). Es ist außerdem ein beliebtes Modellproblem für die Erforschung neuer Ideen und Algorithmen für schwierige Probleme.

==== Normalformen für logische Ausdrücke ====

Um die Beschreibung von Erfüllbarkeitsproblemen zu vereinfachen und zu vereinheitlichen, hat man verschiedene Normalformen für logische Ausdrücke eingeführt. Die wichtigste ist die Konjuktionen-Normalform (CNF - conjunctive normal form). Ein Ausdruck in Konjuktionen-Normalform ist eine UND-Verknüpfung von M Klauseln:
(CLAUSE1) <math>\wedge</math> (CLAUSE2) <math>\wedge</math> ... <math>\wedge</math> (CLAUSEM)
Jede Klausel ist wiederum ein logischer Ausdruck, der aber sehr einfach sein muss: Er darf nur noch k Variablen enthalten, die nur mit den Operatoren NICHT und ODER verknüpft werden dürfen, z.B.
CLAUSE1 := <math>x_1 \vee \neg x_3 \vee x_8</math>
Je nachdem, wie viele Variablen pro Klausel erlaubt sind, spricht man von k-CNF und entsprechend von einem k-SAT Problem. Es ist außerdem üblich, die Menge der Variablen und die Menge der negierten Variablen zusammen als Menge der Literale zu bezeichnen:
LITERALS := <math>\{x_1,...,x_n\} \cup \{\neg x_1,...,\neg x_n\}</math>
Formal definiert man die k-Konjunktionen-Normalform (k-CNF) am besten durch eine Grammatik in [http://de.wikipedia.org/wiki/Backus-Naur-Form Backus-Naur-Form]:
k_CNF ::= CLAUSE | k_CNF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\vee</math> ... <math>\vee</math> LITERAL) # genau k Literale pro Klausel
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
Beispiele:
* 3-CNF: <math>(x_1 \vee \neg x_2 \vee x_4) \wedge (x_2 \vee x_3 \vee \neg x_4) \wedge (\neg x_1 \vee x_4 \vee \neg x_5)</math>
* 2-CNF: <math>(x_1 \vee \neg x_2) \wedge (x_3 \vee x_4)</math> ...
Gesucht ist eine Belegung der Variablen mit True und False, so dass der Ausdruck den Wert True hat. Aus den Eigenschaften der UND- und ODER-Verknüpfungen folgt, dass ein Ausdruck in k-CNF genau dann True ist, wenn jede einzelne Klausel True ist. In jeder Klausel wiederum hat man k Chancen, die Klausel True zu machen, indem man eins der Literale zu True macht. Eventuell werden dadurch aber andere Klauseln wieder zu False, was die Aufgabe so schwierig macht. Die Bedeutung der k-CNF ergibt sich aus folgendem
;Satz: Jeder logische Ausdruck kann effizient nach 3-CNF transformiert werden, jedoch im allgemeinen nicht nach 2-CNF.
Man kann sich also auf Algorithmen für 3-SAT-Probleme konzentrieren, ohne dabei an Ausdrucksmächtigkeit zu verlieren.

Leider gilt der entsprechende Satz nicht für k=2: Ausdrücke in 2-CNF sind weit weniger mächtig, weil man in jeder Klausel nur noch zwei Wahlmöglichkeiten hat. Bestimmte logische Ausdrücke sind aber auch nach 2-CNF transformierbar, beispielsweise die Bedingung, dass zwei Literale u und v immer den entgegegesetzten Wert haben müssen. Dies ergibt ein Paar von ODER-Verknüpfungen:
:<math>(u \leftrightarrow \neg v) \equiv (u \vee \neg v) \wedge (\neg u \vee v)</math>
Die 2-CNF hat den Vorteil, dass es effiziente Algorithmen für das 2-SAT-Problem gibt, die wir jetzt kennenlernen wollen. Es zeigt sich, dass man Ausdrücke in 2-CNF als Graphen repräsentieren kann, indem man sie zunächst in die Implikationen-Normalform (INF für implicative normal form) überführt. Die Implikationen-Normalform besteht ebenfalls aus einer Menge von Klauseln, die durch UND-Operationen verknüpft sind, aber jede Klausel ist jetzt eine Implikation.
Die Grammatik der Implikationen-Normalform (INF) lautet:
INF ::= CLAUSE | INF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\rightarrow</math> LITERAL) # genau 2 Literale pro Implikation
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
und ein gültiger Ausdruck wäre z.B.
:<math>(x_1 \to x_2) \wedge (x_2 \to \neg x_3) \wedge (x_4 \to x_3)</math>
Die Umwandlung von 2-CNF nach INF beruht auf folgender Äquivalenz, die man sich aus der obigen Wahrheitstabelle leicht herleitet:
:<math>(x \vee y) \equiv (\neg x \rightarrow y) \equiv (\neg y \rightarrow x)</math>
Aus dieser Äquivalenz folgt der
;Satz: Ein Ausdruck in 2-CNF kann nach INF transformiert werden, indem man jede Klausel <math>(x \vee y)</math> durch das Klauselpaar <math>(\neg x \rightarrow y) \wedge (\neg y \rightarrow x)</math> ersetzt.
Man beachte, dass man für jede ODER-Klausel des ursprünglichen Ausdrucks zwei Implikationen (eine für jede Richtung des "wenn, dann") einfügen muss, um die Symmetrie des Problems zu erhalten.

==== Lösung des 2-SAT-Problems mit Implikationgraphen ====

Jeder Ausdruck in INF kann als gerichteter Graph dargestellt werden:
# Für jedes Literal wird ein Knoten in den Graphen eingefügt. Es gibt also für jede Variable und für ihre Negation jeweils einen Knoten, d.h. 2n Knoten insgesamt.
# Jede Implikation ist eine gerichtete Kante.
Implikationengraphen eignen sich, um Ursache-Folge-Beziehungen oder Konflikte zwischen Aktionen auszudrücken. Beispielsweise kann man die Klausel <math>(x \rightarrow \neg y)</math> als "wenn man x tut, darf man y nicht tun" interpretieren. Ein anderes schönes Beispiel findet sich in Übung 12.

Für die Implementation eines Implikationengraphen in Python empfiehlt es sich, die Knoten geschickt zu numerieren: Ist die Variable <math>x_i</math> dem Knoten i zugeordnet, so sollte die negierte Variable <math>\neg x_i</math> dem Knoten (i+n) zugeordnet werden. Zu jedem gegebenen Knoten i findet man dann den negierten Partnerknoten j leicht durch die Formel <tt>j = (i + n ) % (2*n)</tt>.

Die Aufgabe besteht jetzt darin, folgende Fragen zu beantworten:
# Ist der durch den Implikationengraphen gegebene Ausdruck erfüllbar?
# Finde eine geeignete Belegung der Variablen, wenn der Ausduck erfüllbar ist.
Die erste Frage beantwortet man leicht, indem man die stark zusammenhängenden Komponenten des Implikationengraphen bildet. Dann gilt folgender
;Satz: Seien u und v zwei Literale, die sich in der selben stark zusammenhängenden Komponente befinden. Dann müssen u und v stets den selben Wert haben, damit der Ausdruck erfüllt sein kann.
Die Korrektheit des Satzes folgt aus der Definition der stark zusammenhängenden Komponenten: Da u und v in der selben Komponente liegen, gibt es im Implikationengraphen einen Weg <math>u \rightsquigarrow v</math> sowie einen Weg <math>v \rightsquigarrow u</math>. Wegen der Transitivität der "wenn, dann" Relation kann man die Wege zu zwei Implikationen verkürzen, die gleichzeitig gelten müssen: <math>(u \rightarrow v) \wedge (v \rightarrow u)</math> (die Verkürzung von Wegen zu direkten Kanten entspricht gerade der Bildung der transitiven Hülle für die Knoten u und v). In der obigen Wertetabelle für logische Operatoren erkennt mann, dass dies äquivalent zur Bedingung <math>(u \leftrightarrow v)</math> ist. Dies ist aber gerade die Behauptung des Satzes.

Die Erfüllbarkeit des Ausdrucks ist nun ein einfacher Spezialfall dieses Satzes.
;Korrolar: Der gegebene Ausdruck ist genau dann erfüllbar, wenn die Literale <math>x_i</math> und <math>\neg x_i</math> sich für kein i in derselben stark zusammenhängenden Komponente befinden.
Setzt man nämlich im Satz <math>u = x_i</math> und <math>v = \neg x_i</math>, und beide Knoten befinden sich in der selben Komponente, dann müsste gelten <math>x_i \leftrightarrow\neg x_i</math>, was offensichtlich ein Widerspruch ist. Damit kann der Ausdruck nicht erfüllbar sein. Umgekehrt gilt, dass der Ausdruck immer erfüllbar ist, wenn <math>x_i</math> und <math>\neg x_i</math> stets in verschiedenen Komponenten liegen, weil der folgende Algorithmus von Aspvall, Plass und Tarjan in diesem Fall stets eine gültige Belegung aller Variablen liefert:
# Bestimme die stark zusammenhängenden Komponenten und bilde den Komponentengraphen. Ordne die Knoten des Komponentengraphen (also die stark zusammenhängenden Komponenten des Originalgraphen) in topologische Sortierung an.
# Betrachte die Komponenten in der topologischen Sortierung von hinten nach vorn und weise ihnen einen Wert nach folgenden Regeln zu (zur Erinnerung: alle Literale in der selben Komponente haben den selben Wert):
#* Wenn die Komponente noch nicht betrachtet wurde, setze ihren Wert auf True, und den Wert der komplementären Komponente (derjenigen, die die negierten Literale enthält) auf False.
#* Andernfalls, gehe zur nächsten Komponente weiter.
Der Algorithmus beruht auf der Symmetrie des Implikationengraphen: Weil Kanten immer paarweise <math>(\neg u \rightarrow v) \wedge (\neg v \rightarrow u)</math> eingefügt werden, ist der Graph schiefsymmetrisch (skew symmetric): die eine Hälfte das Graphen ist die transponierte Spiegelung der anderen Hälfte. Enthält eine stark zusammenhängende Komponente <math>C_i</math> die Knoten <tt>i1, i2, ...</tt>, so gibt es stets eine komplementäre Komponente <math>C_j = \neg C_i</math>, die die komplementären Knoten <tt>j1 = (i1 + n) % (2*n), j2 = (i2 + n) % (2*n), ...</tt> enthält. Gilt <math>C_i = \neg C_i</math> für irgendein i, so ist der Ausdruck nicht erfüllbar. Den Beweis für die Korrektheit des Algorithmus findet man im [http://www.math.ucsd.edu/~sbuss/CourseWeb/Math268_2007WS/2SAT.pdf Originalartikel]. Leider funktioniert dies nicht für k-SAT-Probleme mit <math>k > 2</math>.

Will man nur die Erfüllbarkeit prüfen, vereinfacht sich der Algorithmus zu:
# Bestimme die stark zusammenhängenden Komponenten.
# Teste für alle <tt>i = 0,...,n-1</tt>, dass Knoten <tt>i</tt> und Knoten <tt>(i+n)</tt> in unterschiedlichen Komponenten liegen.
Ist der Ausdruck erfüllbar, kann man eine gültige Belegung der Variablen jetzt mit dem randomisierten Algorithmus bestimmen, den wir im Kapitel [[Randomisierte Algorithmen]] behandeln.

== Weitere wichtige Graphenalgorithmen ==

Eins der wichtigsten Einsatzgebiete für Graphen ist die Optimierung, also die Suche nach der besten Lösung für ein gegebenes Problem:
* Das interval scheduling befasst sich damit, aus einer gegebenen Menge von Aufträgen die richtigen auszuwählen und sie geschickt auf die zur Verfügung stehenden Ressourcen aufzuteilen. Damit beschäftigen wir uns im Kapitel [[Greedy-Algorithmen und Dynamische Programmierung]].
* Beim Problem des Handlungsreisenden sucht man nach der kürzesten Rundreise, die alle gegebenen Städte genau einmal besucht. Dieses Problem behandeln wir im Kapitel [[NP-Vollständigkeit]].
* Viele weitere Anwendungen können wir leider in der Vorlesung nicht mehr behandeln, z.B.
** Algorithmen für den [http://en.wikipedia.org/wiki/Maximum_flow_problem maximalen Fluss] beantworten die Frage, wie man die Durchflussmenge durch ein Netzwerk (z.B. von Ölpipelines) maximiert.
** Beim [http://en.wikipedia.org/wiki/Assignment_problem Problem der optimalen Paarung] ("matching problem" oder "assignment problem") sucht man nach einer Teilmenge der Kanten (also nach einem Teilgraphen), so dass jeder Knoten in diesem Teilgraphen höchstens den Grad 1 hat. Im neuen Graphen gruppieren die Kanten also je zwei Knoten zu einem Paar, und die Paarung soll nach jeweils anwendungsspezifischen Kriterien optimal sein. Dies benötigt man z.B. bei der optimalen Zuordnung von Gruppen, etwas beim Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot) und in der Universität (Zuordnung Studenten - Übungsgruppen).
** In Statistik und maschinellem Lernen haben in den letzten Jahren die [http://en.wikipedia.org/wiki/Graphical_model graphischen Modelle] große Bedeutung erlangt.
* usw. usf.

[[Randomisierte Algorithmen|Nächstes Thema]]

Graphen und Graphenalgorithmen

2012-07-25T17:11:50Z

Ukoethe: /* Transitive Hülle und stark zusammenhängende Komponenten */

== Einführung zu Graphen ==

=== Motivation -- Königsberger Brückenproblem ===
Leonhard Euler [http://de.wikipedia.org/wiki/Leonhard_Euler] erfand den Graphen-Formalismus 1736, um eine scheinbar banale Frage zu beantworten: Ist es möglich, in Königsberg (siehe Stadtplan von 1809 und die schematische Darstellung) einen Spaziergang zu unternehmen, bei dem jede der 7 Brücken genau einmal überquert wird?

[[Image:Koenigsberg1809.png]] 
[[Image:Koenigsberg.jpg]]

Ein Graph abstrahiert von der Geometrie des Problems und repräsentiert nur die Topologie. Jeder Stadtteil von Königsberg ist ein Knoten des Graphen, jede Brücke eine Kante. Der zum Brückenproblem gehörende Graph sieht also so aus:

O
/| \
\| \
O---O
/| /
\| /
O

Der gesuchte Spaziergang würde existieren, wenn es maximal 2 Knoten gäbe, an denen sich eine ungerade Zahl von Kanten trifft. Die Frage muss für Königsberg also verneint werden, denn hier gibt es vier solche Knoten. Ein leicht modifiziertes Problem ist allerdings lösbar: Im obigen Stadtplan erkennt man eine Fähre, die die Stadtteile Kneiphof und Altstadt verbindet. Bezieht man dieselbe in den Spaziergang ein, ergibt sich folgender Graph, bei dem nur noch zwei Knoten mit ungerader Kantenzahl existieren:

--O
/ /| \
\ \| \
--O---O
/| /
\| /
O

Inzwischen haben Graphen eine riesige Zahl weiterer Anwendungen gefunden. Einige Beispiele:

* Landkarten:
** Knoten: Länder
** Kanten: gemeinsame Grenzen

* Logische Schaltkreise:
** Knoten: Gatter
** Kanten: Verbindungen

* Chemie (Summenformeln):
** Knoten: chemische Elemente
** Kanten: Bindungen

* Soziologie (StudiVZ)
** Soziogramm
*** Knoten: Personen
*** Kanten: Freund von ...

=== Definitionen ===

;Ungerichteter Graph: Ein ungerichteter Graph G = ( V, E ) besteht aus
:* einer endliche Menge V von Knoten (vertices)
:* einer endlichen Menge <math>E \subset V \times V</math> von Kanten (edges)
:Die Paare (u,v) und (v,u) gelten dabei als nur ''eine'' Kante (somit gilt die Symmetriebeziehung: (u,v) ∈ E => (v,u) ∈ E ). Die Anzahl der Kanten, die sich an einem Knoten treffen, wird als ''Grad'' (engl. ''degree'') dieses Knotens bezeichnet:
:::degree(v) = |{v' ∈ V | (v,v') ∈ E}|
:(Die Syntax |{...}| bezeichnet dabei die Mächtigkeit der angegebenen Menge, also die Anzahl der Elemente in der Menge.)

Der Graph des Königsberger Brückenproblems ist ungerichtet. Bezeichnet man die Knoten entsprechend des folgenden Bildes
c
/| \
\| \
b---d
/| /
\| /
a

gilt für die Knotengrade: <tt>degree(a) == degree(c) == degree(d) == 3</tt> und <tt>degree(b) == 5</tt>. Genauer muss man bei diesem Graphen von einem ''Multigraphen'' sprechen, weil es zwischen einigen Knotenpaaren (nämlich (a, b) sowie (b, c)) mehrere Kanten ("Mehrfachkanten") gibt. Wir werden in dieser Vorlesung nicht näher auf Multigraphen eingehen.

;Gerichteter Graph: Ein Graph heißt ''gerichtet'', wenn die Kanten (u,v) und (v,u) unterschieden werden. Die Kante (u,v) ∈ E wird nun als Kante von u nach v (aber nicht umgekehrt) interpretiert. Entsprechend unterscheidet man jetzt den ''eingehenden'' und den ''ausgehenden Grad'' jedes Knotens:
:*out_degree(v) = |{v' ∈ V | (v,v') ∈ E}| 
:*in_degree(v) = |{v' ∈ V| (v',v) ∈ E}|

Das folgende Bild zeigt einen gerichteten Graphen. Hier gilt <tt>out_degree(1) == out_degree(3) == in_degree(2) == in_degree(4) == 2</tt> und
<tt>in_degree(1) == in_degree(3) == out_degree(2) == out_degree(4) == 0</tt>:

[[Image:digraph.png|gerichteter Graph]]

 

;Vollständiger Graph: Ein vollständiger Graph ist ein ungerichteter Graph, bei dem jeder Knoten mit allen anderen Knoten verbunden ist.
:::<math>E = \{ (v,w) | v \in V, w \in V, v \ne w \}</math>
:Ein vollständiger Graph mit |V| Knoten hat <math>|E| = \frac{|V|(|V|-1)}{2}</math> Kanten.

Die folgenden Abbildungen zeigen die vollständigen Graphen mit einem bis fünf Knoten (auch als K1 bis K5 bezeichnet).

{| border="0" cellspacing="0" cellpadding="0" style="margin: 1em auto 1em auto"
|-
| [[Image:k1.png|frame|k1]]
| [[Image:k2.png|frame|k2]]
| [[Image:k3.png|frame|k3]]
|-
| [[Image:k4.png|frame|k4]]
| [[Image:k5.png|frame|k5]]
|
|}

''Rätsel'' 
Auf einer Party sind Leute. Alle stoßen miteinander an. Es hat 78 mal "Pling" gemacht.
Wieviele Leute waren da? Antwort: Jede Person ist ein Knoten des Graphen, jedes Antoßen eine Kante.
Da alle miteinander angestoßen haben, handelt es sich um einen vollständigen Graphen. Mit
|V|(|V|-1)/2 = 78 folgt, dass es 13 Personen waren.

 

;Gewichteter Graph: Ein Graph heißt ''gewichtet'', wenn jeder Kante eine reelle Zahl zugeordnet ist. Bei vielen Anwendungen beschränkt man sich auch auf nichtnegative reelle Gewichte. In einem gerichteten Graphen können die Gewichte der Kanten (u,v) und (v,u) unterschiedlich sein.

Die Gewichte kodieren Eigenschaften der Kanten, die für die jeweilige Anwendung interessant sind. Bei der Berechnung des maximalen Flusses in einem Netzwerk sind die Gewichte z.B. die Durchflusskapazitäten jeder Kante, bei der Suche nach kürzesten Weges kodieren Sie den Abstand zwischen den Endknoten der Kante, bei Währungsnetzwerken (jeder Knoten ist eine Währung) geben sie die Wechselkurse an, usw..

 

;Teilgraphen: Ein Graph G' = (V',E') ist ein Teilgraph eines Graphen G, wenn gilt:
:* V' &sube; V
:* E' ⊂ E
:Er heißt ''(auf)spannender Teilgraph'', wenn gilt:
:* V' = V
:Er heißt ''induzierter Teilgraph'', wenn gilt:
:* e = (u,v) ∈ E' ⊂ E ⇔ u ∈ V' und v ∈ V'
:Den von V' induzierten Teilgraphen erhält man also, indem man aus G alle Knoten löscht, die nicht in V' sind, sowie alle Kanten (und nur diese Kanten), die einen der gelöschten Knoten als Endknoten haben.

 

;Wege, Pfade, Zyklen, Kreise, Erreichbarkeit: Sei G = (V,E) ein Graph (ungerichtet oder gerichteter) Graph. Dann gilt folgende rekursive Definition:
:* Für v ∈ V ist (v) ein Weg der Länge 0 in G
:* Falls <math>(v_0, v_1, ..., v_{n-1})</math> ein Weg ist, und eine Kante <math>(v_{n-1}, v_n)\in E</math> existiert, dann ist auch <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ein Weg, und er hat die Länge n.
: Ein Weg ist also eine nichtleere Folge von Knoten, so dass aufeinander folgende Knoten stets durch eine Kante verbunden sind. Die Länge des Weges entspricht der Anzahl der Kanten im Weg (= Anzahl der Knoten - 1).
:* Ein ''Pfad'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, bei dem alle Knoten vi verschieden sind.
:* ''Ein Zyklus'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, der zum Ausgangspunkt zurückkehrt, wenn also v0 = vn gilt.
:* Ein ''Kreis'' ist ein Zyklus ohne Überkreuzungen. Das heisst, es gilt v0 = vn und <math>(v_0, v_1, ..., v_{n-1})</math> ist ein Pfad.
:* Ein Knoten w ∈ V ist von einem anderen Knoten v ∈ V aus ''erreichbar'' genau dann, wenn ein Weg (v, ..., w) existiert. Wir schreiben dann <math>v \rightsquigarrow w</math>.
In einem ungerichteten Graph ist die Erreichbarkeits-Relation stets symmetrisch, das heisst aus <math>v \rightsquigarrow w</math> folgt <math>w \rightsquigarrow v</math>. In einem gerichteten Graphen ist dies im allgemeinen nicht der Fall.

Bestimmte Wege haben spezielle Namen

;Eulerweg: Ein Eulerweg ist ein Weg, der alle '''Kanten''' genau einmal enthält.

Die eingangs erwähnte Frage des Königsberger Brückenproblems ist equivalent zu der Frage, ob der dazugehörige Graph einen Eulerweg besitzt (daher der Name). Ein anderes bekanntes Beispiel ist das "Haus vom Nikolaus": Wenn man diesen Graphen in üblicher Weise in einem Zug zeichnet, erhält man gerade den Eulerweg.

O
/ \
O----O
| \/ |
| /\ | "Das Haus vom Nikolaus": Alle ''Kanten'' werden nur ''einmal'' passiert
O----O

;Hamiltonweg: Ein Hamiltonweg ist ein Weg, der alle '''Knoten''' genau einmal enthält. Das "Haus vom Nikolaus" besitzt auch einen Hamiltonweg:

O
/
O----O
/
/ Alle ''Knoten'' werden nur ''einmal'' passiert
O----O

;Hamiltonkreis: Ein Hamiltonkreis ist ein Kreis, der alle '''Knoten''' genau einmal enthält. Auch ein solches Gebilde ist im Haus von Nilolaus enthalten:

O
/ \
O O
| | v0 = vn
| | vi != vj Für Alle i,j i !=j; i,j >0; i,j < n
O----O

Die folgende Skizze zeigt hingegen einen Zyklus: Der Knoten rechts unten sowie die untere Kante sind zweimal enthalten (die Kante einmal von links nach rechts und einmal von rechts nach links):

O
/ \
O O
\ |
\ | Zyklus
O====O

 

;Zusammenhang, Zusammenhangskomponenten: Ein ungerichteter Graph G heißt ''zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math>
:Ein gerichteter Graph G ist zusammenhängend, wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''oder''' <math>w \rightsquigarrow v</math>.
:Er ist ''stark zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''und''' <math>w \rightsquigarrow v</math>.
:Entsprechende Definitionen gelten für Teilgraphen G'. Ein Teilgraph G' heisst ''Zusammenhangskomponente'' von G, wenn er ein ''maximaler'' zusammenhängender Teilgraph ist, d.h. wenn G' zusammenhängend ist, und man keine Knoten und Kanten aus G mehr zu G' hinzufügen kann, so dass G' immer noch zusammenhängend bleibt. Entsprechend definiert man ''starke Zusammenhangskomponenten'' in einem gerichteten Graphen.

 

;Planarer Graph, ebener Graph: Ein Graph heißt ''planar'', wenn er so in einer Ebene gezeichnet werden ''kann'', dass sich die Kanten nicht schneiden (außer an den Knoten). Ein Graph heißt ''eben'', wenn er tatsächlich so gezeichnet ''ist'', dass sich die Kanten nicht schneiden. Die Einbettung in die Ebene ist im allgemeinen nicht eindeutig.

'''Beispiele:'''

Der folgende Graph ist planar und eben:

O
/|\
/ O \
/ / \ \
O O

Das "Haus vom Nikolaus" ist ebenfalls planar, wird aber üblicherweise nicht als ebener Graph gezeichnet, weil sich die Diagonalen auf der Wand überkreuzen:

O
/ \
O----O
| \/ |
| /\ |
O----O

Eine ebene Einbettung dieses Graphen wird erreicht, wenn man eine der Diagonalen ausserhalb des Hauses zeichnet. Der Graph (also die Menge der Knoten und Kanten) ändert sich dadurch nicht.

O
/ \
--O----O
/ | / |
| | / |
| O----O Das "Haus vom Nikolaus" als ebener Graph gezeichnet.
\ /
-----

Eine alternative Einbettung erhalten wir, wenn wir die andere Diagonale außerhalb des Hauses zeichnen:

O
/ \
O----O--|
| \ | |
| \ | |
O----O | Alternative Einbettung des "Haus vom Nikolaus".
| |
|-------|

Jede Einbettung eines planaren Graphen (also jeder ebene Graph) definiert eine eindeutige Menge von ''Regionen'':

|----O @
| /@ \
| O----O
| |@ / |
| | / @|
| O----O @ entspricht jeweils einer ''Region''. Auch ausserhalb der Figur ist eine Region (die sogenannte ''unendliche'' Region).
|@ |
|-------|

Der vollständige Graph K5 ist kein planarer Graph, da sich zwangsweise Kanten schneiden, wenn man diesen Graphen in der Ebene zeichnet.

 
;Dualer Graph: Jeder ebene Graph G = (V, E) hat einen ''dualen Graphen'' D = (VD, ED), dessen Knoten und Kanten wie folgt definiert sind:
:* VD enthält einen Knoten für jede Region des Graphen G
:* Für jede Kante e ∈ E gibt es eine duale Kante eD ∈ ED, die die an e angrenzenden Regionen (genauer: die entsprechenden Knoten in D) verbindet.

Die folgende Abbildung zeigt einen Graphen (grau) und seinen dualen Graphen (schwarz). Die Knoten des dualen Graphen sind mit Zahlen gekennzeichnet und entsprechen den Regionen des Originalgraphen. Jeder (grauen) Kante des Originalgraphen entspricht eine (schwarze) Kante des dualen Graphen.

 
[[Image:dual-graphs.png]]
 

Für duale Graphen gilt: Wenn der Originalgraph zusammenhängend ist, enthält jede Region des dualen Graphen genau einen Knoten des Originalgraphen. Deshalb ist der duale Graph des dualen Graphen wieder der Originalgraph. Bei nicht-zusammenhängenden Graphen gilt dies nicht (vgl. das Fenster bei obigem Bild). In diesem Fall hat der duale Graph mehrere mögliche Einbettungen in die Ebene (man kann z.B. die rechte Kante zwischen Knoten 2 und 4 auch links vom Fenster einzeichnen), und man erhält nicht notwendigerweise den Originalgraphen, wenn man den dualen Graphen des dualen berechnet.

;Baum: Ein ''Baum'' ist ein zusammenhängender, kreisfreier Graph.

Beispiel: Binärer Suchbaum

;Spannbaum: Ein ''Spannbaum'' eines zusammenhängenden Graphen G ist ein zusammenhängender, kreisfreier Teilgraph von G, der alle Knoten von G enthält

Beispiel: Spannbaum für das "Haus des Nikolaus"

O
/
O O
| /
| /
O----O

Der Spannbaum eines Graphen mit |V| Knoten hat stets |V| - 1 Kanten.

;Wald: Ein ''Wald'' ist ein unzusammenhängender, kreisfreier Graph.
: Jede Zusammenhangskomponente eines Waldes ist ein Baum.

=== Repräsentation von Graphen ===

Sei G = ( V, E ) gegeben und liege V in einer linearen Sortierung vor. 
:::<math>V = \{ v_1, ...., v_n \}</math>

;Adjazenzmatrix: Ein Graph kann durch eine Adjazenzmatrix repräsentiert werden, die soviele Zeilen und Spalten enthält, wie der Graph Knoten hat. Die Elemente der Adjazenzmatrix sind "1", falls eine Kante zwischen den zugehörigen Knoten existiert:
:::<math>\mathrm{\bold A} = a_{ij} =
\begin{cases}
1 & \mathrm{falls}\quad (v_i, v_j) \in E \\
0 & \mathrm{sonst}
\end{cases}
</math>
:Die Indizes der Matrix entsprechen also den Indizes der Knoten gemäß der gegebenen Sortierung. Im Falle eines ungerichteten Graphen ist die Adjazenzmatrix stets symmetrisch (d.h. es gilt <math>a_{ij}=a_{ji}</math>), bei einem gerichteten Graphen ist sie im allgemeinen unsymmetrisch.

Beispiel für einen ungerichteten Graphen:

v = { a,b,c,d } b d
| \ / |
| \/ |
| /\ |
| / \ |
a c

a b c d
-----------
(0 1 0 1) |a
A = (1 0 1 0) |b
(0 1 0 1) |c
(1 0 1 0) |d

Die Adjazenzmatrixdarstellung eignet sich besonders für dichte Graphen (d.h. wenn die Zahl der Kanten in O(|V|2) ist.

;Adjazenzlisten: In der Adjazenzlistendarstellung wird der Graph als Liste von Knoten repräsentiert, die für jeden Knoten einen Eintrag enthält. Der Eintrag für jeden Knoten ist wiederum eine Liste, die die Nachbarknoten dieses Knotens enthält:
:* graph = {adjazencyList(v) | v ∈ V}
:* adjazencyList(v) = {v' ∈ V | (v, v') ∈ E}

In Python implementieren wir Adjazenzlisten zweckmäßig als Array von Arrays:

graph = [[...],[...],...,[...]]
Adjazenzliste für Knoten => 0 1 n

Wenn wir bei dem Graphen oben die Knoten wie bei der Adjazenzmatrix indizieren (also <tt>a => 0</tt>, <tt>b => 1</tt>, <tt>c => 2</tt>, <tt>d => 3</tt>), erhalten wir die Adjazenzlistendarstellung:

graph = [[b, d], [a, c],[b, d], [a, c]]

Auf die Nachbarknoten eines durch seinen Index <tt>node</tt> gegebenen Knotens können wir also wie folgt zugreifen:

for neighbors in graph[node]:
... # do something with neighbor

Die Adjazenzlistendarstellung ist effizienter, wenn der Graph nicht dicht ist, so dass viele Einträge der Adjazenzmatrix Null wären. In der Vorlesung werden wir nur diese Darstellung verwenden.

;<div id="transposed_graph">Transponierter Graph</div>: Den ''transponierten Graphen'' GT eines gerichteten Graphen G erhält man, wenn man alle Kantenrichtungen umkehrt.

Bei ungerichteten Graphen hat die Transposition offensichtlich keinen Effekt, weil alle Kanten bereits in beiden Richtungen vorhanden sind, so dass GT = G gilt. Bei gerichteten Graphen ist die Transposition einfach, wenn der Graph als Adjazenzmatrix implementiert ist, weil man einfach die transponierte Adjazenzmatrix verwenden muss (beachte, dass sich die Reihenfolge der Indizes umkehrt):
:::AT = aji
Ist der Graph hingegen durch eine Adjazenzliste repräsentiert, muss etwas mehr Aufwand getrieben werden:

def transposeGraph(graph):
gt = [[] for k in graph] # zunächst leere Adjazenzlisten von GT
for node in range(len(graph)):
for neighbor in graph[node]:
gt[neighbor].append(node) # füge die umgekehrte Kante in GT ein
return gt

== Durchlaufen von Graphen (Graph Traversal) ==

Wir betrachten zunächst ungerichtete Graphen mit V Knoten und E Kanten. Eine grundlegende Aufgabe in diesen Graphen besteht darin, alle Knoten in einer bestimmten Reihenfolge genau einmal zu besuchen. Hierbei darf man sich von einem gegebenen Startknoten aus nur entlang der Kanten des Graphen bewegen. Die beim Traversieren benutzen Kanten bilden einen Baum, dessen Wurzel der Startknoten ist und der den gesamten Graphen aufspannt, falls der Graph zusammenhängend ist. (Beweis: Da jeder Knoten nur einmal besucht wird, gibt es für jeden besuchten Knoten [mit Ausnahme des Startknotens] genau eine eingehende Kante. Ist der Graph zusammenhängend, wird jeder Knoten tatsächlich erreicht und es gibt genau (V-1) Kanten, exakt soviele wie für einen Baum mit V Knoten notwendig sind.) Ist der Graph nicht zusammenhängend, wird jeder zusammenhängende Teilgraph (jede Zusammenhangskomponente) getrennt traversiert, und man erhält einen sogenannten Wald mit einem Baum pro Zusammenhangskomponente. Die beiden grundlegenden Traversierungsmethoden Tiefensuche und Breitensuche werden im folgenden vorgestellt.

=== Tiefensuche in Graphen (Depth First Search, DFS) ===

Die Idee der Tiefensuche besteht darin, jeden besuchten Knoten sofort über die erste Kante wieder zu verlassen, die zu einem noch nicht besuchten Knoten führt. Man findet dadurch schnell einen möglichst langen Pfad durch den Graphen, und der Traversierungs-Baum wird zunächst in die Tiefe verfolgt, daher der Name des Verfahrens. Hat ein Knoten keine unbesuchten Nachbarknoten mehr, geht man im Baum zurück (sogenanntes back tracking), bis man einen Knoten findet, der noch eine unbesuchte Nachbarn besitzt, und traversiert diese nach dem gleichen Muster. Gibt es gar keine unbesuchten Knoten mehr, kehrt die Suche zum Startknoten zurück und endet dort.

WDie folgende rekursive Implementation der Tiefensuche erwartet den Graphen in Adjazenzlistendarstellung und beginnt die Suche beim Knoten <tt>startnode</tt>. Die Information, ob ein Knoten bereits besucht wurde, wird im Array <tt>visited</tt> gespeichert. Ein solches Array, das zusätzliche Informationen über die Knoten des Graphen bereitstellt, wir häufig property map genannt.

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
print node # Ausgabe der Knotennummer - pre-order
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)

visit(startnode)

[[Image:Tiefens.jpg]]

Ausgabe für den Graphen in diesem Bild (es handelt sich um einen ungerichteten Graphen, die Pfeile symbolisieren nur die Suchrichtung beim Traversal):

>>> dfs(graph, 1)
1
2
4
3
6
7
5

<div id="pre_and_post_order">In dieser Version des Algorithmus werden die Knotennummern ausgegeben, bevor die Nachbarknoten besucht werden. Man bezeichnet die resultierende Sortierung der Knoten als pre-order oder als discovery order. Alternativ kann man die Knotennummern erst ausgeben, nachdem alle Nachbarn besucht wurden, also auf dem Rückweg der Rekursion. In diesem Fall spricht man von post-order oder finishing order:</div>

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)
print node # Ausgabe der Knotennummer - post-order

visit(startnode)

Es ergibt sich jetzt die Ausgabe:

>>> dfs(graph, 1)
6
7
3
4
5
2
1

In realem Code ersetzt man die print-Ausgaben natürlich durch anwendungsspezifische Aktionen und Berechnungen. Einige Anwendungen sind uns im Kapitel [[Suchen]] bereits begegnet.
; Anwendungen der Pre-Order Traversierung
* Kopieren eines Graphen: kopiere zuerst den besuchten Knoten, dann seine Nachbarn und die dazugehörigen Kanten (sowie die Kanten zu bereits besuchten Knoten, die in der Grundversion der Tiefensuche ignoriert werden).
* Bestimmen der Zusammenhangskomponenten eines Graphen (siehe unten)
* In einem Zeichenprogramm: fülle eine Region mit einer Farbe ("flood fill"). Dabei ist jedes Pixel ein Knoten des Graphen und wird mit seinen 4 Nachbarpixceln verbunden. Die Tiefensuche startet bei der Mausposition und endet am Rand des betreffendcen Gebiets.
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von der Wurzel
* Falls der Graph ein Parse-Baum ist, wobei innere Knoten Funktionsaufrufe, Kindknoten Funktionsargumente, und Blattknoten Werte repräsentieren: drucke den zugehörigen Ausdruck aus (also immer zuerst den Funktionsnamen, dann die Argumente, die wiederum geschachtelte Funktionsaufrufe sein können).
; Anwendungen der Post-Order Traversierung
* Löschen eines Graphen: lösche zuerst die Nachbarn, dann den Knoten selbst
* Bestimmen einer topologischen Sortierung eines azyklischen gerichteten Graphens (siehe unten)
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von den Blättern (also die Tiefe des Baumes, siehe Übung 5)
* Falls der Graph ein Parse-Baum ist: führe die zugehörige Berechnung aus (d.h. berechne zuerst die geschachtelten inneren Funktionen, dann mit diesen Ergebnissen die nächst äußeren usw., siehe Übung 5).
; Anwendungen, die Pre- und Post-Order benötigen
* Weg aus einem Labyrinth: die Pre-Order dokumentiert die Suche nach dem Weg, die Post-Order zeigt den Rückweg aus Sackgassen (siehe Übung 9).
Im Spezialfall, wenn der Graph ein Binärbaum ist, unterscheidet man noch eine dritte Variante der Traversierung, nämlich die in-order Traversierung. In diesem Fall behandelt man den Vaterknoten nach den linken, aber vor den rechten Kindern. Diese Reihenfolge wird beim [[Suchen#Beziehungen zwischen dem Suchproblem und dem Sortierproblem|Tree Sort Algorithmus]] verwendet. Diese Sortierung verwendet man auch, wenn man einen Parse-Baum mit binären Operatoren (statt Funktionsaufrufen) ausgeben will, siehe Übung 5.

Eine nützliche Erweiterung der Tiefensuche besteht darin, in der property map <tt>visited</tt> nicht nur zu dokumentieren, dass ein Knoten bereits besucht wurde, sondern auch, von welchem Knoten aus man den jeweiligen Knoten zuerst erreicht hat. Im entstehenden Tiefensuchbaum ist dies gerade der Vaterknoten, weshalb wir die verbesserte property map zweckmäßigerweise in <tt>parents</tt> umbenennen. Für den Startknoten, also die Wurzel des Baumes, wählen wir die Konvention, dass er sein eigener Vaterknoten ist (die Konvention, dafür den Wert <tt>None</tt> zu verwenden, scheidet aus, weil dies bereits die Tatsache signalisiert, dass ein Knoten noch nicht besucht wurde):

def dfs(graph, startnode):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Tiefensuchbaum

def visit(node, parent): # rekursive Hilfsfunktion
if parents[node] is None: # Besuche node, wenn er noch nicht besucht wurde
parents[node] = parent # Markiere node als besucht und speichere seinen Vaterknoten
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn ...
visit(neighbor, node) # ... wobei node zu deren Vaterknoten wird

visit(startnode, startnode) # Konvention für Wurzel: startnode ist sein eigener Vater

return parents # Rückgabe des berechneten Tiefensuch-Baums

Die Ausgabe für den obigen Beispielgraphen lautet:
Knotennummer | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
--------------+-----+-----+-----+-----+-----+-----+-----+-----
Vaterknoten | None| 1 | 1 | 4 | 2 | 2 | 3 | 3

Dabei ist die Knotennummer der Index im Array <tt>parents</tt>, und der Vaterknoten ist der dazugehörige Arrayeintrag. Beachte, dass Knoten 0 in diesem Graphen nicht existiert, daher ist sein Eintrag <tt>None</tt>. Per Konvention hat der Wurzelknoten 1 sich selbst als Vater.

=== Breitensuche in Graphen (Breadth First Search, BFS) ===

Im Gegensatz zur Tiefensuche werden bei der Breitensuche alle Nachbarnknoten abgearbeitet, bevor man rekursiv deren Nachbarn besucht. Man betrachtet somit zuerst alle Knoten, die den Abstand 1 von Startknoten haben, dann diejenigen mit dem Abstand 2 usw. Diese Reihenfolge bezeichnet man als level-order. Wir sind ihr beispielsweise in Übung 6 begegnet, als die ersten 7 Ebenen eines Treap ausgegeben werden sollten. Man implementiert Breitensuche zweckmäßig mit Hilfe einer Queue, die die Knoten in First In - First Out - Reihenfolge bearbeitet. Eine geeignete Datenstruktur hierfür ist die Klasse <tt>[http://docs.python.org/library/collections.html#collections.deque deque]</tt> aus dem Python-Modul <tt>[http://docs.python.org/library/collections.html collections]</tt> (eine Deque implementiert sowohl die Funktionalität einer Queue wie auch die eines Stacks, siehe Übung 3):

from collections import deque

def bfs(graph, startnode)
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if not visited[node]: # Falls node noch nicht (auf einem anderen Weg) besucht wurde
visited[node] = True # Markiere node als besucht
print node # Drucke Knotennummer
for neighbor in graph[node]: # Füge Nachbarn in die Queue ein
q.append(neighbor)

[[Image:Breitens.jpg]]

Der Aufruf dieser Funktion liefert die Knoten des obigen Graphens ebenenweise, also zufällig genau in der Reihenfolge der Knotennummern:
>>> bfs(graph, 1)
1
2
3
4
5
6
7

Neben der ebenenweisen Ausgabe hat die Breitensuche viele weitere wichtige Anwendungen, z.B. beim Testen, ob ein gegebener Graph bi-partit ist (siehe [http://en.wikipedia.org/wiki/Breadth-first_search#Testing_bipartiteness WikiPedia]), sowie bei der Suche nach kürzesten Wegen (siehe unten) und kürzesten Zyklen.

== Weitere Anwendungen der Tiefensuche ==

Die Tiefensuche hat zahlreiche Anwendungen, wobei der grundlegende Algorithmus immer wieder leicht modifiziert und an die jeweilige Aufgabe angepasst wird. Wir beschreiben im folgenden einige Beispiele.

=== Damenproblem ===

Tiefensuche wird häufig verwendet, um systematisch nach der Lösung eines logischen Rätsels (oder allgemeiner nach der Lösung eines diskreten Optimierungsproblems) zu suchen. Besonders anschaulich hierfür ist das Damenproblem. Die Aufgabe besteht darin, <math>k</math> Damen auf einem Schachbrett der Größe <math>k \times k</math> so zu platzieren, dass sie sich (nach den üblichen Schach-Regeln) nicht gegenseitig schlagen können. Das folgende Diagramm zeigt eine Lösung für den Fall <math>k=4</math>. Die Positionen der Damen werden dabei wie üblich durch die Angabe der Spalte (Linie) mit Buchstaben und der Zeile (Reihe) mit Zahlen kodiert, hier also A2, B4, C1, D3:

---------------
| | X | | | 4
|---|---|---|---|
| | | | X | 3
|---|---|---|---|
| X | | | | 2
|---|---|---|---|
| | | X | | 1
---------------
A B C D

Um das Problem systematisch zu lösen, konstruieren wir einen gerichteten Graphen, dessen Knoten die möglichen Positionen der Damen kodieren. Wir verbinden Knoten, die zu benachbarten Linien gehören, genau dann mit einer Kante, wenn die zugehörigen Positionen kompatibel sind, also wenn sich die dort positionierten Damen nicht schlagen können. Der resultierende Graph für <math>k=4</math> hat folgende Gestalt:

[[Image:damenproblem-graph.png|500px|center]]

Knoten, die zur selben Reihe oder Linie gehören, sind beispielsweise nicht direkt verbunden, weil zwei Damen niemals in derselben Linie oder Reihe stehen dürfen. Um eine erlaubte Konfiguration zu finden, verwenden wir nun eine angepasste Version der Tiefensuche: Wir beginnen die Suche beim Knoten <tt>START</tt>. Sobald wir den Knoten <tt>STOP</tt> erreichen, beenden wir die Suche und lesen die Lösung am gerade gefundenen Weg von Start nach Stop ab. Zwei kleine Modifikationen des Grundalgorithmus stellen sicher, dass die Bedingungen der Aufgabe eingehalten werden: Wir dürfen bei der Tiefensuche nur dann zu einem Nachbarn weitergehen, wenn die betreffende Position mit allen im Pfad bereits gesetzten Positionen kompatibel ist, andernfalls ist diese Kante tabu. Landen wir aufgrund dieser Regel in einer Sackgasse (also in einem Knoten, wo keine der ausgehenden Kanten erlaubt ist), müssen wir zur nächsten erlaubten Abzweigung zurückgehen (Backtracking). Beim Zurückgehen müssen wir das <tt>parent</tt>-Flag wieder auf <tt>None</tt> zurücksetzen, weil der betreffende Knoten ja möglicherweise auf einem anderen erlaubten Weg erreichbar ist.

Der folgende Graph zeigt einen solchen Fall: Wir haben zwei Damen auf die Felder A1 und B3 positioniert (grüne Pfeile). Die einzig ausgehende Kante von B3 führt zum Knoten C1, welcher aber mit der Position A1 inkompatibel ist, so dass diese Kante nicht verwendet werden darf (roter Pfeil). Das Backtracking muss jetzt zu Knoten A1 zurückgehen (dabei wird das <tt>parent</tt>-Flag von B3 wieder auf <tt>None</tt> gesetzt), weil A1 mit der Kante nach B4 eine weitere Option hat, die geprüft werden muss (die allerdings hier auch nicht zum Ziel führt).

[[Image:damenproblem-graph-failure.png|500px|center]]

Nach einigen weiteren Sackgassen findet man schließlich den Pfad A2, B4, C1, D3, der im folgenden Graphen grün markiert ist und der obigen Lösung entspricht:

[[Image:damenproblem-graph-success.png|500px|center]]

=== Test, ob ein ungerichteter Graph azyklisch ist ===

Ein zusammenhängender ungerichteter Graph ist azyklisch (also ein Baum) genau dann, wenn es nur einen möglichen Weg von jedem Knoten zu jedem anderen gibt. (Bei gerichteten Graphen sind die Verhältnisse komplizierter. Wir behandeln dies weiter unten.) Das kann man mittels Tiefensuche leicht feststellen: Die Kante, über die wir einen Knoten erstmals erreichen, ist eine Baumkante des Tiefensuchbaums. Erreichen wir einen bereits besuchten Knoten nochmals über eine andere Kante, haben wir einen Zyklus gefunden. Dabei müssen wir allerdings beachten, dass in einem ungerichteten Graphen jede Baumkante zweimal gefunden wird, einmal in Richtung vom Vater zum Kind und einmal in umgekehrter Richtung. Im zweiten Fall endet die Kante zwar in einem bereits besuchten Knoten (dem Vater), aber es entsteht dadurch kein Zyklus. Den Vaterknoten müssen wir deshalb überspringen, wenn wir über die Nachbarn iterieren:

def undirected_cycle_test(graph): # Annahme: der Graph ist zusammenhängend
# (andernfalls führe den Algorithmus für jede Zusammenhangskomponente aus)
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node, from_node): # rekursive Hilfsfunktion: gibt True zurück, wenn Zyklus gefunden wurde
if not visited[node]: # wenn node noch nicht besucht wurde
visited[node] = True # markiere node als besucht
for neighbor in graph[node]: # besuche die Nachbarn ...
if neighbor == from_node: # ... aber überspringe den Vaterknoten
continue
if visit(neighbor, node): # ... signalisiere, wenn rekursiv ein Zyklus gefunden wurde
return True
return False # kein Zyklus gefunden
else:
return True # Knoten schon besucht => Zyklus

startnode = 0 # starte bei beliebigem Knoten (hier: Knoten 0)
return visit(startnode, startnode) # gebe True zurück, wenn ein Zyklus gefunden wurde

Wenn wir einen Zyklus finden, wird das weitere Traversieren das Graphen abgebrochen, denn ein Graph, der einmal zyklisch war, kann später nicht wieder azyklisch werden. Die notwendige Modifikation für unzusammenhängende Graphen erfolgt analog zum Algorithmus für die Detektion von Zusammenhangskomponenten, der im nächsten Abschnitt beschrieben wird.

=== Finden von Zusammenhangskomponenten ===

Das Auffinden und Markieren von Zusammenhangskomponenten (also maximalen zusammenhängenden Teilgraphen) ist eine grundlegende Aufgabe in ungerichteten, unzusammenhängenden Graphen (bei gerichteten Graphen sind die Verhältnisse wiederum komplizierter, siehe unten). Zwei Knoten u und v gehören zur selben Zusammenhangskomponente genau dann, wenn es einen Pfad von u nach v gibt (da der Graph ungerichtet ist, gibt es dann auch einen Pfad von v nach u). Man sagt auch, dass "v von u aus erreichbar" ist. Unzusammenhängende Graphen entstehen in der Praxis häufig, wenn die Kanten gewisse Relationen zwischen den Knoten kodieren:
* Wenn die Knoten Städte sind und die Kanten Straßen, sind diejenigen Städte in einer Zusammenhangskomponente, die per Auto von einander erreichbar sind. Unzusammenhängende Graphen entstehen hier beispielsweise, wenn eine Insel nicht durch eine Brücke erschlossen ist, wenn Grenzen gesperrt sind oder wenn ein Gebirge zu unwegsam ist, um Straßen zu bauen.
* Wenn Knoten Personen sind, und Kanten die Eltern-Kind-Relation beschreiben, so umfasst jede Zusammenhangskomponenten die Verwandten (auch wenn sie nur über viele "Ecken" verwandt sind).
* In der Bildverarbeitung entsprechen Knoten den Pixeln, und dieselben werden durch eine Kante verbunden, wenn sie zum selben Objekt gehören. Die Zusammenhangskomponenten entsprechen somit den Objekten im Bild (siehe Übungsaufgabe).
Die Zusammenhangskomponenten bilden eine Äquivalenzrelation. Folglich kann für jede Komponente ein Reprässentant bestimmt werden, der sogenannte "Anker". Kennt jeder Knoten seinen Anker, ist das Problem der Zusammenhangskomponenten gelöst.

==== Lösung mittels Tiefensuche ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden. Anstelle der property map <tt>visited</tt> verwenden wir diesmal eine property map <tt>anchors</tt>, die für jeden Knoten die Knotennummer des zugehörigen Ankers angibt, oder <tt>None</tt>, wenn der Knoten noch nicht besucht wurde. Dabei verwenden wir wieder die Konvention, dass Anker auf sich selbst zeigen. Für viele Anwendungen ist es außerdem (oder stattdessen) zweckmäßig, die Zusammenhangskomponenten mit einer laufenden Nummer, einem sogenannten Label, durchzuzählen. Dann kann man zusätzliche Informationen zu jeder Komponente (beispielsweise deren Größe) einfach in einem Array speichern, das über die Labels indexiert wird. Die folgende Version der Tiefensuche bestimmt sowohl die Anker als auch die Labels für jeden Knoten:

def connectedComponents(graph):
anchors = [None] * len(graph) # property map für Anker jedes Knotens
labels = [None] * len(graph) # property map für Label jedes Knotens

def visit(node, anchor):
"""anchor ist der Anker der aktuellen ZK"""
if anchors[node] is None: # wenn node noch nicht besucht wurde:
anchors[node] = anchor # setze seinen Anker
labels[node] = labels[anchor] # und sein Label
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor, anchor)

current_label = 0 # Zählung der ZK beginnt bei 0
for node in xrange(len(graph)):
if anchors[node] is None: # Anker noch nicht bekannt => neue ZK gefunden
labels[node] = current_label # Label des Ankers setzen
visit(node, node) # Knoten der neuen ZK rekursiv suchen
current_label += 1 # Label für die nächste ZK hochzählen
return anchors, labels
Interessant ist hier die Schleife über alle Knoten des Graphen am Ende des Algorithmus, die bei den bisherigen Versionen der Tiefensuche nicht vorhanden war. Um ihre Funktionsweise zu verstehen, nehmen wir für den Moment an, dass der Graph zusammenhängend ist. Dann findet diese Schleife den ersten Knoten des Graphen und führt die Tiefensuche mit diesem Knoten als Startknoten aus. Sobald die Rekursion zurückkehrt, sind alle Knoten des Graphen besucht (weil der Graph ja zusammenhängend war), so dass die Schleife alle weiteren Knoten überspringt (die if-Anweisung liefert für keinen weiteren Knoten True). Bei unzusammenhängenden Graphen dagegen erreicht die Tiefensuche nur die Knoten derselben Komponente, die im weiteren Verlauf der Schleife übersprungen werden. Findet die if-Anweisung jetzt einen noch nicht besuchten Knoten, muss dieser folglich in einer neuen Komponente liegen. Wir verwenden diesen Knoten als Anker und bestimmen die übrigen Knoten dieser Komponente wiederum mit Tiefensuche.

* Beispiel: ... under construction 

Man erkennt, dass die Tiefensuche nach dem Anlagerungsprinzip vorgeht: Beginnend vom einem Startknoten (dem Anker) werden die Knoten der aktuellen Komponente nach und nach an den Tiefensuchbaum angehangen. Erst, wenn nichts mehr angelagert werden kann, geht der Algorithmus zur nächsten Komponente über.

==== Lösung mittels Union-Find-Algorithmus ====

Im Gegensatz zum Anlagerungsprinzip sucht der Union-Find-Algorithmus die Zusammenhangskomponenten mit dem Verschmelzungsprinzip: Eingangs wird jeder Knoten als ein Teilgraph für sich betrachtet. Dann iteriert man über alle Kanten und verbindet deren Endknoten jeweils zu einem gemeinsamen Teilgraphen (falls die beiden Enden einer Kante bereits im selben Teilgraphen liegen, wird diese Kante ignoriert). Solange noch Kanten vorhanden sind, werden dadurch immer wieder Teilgraphen in größere Teilgraphen verschmolzen. Am Ende bleiben die maximalen zusammenhängenden Teilgraphen (also gerade die Zusammenhangskomponenten) übrig. Dieser Algorithmus kommt ohne Tiefensuche aus und ist daher in der Praxis oft schneller, allerdings auch etwas komplizierter zu implementieren.

Der Schlüssel des Algorithmus ist eine Funktion <tt>findAnchor()</tt>, die zu jedem Knoten den aktuellen Anker sucht. Der Anker existiert immer, da jeder Knoten von Anfang an zu einem Teilgraphen gehört (anfangs ist jeder Teilgraph trivial und besteht nur aus dem Knoten selbst). Die Verschmelzung wird realisiert, indem der Anker des einen Teilgraphen seine Rolle verliert und stattdessen der Anker des anderen Teilgraphen eingesetzt wird.

Zur Verwaltung der Anker verwenden wir wieder eine property map <tt>anchors</tt> mit der Konvention, dass die Anker auf sich selbst verweisen. Es wäre jedoch zu teuer, wenn man bei jeder Verschmelzung alle Anker-Einträge der beteiligten Knoten aktualisieren müsste, da jeder Knoten im Laufe des Algorithmus mehrmals seinen Anker wechseln kann. Statt dessen definiert man Anker rekursiv: Verweist ein Knoten auf einen Anker, der mittlerweile diese Rolle verloren hat, folgt man dem Verweis von diesem Knoten (dem ehemaligen Anker) weiter, bis man einen tatsächlichen Anker gefunden hat - erkennbar daran, dass er auf sich selbst verweist. Diese Suchfunktion kann folgendermassen implementiert werden:

def findAnchor(anchors, node):
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
return node

Allerdings kann diese Kette im Laufe vieler Verschmelzungen sehr lang werden, so dass das Verfolgen der Kette teuer wird. Man vermeidet dies durch die sogenannte Pfadkompression: Immer, wenn man den Anker gefunden hat, aktualisiert man den Eintrag am Anfang der Kette. Die Funktion <tt>findAnchor()</tt> wird dadurch nur wenig komplizierter:

def findAnchor(anchors, node):
start = node # wir merken uns den Anfang der Kette
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
anchors[start] = node # Pfadkompression: aktualisiere den Eintrag am Anfang der Kette
return node

Man kann zeigen, dass die Ankersuche mit Pfadkompression zu einer fast konstanten amortisierten Laufzeit pro Aufruf führt.

Um mit jeder Kante des (ungerichteten) Graphen nur maximal einmal eine Verschmelzung durchzuführen, betrachten wir jede Kante nur in der Richtung von der kleineren zur größeren Knotennummer, die umgekehrte Richtung wird ignoriert. Außerdem ist es zweckmäßig, bei jeder Verschmelzung denjenigen Anker mit der kleineren Knotennummer als neuen Anker zu übernehmen. Dann gilt für jede Zusammenhangskomponente, dass gerade der Knoten mit der kleinsten Knotennummer der Anker ist (genau wie bei der Lösung mittels Tiefensuche), was die weitere Analyse vereinfacht, z.B. die Zuordnung der Labels zu den Komponenten am Ende des Algorithmus.

def unionFindConnectedComponents(graph):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker

for node in xrange(len(graph)): # iteriere über alle Knoten
for neighbor in graph[node]: # ... und über deren ausgehende Kanten
if neighbor < node: # ignoriere Kanten, die in falscher Richtung verlaufen
continue
# hier landen wir für jede Kante des Graphen genau einmal
a1 = findAnchor(anchors, node) # finde Anker ...
a2 = findAnchor(anchors, neighbor) # ... der beiden Endknoten
if a1 < a2: # Verschmelze die beiden Teilgraphen
anchors[a2] = a1 # (verwende den kleineren der beiden Anker als Anker des
elif a2 < a1: # entstehenden Teilgraphen. Falls node und neighbor
anchors[a1] = a2 # den gleichen Anker haben, waren sie bereits im gleichen
# Teilgraphen, und es passiert hier nichts.)
# Bestimme jetzt noch die Labels der Komponenten
labels = [None]*len(graph) # Initialisierung der property map für Labels
current_label = 0 # die Zählung beginnt bei 0
for node in xrange(len(graph)):
a = findAnchor(anchors, node) # wegen der Pfadkompression zeigt jeder Knoten jetzt direkt auf seinen Anker
if a == node: # node ist ein Anker
labels[a] = current_label # => beginne eine neue Komponente
current_label += 1 # und zähle Label für die nächste ZK hoch
else:
labels[node] = labels[a] # node ist kein Anker => setzte das Label des Ankers
# (wir wissen, dass labels[a] bereits gesetzt ist, weil
# der Anker immer der Knoten mit der kleinsten Nummer ist)
return anchors, labels

* Beispiel: ... under construction

== Kürzeste Wege (Pfade) ==

Eine weitere grundlegende Aufgabe in Graphen ist die Bestimmung eines kürzesten Weges zwischen zwei gegebenen Knoten. Dies hat offensichtliche Anwendungen bei Routenplanern und Navigationssystemen und ist darüber hinaus wichtiger Bestandteil anderer Algorithmen, z.B. bei der Berechnung eines maximalen Flusses mit der [http://en.wikipedia.org/wiki/Edmonds%E2%80%93Karp_algorithm Methode von Edmonds und Karp].

=== Kürzeste Wege in ungewichteten Graphen mittels Breitensuche ===

Im Fall eines ungewichteten Graphen ist die Länge eines Weges einfach durch die Anzahl der durchlaufenen Kanten definiert. Daraus folgt, dass kürzeste Pfade mit einer leicht angepassten Version der Breitensuche gefunden werden können: Aufgrund des first in-first out-Verhaltens der Queue betrachtet die Breitensuche alle (erreichbaren) Knoten in der Reihenfolge ihres Abstandes vom Startknoten. Wenn wir den Zielknoten zum ersten Mal erreichen, und der gerade gefundene Weg vom Start zum Ziel hat die Länge L, muss dies der kürzeste Weg sein: Alle möglichen Wege der Länge L' < L hat die Breitensuche ja bereits betrachtet, ohne dass dabei der Zielknoten erreicht wurde. Daraus folgt übrigens eine allgemeine Eigenschaft aller Algorithmen für kürzeste Wege: Wenn der kürzeste Weg vom Start zum Ziel die Länge L hat, finden diese Algorithmen als Nebenprodukt auch die kürzesten Wege zu allen Knoten, für die L' < L gilt.

Um den Algorithmus zu implementieren, passen wir die Breitensuche so an, dass anstelle der property map <tt>visited</tt> eine property map <tt>parents</tt> verwendet wird, die für jeden besuchten Knoten den Vaterknoten im Breitensuchbaum speichert. Durch Rückverfolgen der <tt>parent</tt>-Kette können wir den Pfad vom Ziel zum Start rekonstruieren, und durch Umdrehen der Reihenfolge erhalten wir den gesuchten Pfad vom Start zum Ziel. Sobald der Zielknoten erreicht wurde, können wir die Breitensuche abbrechen (<tt>break</tt>-Befehl in der ersten <tt>while</tt>-Schleife). Falls der gegebene Graph unzusammenhängend ist, kann es passieren, dass gar kein Weg gefunden wird, weil Start und Ziel in verschiedenen Zusammenhangskomponenten liegen. Dies erkennen wir daran, dass die Breitensuche beendet wurde, ohne den Zielknoten zu besuchen. Dann gibt die Funktion statt eines Pfades dern Wert <tt>None</tt> zurück:

from collections import deque

def shortestPath(graph, startnode, destination):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Breitensuchbaum
parents[startnode] = startnode # startnode ist die Wurzel des Baums => verweist auf sich selbst

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # Besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn sie noch nicht besucht wurden
parents[neighbor] = node # setze node als Vaterknoten
q.append(neighbor) # und füge neighbor in die Queue ein

if parents[destination] is None: # Breitensuche wurde beendet ohne den Zielknoten zu besuchen
return None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path # gefundenen Pfad zurückgeben

=== Gewichtete Graphen ===

Das Problem der Suche nach kürzesten Wegen wird wesentlich interessanter und realistischer, wenn wir zu gewichteten Graphen übergehen:

; Definition - kantengewichteter Graph
: Jeder Kante (s,t) des Graphen ist eine reelle oder natürliche Zahl wst zugeordnet, die üblicherweise als ''Kantengewicht'' bezeichnet wird.

; Definition - knotengewichteter Graph
: Jedem Knoten v des Graphen ist eine reelle oder natürliche Zahl wv zugeordnet, die üblicherweise als ''Knotengewicht'' bezeichnet wird.

Je nach Anwendung benötigt man Knoten- oder Kantengewichte oder auch beides zugleich. Wir beschränken uns in der Vorlesung auf kantengewichtete Graphen. Beispiele für die Informationen, die man durch Kantengewichte ausdrücken kann, sind
* wenn die Knoten Orte sind: Abstand von Anfangs- und Endknoten jeder Kante (z.B. Luftline oder Straßenentfernung), Fahrzeit zwischen den Orten
* wenn der Knoten ein Rohrnetzwerk beschreibt: Durchflusskapazität der einzelnen Rohre (für max-Flussprobleme), analog bei elektrischen Netzwerken: elektrischer Widerstand
* wenn die Knoten Währungen repräsentieren, können deren Wechselkurse durch Kantengewichte angegeben werden.
Bei einigen Beispielen ergeben sich unterschiedliche Kantengewichte, wenn eine Kante von s nach t anstatt von t nach s durchlaufen wird. Beispielsweise können sich die Fahrzeiten erheblich unterscheiden, wenn es in einer Richtung bergauf, in der anderen bergab geht, obwohl die Entfernung in beiden Fällen gleich ist. Hier ergibt sich natürlicherweise ein gerichteter Graph. In anderen Beispielen (z.B. bei Luftlinienentfernungen, in guter Näherung auch bei Straßenentfernungen) sind die Gewichte von der Richtung unabhängig, so dass wir ungerichtete Graphen verwenden können.

Die Repräsentation der Kantengewichte im Programm richtet sich nach der Repräsentation des Graphen selbst. Am einfachsten ist wiederum die Adjazenzmatrix, die aber nur für dichte Graphen (<math>E = O(V^2)</math>, mit E als Anzahl der Kanten und V als Anzahl der Knoten) effizient ist. Bei gewichteten Graphen gibt das Matrixelement aij das Gewicht der Kante i ⇒ j (wobei aij = 0 gesetzt wird, wenn diese Kante nicht existiert). Wie zuvor gilt für ungerichtete Graphen aij = aji (symmetrische Matrix), während dies für gerichtete Graphen nicht gelten muss.

Bei Graphen in Adjazenzlistendarstellung hat es sich bewährt, die Gewichte in einer property map zu speichern. Weiter oben haben wir bereits property maps für Knoteneigenschaften (z.B. <tt>visited</tt> und <tt>anchors</tt>) gesehen. Property maps für Kanten funktionieren ganz analog, allerdings muss man jetzt Paare von Knoten (nämlich Anfangs- und Endknoten der Kante) als Schlüssel verwenden und die Daten entsprechend in einem assoziativen Array ablegen:
w = weights[(i,j)] # Zugriff auf das Gewicht der Kante i ⇒ j
Alternativ könnte man auch die Graph-Datenstruktur selbst erweitern, aber dies ist weniger zu empfehlen, weil jeder Algorithmus andere Erwiterungen benötigt und damit die Datenstruktur sehr unübersichtlich würde.

Der kürzeste Weg ist nun definiert als der Weg, bei dem die Summe der Kantengewichte minimal ist:
;Definition - Problem des kürzesten Weges
: Sei P die Menge aller Wege von u nach v, und <math>p \in P</math> einer dieser Wege. Wenn der Grpah einfach ist (es also keine Mehrfachkanten zwischen denselben Knoten und keine Schleifen gibt), ist der Weg p durch die Folge der besuchten Knoten eindeutig bestimmt:
: <math>p : \ \ u = x_0 \rightarrow x_1 \rightarrow x_2 \rightarrow ... \rightarrow v = x_{n_p}</math>
:wo <math>n_p</math> die Anzahl der Kanten im Weg p ist. Seine Kosten Wp ergeben sich als Summer der Gewichte der einzelnen Kanten
: <math>W_p = \sum_{k=1}^{n_p} w_{x_{k-1}x_k}</math>
: und ein kürzester Weg <math>p^* \in P</math> ist ein Weg mit minimalen Kosten
: <math>p^* = \textrm{argmin}_{p\in P}\ \ W_p</math>
: Das Problem des kürzesten Weges besteht darin, einen optimalen Weg p* zwischen gegebenen Knoten u und v zu finden.
Die Lösung dieses Problems hängt davon ab, ob alle Kantengewichte positiv sind, oder ob es auch negative Kantengewichte gibt. In letzeren Fall ist es möglich, durch eine Verlängerung des Weges die Kosten zu redizieren, während sich im ersteren Fall die Kosten immer erhöhen, wenn man den Weg verlängert.

Negative Gewichte treten z.B. bei den Währungsgraphen auf. Auf den ersten Blick entsprechen diese Graphen nicht den Anforderungen an das Problem des kürzesten Weges, weil Wechselkurse miteinander (und mit Geldbeträgen) multipliziert anstatt addiert werden. Man beseitigt diese Schwierigkeit aber leicht, indem man die Logarithmen der Wechselkurse als Kantengewichte verwendet, wodurch sich die Multiplikation in eine Addition der Logarithmen verwandelt. Wechselkurse < 1 führen nun zu negativen Gewichten.

Interessant werden negative Gewichte vor allem in Graphen mit Zyklen. Dann kann es nämlich passieren, dass die Gesamtkosten eines Zyklus ebenfalls negativ sind. Jeder Weg, der den Zyklus enthält, hat dann Kosten von <math>-\infty</math>, weil man den Zyklus beliebig oft durchlaufen und dadurch die Gesamtkosten immer weiter verkleinern kann:

/\ 1. Durchlauf: Kosten -1
1 / \ -4 2. Durchlauf: Kosten -2
/____\ etc.
2

Um hier nicht in einer Endlosschleife zu landen, benötigt man spezielle Algorithmen, die mit dieser Situation umgehen können. Der [http://de.wikipedia.org/wiki/Bellman-Ford-Algorithmus Algorithmus von Bellmann und Ford] beispielsweise bricht die Suche nach dem kürzesten Weg ab, sobald er einen negativen Zyklus entdeckt, aber andernfalls kann er negative Gewichte problemlos verarbeiten.

Die Detektion negativer Zyklen hat wiederum eine interessante Anwendung bei Währungsgraphen: Ein Zyklus bedeutet hier, dass man Geld über mehrere Stufen von einer Währung in die nächste und am Schluß wieder in die Originalwährung umtauscht, und ein negativer Zyklus führt dazu, dass man am Ende mehr Geld besitzt als am Anfang (damit negative Zyklen wirklich einen Gewinn bedeuten und keinen Verlust, müssen die Wechselkurse vor der Logarithmierung in [http://de.wikipedia.org/wiki/Wechselkurs#Nominaler_Wechselkurs Preisnotierung] angegeben sein). Bei Privatpersonen ist dies ausgeschlossen, weil die Umtauschgebühren den möglichen Gewinn mehr als aufzehren. Banken mit direktem weltweitem Börsenzugang hingegen unternehmen große Anstrengungen, um solche negativen Zyklen möglichst schnell (nämlich vor der Konkurrenz) zu entdecken und auszunutzen. Diese Geschäftsmethode bezeichnet man als [http://de.wikipedia.org/wiki/Arbitrage Arbitrage] und die Existenz eines negativen Zyklus als Arbitragegelegenheit. Durch die Kursschwankungen (und durch die ausgleichende Wirkung der Arbitragegeschäfte selbst) existieren die Arbitragegelegenheiten nur für kurze Zeit, und ihre Detektion erfordert leistungsfähige Echtzeitalgorithmen.

In dieser Vorlesung beschränken wir uns hingegen auf Graphen mit ausschließlich positiven Gewichten. In diesem Fall ist der Algorithmus von Dijkstra die Methode der Wahl, weil er wesentlich schneller arbeitet als der Bellmann-Ford-Algorithmus.

=== Algorithmus von Dijkstra ===

==== Edsger Wybe Dijkstra ====

geb. 11. Mai 1930 in Rotterdam

ges. 06. August 2002

Dijkstra war ein niederländischer Informatiker und Wegbereiter der strukturierten Programmierung. 1972 erhielt er für seine Leistung in der Technik und Kunst der Programmiersprachen den Turing Award, der jährlich von der Association for Computing Machinery (ACM) an Personen verliehen wird, die sich besonders um die Entwicklung der Informatik verdient gemacht haben. Zu seinen Beiträgen zur Informatik gehören unter anderem der Dijkstra-Algorithmus zur Berechnung des kürzesten Weges in einem Graphen sowie eine Abhandlung über den go-to-Befehl und warum er nicht benutzt werden sollte. Der go-to-Befehl war in den 60er und 70er Jahren weit verbreitet, führte aber zu Spaghetti-Code. In seinem berühmten Paper "A Case against the GO TO Statement"[http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF], das als Brief mit dem Titel "Go-to statement considered harmful" veröffentlicht wurde, argumentiert Dijkstra, dass es umso schwieriger ist, dem Quellcode eines Programmes zu folgen, je mehr go-to-Befehle darin enthalten sind und zeigt, dass man auch ohne diesen Befehl gute Programme schreiben kann.

==== Algorithmus ====

Der Dijkstra-Algorithmus für kürzeste Wege ist dem oben vorgestellten Algorithmus <tt>shortestPath()</tt> auf der Basis von Breitensuche sehr ähnlich. Insbesondere gilt auch hier, dass neben dem kürzesten Weg vom Start zum Ziel auch alle kürzesten Wege gefunden werden, deren Endknoten dem Start näher sind als der Zielknoten. Aufgrund der Kantengewichte gibt es aber einen wichtigen Unterschied: Der erste gefundene Weg zu einem Knoten ist nicht mehr notwendigerweise der kürzeste. Wir bestimmen deshalb für jeden Knoten mehrere Kandidatenwege und verwenden eine Prioritätswarteschlange (statt einer einfachen First in - First out - Queue), um diese Wege nach ihrer Länge zu sortieren. Die Kandidatenwege für einen gegebenen Knoten werden unterschieden, indem wir auch den Vorgängerknoten im jeweiligen Weg speichern. Wenn ein Knoten erstmals an die Spitze der Prioritätswarteschlange gelangt, haben wir den kürzesten Weg zu diesem Knoten gefunden (das wird weiter unten formal bewiesen), und der Vorgänger des Knotens in diesem Weg wird zu seinem Vaterknoten. Erscheint derselbe Knoten später nochmals an der Spitze der Prioritätswarteschlange, handelt es sich um einen Kandidatenweg, der sich nicht als kürzester erwiesen hat und deshalb ignoriert werden kann. Wir erkennen dies leicht daran, dass der Vaterknoten in der property map <tt>parents</tt> bereits gesetzt ist.

Eine geeignete Datenstruktur für die Prioritätswarteschlange wird durch das Python-Modul [http://docs.python.org/library/heapq.html heapq] realisiert. Es verwendet ein normales Pythonarray als unterliegende Repräsentation für einen Heap und stellt effiziente <tt>heappush</tt> und <tt>heappop</tt>-Funktionen zur Verfügung. Dies entspricht genau unserer Vorgehensweise im Kapitel [[Prioritätswarteschlangen]]. Als Datenelement erwartet die Funktion <tt>heappush</tt> ein Tupel, dessen erstes Element die Priorität sein muss. Die übrigen Elemente des Tupels (und damit auch deren Anzahl) können je nach Anwendung frei festgelegt werden. Wir legen fest, dass das zweite Element den Endknoten des betrachteten Weges und das dritte den Vorgängerknoten speichert.

Die Kantengewichte werden dem Algorithmus in der property map <tt>weights</tt> übergeben:

<code python>
import heapq # heapq implementiert die Funktionen für Heaps

def dijkstra(graph, weights, startnode, destination):
parents = [None]*len(graph) # registriere für jeden Knoten den Vaterknoten im Pfadbaum

q = [] # Array q wird als Heap verwendet
heapq.heappush(q, (0.0, startnode, startnode)) # Startknoten in Heap einfügen

while len(q) > 0: # solange es noch Knoten im Heap gibt:
length, node, predecessor = heapq.heappop(q) # Knoten aus dem Heap nehmen
if parents[node] is not None: # parent ist schon gesetzt => es gab einen anderen, kürzeren Weg
continue # => wir können diesen Weg ignorieren
parents[node] = predecessor # parent setzen
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # die Nachbarn von node besuchen,
if parents[neighbor] is None: # aber nur, wenn ihr kürzester Weg noch nicht bekannt ist
newLength = length + weights[(node,neighbor)] # berechne Pfadlänge zu neighbor
heapq.heappush(q, (newLength, neighbor, node)) # und füge neighbor in den Heap ein

if parents[destination] is None: # Suche wurde beendet ohne den Zielknoten zu besuchen
return None, None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path, length # gefundenen Pfad und dessen Länge zurückgeben
</code>
Die wesentlichen Unterschiede zur Breitensuche sind im Code rot markiert: Anstelle der Queue verwenden wir jetzt einen Heap, und der Startknoten wird mit Pfadlänge 0 als erstes eingefügt. In der Schleife <tt>while len(q) > 0:</tt> wird jeweils der Knoten <tt>node</tt> mit der aktuell kürzesten Pfadlänge aus dem Heap entfernt. Die Pfadlänge vom Start zu diesem Knoten wird in der Variable <tt>length</tt> gespeichert, sein Vorgänger in der Variable <tt>predecessor</tt>. Wenn der aktuelle Weg nicht der kürzeste ist (<tt>parents[node]</tt> war bereits gesetzt), wird dieser Weg ignoriert. Andernfalls werden die property map <tt>parents</tt> aktualisiert und die Nachbarn von <tt>node</tt> besucht. Beim Scannen der Nachbarn berechnen wir zunächst die Länge <tt>newLength</tt> das Weges <tt>startnode => node => neighbor</tt> als Summe von <tt>length</tt> und dem Gewicht der Kante <tt>(node, neighbode)</tt>. Diese Länge wird beim Einfügen des Nachbarknotens in den Heap zur Priorität des aktuellen Weges.

Die wichtigsten Prinzipien des Dijkstra-Algorithmus noch einmal im Überblick:
* Der Dijkstra-Algorithmus ist Breitensuche mit Prioritätswarteschlange (Heap) statt einer einfache Warteschlange (Queue).
* Die Prioritätswarteschlange speichert alle Wege, die bereits gefunden worden sind und ordnet sie aufsteigend nach ihrer Länge.
* Das Sortieren (und damit der ganze Algorithmus) funktioniert nur mit positiven Kantengewichten korrekt.
* Da ein Knoten auf mehreren Wegen erreichbar sein kann, kann er auch mehrmals im Heap sein.
* Wenn ein Knoten erstmals aus der Prioritätswarteschlange entnommen wird, ist der gefundene Weg der kürzeste zu diesem Knoten. Andernfalls wird der Weg ignoriert.
* Wenn der Knoten <tt>destination</tt> aus dem Heap entnommen wird, ist der kürzeste Weg von Start nach Ziel gefunden, und die Suche kann beendet werden.
In unserer Implementation können, wie gesagt, mehrere Wege zum selben Knoten gleichzeitig in der Prioritätswarteschlange sein. Im Prinzip wäre es auch möglich, immer nur den besten zur Zeit bekannten Weg zu jedem Enknoten in der Prioritätswarteschlange zu halten - sobald ein besserer Kandidat gefunden wird, ersetzt er den bisherigen Kandidaten, anstatt zusätzlich eingefügt zu werden. Dies erfordert aber eine wesentlich kompliziertere Prioritätswarteschlange, die eine effiziente <tt>updatePriority</tt>-Funktion anbietet, ohne dass dadurch eine signifikante Beschleunigung erreicht wird. Deshalb verfolgen wir diesen Ansatz nicht.

==== Beispiel ====

under construction

[[Image:Bsp.jpg]]

==== Komplexität von Dijkstra ====

Zur Analyse der Komplexität nehmen wir an, dass der Graph V Knoten und E Kanten hat. Die Initialisierung der property map <tt>parents</tt> am Anfang der Funktion hat offensichtlich Komplexität O(V), weil Speicher für V Knoten allokiert wird. Der Code am Ende der Funktion, der aus der property map <tt>parents</tt> den Pfad extrahiert, hat ebenfalls die Komplexität O(V), weil der Pfad im ungünstigen Fall sämtliche Knoten des Graphen umfasst. Beides wird durch die Komplexität der Hauptschleife dominiert, zu deren Analyse wir den folgenden Codeausschnitt genauer anschauen wollen:

while len(q) > 0:
... # 1
if parents[node] is not None:
continue
parents[node] = predecessor
... # 2
Wir erkennen, dass der Codeabschnitt <tt># 2</tt> für jeden Knoten höchstens einmal erreicht werden kann: Da <tt>parents[node]</tt> beim ersten Durchlauf gesetzt wird, kann die <tt>if</tt>-Abfrage beim gleichen Knoten nie wieder <tt>False</tt> liefern, und das nachfolgende <tt>continue</tt> bewirkt, dass der Abschnitt <tt># 2</tt> dann übersprungen wird. Man sagt auch, dass jeder Knoten höchstens einmal expandiert wird, auch wenn er mehrmals im Heap war.

Der Codeabschnitt <tt># 2</tt> selbst enthält eine Schleife über alle ausgehenden Kanten des Knotens <tt>node</tt>. Im ungünstigsten Fall iterieren wir bei allen Knoten über alle ausgehenden Kanten, aber das sind gerade alle Kanten des Graphen je einmal in den beiden möglichen Richtungen. Die Funktion <tt>heappush</tt> wird sogar höchstens E Mal aufgerufen, weil eine Kante nur in den Heap eingefügt wird, wenn der kürzeste Weg der jeweiligen Endknotens noch nicht bekannt ist (siehe die <tt>if</tt>-Abfrage in der <tt>for</tt>-Schleife), und das ist nur ein einer Richtung möglich. Dies hat zwei Konsequenzen:
* Die Schleife <tt>while len(q) > 0:</tt> wird nur so oft ausgeführt, wie Elemente im Heap sind, also höchstens E Mal. Das gleiche gilt für den Codeabschnitt <tt># 1</tt>, der das <tt>heappop</tt> enthält.
* Die Operationen <tt>heappush</tt> und <tt>heappop</tt> haben logarithmische Komplexität in der Größe des Heaps, sind also in <math>O(\log\,E)</math>. In einfachen Graphen gilt aber <math>E = O(V^2)</math>, so dass sich die Komplexität der Heapoperationen vereinfacht zu <math>O(\log\,E)=O(\log\,V^2)=O(2\log\,V)=O(\log\,V)</math>.
Zusammenfassend gilt: <tt>heappush</tt> und <tt>heappop</tt> werden maximal E Mal aufgerufen und haben eine Komplexität in <math>O(\log\,V)</math>. Folglich hat der Algorithmus von Dijkstra die Komplexität:
:<math>O(E\,\log\,V)</math>

==== Vergleich mit Breitensuche und Tiefensuche ====

Der Dijkstra-Algorithmus ist eng mit der Breiten- und Tiefensuche verwandt - man kann diese Algorithmen aus dem Dijkstra-Algorithmus gewinnen, indem man einfach die Regel zur Festlegung der Prioritäten ändert. Anstelle der Länge des Pfades verwenden wir als Priorität den Wert eine Zählvariable <tt>count</tt>, die nach jeder Einfügung in den Heap (also nach jedem Aufruf von <tt>heappush</tt>) aktualisiert wird. Zählen wir die Variable hoch, haben die zuerst eingefügten Kanten die höchste Priorität, der Heap verhält sich also wie eine Queue (First in-First out), und wir erhalten eine Breitensuche. Zählen wir die Variable hingegen (von E beginnend) herunter, haben die zuletzt eingefügten Kanten höchste Priorität. Der Heap verhält sich dann wie ein Stack (Last in-First out), und wir bekommen Tiefensuche. Statt eines Heaps plus Zählvariable kann man jetzt natürlich direkt eine Queue bzw. einen Stack verwenden. Dadurch fällt der Aufwand <math>O(\log\,V)</math> für die Heapoperationen weg und wird durch die effizienten O(1)-Operationen von Queue bzw. Stack ersetzt. Damit erhalten wir für Breiten- und Tiefensuche die schon bekannte Komplexität O(E).

==== Korrektheit von Dijkstra ====

Wir beweisen mittels vollständiger Induktion die Schleifen-Invariante: Falls <tt>parents[node]</tt> gesetzt (also ungleich <tt>None</tt>) ist, dann liefert das Zurückverfolgen des Weges von <tt>node</tt> nach <tt>startnode</tt> den kürzesten Weg.
;Induktionsanfang: <tt>parents[startnode]</tt> ist als einziges gesetzt. Zurückverfolgen liefert den trivialen Weg <tt>[startnode]</tt>, der mit Länge 0 offensichtlich der kürzeste Pfad ist → die Bedingung ist erfüllt.
;Induktionsschritt: Wir zeigen mit einem indirektem Beweis, dass wir immer einen kürzesten Weg bekommen, wenn <tt>parents[node]</tt> gesetzt wird.
:Sei <math>S</math> = <tt>{v | parents[v] is not None}</tt> die Menge aller Knoten, von denen wir den kürzesten Weg schon kennen (Induktionsvoraussetzung), und <tt>node</tt> der Knoten, der sich gerade an der Spitze des Heaps befindet. Dann ist <tt>predecessor</tt> der Vorgänger von <tt>node</tt> im aktuellen Weg, und es muss <tt>predecessor</tt><math>\in S</math> gelten, weil die Nachbarn von <tt>predecessor</tt> (und damit auch der aktuelle <tt>node</tt>) erst in den Heap eingefügt werden, wenn der kürzeste Weg für <tt>predecessor</tt> gefunden wurde. Man beachte auch, dass alle Knoten, die noch nicht in <math>S</math> enthalten sind, weiter vom Start entfernt sind als alle Knoten in <math>S</math>, weil alle neu in den Heap eingefügten Wege länger sind als der kürzeste Weg des jeweiligen Vorgängers.
:Der indirekte Beweis nimmt jetzt an, dass der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> nicht der kürzeste Weg ist. Dann muss es einen anderen, kürzeren Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> geben. Für den Vorgänger <tt>x</tt> in diesem Weg unterscheiden wir zwei Fälle:
:* <tt>x</tt><math>\in S</math>: In diesem Fall ist die Länge des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> bereits bekannt, und dieser Weg ist in der Prioritätswarteschlange enthalten. Dann kann er aber nicht der kürzeste sein, denn an der Spitze der Warteschlange war nach Voraussetzung der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt>.
:* <tt>x</tt><math>\notin S</math>: Die Kosten des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> berechnen sich als <tt>Kosten(x → startnode) + weight[(x, node)]</tt>, und die Kosten des Weges <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> sind analog <tt>Kosten(predecessor → startnode) + weight[(predecessor, node)]</tt>. Aufgrund der Induktionsvoraussetzung gilt aber <tt>predecessor</tt><math>\in S</math>, und somit <tt>Kosten(predecessor → startnode) < Kosten(x → startnode)</tt>, weil <tt>x</tt> andernfalls vor <tt>predecessor</tt> an der Spitze des Heaps gewesen wäre, was mit der Annahme <tt>x</tt><math>\notin S</math> unverträglich ist. Damit der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> trotzdem der kürzeste Weg sein kann, müsste <tt>Kosten(x → startnode) < Kosten(node → startnode)</tt> gelten, denn durch die Kante <tt>(x, node)</tt> kommen ja noch Kosten hinzu. Das wäre aber nur möglich, wenn der Knoten <tt>x</tt> vor dem Knoten <tt>node</tt> an die Spitze des Heaps gelangt, im Widerspruch zur Annahme, dass <tt>node</tt> sich gerade an der Spitze des Heaps befindet. Somit kann die Behauptung, dass der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> der kürzeste Weg ist, nicht stimmen.
In beiden Fällen erhalten wir einen Widerspruch, und die Behauptung ist somit bewiesen. Da die Invariante insbesondere für den Weg zum Zielknoten <tt>destination</tt> erfüllt ist, folgt daraus auch die Korrektheit des Algorithmus von Dijkstra.

=== A*-Algorithmus - Wie kann man Dijkstra noch verbessern? ===

Eine wichtige Eigenschaft des Dijkstra-Algorithmus ist, dass neben dem kürzesten Weg vom Start zum Ziel auch die kürzesten Wege zu allen Knoten berechnet werden, die näher am Startknoten liegen als das Ziel, obwohl uns diese Wege gar nicht interessieren. Sucht man beispielsweise in einem Graphen mit den Straßenverbindungen in Deutschland den kürzesten Weg von Frankfurt (Main) nach Dresden (ca. 460 km), werden auch die kürzesten Wege von Frankfurt nach Köln (190 km), Dortmund (220 km) und Stuttgart (210 km) und vielen anderen Städten gefunden. Aufgrund der geographischen Lage dieser Städte ist eigentlich von vornherein klar, dass sie mit dem kürzesten Weg nach Dresden nicht das geringste zu tun haben. Anders sieht es mit Erfurt (260 km) oder Suhl (210 km) aus - diese Städte liegen zwischen Frankfurt und Dresden und kommen deshalb als Zwischenstationen des gesuchten Weges in Frage.

Damit Dijkstra korrekt funktioniert, würde es im Prinzip ausreichen, wenn man die kürzesten Wege nur für diejenigen Knoten ausrechnet, die auf dem kürzesten Weg vom Start zum Ziel liegen, denn nur diese Knoten braucht man, um den gesuchten Weg über die <tt>parent</tt>-Kette zurückzuverfolgen. Das Problem ist nur, dass man diese Knoten erst kennt, wenn der Algorithmus fertig durchgelaufen ist. Schließt man Knoten zu früh von der Betrachtung aus, kommt am Ende möglicherweise nicht der korrekte kürzeste Weg heraus.

Der A*-Algorithmus löst dieses Dilemma mit folgender Idee: Ändere die Prioritäten für den Heap so ab, dass unwichtige Knoten nur mit geringerer Wahscheinlichkeit expandiert werden, aber stelle gleichzeitig sicher, dass alle wichtigen Knoten (also diejenigen auf dem korrekten kürzesten Weg) auf jeden Fall expandiert werden. Es zeigt sich, dass man diese Idee umsetzen kann, wenn eine Schätzung für den Restweg (also für die noch verbleibende Entfernung von jedem Knoten zum Ziel) verfügbar ist:
rest = guess(neighbor, destination)
Diese Schätzung addiert man einfach zur wahren Länge des Weges <tt>startnode → node</tt> dazu, um die verbesserte Priorität zu erhalten:
priority = newLength + guess(neighbor, destination)
(Im originalen Dijkstra-Algorithmus wird als Priorität nur <tt>newLength</tt> allein verwendet. Man beachte, dass man <tt>newLength</tt> jetzt zusätzlich im Heap speichern muss, weil man es für die Expansion des Knotens später noch benötigt.)

Damit sicher gestellt ist, dass der A*-Algorithmus immer noch die korrekten kürzesten Wege findet, darf die Schätzung den wahren Restweg niemals überschätzen. Es muss immer gelten:
0 <= guess(node, destination) <= trueDistance(node, destination)
Damit gilt insbesondere <tt>guess(destination, destination) = trueDistance(destination, destination) = 0</tt>, an der Priorität des Knotens <tt>destination</tt> ändert sich also nichts. Die Prioritäten aller anderen Knoten veschlechtern sich hingegen, weil zur bisherigen Priorität noch atwas addiert wird. Für die wichtigen Knoten auf dem kürzesten Weg vom Start nach Ziel gilt jedoch, dass deren neue Priorität immer noch besser ist als die Priorität des Zielknotens selbst. Für diese Knoten gilt nämlich
falls node auf dem kürzesten Weg von startnode nach destination liegt:
trueDistance(startnode, node) + guess(node, destination) <= trueDistance(startnode, destination)
weil der Weg von Start nach <tt>node</tt> ein Teil des kürzesten Wegs von Start nach Ziel ist und die Restschätzung die wahre Entfernung immer unterschätzt. Diese Knoten werden deshalb stets vor dem Zielknoten expandiert, so dass wir die <tt>parent</tt>-Kette immer noch korrekt zurückverfolgen können. Für alle anderen Knoten gilt idealerweise, dass die neue Priorität schlechter ist als die Priorität von <tt>destination</tt>, so dass man sich diese irrelevanten Knotenexpansionen sparen kann.

Für das Beispiel eines Straßennetzwerks bietet sich als Schätzung die Luftlinienentfernung an, weil Straßen nie kürzer sein können als die Luftlinie. Damit erreicht man in der Praxis deutliche Einsparungen. Generell gilt, dass der A*-Algorithmus im typischen Fall schneller ist als der Algorithmus von Dijkstra, aber man kann immer pathologische Fälle konstruieren, wo die Änderung der Prioritäten nichts bringt. Die Komplexität des A*-Algorithmus im ungünstigen Fall ist deshalb nach wie vor <math>O(E\,\log\,V)</math>.

=='''Minimaler Spannbaum'''==
'''(engl.: minimum spanning tree; abgekürzt: MST)'''

[[Image:Minimum_spanning_tree.png‎ |thumb|200px|right|Ein minimal aufspannender Baum verbindet alle Punkte eines Graphen bei minimaler Kantenlänge ([http://de.wikipedia.org/wiki/Spannbaum Quelle])]]

:''gegeben'': gewichteter Graph G, zusammenhängend 
:''gesucht'': Untermenge <math>E'\subseteq E</math> der Kanten, so dass die Summe der Kantengewichte <math>\sum_{e\in E'} w_e</math> minimal und der entstehende Graph G' zusammenhängend ist. 
* G' definiert immer einen Baum, denn andernfalls könnte man eine Kante weglassen und dadurch die Summe <math>\sum_{e\in E'} w_e</math> verringern, ohne dass sich am Zusammenhang von G' etwas ändert. 
* Wenn der Graph G nicht zusammenhängend ist, kann man den Spannbaum für jede Zusammenhangskomponente getrennt ausrechnen. Man erhält dann einen aufspannenden Wald.
* Der MST ist ähnlich wie der Dijkstra-Algorithmus: Dort ist ein Pfad gesucht, bei dem die Summe der Gewichte über den Pfad minimal ist. Beim MST suchen wir eine Lösung, bei der die Summe der Gewichte über den ganzen Graphen minimal ist.
* Das Problem des MST ist nahe verwandt mit der Bestimmung der Zusammenhangskomponente, z.B. über den Tiefensuchbaum. Für die Zusammenhangskomponenten genügt allerdings ein beliebiger Baum, während beim MST ein minimaler Baum gesucht ist.

=== Anwendungen ===
==== Wie verbindet man n gegebene Punkte mit möglichst kurzen Straßen (Eisenbahnen, Drähten [bei Schaltungen] usw.)?====

 
{| class="wikitable" style="text-align:center" border="0" cellpadding="5" cellspacing="0"
|MST minimale Verbindung (Abb.1)
|MST = 2 (Länge = Kantengewicht)(Abb.2)
|- valign="top"
| [[Image:mst.png]]
| [[Image:Gleichseitigesdreieck.png]]
|}
*In der Praxis: Die Festlegung, dass man nur die gegebenen Punkte verwenden darf, ist eine ziemliche starke Einschränkung.

* Wenn man sich vorstellt, es sind drei Punkte gegeben, die als gleichseitiges Dreieck angeordnet sind, dann ist der MST (siehe Abb.2, schwarz gezeichnet) und hat die Länge 2. Man kann hier die Länge als Kantengewicht verwenden.

* Wenn es erlaubt ist zusätzliche Punkte einzufügen, dann kann man in der Mitte einen neuen Punkt setzen <math>\rightarrow</math> neuer MST (siehe Abb.2, orange gezeichnet). 

* Höhe = <math>\frac{1}{2}\sqrt{3}</math>, Schwerpunkt: teilt die Höhe des Dreiecks im Verhältnis 2:1; der Abstand von obersten Punkt bis zum neu eingeführten Punkt: <math>\frac{2}{3}h = \frac{\sqrt{3}}{3}</math>, davon insgesamt 3 Stück, damit (gilt für den MST in orange eingezeichnet): MST = <math>3\left(\frac{1}{3}\right) \sqrt{3} = \sqrt{3} \approx 1,7</math><br\>

* Damit ist der MST in orange kürzer als der schwarz gezeichnete MST. <br\>
<math>\Rightarrow</math>Folgerung: MST kann kürzer werden, wenn man einen Punkt dazu nimmt.
* Umgekehrt kann der MST auch kürzer werden, wenn man einen Punkt aus dem Graphen entfernt, aber wie das Beipiel des gleichseitigen Dreiecks zeigt, ist dies nicht immer der Fall.

[[Image: bahn.png|Bahnstrecke Verbindung (Abb.3)]]

* Methode der zusätzlichen Punkteinfügung hat man früher beim Bahnstreckenbau verwendet. Durch Einführung eines Knotenpunktes kann die Streckenlänge verkürzt werden (Dreiecksungleichung).

==== Bestimmung von Datenclustern ====

[[Image:cluster.png]]

* Daten (in der Abb.: Punkte) bilden Gruppen.

* In der Abbildung hat man 2 verschiedene Messungen gemacht (als x- und y-Achse aufgetragen), bspw. Größe und Gewicht von Personen. Für jede Person i wird ein Punkt an der Koordinate (Größei, Gewichti) gezeichnet (siehe Bild a). Dies bezeichnet man als ''Scatter Plot''. Wenn bestimmte Wertkombinationen häufiger auftreten als andere, bilden sich mitunter Gruppen aus, bspw. eine Gruppe für "klein und schwer" etc.

* Durch Verbinden der Punkte mittels eines MST (siehe Abbildung (b)) sieht man, dass es kurze (innerhalb der Gruppen) und lange Kanten (zwischen den Gruppen) gibt.

* Wenn man geschickt eine Schwelle einführt und alle Kanten löscht, die länger sind als die Schwelle, dann bekommt man als Zusammenhangskomponente die einzelnen Gruppen.

=== Algorithmen ===

Genau wie bei der Bestimmung von Zusammenhangskomponenten kann man auch das MST-Problem entweder nach dem Anlagerungsprinzip oder nach dem Verschmelzungsprinzip lösen (dazu gibt es noch weitere Möglichkeiten, z.B. den [http://de.wikipedia.org/wiki/Algorithmus_von_Bor%C5%AFvka Algorithmus von Boruvka]). Der Anlagerungsalgorithmus für MST wurde zuerst von Prim beschrieben und trägt deshalb seinen Namen, der Verschmelzungsalgorithmus stammt von Kruskal. Im Vergleich zu den Algorithmen für Zusammenhangskomponenten ändert sich im wesentlichen nur die Reihenfolge, in der die Kanten betrachtet werden: Eine Prioritätswarteschlange stellt jetzt sicher, dass am Ende wirklich der Baum mit den geringstmöglichen Kosten herauskommt.

====Algorithmus von Prim====
[http://de.wikipedia.org/wiki/Algorithmus_von_Prim Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]

Der Algorithmus von Prim geht nach dem Anlagerungsprinzip vor (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Tiefensuche|Zusammenhangskomponenten mit Tiefensuche]]): Starte an der Wurzel (ein willkürlich gewählter Knoten) und füge jeweils die günstigste Kante an die aktuellen Teillösung an, die keinen Zyklus verursacht. Die Sortierung der Kanten nach Priorität erfolgt analog zum Dijsktra-Algorithmus, aber die Definitionen, welche Kante die günstigste ist, unterscheiden sich. Die Konvention für die Bedeutung der Elemente des Heaps ist ebenfalls identisch: ein Tupel mit <tt>(priority, node, predecessor)</tt>. Die folgende Implementation verdeutlicht sehr schön die Ähnlichkeit der beiden Algorithmen. Das Ergebnis wird als property map <tt>parents</tt> zurückgegeben, in der für jeden Knoten sein Vorgänger im MST steht, wobei die Wurzel wie üblich auf sich selbst verweist.

import heapq

def prim(graph, weights): # Kantengewichte wie bei Dijkstra als property map
sum = 0.0 # wird später das Gewicht des Spannbaums sein
start = 0 # Knoten 0 wird willkürlich als Wurzel gewählt

parents = [None]*len(graph) # property map, die den resultierenden Baum kodiert
parents[start] = start # Wurzel zeigt auf sich selbst

heap = [] # Heap für die Kanten des Graphen
for neighbor in graph[start]: # besuche die Nachbarn von start
heapq.heappush(heap, (weights[(start, neighbor)], neighbor, start)) # und fülle Heap

while len(heap) > 0:
w, node, predecessor = heapq.heappop(heap) # hole billigste Kante aus dem Heap
if parents[node] is not None: # die Kante würde einen Zyklus verursachen
continue # => ignoriere diese Kante
parents[node] = predecessor # füge Kante in den MST ein
sum += w # und aktualisiere das Gesamtgewicht
for neighbor in graph[node]: # besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn kein Zyklus entsteht
heapq.heappush(heap, (weights[(node,neighbor)], neighbor, node)) # füge Kandidaten in Heap ein

return parents, sum # MST und Gesamtgewicht zurückgeben

====Algorithmus von Kruskal====
[http://de.wikipedia.org/wiki/Algorithmus_von_Kruskal Wikipedia (de)]
[http://en.wikipedia.org/wiki/Kruskal%27s_algorithm (en)]

Die alternative Vorgehensweise ist das Verschmelzungsprinzip (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]]), das der Algorithmus von Kruskal verwendet. Jeder Knoten wird zunächst als trivialer Baum mit nur einem Knoten betrachtet, und alle Kanten werden aufsteigend nach Gewicht sortiert. Dann wird die billigste noch nicht betrachtete Kante in den MST eingefügt, falls sich dadurch kein Zyklus bildet (erkennbar daran, dass die Endknoten in verschiedenen Zusammenhangskomponenten liegen, das heisst verschiedene Anker haben). Da der fertige Baum (V-1) Kanten haben muss, wird dies (V-1) Mal zutreffen. Andernfalls wird diese Kante ignoriert. Anders ausgedrückt: Der Algorithmus beginnt mit ''V'' Bäumen; in (''V''-1) Verschmelzungsschritten kombiniert er jeweils zwei Bäume (unter Verwendung der kürzesten möglichen Kante), bis nur noch ein Baum übrig bleibt. Der einzige Unterschied zum einfachen Union-Find besteht darin, dass die Kanten in aufsteigender Reihenfolge betrachtet werden müssen, was wir hier durch eine Prioritätswarteschlange realisieren. Der Algorithmus von J.Kruskal ist seit 1956 bekannt.

def kruskal(graph, weights):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker
results = [] # result wird später die Kanten des MST enthalten

heap = [] # Heap zum Sortieren der Kanten nach Gewicht
for edge, w in weights.iteritems(): # alle Kanten einfügen
heapq.heappush(heap, (w, edge))

while len(heap) > 0: # solange noch Kanten vorhanden sind
w, edge = heapq.heappop(heap) # billigste Kante aus dem Heap nehmen
a1 = findAnchor(anchors, edge[0]) # Anker von Startknoten der Kante
a2 = findAnchor(anchors, edge[1]) # ... und Endknoten bestimmen
if a1 != a2: # wenn die Knoten in verschiedenen Komponenten sind
anchors[a2] = a1 # Komponenten verschmelzen
result.append(edge) # ... und Kante in MST einfügen

return result # Kanten des MST zurückgeben

Die Funktion <tt>findAnchor()</tt> wurde im Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]] implementiert. Im Unterschied zum Algorithmus von Prim geben wir hier nicht die property map <tt>parents</tt> zurück, sondern einfach eine Liste der Kanten im MST.

Der Algorithmus eignet sich insbesondere für das Clusteringproblem, da der Schwellwert von vornerein als maximales Kantengewicht an den Algorithmus übergeben werden kann. Man hört mit dem Vereinigen auf, wenn das Gewicht der billigste Kante im Heap den Schwellwert überschreitet. Beim Algorithmus von Kruskal kann dann keine bessere Kante als der Schwellwert mehr kommen, da die Kanten vorher sortiert worden sind.

Komplexität: wie beim Dijkstra-Algorithmus, weil jede Kante genau einmal in den Heap kommt. Der Aufwand für das Sortieren ist somit <math>O\left(E\log E\right)</math>, was sich zu <math>O \left(E\,\log\,V\right)</math> reduziert, falls keine Mehrfachkanten vorhanden sind.

=> geeignet für Übungsaufgabe

====Verwendung einer BucketPriorityQueue====

Beide Algorithmen zur Bestimmung des minimalen Spannbaums benötigen eine Prioritätswarteschlange. Wenn die Kantengewichte ganze Zahlen im Bereich <tt>0...(m-1)</tt> sind, kann man die MST-Algorithmen deutlich beschleunigen, wenn man anstelle des Heaps eine [[Prioritätswarteschlangen#Prioritätssuche mit dem Bucket-Prinzip|<tt>BucketPriorityQueue</tt>]] verwendet. Die Operationen zum Einfügen einer Kante in die Queue und zum Entfernen der billibsten Kante aus der Queue beschleunigen sich dadurch auf O(1) statt O(log V) (außer wenn die Gewichte sehr ungünstig auf die Kanten verteilt sind). In der Praxis erreicht man durch diese Änderung typischerweise deutliche Verbesserungen. In der Bildverarbeitung können die Prioritäten beispielsweise die Wahrscheinlichkeit kodieren, dass zwei benachbarte Pixel zu verschiedenen Objekten gehören. Bildet man jetzt den MST, und bricht bei einer bestimmten Wahrscheinlichkeit ab, erhält man Cluster von Pixeln, die wahrscheinlich zum selben Objekt gehören (weil der MST ja die Kanten mit minimalem Gewicht bevorzugt, und kleine Gewichte bedeuten kleine Wahrscheinlichkeit, dass benachbarte Pixel von einander getrennt werden). Da man die Wahrscheinlichkeiten nur mit einer Genauigkeit von ca. 1% berechnen kann, reichen hiefür 100 bis 200 Quantisierungstufen aus. Durch Verwendung der schnellen <tt>BucketPriorityQueue</tt> kann man jetzt wesentlich größere Bilder in akzeptabler Zeit bearbeiten als dies mit einem Heap möglich wäre.

== Algorithmen für gerichtete Graphen ==

Zur Erinnerung: in einem gerichteten Graphen sind die Kanten (i → j) und (j → i) voneinander verschieden, und eventuell existiert nur eine der beiden Richtungen. Im allgemeinen unterscheidet sich der [[Graphen_und_Graphenalgorithmen#transposed_graph|transponierte Graph]] GT also vom Originalgraphen G. Beim Traversieren des Graphen und bei der Pfadsuche dürfen Kanten nur in passender Richtung verwendet werden. Bei gewichteten Graphen tritt häufig der Fall auf, dass zwar Kanten in beiden Richtungen existieren, diese aber unterschiedliche Gewichte haben.

Gerichtete Graphen ergeben sich in natürlicher Weise aus vielen Anwendungsproblemen:
* Routenplanung
** Bei Straßennetzwerken enstehen gerichtete Graphen, sobald es Einbahnstraßen gibt.
** Verwendet man Gewichte, um die erwarteten Fahrzeiten entlang einer Straße zu kodieren, gibt es Asymmetrien z.B. dann, wenn Straßen in einer Richtung bergab, in der anderen bergauf befahren werden. Hier existieren zwar Kanten in beiden Richtungen, sie haben aber unterschiedliche Gewichte. Ähnliches gilt für Flüge: Durch den Gegenwind des Jetstreams braucht man von Frankfurt nach New York länger als umgekehrt von New York nach Frankfurt.
* zeitliche oder kausale Abhängigkeiten
** Wenn die Knoten Ereignisse repräsentieren, von denen einige die Ursache von anderen sind, diese wiederum die Ursache der nächsten usw., verbindet man die Knoten zweckmäßig durch gerichtete Kanten, die die Kausalitätsbeziehungen kodieren. Handelt es sich um logische "wenn-dann"-Regeln, erhält man einen [[Graphen_und_Graphenalgorithmen#Anwendung:_Das_Erf.C3.BCllbarkeitsproblem_in_Implikationengraphen|Implikationengraph]] (siehe unten). Handelt es sich hingegen um Wahrscheinlichkeitsaussagen ("Wenn das Wetter schön ist, haben Studenten tendenziell gute Laune, wenn eine Prüfung bevorsteht eher schlechte usw."), erhält man ein [http://de.wikipedia.org/wiki/Bayessches_Netz Bayessches Netz].
** Wenn bestimmte Aufgaben erst begonnen werden können, nachdem andere Aufgaben erledigt sind, erhält man einen Abhängigkeitsgraphen. Beispielsweise dürfen Sie erst an der Klausur teilnehmen, nachdem Sie die Übungsaufgaben gelöst haben, und Sie dürfen erst die Abschlussarbeit beginnen, nachdem Sie bestimmte Prüfungen bestanden haben. Ein anderes schönes Beispiel liefern die Regeln für das [[Graphen_und_Graphenalgorithmen#Anwendung:_Abh.C3.A4ngigkeitsgraph|Ankleiden]] weiter unten.
** Gerichtete Graphen kodieren die Abhängigkeiten zwischen Programmbibliotheken. Beispielsweise benötigt das Pythonmodul <tt>json</tt> die internen Submodule <tt>json.encoder</tt> und <tt>json.decode</tt> sowie das externe Modul <tt>decimal</tt>. Die Submodule benötigen wiederum die externen Module <tt>re</tt> und <tt>sys</tt>, das Modul <tt>decimal</tt> braucht <tt>copy</tt> und <tt>collections</tt> usw.
** Das Internet kann als gerichteter Graph dargestellt werden, wobei die Webseiten die Knoten, und die Hyperlinks die Kanten sind.
* Sequence Alignment
** Eine gute Rechtschreibprüfung markiert nicht nur fehlerhafte Wörter, sondern macht auch plausible Vorschläge, was eigentlich gemeint gewesen sein könnte. Dazu muss sie das gegebene Wort mit den Wörtern eines Wörterbuchs vergleichen und die Ähnlichkeit bewerten. Ein analoges Problem ergibt sich, wenn man DNA Fragmente mit der Information in einer Genomdatenbank abgleichen will.

=== Anwendung: Sequence Alignment / Edit Distance ===

:gegeben: zwei Wörter (allgemein: beliebige Zeichenfolgen)
:gesucht: Wie kann man die Buchstaben am besten in Übereinstimmung bringen?

:Beispiel: WORTE – NORDEN

Zwei mögliche Alignments sind

WORTE. W.ORTE
NORDEN NORDEN

wobei der Punkt anzeigt, dass der untere Buchstabe keinen Partner hat, und rote Buchstaben oben und unten übereinstimmen. Jede Nicht-Übereinstimmung verursacht nun gewisse Kosten. Dabei unterscheiden wir zwei Fälle:
# Matche a[i] mit b[j]. Falls a[i] == b[j], ist das gut (rote Buchstaben), und es entstehen keine Kosten. Andernfalls entstehen Kosten U (schwarze Buchstaben).
# Wir überspringen a[i] oder b[j] (Buchstabe vs. Punkt). Dann entstehen Kosten V. (Manchmal unterscheidet man auch noch Kosten Va und Vb, wenn das Überspringen bei a und b unterschieldiche Signifikanz hat.)

Gesucht ist nun das Alignment mit minimalen Kosten

Diese Aufgabe kann man sehr schön als gerichteten Graphen darstellen: Wir definieren ein rechteckiges Gitter und schreiben das erste Wort über das Gitter und das andere links davon. Die Gitterpunkte verbinden wir mit Pfeilen (gerichteten Kanten), wobei ein Pfeil nach rechts bedeutet, dass wir beim oberen Wort einen Buchstaben überspringen, ein Pfeil nach unten, dass wir beim linken Wort einen Buchstaben überspringen, und ein diagonaler Pfeil, dass wir zwei Buchstaben matchen (und zwar die am Pfeilende). Die Farben der Pfeile symbolisieren die Kosten: rot für das Überspringen eines Buchstabens (Kosten V), blau für das Matchen, wenn die Buchstaben nicht übereinstimmen (Kosten U), und grün, wenn die Buchstaben übereinstimmen (keine Kosten).

[[Image:sequence-alignment.png|300px]]

Lösung:
:Suche den kürzesten Pfad vom Knoten "START" (oben links) nach unten rechts. Dazu kann der [[Graphen und Graphenalgorithmen#Algorithmus von Dijkstra|Algorithmus von Dijkstra]] verwendet werden, der auf gerichteten Graphen genauso funktioniert wie auf ungerichteten.

Für unser Beispiel von oben erhalten wir die folgenden Pfade:

[[Image:sequence-alignment-weg1.png|400px]]     [[Image:sequence-alignment-weg2.png|400px]]

Durch Addieren der Kosten entsprechend der Farben sieht man, dass der erste Weg die Kosten 2U+V und der zweite die Kosten 5U+V hat. Der erste Weg ist offensichtlich günstiger und entspricht dem besten Alignment.

=== Anwendung: Abhängigkeitsgraph ===

Beispiel: Wie erklärt man einem zerstreuten Professor, wie er sich morgens anziehen soll? Der folgende Graph enthält einen Knoten für jede Aktion, und eine Kante (i → j) bedeutet, dass die Aktion i vor der Aktion j abgeschlossen werden muss.

[[Image:anziehen-graph.png|600px]]

In derartigen Abhängigkeitsgraphen ist die wichtigste Frage immer, ob der Graph azyklisch ist. Wäre dies nämlich nicht der Fall, kann es keine Reihenfolge der Aktionen geben, die alle Abhängigkeiten erfüllt. Dies sieht man leicht, wenn man den einfachsten möglichen Zyklus betrachtet: es gibt sowohl eine Kante (i → j) als auch eine (j → i). Dann müsste man i vor j erledigen, aber ebenso j vor i, was offensichtlich unmöglich ist - das im Graph kodierte Problem ist dann unlösbar. Wegen ihrer Wichtigkeit wird für gerichtete azyklische Graphen oft die Abkürzung DAG (von directed acyclic graph) verwendet. Ein Graph ist genau dann ein DAG, wenn es eine topologische Sortierung gibt:
;topologische Sortierung: Zeichne die Knoten so auf eine Gerade, dass alle Kanten (Pfeile) nach rechts zeigen.
Arbeitet man die Aktionen nach einer (beliebigen) topologischen Sortierung ab, werden automatisch alle Abhängigkeiten eingehalten: Da alle Pfeile nach rechts zeigen, werden abhängige Aktionen immer später ausgeführt. Die topologische Sortierung ist im allgemeinen nicht eindeutig. Die folgende Skizze zeigt eine mögliche topologische Sortierung für das Anziehen:

[[Image:anziehen-topologische-sortierung.png|600px]]

Eine solche fest vorgegebene Reihenfolge ist für den zerstreuten Professor sicherlich eine größere Hilfe als der ursprüngliche Graph. Man erkennt, dass die Sortierung nicht eindeutig ist, beispielsweise bei der Uhr: Da für die Uhr keine Abhängigkeiten definiert sind, kann man diese Aktion an beliebiger Stelle einsortieren. Hier wurde willkürlich die letzte Stelle gewählt.

==== Zwei Algorithmen zum Finden der topologischen Sortierung ====

Die folgenden Algorithmen finden entweder eine topologische Sortierung, oder signalisieren, dass der Graph zyklisch ist.

===== Algorithmus 1 =====
# Suche einen Knoten mit Eingangsgrad 0 (ohne eingehende Pfeile) => in einem gerichteten azyklischen Graphen gibt es immer einen solchen Knoten
# Platziere diesen Knoten auf der Geraden (beliebig)
# Entferne den Knoten aus dem Graphen zusammen mit den ausgehenden Kanten
# Gehe zu 1., aber platziere in 2. immer rechts der Knoten, die schon auf der Geraden vorhanden sind.
: => Wenn noch Knoten übrig sind, aber keiner Eingangsgrad 0 hat, muss der Graph zyklisch sein.

[[Image:bild6.JPG]]

Beispiel für einen zyklischen Graphen: kein Knoten hat Eingangsgrad 0.

Um den Algorithmus zu implementieren, verwenden wir eine property map <tt>in_degree</tt>, die wir in einem ersten Durchlauf durch den Graphen füllen und die dann für jeden Knoten die Anzahl der eingehenden Kanten speichert. Dann gehen wir sukzessive zu allen Knoten mit <tt>in_degree == 0</tt>. Anstatt sie aber tatsächlich aus dem Graphen zu entfernen wie im obigen Pseudocode, dekrementieren wir nur den <tt>in_degree</tt> ihrer Nachbarn. Wird der <tt>in_degree</tt> eines Nachbarn dadurch 0, wird er ebenfalls in das Array der zu scannenden Knoten aufgenommen. Wenn der Graph azyklisch ist, enthält das Array am Ende alle Knoten des Graphen, und die Reihenfolge der Einfügungen definiert eine topologische Sortierung. Andernfalls ist das Array zu kurz, und wir signalisieren durch Zurückgeben von <tt>None</tt>, dass der Graph zyklisch ist:

def topological_sort(graph): # ein gerichteter Graph
in_degree = [0]*len(graph) # property map für den Eingangsgrad jeden Knotens
for node in xrange(len(graph)): # besuche alle Knoten
for neighbor in graph[node]: # ... und deren Nachbarn
in_degree[neighbor] += 1 # ... und inkrementiere den Eingangsgrad

result = [] # wird später die topologische Sortierung enthalten
for node in xrange(len(graph)):
if in_degree[node] == 0:
result.append(node) # füge alle Knoten mit Eingangsgrad 0 in result ein

k = 0
while k < len(result): # besuche alle Knoten mit Eingangsgrad 0
node = result[k]
k += 1
for neighbor in graph[node]: # besuche alle Nachbarn
in_degree[neighbor] -= 1 # entferne 'virtuell' die eingehende Kante
if in_degree[neighbor] == 0: # wenn neighbor jetzt Eingangsgrad 0 hat
result.append(neighbor) # ... füge ihn in result ein

if len(result) == len(graph): # wenn alle Knoten jetzt Eingangsgrad 0 haben
return result # ... ist result eine topologische Sortierung
else:
return None # andernfalls ist der Graph zyklisch

===== Algorithmus 2 =====
Der obige Algorithmus hat den Nachteil, dass er jeden Knoten zweimal expandiert. Man kann eine topologische Sortierung stattdessen auch mit Tiefensuche bestimmen. Es gilt nämlich der folgende
;Satz: Wird ein DAG mittels Tiefensuche traversiert, definiert die reverse post-order eine topologische Sortierung.
Zur Erinnerung: die post-order erhält man, indem man jeden Knoten ausgibt, nachdem die Rekursion zu allen seinen Nachbarn beendet ist, siehe unsere [[Graphen_und_Graphenalgorithmen#pre_and_post_order|Diskussion weiter oben]]. Die reverse post-order ist gerade die Umkehrung dieser Reihenfolge. Die folgende Implementation verwendet die rekursive Version der Tiefensuche, in der Praxis wird man meist die iterative Version mit Stack bevorzugen, weil bei großen Graphen die Aufruftiefe sehr groß werden kann:

def reverse_post_order(graph): # gerichteter Graph
result = [] # enthält später die reverse post-order
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node): # besuche node
if not visited[node]: # aber nur, wenn er noch nicht besucht wurde
visited[node] = True # markiere ihn als besucht
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor)
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order

for node in xrange(len(graph)): # besuche alle Knoten
visit(node)

result.reverse() # post-order => reverse post-order
return result

Die Tatsache, dass die reverse post-order tatsächlich eine topologische Sortierung liefert, leuchtet wahrscheinlich nicht unmittelbar ein. Bevor wir diese Tatsache beweisen. wollen wir uns anhand des Ankleidegraphen klar machen, dass die pre-order (die man intuitiv vielleicht eher wählen würde) keine topologische Sortierung ist. Startet man die Tiefensuche beim Knoten "Unterhemd", werden die Knoten in der Reihenfolge "Unterhemd", "Oberhemd", "Schlips", "Jackett", "Gürtel" gefunden. Da dann alle von "Unterhemd" erreichbaren Knoten erschöpft sind, startet man die Tiefensuche als nächstes bei "Unterhose" und erreicht von dort aus "Hose" und "Schuhe". Man erkennt sofort, dass diese Reihenfolge nicht funktioniert: "Hose" kommt nach "Gürtel", und "Jackett" kommt vor "Gürtel". Bei dieser Anordnung gibt es Pfeile nach links, die Abhängigkeitsbedingungen sind somit verletzt.

Damit die reverse post-order eine zulässige Sortierung sein kann, muss stets gelten, dass Knoten u vor Knoten v einsortiert wurde, wenn die Kante (u → v) existiert. Das ist aber äquivalent zur Forderung, dass in der ursprünglichen post-order (vor dem <tt>reverse</tt>) u hinter v stehen muss. Wir betrachten den <tt>visit</tt>-Aufruf, bei dem u expandiert wird. Gelangt man jetzt zu u's Nachbarn v, gibt es zwei Möglichkeiten: Wenn v bereits expandiert wurde, befindet es sich bereits im Array <tt>result</tt> und <tt>visit</tt> kehrt sofort zurück. Andernfalls wird v ebenfalls expandiert und demzufolge in <tt>result</tt> eingetragen, bevor der rekursive Aufruf <tt>visit(v)</tt> zurückkehrt. Knoten u wird aber erst in <tt>result</tt> eingefügt, nachdem alle rekursiven <tt>visit</tt>-Aufrufe seiner Nachbarn zurückgekehrt sind. In beiden Fällen steht u in der post-order wie gefordert hinter v, und daraus folgt die Behauptung.

Der obige Algorithmus liefert natürlich nur dann eine topologische Sortierung, wenn der Graph wirklich azyklisch ist (man kann ihn aber auch anwenden, um die reverse post-order für einen zyklischen Graphen zu bestimmen, siehe Abschnitt "[[Graphen_und_Graphenalgorithmen#Transitive Hülle und stark zusammenhängende Komponenten|Stark zusammenhängende Komponenten]]"). Dieser Fall tritt in der Praxis häufig auf, weil zyklische Graphen bei vielen Anwendungen gar nicht erst entstehen können. Weiß man allerdings nicht, ob der Graph azyklisch ist oder nicht, muss man einen zusätzlichen Test auf Zyklen in den Algorithmus einbauen.

Zyklische Graphen sind dadurch gekennzeichnet, dass es im obigen Beweis eine dritte Möglichkeit gibt: Während der Expansion von u wird rekursiv v expandiert, und es gibt eine Rückwärtskante (v → u). (Es spielt dabei keine Rolle, ob v von u aus direkt oder indirekt erreicht wurde.) Ein Zyklus wird also entdeckt, wenn die Tiefensuche zu u zurückkehrt, solange u noch aktiv ist, d.h. wenn die Rekursion von u aus gestartet und noch nicht beendet wurde. Dies kann man leicht feststellen, wenn man in der property map <tt>visited</tt> drei Werte zulässt: 0 für "noch nicht besucht", 1 für "aktiv" und 2 für "beendet". Wir signalisieren einen Zyklus, sobald <tt>visit</tt> für einen Knoten aufgerufen wird, der gerade aktiv ist:

def topological_sort_DFS(graph): # gerichteter Graph
result = [] # enthält später die topologische Sortierung

not_visited, active, finished = 0, 1, 2 # drei Zustände für visited
visited = [not_visited]*len(graph) # Flags für aktive und bereits besuchte Knoten

def visit(node): # besuche node (gibt "True" zurück, wenn Zyklus gefunden wurde)
if visited[node] == not_visited: # ... aber nur, wenn er noch nicht besucht wurde
visited[node] = active # markiere ihn als aktiv
for neighbor in graph[node]: # und besuche die Nachbarn
if visit(neighbor): # wenn rekursiv ein Zyklus gefunden wurde
return True # ... brechen wir ab und signalisieren den Zyklus
visited[node] = finished # Rekursion beendet, node ist nicht mehr aktiv
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order
return False # kein Zyklus gefunden
elif visited[node] == active: # Rekursion erreicht einen noch aktiven Knoten
return True # => Zyklus gefunden

for node in xrange(len(graph)): # besuche alle Knoten
if visit(node): # wenn Zyklus gefunden wurde
return None # ... gibt es keine topologische Sortierung

result.reverse() # post-order => reverse post-order (=topologische Sortierung)
return result

Man macht sich leicht klar, dass kein Zyklus vorliegt, wenn die Rekursion einen Knoten erreicht, der bereits auf <tt>finished</tt> gesetzt ist. Nehmen wir an, dass u gerade expandiert wird, und sein Nachbar v ist bereits <tt>finished</tt>. Wenn es einen Zyklus gäbe, müsste es einen Weg von v nach u geben. Dann wäre u aber bereits während der Expansion von v gefunden worden. Da v nicht mehr im Zustand <tt>active</tt> ist, muss die Expansion von v schon abgeschlossen gewesen sein, ohne dass u gefunden wurde. Folglich kann es keinen solchen Zyklus geben.

=== Transitive Hülle und stark zusammenhängende Komponenten ===

Auch bei gerichteten Graphen ist die Frage, welche Knoten miteinander zusammenhängen, von großem Interesse. Wir betrachten dazu wieder die Relation "Knoten v ist von Knoten u aus erreichbar", die anzeigt, ob es einen Weg von u nach v gibt oder nicht. In ungerichteten Graphen ist diese Relation immer symmetrisch, weil jeder Weg in beiden Richtungen benutzt werden kann. In gerichteten Graphen gilt dies nicht. Man muss hier zwei Arten von Zusammenhangskomponenten unterscheiden:
;Transitive Hülle: Die transitive Hülle eines Knotens u ist die Menge aller Knoten, die von u aus erreichbar sind:
:<math>T(u) = \{v\ |\ u \rightsquigarrow v\}</math>
;Stark zusammenhängende Komponenten: Die stark zusammenhängende Komponenten <math>C_i</math> eines gerichteten Graphen sind maximale Teilgraphen, so dass alle Knoten innerhalb einer Komponente von jedem anderen Knoten der selben Komponente aus erreichbar sind
:<math>u,v \in C_i\ \ \Leftrightarrow\ \ u \rightsquigarrow v \wedge v \rightsquigarrow u</math>
Die erste Definition betrachtet den Zusammenhang asymmetrisch, ohne Beachtung der Frage, ob es auch einen Rückweg von Knoten v nach u gibt, die zweite hingegen symmetrisch.

Die transitive Hülle benötigt man, wenn man Fragen der Erreichbarkeit besonders effizient beantworten will. Wir hatten bespielsweise oben erwähnt, dass das Python-Modul <tt>json</tt> direkt und indirekt von mehreren anderen Module abhängt, die vorher installiert werden müssen, damit <tt>json</tt> funktioniert. Bittet man den Systemadministrator, das <tt>json</tt>-Paket zu installieren, will er diese Abhängigkeiten wahrscheinlich nicht erst mühsam rekursiv heraussuchen, sondern er verlangt eine Liste aller Pakete, die installiert werden müssen. Dies ist gerade die transitive Hülle von <tt>json</tt> im Abhängigkeitsgraphen. Damit man diese nicht manuell bestimmen muss, verwendet man Installationsprogrammen wie z.B. [http://pypi.python.org/pypi/pip/ pip], die die Abhängigkeiten automatisch herausfinden und installieren.

Bei der Bestimmung der transitiven Hülle modifiziert man den gegebenen Graphen, indem man jedesmal eine neue Kante (u → v) einfügt, wenn diese Kante noch nicht existiert, aber v von u aus erreichbar ist. Dies gelingt mit einer sehr einfachen Variation der Tiefensuche: Wir rufen <tt>visit(k)</tt> für jeden Knoten k auf, aber setzen die property map <tt>visited</tt> zuvor auf <tt>False</tt> zurück. Alle Knoten, die während der Rekursion erreicht werden, sind im modifizierten Graphen Nachbarn von k. Ein etwas effizienterer Ansatz ist der [http://de.wikipedia.org/wiki/Algorithmus_von_Floyd_und_Warshall Algorithmus von Floyd und Warshall].

Die Bestimmung der stark zusammenhängenden Komponenten ist etwas schwieriger. Es existieren eine ganze Reihe von effizienten Algorithmen (siehe [http://en.wikipedia.org/wiki/Strongly_connected_component WikiPedia]), deren einfachster der Algorithmus von Kosaraju ist:

gegeben: gerichteter Graph

# Bestimme die reverse post-order (mit der Funktion <tt>reverse_post_order</tt>)
# Bilde den transponierten Graphen <math>G^T</math> (mit der Funktion <tt>transposeGraph</tt>)
# Bestimme die Zusammenhangskomponenten von <math>G^T</math> mittels Tiefensuche, aber betrachte die Knoten dabei in der reverse post-order aus Schritt 1 (dies kann mit einer minimalen Modifikation der Funktion <tt>connectedComponents</tt> geschehen, indem man die Zeile <tt>for node in xrange(len(graph)):</tt> einfach nach <tt>for node in ordered:</tt> abändert, wobei <tt>ordered</tt> das Ergebnis der Funktion <tt>reverse_post_order</tt> ist, also ein Array, das die Knoten in der gewünschten Reihenfolge enthält).
Die Zusammenhangskomponenten, die man in Schritt 3 findet, sind gerade die stark zusammenhängenden Komponenten des Originalgraphen G. Die folgende Skizze zeigt diese in grün für den schwarz gezeichneten gerichteten Graphen.

[[Image:strongly-connected-components.png|400px]]

Zum Beweis der Korrektheit des Algorithmus von Kosaraju zeigen wir zwei Implikationen: 1. Wenn die Knoten u und v in der selben stark zusammenhängenden Komponente liegen, werden sie in Schritt 3 des Algorithmus auch der selben Komponente zugewiesen. 2. Wenn die Knoten u und v in Schritt 3 der selben Komponente zugewiesen wurden, müssen sie auch in der selben stark zusammenhängenden Komponente liegen.
# Knoten u und v gehören zur selben stark zusammenhängenden Komponente von G. Per Definition gilt, dass u von v aus erreichbar ist und umgekehrt. Dies muss auch im transponierten Graphen GT gelten (der Weg <math>u \rightsquigarrow v</math> wird jetzt zum Weg <math>v \rightsquigarrow u</math> und umgekehrt). Wird u bei der Tiefensuche in Schritt 3 vor v expandiert, ist v von u aus erreichbar und gehört somit zur selben Komponente. Das umgekehrte gilt, wenn v vor u expandiert wird. Daraus folgt die Behauptung 1.
# Knoten u und v werden in Schritt 3 der selben Komponente zugewiesen: Sei x der Anker dieser Komponente. Da u in der gleichen Komponente wie x liegt, muss es in GT einen Weg <math>x \rightsquigarrow u</math>, und demnach in G einen Weg <math>u \rightsquigarrow x</math> geben. Da x der Anker seiner Komponente ist, wissen wir aber auch, dass x in der reverse post-order vor u liegt (denn der Anker ist der Knoten, mit dem eine neue Komponente gestartet wird; er muss deshalb im Array <tt>ordered</tt> als erster Konten seiner Komponente gefunden worden sein). Wir unterscheiden jetzt im Schritt 1 des Algorithmus zwei Fälle:
## u wurde bei der Bestimmung der post-order vor x expandiert. Dann kann x nur dann in der reverse post-order vor u liegen (oder, einfacher ausgedrückt, x kann nur dann in der post-order hinter u liegen), wenn x im Graphen G nicht von u aus erreichbar war. Das ist aber unmöglich, weil wir ja schon wissen, dass es in G einen Weg <math>u \rightsquigarrow x</math> gibt.
## Folglich wurde u bei der Bestimmung der post-order nach x expandiert. Da x in der post-order hinter u liegt, muss u während der Expansion von x erreicht worden sein. Deshalb muss es in G auch einen Weg <math>x \rightsquigarrow u</math> geben.
#:Somit sind x und u in der selben stark zusammenhängenden Komponente. Die gleiche Überlegung gilt für x und v. Wegen der Transitivität der relation "ist erreichbar" folgt daraus, dass auch u und v in der selben Komponente liegen, also die Behauptung 2.

Die folgende Skizze illustriert, dass der Komponentengraph stets azyklisch ist. Den Komponentengraph erhält man, indem man für jede Komponente <math>C_i</math> einen Knoten erzeugt (grün), und die Knoten i und j durch eine gerichtete Kante verbindet (rot), wenn es im Originalgraphen eine Kante (u → v) mit <math>u \in C_i</math> und <math>v \in C_j</math> gibt. Es ist dann garantiert, dass es keine Kante in umgekehrter Richtung geben kann. Daraus folgt insbesondere, dass ein DAG nur triviale stark verbundene Komponenten haben kann, die aus einzelnen Knoten bestehen.

[[Image:strongly-connected-components-graph.png|400px]]

=== Anwendung: Das Erfüllbarkeitsproblem in Implikationengraphen ===

Das Erfüllbarkeitsproblem hat auf den ersten Blick nichts mit Graphen zu tun, denn es geht um Wahrheitswerte logischer Ausdrücke. Man kann logische Ausdrücke jedoch unter bestimmten Bedingungen in eine Graphendarstellung überführen und somit das ursprüngliche Problem auf ein Problem der Graphentheorie reduzieren, für das bereits ein Lösungsverfahren bekannt ist. In diesem Abschnitt wollen wir dies für die sogenannten Implikationengraphen zeigen, ein weiteres Beispiel findet sich im Kapitel [[NP-Vollständigkeit]].

==== Das Erfüllbarkeitsproblem ====

(vgl. [http://de.wikipedia.org/wiki/Erfüllbarkeitsproblem_der_Aussagenlogik WikiPedia (de)])

Das Erfüllbarkeitsproblem (SAT-Problem, von satisfiability) befasst sich mit logischen (oder Booleschen) Funktionen: Gegeben sei eine Menge <math>\{x_1, ... ,x_n\}</math> Boolscher Variablen (d.h., die <math>x_i</math> können nur die Werte True oder False annehmen), sowie eine logische Formel, in der die Variablen mit den üblichen logischen Operatoren
:<math>\neg\quad</math>: Negation ("nicht", in Python: <tt>not</tt>)
:<math>\vee\quad</math>: Disjunktion ("oder", in Python: <tt>or</tt>)
:<math>\wedge\quad</math>: Konjuktion ("und", in Python: <tt>and</tt>)
:<math>\rightarrow\quad</math>: Implikation ("wenn, dann", in Python nicht als Operator definiert)
:<math>\leftrightarrow\quad</math>: Äquivalenz ("genau dann, wenn", in Python: <tt>==</tt>)
:<math>\neq\quad</math>: exklusive Disjunktion ("entweder oder", in Python: <tt>!=</tt>)
verknüpft sind. Klammern definieren die Reihenfolge der Auswertung der Operationen. Für jede Belegung der Variablen <math>x_i</math> mit True oder False liefert die Formel den Wert der Funktion, der natürlich auch nur True oder False sein kann. Wenn Formel und Belegung gegeben sind, ist die Auswertung der Funktion ein sehr einfaches Problem: Man transformiert die Formel in einen Parse-Baum (siehe Übungsaufgabe "Taschenrechner) und wertet jeden Knoten mit Hilfe der üblichen Wertetabellen für logische Operatoren aus, die wir hier zur Erinnerung noch einmal angeben:
{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>a</math>
|width="70px"| <math>b</math>
|width="70px"| <math>a \vee b </math>
|width="70px"| <math>a \wedge b</math>
|width="70px"| <math>a \rightarrow b</math>
|width="70px"| <math>b \rightarrow a</math>
|width="70px"| <math>a \leftrightarrow b</math>
|width="70px"| <math>a \neq b</math>
|- align="center"
| 0 || 0 || 0 || 0 || 1 || 1 || 1 || 0
|- align="center"
| 0 || 1 || 1 || 0 || 1 || 0 || 0 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 0 || 1 || 0 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1 || 0
|}

Beim Erfüllbarkeitsproblem wird die Frage umgekehrt gestellt:
:Gegeben sei eine logische Funktion. Ist es möglich, dass die Funktion jemals den Wert True annimmt?
Das heisst, kann man die Variablen <math>x_i</math> so mit True oder False belegen, dass die Formel am Ende wahr ist? Im Prinzip kann man diese Frage durch erschöpfende Suche leicht beantworten, indem man die Funktion für alle <math>2^n</math> möglichen Belegungen einfach ausrechnet, aber das dauert für große n (ab ca. <math>n\ge 40</math>) viel zu lange. Erstaunlicherweise ist es aber noch niemanden gelungen, einen Algorithmus zu finden, der für beliebige logische Funktionen schneller funktioniert. Im Gegenteil wurde gezeigt, dass das Erfüllbarkeitsproblem [[NP-Vollständigkeit|NP-vollständig]] ist, so dass wahrscheinlich kein solcher Algorithmus existiert. Trotz (oder gerade wegen) seiner Schwierigkeit hat das Erfüllbarkeitsproblem viele Anwendungen gefunden, vor allem beim Testen logischer Schaltkreise ("Gibt es eine Belegung der Eingänge, so dass am Ausgang der verbotene Wert X entsteht?") und bei der Planerstellung in der künstlichen Intelligenz ("Kann man ausschließen, dass der generierte Plan Konflikte enthält?"). Es ist außerdem ein beliebtes Modellproblem für die Erforschung neuer Ideen und Algorithmen für schwierige Probleme.

==== Normalformen für logische Ausdrücke ====

Um die Beschreibung von Erfüllbarkeitsproblemen zu vereinfachen und zu vereinheitlichen, hat man verschiedene Normalformen für logische Ausdrücke eingeführt. Die wichtigste ist die Konjuktionen-Normalform (CNF - conjunctive normal form). Ein Ausdruck in Konjuktionen-Normalform ist eine UND-Verknüpfung von M Klauseln:
(CLAUSE1) <math>\wedge</math> (CLAUSE2) <math>\wedge</math> ... <math>\wedge</math> (CLAUSEM)
Jede Klausel ist wiederum ein logischer Ausdruck, der aber sehr einfach sein muss: Er darf nur noch k Variablen enthalten, die nur mit den Operatoren NICHT und ODER verknüpft werden dürfen, z.B.
CLAUSE1 := <math>x_1 \vee \neg x_3 \vee x_8</math>
Je nachdem, wie viele Variablen pro Klausel erlaubt sind, spricht man von k-CNF und entsprechend von einem k-SAT Problem. Es ist außerdem üblich, die Menge der Variablen und die Menge der negierten Variablen zusammen als Menge der Literale zu bezeichnen:
LITERALS := <math>\{x_1,...,x_n\} \cup \{\neg x_1,...,\neg x_n\}</math>
Formal definiert man die k-Konjunktionen-Normalform (k-CNF) am besten durch eine Grammatik in [http://de.wikipedia.org/wiki/Backus-Naur-Form Backus-Naur-Form]:
k_CNF ::= CLAUSE | k_CNF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\vee</math> ... <math>\vee</math> LITERAL) # genau k Literale pro Klausel
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
Beispiele:
* 3-CNF: <math>(x_1 \vee \neg x_2 \vee x_4) \wedge (x_2 \vee x_3 \vee \neg x_4) \wedge (\neg x_1 \vee x_4 \vee \neg x_5)</math>
* 2-CNF: <math>(x_1 \vee \neg x_2) \wedge (x_3 \vee x_4)</math> ...
Gesucht ist eine Belegung der Variablen mit True und False, so dass der Ausdruck den Wert True hat. Aus den Eigenschaften der UND- und ODER-Verknüpfungen folgt, dass ein Ausdruck in k-CNF genau dann True ist, wenn jede einzelne Klausel True ist. In jeder Klausel wiederum hat man k Chancen, die Klausel True zu machen, indem man eins der Literale zu True macht. Eventuell werden dadurch aber andere Klauseln wieder zu False, was die Aufgabe so schwierig macht. Die Bedeutung der k-CNF ergibt sich aus folgendem
;Satz: Jeder logische Ausdruck kann effizient nach 3-CNF transformiert werden, jedoch im allgemeinen nicht nach 2-CNF.
Man kann sich also auf Algorithmen für 3-SAT-Probleme konzentrieren, ohne dabei an Ausdrucksmächtigkeit zu verlieren.

Leider gilt der entsprechende Satz nicht für k=2: Ausdrücke in 2-CNF sind weit weniger mächtig, weil man in jeder Klausel nur noch zwei Wahlmöglichkeiten hat. Bestimmte logische Ausdrücke sind aber auch nach 2-CNF transformierbar, beispielsweise die Bedingung, dass zwei Literale u und v immer den entgegegesetzten Wert haben müssen. Dies ergibt ein Paar von ODER-Verknüpfungen:
:<math>(u \leftrightarrow \neg v) \equiv (u \vee \neg v) \wedge (\neg u \vee v)</math>
Die 2-CNF hat den Vorteil, dass es effiziente Algorithmen für das 2-SAT-Problem gibt, die wir jetzt kennenlernen wollen. Es zeigt sich, dass man Ausdrücke in 2-CNF als Graphen repräsentieren kann, indem man sie zunächst in die Implikationen-Normalform (INF für implicative normal form) überführt. Die Implikationen-Normalform besteht ebenfalls aus einer Menge von Klauseln, die durch UND-Operationen verknüpft sind, aber jede Klausel ist jetzt eine Implikation.
Die Grammatik der Implikationen-Normalform (INF) lautet:
INF ::= CLAUSE | INF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\rightarrow</math> LITERAL) # genau 2 Literale pro Implikation
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
und ein gültiger Ausdruck wäre z.B.
:<math>(x_1 \to x_2) \wedge (x_2 \to \neg x_3) \wedge (x_4 \to x_3)</math>
Die Umwandlung von 2-CNF nach INF beruht auf folgender Äquivalenz, die man sich aus der obigen Wahrheitstabelle leicht herleitet:
:<math>(x \vee y) \equiv (\neg x \rightarrow y) \equiv (\neg y \rightarrow x)</math>
Aus dieser Äquivalenz folgt der
;Satz: Ein Ausdruck in 2-CNF kann nach INF transformiert werden, indem man jede Klausel <math>(x \vee y)</math> durch das Klauselpaar <math>(\neg x \rightarrow y) \wedge (\neg y \rightarrow x)</math> ersetzt.
Man beachte, dass man für jede ODER-Klausel des ursprünglichen Ausdrucks zwei Implikationen (eine für jede Richtung des "wenn, dann") einfügen muss, um die Symmetrie des Problems zu erhalten.

==== Lösung des 2-SAT-Problems mit Implikationgraphen ====

Jeder Ausdruck in INF kann als gerichteter Graph dargestellt werden:
# Für jedes Literal wird ein Knoten in den Graphen eingefügt. Es gibt also für jede Variable und für ihre Negation jeweils einen Knoten, d.h. 2n Knoten insgesamt.
# Jede Implikation ist eine gerichtete Kante.
Implikationengraphen eignen sich, um Ursache-Folge-Beziehungen oder Konflikte zwischen Aktionen auszudrücken. Beispielsweise kann man die Klausel <math>(x \rightarrow \neg y)</math> als "wenn man x tut, darf man y nicht tun" interpretieren. Ein anderes schönes Beispiel findet sich in Übung 12.

Für die Implementation eines Implikationengraphen in Python empfiehlt es sich, die Knoten geschickt zu numerieren: Ist die Variable <math>x_i</math> dem Knoten i zugeordnet, so sollte die negierte Variable <math>\neg x_i</math> dem Knoten (i+n) zugeordnet werden. Zu jedem gegebenen Knoten i findet man dann den negierten Partnerknoten j leicht durch die Formel <tt>j = (i + n ) % (2*n)</tt>.

Die Aufgabe besteht jetzt darin, folgende Fragen zu beantworten:
# Ist der durch den Implikationengraphen gegebene Ausdruck erfüllbar?
# Finde eine geeignete Belegung der Variablen, wenn der Ausduck erfüllbar ist.
Die erste Frage beantwortet man leicht, indem man die stark zusammenhängenden Komponenten des Implikationengraphen bildet. Dann gilt folgender
;Satz: Seien u und v zwei Literale, die sich in der selben stark zusammenhängenden Komponente befinden. Dann müssen u und v stets den selben Wert haben, damit der Ausdruck erfüllt sein kann.
Die Korrektheit des Satzes folgt aus der Definition der stark zusammenhängenden Komponenten: Da u und v in der selben Komponente liegen, gibt es im Implikationengraphen einen Weg <math>u \rightsquigarrow v</math> sowie einen Weg <math>v \rightsquigarrow u</math>. Wegen der Transitivität der "wenn, dann" Relation kann man die Wege zu zwei Implikationen verkürzen, die gleichzeitig gelten müssen: <math>(u \rightarrow v) \wedge (v \rightarrow u)</math> (die Verkürzung von Wegen zu direkten Kanten entspricht gerade der Bildung der transitiven Hülle für die Knoten u und v). In der obigen Wertetabelle für logische Operatoren erkennt mann, dass dies äquivalent zur Bedingung <math>(u \leftrightarrow v)</math> ist. Dies ist aber gerade die Behauptung des Satzes.

Die Erfüllbarkeit des Ausdrucks ist nun ein einfacher Spezialfall dieses Satzes.
;Korrolar: Der gegebene Ausdruck ist genau dann erfüllbar, wenn die Literale <math>x_i</math> und <math>\neg x_i</math> sich für kein i in derselben stark zusammenhängenden Komponente befinden.
Setzt man nämlich im Satz <math>u = x_i</math> und <math>v = \neg x_i</math>, und beide Knoten befinden sich in der selben Komponente, dann müsste gelten <math>x_i \leftrightarrow\neg x_i</math>, was offensichtlich ein Widerspruch ist. Damit kann der Ausdruck nicht erfüllbar sein. Umgekehrt gilt, dass der Ausdruck immer erfüllbar ist, wenn <math>x_i</math> und <math>\neg x_i</math> stets in verschiedenen Komponenten liegen, weil der folgende Algorithmus von Aspvall, Plass und Tarjan in diesem Fall stets eine gültige Belegung aller Variablen liefert:
# Bestimme die stark zusammenhängenden Komponenten und bilde den Komponentengraphen. Ordne die Knoten des Komponentengraphen (also die stark zusammenhängenden Komponenten des Originalgraphen) in topologische Sortierung an.
# Betrachte die Komponenten in der topologischen Sortierung von hinten nach vorn und weise ihnen einen Wert nach folgenden Regeln zu (zur Erinnerung: alle Literale in der selben Komponente haben den selben Wert):
#* Wenn die Komponente noch nicht betrachtet wurde, setze ihren Wert auf True, und den Wert der komplementären Komponente (derjenigen, die die negierten Literale enthält) auf False.
#* Andernfalls, gehe zur nächsten Komponente weiter.
Der Algorithmus beruht auf der Symmetrie des Implikationengraphen: Weil Kanten immer paarweise <math>(\neg u \rightarrow v) \wedge (\neg v \rightarrow u)</math> eingefügt werden, ist der Graph schiefsymmetrisch (skew symmetric): die eine Hälfte das Graphen ist die transponierte Spiegelung der anderen Hälfte. Enthält eine stark zusammenhängende Komponente <math>C_i</math> die Knoten <tt>i1, i2, ...</tt>, so gibt es stets eine komplementäre Komponente <math>C_j = \neg C_i</math>, die die komplementären Knoten <tt>j1 = (i1 + n) % (2*n), j2 = (i2 + n) % (2*n), ...</tt> enthält. Gilt <math>C_i = \neg C_i</math> für irgendein i, so ist der Ausdruck nicht erfüllbar. Den Beweis für die Korrektheit des Algorithmus findet man im [http://www.math.ucsd.edu/~sbuss/CourseWeb/Math268_2007WS/2SAT.pdf Originalartikel]. Leider funktioniert dies nicht für k-SAT-Probleme mit <math>k > 2</math>.

Will man nur die Erfüllbarkeit prüfen, vereinfacht sich der Algorithmus zu:
# Bestimme die stark zusammenhängenden Komponenten.
# Teste für alle <tt>i = 0,...,n-1</tt>, dass Knoten <tt>i</tt> und Knoten <tt>(i+n)</tt> in unterschiedlichen Komponenten liegen.
Ist der Ausdruck erfüllbar, kann man eine gültige Belegung der Variablen jetzt mit dem randomisierten Algorithmus bestimmen, den wir im Kapitel [[Randomisierte Algorithmen]] behandeln.

== Weitere wichtige Graphenalgorithmen ==

Eins der wichtigsten Einsatzgebiete für Graphen ist die Optimierung, also die Suche nach der besten Lösung für ein gegebenes Problem:
* Das interval scheduling befasst sich damit, aus einer gegebenen Menge von Aufträgen die richtigen auszuwählen und sie geschickt auf die zur Verfügung stehenden Ressourcen aufzuteilen. Damit beschäftigen wir uns im Kapitel [[Greedy-Algorithmen und Dynamische Programmierung]].
* Beim Problem des Handlungsreisenden sucht man nach der kürzesten Rundreise, die alle gegebenen Städte genau einmal besucht. Dieses Problem behandeln wir im Kapitel [[NP-Vollständigkeit]].
* Viele weitere Anwendungen können wir leider in der Vorlesung nicht mehr behandeln, z.B.
** Algorithmen für den [http://en.wikipedia.org/wiki/Maximum_flow_problem maximalen Fluss] beantworten die Frage, wie man die Durchflussmenge durch ein Netzwerk (z.B. von Ölpipelines) maximiert.
** Beim [http://en.wikipedia.org/wiki/Assignment_problem Problem der optimalen Paarung] ("matching problem" oder "assignment problem") sucht man nach einer Teilmenge der Kanten (also nach einem Teilgraphen), so dass jeder Knoten in diesem Teilgraphen höchstens den Grad 1 hat. Im neuen Graphen gruppieren die Kanten also je zwei Knoten zu einem Paar, und die Paarung soll nach jeweils anwendungsspezifischen Kriterien optimal sein. Dies benötigt man z.B. bei der optimalen Zuordnung von Gruppen, etwas beim Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot) und in der Universität (Zuordnung Studenten - Übungsgruppen).
** In Statistik und maschinellem Lernen haben in den letzten Jahren die [http://en.wikipedia.org/wiki/Graphical_model graphischen Modelle] große Bedeutung erlangt.
* usw. usf.

[[Randomisierte Algorithmen|Nächstes Thema]]

Graphen und Graphenalgorithmen

2012-07-25T17:09:21Z

Ukoethe: /* Algorithmus 2 */

== Einführung zu Graphen ==

=== Motivation -- Königsberger Brückenproblem ===
Leonhard Euler [http://de.wikipedia.org/wiki/Leonhard_Euler] erfand den Graphen-Formalismus 1736, um eine scheinbar banale Frage zu beantworten: Ist es möglich, in Königsberg (siehe Stadtplan von 1809 und die schematische Darstellung) einen Spaziergang zu unternehmen, bei dem jede der 7 Brücken genau einmal überquert wird?

[[Image:Koenigsberg1809.png]] 
[[Image:Koenigsberg.jpg]]

Ein Graph abstrahiert von der Geometrie des Problems und repräsentiert nur die Topologie. Jeder Stadtteil von Königsberg ist ein Knoten des Graphen, jede Brücke eine Kante. Der zum Brückenproblem gehörende Graph sieht also so aus:

O
/| \
\| \
O---O
/| /
\| /
O

Der gesuchte Spaziergang würde existieren, wenn es maximal 2 Knoten gäbe, an denen sich eine ungerade Zahl von Kanten trifft. Die Frage muss für Königsberg also verneint werden, denn hier gibt es vier solche Knoten. Ein leicht modifiziertes Problem ist allerdings lösbar: Im obigen Stadtplan erkennt man eine Fähre, die die Stadtteile Kneiphof und Altstadt verbindet. Bezieht man dieselbe in den Spaziergang ein, ergibt sich folgender Graph, bei dem nur noch zwei Knoten mit ungerader Kantenzahl existieren:

--O
/ /| \
\ \| \
--O---O
/| /
\| /
O

Inzwischen haben Graphen eine riesige Zahl weiterer Anwendungen gefunden. Einige Beispiele:

* Landkarten:
** Knoten: Länder
** Kanten: gemeinsame Grenzen

* Logische Schaltkreise:
** Knoten: Gatter
** Kanten: Verbindungen

* Chemie (Summenformeln):
** Knoten: chemische Elemente
** Kanten: Bindungen

* Soziologie (StudiVZ)
** Soziogramm
*** Knoten: Personen
*** Kanten: Freund von ...

=== Definitionen ===

;Ungerichteter Graph: Ein ungerichteter Graph G = ( V, E ) besteht aus
:* einer endliche Menge V von Knoten (vertices)
:* einer endlichen Menge <math>E \subset V \times V</math> von Kanten (edges)
:Die Paare (u,v) und (v,u) gelten dabei als nur ''eine'' Kante (somit gilt die Symmetriebeziehung: (u,v) ∈ E => (v,u) ∈ E ). Die Anzahl der Kanten, die sich an einem Knoten treffen, wird als ''Grad'' (engl. ''degree'') dieses Knotens bezeichnet:
:::degree(v) = |{v' ∈ V | (v,v') ∈ E}|
:(Die Syntax |{...}| bezeichnet dabei die Mächtigkeit der angegebenen Menge, also die Anzahl der Elemente in der Menge.)

Der Graph des Königsberger Brückenproblems ist ungerichtet. Bezeichnet man die Knoten entsprechend des folgenden Bildes
c
/| \
\| \
b---d
/| /
\| /
a

gilt für die Knotengrade: <tt>degree(a) == degree(c) == degree(d) == 3</tt> und <tt>degree(b) == 5</tt>. Genauer muss man bei diesem Graphen von einem ''Multigraphen'' sprechen, weil es zwischen einigen Knotenpaaren (nämlich (a, b) sowie (b, c)) mehrere Kanten ("Mehrfachkanten") gibt. Wir werden in dieser Vorlesung nicht näher auf Multigraphen eingehen.

;Gerichteter Graph: Ein Graph heißt ''gerichtet'', wenn die Kanten (u,v) und (v,u) unterschieden werden. Die Kante (u,v) ∈ E wird nun als Kante von u nach v (aber nicht umgekehrt) interpretiert. Entsprechend unterscheidet man jetzt den ''eingehenden'' und den ''ausgehenden Grad'' jedes Knotens:
:*out_degree(v) = |{v' ∈ V | (v,v') ∈ E}| 
:*in_degree(v) = |{v' ∈ V| (v',v) ∈ E}|

Das folgende Bild zeigt einen gerichteten Graphen. Hier gilt <tt>out_degree(1) == out_degree(3) == in_degree(2) == in_degree(4) == 2</tt> und
<tt>in_degree(1) == in_degree(3) == out_degree(2) == out_degree(4) == 0</tt>:

[[Image:digraph.png|gerichteter Graph]]

 

;Vollständiger Graph: Ein vollständiger Graph ist ein ungerichteter Graph, bei dem jeder Knoten mit allen anderen Knoten verbunden ist.
:::<math>E = \{ (v,w) | v \in V, w \in V, v \ne w \}</math>
:Ein vollständiger Graph mit |V| Knoten hat <math>|E| = \frac{|V|(|V|-1)}{2}</math> Kanten.

Die folgenden Abbildungen zeigen die vollständigen Graphen mit einem bis fünf Knoten (auch als K1 bis K5 bezeichnet).

{| border="0" cellspacing="0" cellpadding="0" style="margin: 1em auto 1em auto"
|-
| [[Image:k1.png|frame|k1]]
| [[Image:k2.png|frame|k2]]
| [[Image:k3.png|frame|k3]]
|-
| [[Image:k4.png|frame|k4]]
| [[Image:k5.png|frame|k5]]
|
|}

''Rätsel'' 
Auf einer Party sind Leute. Alle stoßen miteinander an. Es hat 78 mal "Pling" gemacht.
Wieviele Leute waren da? Antwort: Jede Person ist ein Knoten des Graphen, jedes Antoßen eine Kante.
Da alle miteinander angestoßen haben, handelt es sich um einen vollständigen Graphen. Mit
|V|(|V|-1)/2 = 78 folgt, dass es 13 Personen waren.

 

;Gewichteter Graph: Ein Graph heißt ''gewichtet'', wenn jeder Kante eine reelle Zahl zugeordnet ist. Bei vielen Anwendungen beschränkt man sich auch auf nichtnegative reelle Gewichte. In einem gerichteten Graphen können die Gewichte der Kanten (u,v) und (v,u) unterschiedlich sein.

Die Gewichte kodieren Eigenschaften der Kanten, die für die jeweilige Anwendung interessant sind. Bei der Berechnung des maximalen Flusses in einem Netzwerk sind die Gewichte z.B. die Durchflusskapazitäten jeder Kante, bei der Suche nach kürzesten Weges kodieren Sie den Abstand zwischen den Endknoten der Kante, bei Währungsnetzwerken (jeder Knoten ist eine Währung) geben sie die Wechselkurse an, usw..

 

;Teilgraphen: Ein Graph G' = (V',E') ist ein Teilgraph eines Graphen G, wenn gilt:
:* V' &sube; V
:* E' ⊂ E
:Er heißt ''(auf)spannender Teilgraph'', wenn gilt:
:* V' = V
:Er heißt ''induzierter Teilgraph'', wenn gilt:
:* e = (u,v) ∈ E' ⊂ E ⇔ u ∈ V' und v ∈ V'
:Den von V' induzierten Teilgraphen erhält man also, indem man aus G alle Knoten löscht, die nicht in V' sind, sowie alle Kanten (und nur diese Kanten), die einen der gelöschten Knoten als Endknoten haben.

 

;Wege, Pfade, Zyklen, Kreise, Erreichbarkeit: Sei G = (V,E) ein Graph (ungerichtet oder gerichteter) Graph. Dann gilt folgende rekursive Definition:
:* Für v ∈ V ist (v) ein Weg der Länge 0 in G
:* Falls <math>(v_0, v_1, ..., v_{n-1})</math> ein Weg ist, und eine Kante <math>(v_{n-1}, v_n)\in E</math> existiert, dann ist auch <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ein Weg, und er hat die Länge n.
: Ein Weg ist also eine nichtleere Folge von Knoten, so dass aufeinander folgende Knoten stets durch eine Kante verbunden sind. Die Länge des Weges entspricht der Anzahl der Kanten im Weg (= Anzahl der Knoten - 1).
:* Ein ''Pfad'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, bei dem alle Knoten vi verschieden sind.
:* ''Ein Zyklus'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, der zum Ausgangspunkt zurückkehrt, wenn also v0 = vn gilt.
:* Ein ''Kreis'' ist ein Zyklus ohne Überkreuzungen. Das heisst, es gilt v0 = vn und <math>(v_0, v_1, ..., v_{n-1})</math> ist ein Pfad.
:* Ein Knoten w ∈ V ist von einem anderen Knoten v ∈ V aus ''erreichbar'' genau dann, wenn ein Weg (v, ..., w) existiert. Wir schreiben dann <math>v \rightsquigarrow w</math>.
In einem ungerichteten Graph ist die Erreichbarkeits-Relation stets symmetrisch, das heisst aus <math>v \rightsquigarrow w</math> folgt <math>w \rightsquigarrow v</math>. In einem gerichteten Graphen ist dies im allgemeinen nicht der Fall.

Bestimmte Wege haben spezielle Namen

;Eulerweg: Ein Eulerweg ist ein Weg, der alle '''Kanten''' genau einmal enthält.

Die eingangs erwähnte Frage des Königsberger Brückenproblems ist equivalent zu der Frage, ob der dazugehörige Graph einen Eulerweg besitzt (daher der Name). Ein anderes bekanntes Beispiel ist das "Haus vom Nikolaus": Wenn man diesen Graphen in üblicher Weise in einem Zug zeichnet, erhält man gerade den Eulerweg.

O
/ \
O----O
| \/ |
| /\ | "Das Haus vom Nikolaus": Alle ''Kanten'' werden nur ''einmal'' passiert
O----O

;Hamiltonweg: Ein Hamiltonweg ist ein Weg, der alle '''Knoten''' genau einmal enthält. Das "Haus vom Nikolaus" besitzt auch einen Hamiltonweg:

O
/
O----O
/
/ Alle ''Knoten'' werden nur ''einmal'' passiert
O----O

;Hamiltonkreis: Ein Hamiltonkreis ist ein Kreis, der alle '''Knoten''' genau einmal enthält. Auch ein solches Gebilde ist im Haus von Nilolaus enthalten:

O
/ \
O O
| | v0 = vn
| | vi != vj Für Alle i,j i !=j; i,j >0; i,j < n
O----O

Die folgende Skizze zeigt hingegen einen Zyklus: Der Knoten rechts unten sowie die untere Kante sind zweimal enthalten (die Kante einmal von links nach rechts und einmal von rechts nach links):

O
/ \
O O
\ |
\ | Zyklus
O====O

 

;Zusammenhang, Zusammenhangskomponenten: Ein ungerichteter Graph G heißt ''zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math>
:Ein gerichteter Graph G ist zusammenhängend, wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''oder''' <math>w \rightsquigarrow v</math>.
:Er ist ''stark zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''und''' <math>w \rightsquigarrow v</math>.
:Entsprechende Definitionen gelten für Teilgraphen G'. Ein Teilgraph G' heisst ''Zusammenhangskomponente'' von G, wenn er ein ''maximaler'' zusammenhängender Teilgraph ist, d.h. wenn G' zusammenhängend ist, und man keine Knoten und Kanten aus G mehr zu G' hinzufügen kann, so dass G' immer noch zusammenhängend bleibt. Entsprechend definiert man ''starke Zusammenhangskomponenten'' in einem gerichteten Graphen.

 

;Planarer Graph, ebener Graph: Ein Graph heißt ''planar'', wenn er so in einer Ebene gezeichnet werden ''kann'', dass sich die Kanten nicht schneiden (außer an den Knoten). Ein Graph heißt ''eben'', wenn er tatsächlich so gezeichnet ''ist'', dass sich die Kanten nicht schneiden. Die Einbettung in die Ebene ist im allgemeinen nicht eindeutig.

'''Beispiele:'''

Der folgende Graph ist planar und eben:

O
/|\
/ O \
/ / \ \
O O

Das "Haus vom Nikolaus" ist ebenfalls planar, wird aber üblicherweise nicht als ebener Graph gezeichnet, weil sich die Diagonalen auf der Wand überkreuzen:

O
/ \
O----O
| \/ |
| /\ |
O----O

Eine ebene Einbettung dieses Graphen wird erreicht, wenn man eine der Diagonalen ausserhalb des Hauses zeichnet. Der Graph (also die Menge der Knoten und Kanten) ändert sich dadurch nicht.

O
/ \
--O----O
/ | / |
| | / |
| O----O Das "Haus vom Nikolaus" als ebener Graph gezeichnet.
\ /
-----

Eine alternative Einbettung erhalten wir, wenn wir die andere Diagonale außerhalb des Hauses zeichnen:

O
/ \
O----O--|
| \ | |
| \ | |
O----O | Alternative Einbettung des "Haus vom Nikolaus".
| |
|-------|

Jede Einbettung eines planaren Graphen (also jeder ebene Graph) definiert eine eindeutige Menge von ''Regionen'':

|----O @
| /@ \
| O----O
| |@ / |
| | / @|
| O----O @ entspricht jeweils einer ''Region''. Auch ausserhalb der Figur ist eine Region (die sogenannte ''unendliche'' Region).
|@ |
|-------|

Der vollständige Graph K5 ist kein planarer Graph, da sich zwangsweise Kanten schneiden, wenn man diesen Graphen in der Ebene zeichnet.

 
;Dualer Graph: Jeder ebene Graph G = (V, E) hat einen ''dualen Graphen'' D = (VD, ED), dessen Knoten und Kanten wie folgt definiert sind:
:* VD enthält einen Knoten für jede Region des Graphen G
:* Für jede Kante e ∈ E gibt es eine duale Kante eD ∈ ED, die die an e angrenzenden Regionen (genauer: die entsprechenden Knoten in D) verbindet.

Die folgende Abbildung zeigt einen Graphen (grau) und seinen dualen Graphen (schwarz). Die Knoten des dualen Graphen sind mit Zahlen gekennzeichnet und entsprechen den Regionen des Originalgraphen. Jeder (grauen) Kante des Originalgraphen entspricht eine (schwarze) Kante des dualen Graphen.

 
[[Image:dual-graphs.png]]
 

Für duale Graphen gilt: Wenn der Originalgraph zusammenhängend ist, enthält jede Region des dualen Graphen genau einen Knoten des Originalgraphen. Deshalb ist der duale Graph des dualen Graphen wieder der Originalgraph. Bei nicht-zusammenhängenden Graphen gilt dies nicht (vgl. das Fenster bei obigem Bild). In diesem Fall hat der duale Graph mehrere mögliche Einbettungen in die Ebene (man kann z.B. die rechte Kante zwischen Knoten 2 und 4 auch links vom Fenster einzeichnen), und man erhält nicht notwendigerweise den Originalgraphen, wenn man den dualen Graphen des dualen berechnet.

;Baum: Ein ''Baum'' ist ein zusammenhängender, kreisfreier Graph.

Beispiel: Binärer Suchbaum

;Spannbaum: Ein ''Spannbaum'' eines zusammenhängenden Graphen G ist ein zusammenhängender, kreisfreier Teilgraph von G, der alle Knoten von G enthält

Beispiel: Spannbaum für das "Haus des Nikolaus"

O
/
O O
| /
| /
O----O

Der Spannbaum eines Graphen mit |V| Knoten hat stets |V| - 1 Kanten.

;Wald: Ein ''Wald'' ist ein unzusammenhängender, kreisfreier Graph.
: Jede Zusammenhangskomponente eines Waldes ist ein Baum.

=== Repräsentation von Graphen ===

Sei G = ( V, E ) gegeben und liege V in einer linearen Sortierung vor. 
:::<math>V = \{ v_1, ...., v_n \}</math>

;Adjazenzmatrix: Ein Graph kann durch eine Adjazenzmatrix repräsentiert werden, die soviele Zeilen und Spalten enthält, wie der Graph Knoten hat. Die Elemente der Adjazenzmatrix sind "1", falls eine Kante zwischen den zugehörigen Knoten existiert:
:::<math>\mathrm{\bold A} = a_{ij} =
\begin{cases}
1 & \mathrm{falls}\quad (v_i, v_j) \in E \\
0 & \mathrm{sonst}
\end{cases}
</math>
:Die Indizes der Matrix entsprechen also den Indizes der Knoten gemäß der gegebenen Sortierung. Im Falle eines ungerichteten Graphen ist die Adjazenzmatrix stets symmetrisch (d.h. es gilt <math>a_{ij}=a_{ji}</math>), bei einem gerichteten Graphen ist sie im allgemeinen unsymmetrisch.

Beispiel für einen ungerichteten Graphen:

v = { a,b,c,d } b d
| \ / |
| \/ |
| /\ |
| / \ |
a c

a b c d
-----------
(0 1 0 1) |a
A = (1 0 1 0) |b
(0 1 0 1) |c
(1 0 1 0) |d

Die Adjazenzmatrixdarstellung eignet sich besonders für dichte Graphen (d.h. wenn die Zahl der Kanten in O(|V|2) ist.

;Adjazenzlisten: In der Adjazenzlistendarstellung wird der Graph als Liste von Knoten repräsentiert, die für jeden Knoten einen Eintrag enthält. Der Eintrag für jeden Knoten ist wiederum eine Liste, die die Nachbarknoten dieses Knotens enthält:
:* graph = {adjazencyList(v) | v ∈ V}
:* adjazencyList(v) = {v' ∈ V | (v, v') ∈ E}

In Python implementieren wir Adjazenzlisten zweckmäßig als Array von Arrays:

graph = [[...],[...],...,[...]]
Adjazenzliste für Knoten => 0 1 n

Wenn wir bei dem Graphen oben die Knoten wie bei der Adjazenzmatrix indizieren (also <tt>a => 0</tt>, <tt>b => 1</tt>, <tt>c => 2</tt>, <tt>d => 3</tt>), erhalten wir die Adjazenzlistendarstellung:

graph = [[b, d], [a, c],[b, d], [a, c]]

Auf die Nachbarknoten eines durch seinen Index <tt>node</tt> gegebenen Knotens können wir also wie folgt zugreifen:

for neighbors in graph[node]:
... # do something with neighbor

Die Adjazenzlistendarstellung ist effizienter, wenn der Graph nicht dicht ist, so dass viele Einträge der Adjazenzmatrix Null wären. In der Vorlesung werden wir nur diese Darstellung verwenden.

;<div id="transposed_graph">Transponierter Graph</div>: Den ''transponierten Graphen'' GT eines gerichteten Graphen G erhält man, wenn man alle Kantenrichtungen umkehrt.

Bei ungerichteten Graphen hat die Transposition offensichtlich keinen Effekt, weil alle Kanten bereits in beiden Richtungen vorhanden sind, so dass GT = G gilt. Bei gerichteten Graphen ist die Transposition einfach, wenn der Graph als Adjazenzmatrix implementiert ist, weil man einfach die transponierte Adjazenzmatrix verwenden muss (beachte, dass sich die Reihenfolge der Indizes umkehrt):
:::AT = aji
Ist der Graph hingegen durch eine Adjazenzliste repräsentiert, muss etwas mehr Aufwand getrieben werden:

def transposeGraph(graph):
gt = [[] for k in graph] # zunächst leere Adjazenzlisten von GT
for node in range(len(graph)):
for neighbor in graph[node]:
gt[neighbor].append(node) # füge die umgekehrte Kante in GT ein
return gt

== Durchlaufen von Graphen (Graph Traversal) ==

Wir betrachten zunächst ungerichtete Graphen mit V Knoten und E Kanten. Eine grundlegende Aufgabe in diesen Graphen besteht darin, alle Knoten in einer bestimmten Reihenfolge genau einmal zu besuchen. Hierbei darf man sich von einem gegebenen Startknoten aus nur entlang der Kanten des Graphen bewegen. Die beim Traversieren benutzen Kanten bilden einen Baum, dessen Wurzel der Startknoten ist und der den gesamten Graphen aufspannt, falls der Graph zusammenhängend ist. (Beweis: Da jeder Knoten nur einmal besucht wird, gibt es für jeden besuchten Knoten [mit Ausnahme des Startknotens] genau eine eingehende Kante. Ist der Graph zusammenhängend, wird jeder Knoten tatsächlich erreicht und es gibt genau (V-1) Kanten, exakt soviele wie für einen Baum mit V Knoten notwendig sind.) Ist der Graph nicht zusammenhängend, wird jeder zusammenhängende Teilgraph (jede Zusammenhangskomponente) getrennt traversiert, und man erhält einen sogenannten Wald mit einem Baum pro Zusammenhangskomponente. Die beiden grundlegenden Traversierungsmethoden Tiefensuche und Breitensuche werden im folgenden vorgestellt.

=== Tiefensuche in Graphen (Depth First Search, DFS) ===

Die Idee der Tiefensuche besteht darin, jeden besuchten Knoten sofort über die erste Kante wieder zu verlassen, die zu einem noch nicht besuchten Knoten führt. Man findet dadurch schnell einen möglichst langen Pfad durch den Graphen, und der Traversierungs-Baum wird zunächst in die Tiefe verfolgt, daher der Name des Verfahrens. Hat ein Knoten keine unbesuchten Nachbarknoten mehr, geht man im Baum zurück (sogenanntes back tracking), bis man einen Knoten findet, der noch eine unbesuchte Nachbarn besitzt, und traversiert diese nach dem gleichen Muster. Gibt es gar keine unbesuchten Knoten mehr, kehrt die Suche zum Startknoten zurück und endet dort.

WDie folgende rekursive Implementation der Tiefensuche erwartet den Graphen in Adjazenzlistendarstellung und beginnt die Suche beim Knoten <tt>startnode</tt>. Die Information, ob ein Knoten bereits besucht wurde, wird im Array <tt>visited</tt> gespeichert. Ein solches Array, das zusätzliche Informationen über die Knoten des Graphen bereitstellt, wir häufig property map genannt.

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
print node # Ausgabe der Knotennummer - pre-order
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)

visit(startnode)

[[Image:Tiefens.jpg]]

Ausgabe für den Graphen in diesem Bild (es handelt sich um einen ungerichteten Graphen, die Pfeile symbolisieren nur die Suchrichtung beim Traversal):

>>> dfs(graph, 1)
1
2
4
3
6
7
5

<div id="pre_and_post_order">In dieser Version des Algorithmus werden die Knotennummern ausgegeben, bevor die Nachbarknoten besucht werden. Man bezeichnet die resultierende Sortierung der Knoten als pre-order oder als discovery order. Alternativ kann man die Knotennummern erst ausgeben, nachdem alle Nachbarn besucht wurden, also auf dem Rückweg der Rekursion. In diesem Fall spricht man von post-order oder finishing order:</div>

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)
print node # Ausgabe der Knotennummer - post-order

visit(startnode)

Es ergibt sich jetzt die Ausgabe:

>>> dfs(graph, 1)
6
7
3
4
5
2
1

In realem Code ersetzt man die print-Ausgaben natürlich durch anwendungsspezifische Aktionen und Berechnungen. Einige Anwendungen sind uns im Kapitel [[Suchen]] bereits begegnet.
; Anwendungen der Pre-Order Traversierung
* Kopieren eines Graphen: kopiere zuerst den besuchten Knoten, dann seine Nachbarn und die dazugehörigen Kanten (sowie die Kanten zu bereits besuchten Knoten, die in der Grundversion der Tiefensuche ignoriert werden).
* Bestimmen der Zusammenhangskomponenten eines Graphen (siehe unten)
* In einem Zeichenprogramm: fülle eine Region mit einer Farbe ("flood fill"). Dabei ist jedes Pixel ein Knoten des Graphen und wird mit seinen 4 Nachbarpixceln verbunden. Die Tiefensuche startet bei der Mausposition und endet am Rand des betreffendcen Gebiets.
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von der Wurzel
* Falls der Graph ein Parse-Baum ist, wobei innere Knoten Funktionsaufrufe, Kindknoten Funktionsargumente, und Blattknoten Werte repräsentieren: drucke den zugehörigen Ausdruck aus (also immer zuerst den Funktionsnamen, dann die Argumente, die wiederum geschachtelte Funktionsaufrufe sein können).
; Anwendungen der Post-Order Traversierung
* Löschen eines Graphen: lösche zuerst die Nachbarn, dann den Knoten selbst
* Bestimmen einer topologischen Sortierung eines azyklischen gerichteten Graphens (siehe unten)
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von den Blättern (also die Tiefe des Baumes, siehe Übung 5)
* Falls der Graph ein Parse-Baum ist: führe die zugehörige Berechnung aus (d.h. berechne zuerst die geschachtelten inneren Funktionen, dann mit diesen Ergebnissen die nächst äußeren usw., siehe Übung 5).
; Anwendungen, die Pre- und Post-Order benötigen
* Weg aus einem Labyrinth: die Pre-Order dokumentiert die Suche nach dem Weg, die Post-Order zeigt den Rückweg aus Sackgassen (siehe Übung 9).
Im Spezialfall, wenn der Graph ein Binärbaum ist, unterscheidet man noch eine dritte Variante der Traversierung, nämlich die in-order Traversierung. In diesem Fall behandelt man den Vaterknoten nach den linken, aber vor den rechten Kindern. Diese Reihenfolge wird beim [[Suchen#Beziehungen zwischen dem Suchproblem und dem Sortierproblem|Tree Sort Algorithmus]] verwendet. Diese Sortierung verwendet man auch, wenn man einen Parse-Baum mit binären Operatoren (statt Funktionsaufrufen) ausgeben will, siehe Übung 5.

Eine nützliche Erweiterung der Tiefensuche besteht darin, in der property map <tt>visited</tt> nicht nur zu dokumentieren, dass ein Knoten bereits besucht wurde, sondern auch, von welchem Knoten aus man den jeweiligen Knoten zuerst erreicht hat. Im entstehenden Tiefensuchbaum ist dies gerade der Vaterknoten, weshalb wir die verbesserte property map zweckmäßigerweise in <tt>parents</tt> umbenennen. Für den Startknoten, also die Wurzel des Baumes, wählen wir die Konvention, dass er sein eigener Vaterknoten ist (die Konvention, dafür den Wert <tt>None</tt> zu verwenden, scheidet aus, weil dies bereits die Tatsache signalisiert, dass ein Knoten noch nicht besucht wurde):

def dfs(graph, startnode):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Tiefensuchbaum

def visit(node, parent): # rekursive Hilfsfunktion
if parents[node] is None: # Besuche node, wenn er noch nicht besucht wurde
parents[node] = parent # Markiere node als besucht und speichere seinen Vaterknoten
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn ...
visit(neighbor, node) # ... wobei node zu deren Vaterknoten wird

visit(startnode, startnode) # Konvention für Wurzel: startnode ist sein eigener Vater

return parents # Rückgabe des berechneten Tiefensuch-Baums

Die Ausgabe für den obigen Beispielgraphen lautet:
Knotennummer | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
--------------+-----+-----+-----+-----+-----+-----+-----+-----
Vaterknoten | None| 1 | 1 | 4 | 2 | 2 | 3 | 3

Dabei ist die Knotennummer der Index im Array <tt>parents</tt>, und der Vaterknoten ist der dazugehörige Arrayeintrag. Beachte, dass Knoten 0 in diesem Graphen nicht existiert, daher ist sein Eintrag <tt>None</tt>. Per Konvention hat der Wurzelknoten 1 sich selbst als Vater.

=== Breitensuche in Graphen (Breadth First Search, BFS) ===

Im Gegensatz zur Tiefensuche werden bei der Breitensuche alle Nachbarnknoten abgearbeitet, bevor man rekursiv deren Nachbarn besucht. Man betrachtet somit zuerst alle Knoten, die den Abstand 1 von Startknoten haben, dann diejenigen mit dem Abstand 2 usw. Diese Reihenfolge bezeichnet man als level-order. Wir sind ihr beispielsweise in Übung 6 begegnet, als die ersten 7 Ebenen eines Treap ausgegeben werden sollten. Man implementiert Breitensuche zweckmäßig mit Hilfe einer Queue, die die Knoten in First In - First Out - Reihenfolge bearbeitet. Eine geeignete Datenstruktur hierfür ist die Klasse <tt>[http://docs.python.org/library/collections.html#collections.deque deque]</tt> aus dem Python-Modul <tt>[http://docs.python.org/library/collections.html collections]</tt> (eine Deque implementiert sowohl die Funktionalität einer Queue wie auch die eines Stacks, siehe Übung 3):

from collections import deque

def bfs(graph, startnode)
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if not visited[node]: # Falls node noch nicht (auf einem anderen Weg) besucht wurde
visited[node] = True # Markiere node als besucht
print node # Drucke Knotennummer
for neighbor in graph[node]: # Füge Nachbarn in die Queue ein
q.append(neighbor)

[[Image:Breitens.jpg]]

Der Aufruf dieser Funktion liefert die Knoten des obigen Graphens ebenenweise, also zufällig genau in der Reihenfolge der Knotennummern:
>>> bfs(graph, 1)
1
2
3
4
5
6
7

Neben der ebenenweisen Ausgabe hat die Breitensuche viele weitere wichtige Anwendungen, z.B. beim Testen, ob ein gegebener Graph bi-partit ist (siehe [http://en.wikipedia.org/wiki/Breadth-first_search#Testing_bipartiteness WikiPedia]), sowie bei der Suche nach kürzesten Wegen (siehe unten) und kürzesten Zyklen.

== Weitere Anwendungen der Tiefensuche ==

Die Tiefensuche hat zahlreiche Anwendungen, wobei der grundlegende Algorithmus immer wieder leicht modifiziert und an die jeweilige Aufgabe angepasst wird. Wir beschreiben im folgenden einige Beispiele.

=== Damenproblem ===

Tiefensuche wird häufig verwendet, um systematisch nach der Lösung eines logischen Rätsels (oder allgemeiner nach der Lösung eines diskreten Optimierungsproblems) zu suchen. Besonders anschaulich hierfür ist das Damenproblem. Die Aufgabe besteht darin, <math>k</math> Damen auf einem Schachbrett der Größe <math>k \times k</math> so zu platzieren, dass sie sich (nach den üblichen Schach-Regeln) nicht gegenseitig schlagen können. Das folgende Diagramm zeigt eine Lösung für den Fall <math>k=4</math>. Die Positionen der Damen werden dabei wie üblich durch die Angabe der Spalte (Linie) mit Buchstaben und der Zeile (Reihe) mit Zahlen kodiert, hier also A2, B4, C1, D3:

---------------
| | X | | | 4
|---|---|---|---|
| | | | X | 3
|---|---|---|---|
| X | | | | 2
|---|---|---|---|
| | | X | | 1
---------------
A B C D

Um das Problem systematisch zu lösen, konstruieren wir einen gerichteten Graphen, dessen Knoten die möglichen Positionen der Damen kodieren. Wir verbinden Knoten, die zu benachbarten Linien gehören, genau dann mit einer Kante, wenn die zugehörigen Positionen kompatibel sind, also wenn sich die dort positionierten Damen nicht schlagen können. Der resultierende Graph für <math>k=4</math> hat folgende Gestalt:

[[Image:damenproblem-graph.png|500px|center]]

Knoten, die zur selben Reihe oder Linie gehören, sind beispielsweise nicht direkt verbunden, weil zwei Damen niemals in derselben Linie oder Reihe stehen dürfen. Um eine erlaubte Konfiguration zu finden, verwenden wir nun eine angepasste Version der Tiefensuche: Wir beginnen die Suche beim Knoten <tt>START</tt>. Sobald wir den Knoten <tt>STOP</tt> erreichen, beenden wir die Suche und lesen die Lösung am gerade gefundenen Weg von Start nach Stop ab. Zwei kleine Modifikationen des Grundalgorithmus stellen sicher, dass die Bedingungen der Aufgabe eingehalten werden: Wir dürfen bei der Tiefensuche nur dann zu einem Nachbarn weitergehen, wenn die betreffende Position mit allen im Pfad bereits gesetzten Positionen kompatibel ist, andernfalls ist diese Kante tabu. Landen wir aufgrund dieser Regel in einer Sackgasse (also in einem Knoten, wo keine der ausgehenden Kanten erlaubt ist), müssen wir zur nächsten erlaubten Abzweigung zurückgehen (Backtracking). Beim Zurückgehen müssen wir das <tt>parent</tt>-Flag wieder auf <tt>None</tt> zurücksetzen, weil der betreffende Knoten ja möglicherweise auf einem anderen erlaubten Weg erreichbar ist.

Der folgende Graph zeigt einen solchen Fall: Wir haben zwei Damen auf die Felder A1 und B3 positioniert (grüne Pfeile). Die einzig ausgehende Kante von B3 führt zum Knoten C1, welcher aber mit der Position A1 inkompatibel ist, so dass diese Kante nicht verwendet werden darf (roter Pfeil). Das Backtracking muss jetzt zu Knoten A1 zurückgehen (dabei wird das <tt>parent</tt>-Flag von B3 wieder auf <tt>None</tt> gesetzt), weil A1 mit der Kante nach B4 eine weitere Option hat, die geprüft werden muss (die allerdings hier auch nicht zum Ziel führt).

[[Image:damenproblem-graph-failure.png|500px|center]]

Nach einigen weiteren Sackgassen findet man schließlich den Pfad A2, B4, C1, D3, der im folgenden Graphen grün markiert ist und der obigen Lösung entspricht:

[[Image:damenproblem-graph-success.png|500px|center]]

=== Test, ob ein ungerichteter Graph azyklisch ist ===

Ein zusammenhängender ungerichteter Graph ist azyklisch (also ein Baum) genau dann, wenn es nur einen möglichen Weg von jedem Knoten zu jedem anderen gibt. (Bei gerichteten Graphen sind die Verhältnisse komplizierter. Wir behandeln dies weiter unten.) Das kann man mittels Tiefensuche leicht feststellen: Die Kante, über die wir einen Knoten erstmals erreichen, ist eine Baumkante des Tiefensuchbaums. Erreichen wir einen bereits besuchten Knoten nochmals über eine andere Kante, haben wir einen Zyklus gefunden. Dabei müssen wir allerdings beachten, dass in einem ungerichteten Graphen jede Baumkante zweimal gefunden wird, einmal in Richtung vom Vater zum Kind und einmal in umgekehrter Richtung. Im zweiten Fall endet die Kante zwar in einem bereits besuchten Knoten (dem Vater), aber es entsteht dadurch kein Zyklus. Den Vaterknoten müssen wir deshalb überspringen, wenn wir über die Nachbarn iterieren:

def undirected_cycle_test(graph): # Annahme: der Graph ist zusammenhängend
# (andernfalls führe den Algorithmus für jede Zusammenhangskomponente aus)
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node, from_node): # rekursive Hilfsfunktion: gibt True zurück, wenn Zyklus gefunden wurde
if not visited[node]: # wenn node noch nicht besucht wurde
visited[node] = True # markiere node als besucht
for neighbor in graph[node]: # besuche die Nachbarn ...
if neighbor == from_node: # ... aber überspringe den Vaterknoten
continue
if visit(neighbor, node): # ... signalisiere, wenn rekursiv ein Zyklus gefunden wurde
return True
return False # kein Zyklus gefunden
else:
return True # Knoten schon besucht => Zyklus

startnode = 0 # starte bei beliebigem Knoten (hier: Knoten 0)
return visit(startnode, startnode) # gebe True zurück, wenn ein Zyklus gefunden wurde

Wenn wir einen Zyklus finden, wird das weitere Traversieren das Graphen abgebrochen, denn ein Graph, der einmal zyklisch war, kann später nicht wieder azyklisch werden. Die notwendige Modifikation für unzusammenhängende Graphen erfolgt analog zum Algorithmus für die Detektion von Zusammenhangskomponenten, der im nächsten Abschnitt beschrieben wird.

=== Finden von Zusammenhangskomponenten ===

Das Auffinden und Markieren von Zusammenhangskomponenten (also maximalen zusammenhängenden Teilgraphen) ist eine grundlegende Aufgabe in ungerichteten, unzusammenhängenden Graphen (bei gerichteten Graphen sind die Verhältnisse wiederum komplizierter, siehe unten). Zwei Knoten u und v gehören zur selben Zusammenhangskomponente genau dann, wenn es einen Pfad von u nach v gibt (da der Graph ungerichtet ist, gibt es dann auch einen Pfad von v nach u). Man sagt auch, dass "v von u aus erreichbar" ist. Unzusammenhängende Graphen entstehen in der Praxis häufig, wenn die Kanten gewisse Relationen zwischen den Knoten kodieren:
* Wenn die Knoten Städte sind und die Kanten Straßen, sind diejenigen Städte in einer Zusammenhangskomponente, die per Auto von einander erreichbar sind. Unzusammenhängende Graphen entstehen hier beispielsweise, wenn eine Insel nicht durch eine Brücke erschlossen ist, wenn Grenzen gesperrt sind oder wenn ein Gebirge zu unwegsam ist, um Straßen zu bauen.
* Wenn Knoten Personen sind, und Kanten die Eltern-Kind-Relation beschreiben, so umfasst jede Zusammenhangskomponenten die Verwandten (auch wenn sie nur über viele "Ecken" verwandt sind).
* In der Bildverarbeitung entsprechen Knoten den Pixeln, und dieselben werden durch eine Kante verbunden, wenn sie zum selben Objekt gehören. Die Zusammenhangskomponenten entsprechen somit den Objekten im Bild (siehe Übungsaufgabe).
Die Zusammenhangskomponenten bilden eine Äquivalenzrelation. Folglich kann für jede Komponente ein Reprässentant bestimmt werden, der sogenannte "Anker". Kennt jeder Knoten seinen Anker, ist das Problem der Zusammenhangskomponenten gelöst.

==== Lösung mittels Tiefensuche ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden. Anstelle der property map <tt>visited</tt> verwenden wir diesmal eine property map <tt>anchors</tt>, die für jeden Knoten die Knotennummer des zugehörigen Ankers angibt, oder <tt>None</tt>, wenn der Knoten noch nicht besucht wurde. Dabei verwenden wir wieder die Konvention, dass Anker auf sich selbst zeigen. Für viele Anwendungen ist es außerdem (oder stattdessen) zweckmäßig, die Zusammenhangskomponenten mit einer laufenden Nummer, einem sogenannten Label, durchzuzählen. Dann kann man zusätzliche Informationen zu jeder Komponente (beispielsweise deren Größe) einfach in einem Array speichern, das über die Labels indexiert wird. Die folgende Version der Tiefensuche bestimmt sowohl die Anker als auch die Labels für jeden Knoten:

def connectedComponents(graph):
anchors = [None] * len(graph) # property map für Anker jedes Knotens
labels = [None] * len(graph) # property map für Label jedes Knotens

def visit(node, anchor):
"""anchor ist der Anker der aktuellen ZK"""
if anchors[node] is None: # wenn node noch nicht besucht wurde:
anchors[node] = anchor # setze seinen Anker
labels[node] = labels[anchor] # und sein Label
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor, anchor)

current_label = 0 # Zählung der ZK beginnt bei 0
for node in xrange(len(graph)):
if anchors[node] is None: # Anker noch nicht bekannt => neue ZK gefunden
labels[node] = current_label # Label des Ankers setzen
visit(node, node) # Knoten der neuen ZK rekursiv suchen
current_label += 1 # Label für die nächste ZK hochzählen
return anchors, labels
Interessant ist hier die Schleife über alle Knoten des Graphen am Ende des Algorithmus, die bei den bisherigen Versionen der Tiefensuche nicht vorhanden war. Um ihre Funktionsweise zu verstehen, nehmen wir für den Moment an, dass der Graph zusammenhängend ist. Dann findet diese Schleife den ersten Knoten des Graphen und führt die Tiefensuche mit diesem Knoten als Startknoten aus. Sobald die Rekursion zurückkehrt, sind alle Knoten des Graphen besucht (weil der Graph ja zusammenhängend war), so dass die Schleife alle weiteren Knoten überspringt (die if-Anweisung liefert für keinen weiteren Knoten True). Bei unzusammenhängenden Graphen dagegen erreicht die Tiefensuche nur die Knoten derselben Komponente, die im weiteren Verlauf der Schleife übersprungen werden. Findet die if-Anweisung jetzt einen noch nicht besuchten Knoten, muss dieser folglich in einer neuen Komponente liegen. Wir verwenden diesen Knoten als Anker und bestimmen die übrigen Knoten dieser Komponente wiederum mit Tiefensuche.

* Beispiel: ... under construction 

Man erkennt, dass die Tiefensuche nach dem Anlagerungsprinzip vorgeht: Beginnend vom einem Startknoten (dem Anker) werden die Knoten der aktuellen Komponente nach und nach an den Tiefensuchbaum angehangen. Erst, wenn nichts mehr angelagert werden kann, geht der Algorithmus zur nächsten Komponente über.

==== Lösung mittels Union-Find-Algorithmus ====

Im Gegensatz zum Anlagerungsprinzip sucht der Union-Find-Algorithmus die Zusammenhangskomponenten mit dem Verschmelzungsprinzip: Eingangs wird jeder Knoten als ein Teilgraph für sich betrachtet. Dann iteriert man über alle Kanten und verbindet deren Endknoten jeweils zu einem gemeinsamen Teilgraphen (falls die beiden Enden einer Kante bereits im selben Teilgraphen liegen, wird diese Kante ignoriert). Solange noch Kanten vorhanden sind, werden dadurch immer wieder Teilgraphen in größere Teilgraphen verschmolzen. Am Ende bleiben die maximalen zusammenhängenden Teilgraphen (also gerade die Zusammenhangskomponenten) übrig. Dieser Algorithmus kommt ohne Tiefensuche aus und ist daher in der Praxis oft schneller, allerdings auch etwas komplizierter zu implementieren.

Der Schlüssel des Algorithmus ist eine Funktion <tt>findAnchor()</tt>, die zu jedem Knoten den aktuellen Anker sucht. Der Anker existiert immer, da jeder Knoten von Anfang an zu einem Teilgraphen gehört (anfangs ist jeder Teilgraph trivial und besteht nur aus dem Knoten selbst). Die Verschmelzung wird realisiert, indem der Anker des einen Teilgraphen seine Rolle verliert und stattdessen der Anker des anderen Teilgraphen eingesetzt wird.

Zur Verwaltung der Anker verwenden wir wieder eine property map <tt>anchors</tt> mit der Konvention, dass die Anker auf sich selbst verweisen. Es wäre jedoch zu teuer, wenn man bei jeder Verschmelzung alle Anker-Einträge der beteiligten Knoten aktualisieren müsste, da jeder Knoten im Laufe des Algorithmus mehrmals seinen Anker wechseln kann. Statt dessen definiert man Anker rekursiv: Verweist ein Knoten auf einen Anker, der mittlerweile diese Rolle verloren hat, folgt man dem Verweis von diesem Knoten (dem ehemaligen Anker) weiter, bis man einen tatsächlichen Anker gefunden hat - erkennbar daran, dass er auf sich selbst verweist. Diese Suchfunktion kann folgendermassen implementiert werden:

def findAnchor(anchors, node):
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
return node

Allerdings kann diese Kette im Laufe vieler Verschmelzungen sehr lang werden, so dass das Verfolgen der Kette teuer wird. Man vermeidet dies durch die sogenannte Pfadkompression: Immer, wenn man den Anker gefunden hat, aktualisiert man den Eintrag am Anfang der Kette. Die Funktion <tt>findAnchor()</tt> wird dadurch nur wenig komplizierter:

def findAnchor(anchors, node):
start = node # wir merken uns den Anfang der Kette
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
anchors[start] = node # Pfadkompression: aktualisiere den Eintrag am Anfang der Kette
return node

Man kann zeigen, dass die Ankersuche mit Pfadkompression zu einer fast konstanten amortisierten Laufzeit pro Aufruf führt.

Um mit jeder Kante des (ungerichteten) Graphen nur maximal einmal eine Verschmelzung durchzuführen, betrachten wir jede Kante nur in der Richtung von der kleineren zur größeren Knotennummer, die umgekehrte Richtung wird ignoriert. Außerdem ist es zweckmäßig, bei jeder Verschmelzung denjenigen Anker mit der kleineren Knotennummer als neuen Anker zu übernehmen. Dann gilt für jede Zusammenhangskomponente, dass gerade der Knoten mit der kleinsten Knotennummer der Anker ist (genau wie bei der Lösung mittels Tiefensuche), was die weitere Analyse vereinfacht, z.B. die Zuordnung der Labels zu den Komponenten am Ende des Algorithmus.

def unionFindConnectedComponents(graph):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker

for node in xrange(len(graph)): # iteriere über alle Knoten
for neighbor in graph[node]: # ... und über deren ausgehende Kanten
if neighbor < node: # ignoriere Kanten, die in falscher Richtung verlaufen
continue
# hier landen wir für jede Kante des Graphen genau einmal
a1 = findAnchor(anchors, node) # finde Anker ...
a2 = findAnchor(anchors, neighbor) # ... der beiden Endknoten
if a1 < a2: # Verschmelze die beiden Teilgraphen
anchors[a2] = a1 # (verwende den kleineren der beiden Anker als Anker des
elif a2 < a1: # entstehenden Teilgraphen. Falls node und neighbor
anchors[a1] = a2 # den gleichen Anker haben, waren sie bereits im gleichen
# Teilgraphen, und es passiert hier nichts.)
# Bestimme jetzt noch die Labels der Komponenten
labels = [None]*len(graph) # Initialisierung der property map für Labels
current_label = 0 # die Zählung beginnt bei 0
for node in xrange(len(graph)):
a = findAnchor(anchors, node) # wegen der Pfadkompression zeigt jeder Knoten jetzt direkt auf seinen Anker
if a == node: # node ist ein Anker
labels[a] = current_label # => beginne eine neue Komponente
current_label += 1 # und zähle Label für die nächste ZK hoch
else:
labels[node] = labels[a] # node ist kein Anker => setzte das Label des Ankers
# (wir wissen, dass labels[a] bereits gesetzt ist, weil
# der Anker immer der Knoten mit der kleinsten Nummer ist)
return anchors, labels

* Beispiel: ... under construction

== Kürzeste Wege (Pfade) ==

Eine weitere grundlegende Aufgabe in Graphen ist die Bestimmung eines kürzesten Weges zwischen zwei gegebenen Knoten. Dies hat offensichtliche Anwendungen bei Routenplanern und Navigationssystemen und ist darüber hinaus wichtiger Bestandteil anderer Algorithmen, z.B. bei der Berechnung eines maximalen Flusses mit der [http://en.wikipedia.org/wiki/Edmonds%E2%80%93Karp_algorithm Methode von Edmonds und Karp].

=== Kürzeste Wege in ungewichteten Graphen mittels Breitensuche ===

Im Fall eines ungewichteten Graphen ist die Länge eines Weges einfach durch die Anzahl der durchlaufenen Kanten definiert. Daraus folgt, dass kürzeste Pfade mit einer leicht angepassten Version der Breitensuche gefunden werden können: Aufgrund des first in-first out-Verhaltens der Queue betrachtet die Breitensuche alle (erreichbaren) Knoten in der Reihenfolge ihres Abstandes vom Startknoten. Wenn wir den Zielknoten zum ersten Mal erreichen, und der gerade gefundene Weg vom Start zum Ziel hat die Länge L, muss dies der kürzeste Weg sein: Alle möglichen Wege der Länge L' < L hat die Breitensuche ja bereits betrachtet, ohne dass dabei der Zielknoten erreicht wurde. Daraus folgt übrigens eine allgemeine Eigenschaft aller Algorithmen für kürzeste Wege: Wenn der kürzeste Weg vom Start zum Ziel die Länge L hat, finden diese Algorithmen als Nebenprodukt auch die kürzesten Wege zu allen Knoten, für die L' < L gilt.

Um den Algorithmus zu implementieren, passen wir die Breitensuche so an, dass anstelle der property map <tt>visited</tt> eine property map <tt>parents</tt> verwendet wird, die für jeden besuchten Knoten den Vaterknoten im Breitensuchbaum speichert. Durch Rückverfolgen der <tt>parent</tt>-Kette können wir den Pfad vom Ziel zum Start rekonstruieren, und durch Umdrehen der Reihenfolge erhalten wir den gesuchten Pfad vom Start zum Ziel. Sobald der Zielknoten erreicht wurde, können wir die Breitensuche abbrechen (<tt>break</tt>-Befehl in der ersten <tt>while</tt>-Schleife). Falls der gegebene Graph unzusammenhängend ist, kann es passieren, dass gar kein Weg gefunden wird, weil Start und Ziel in verschiedenen Zusammenhangskomponenten liegen. Dies erkennen wir daran, dass die Breitensuche beendet wurde, ohne den Zielknoten zu besuchen. Dann gibt die Funktion statt eines Pfades dern Wert <tt>None</tt> zurück:

from collections import deque

def shortestPath(graph, startnode, destination):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Breitensuchbaum
parents[startnode] = startnode # startnode ist die Wurzel des Baums => verweist auf sich selbst

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # Besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn sie noch nicht besucht wurden
parents[neighbor] = node # setze node als Vaterknoten
q.append(neighbor) # und füge neighbor in die Queue ein

if parents[destination] is None: # Breitensuche wurde beendet ohne den Zielknoten zu besuchen
return None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path # gefundenen Pfad zurückgeben

=== Gewichtete Graphen ===

Das Problem der Suche nach kürzesten Wegen wird wesentlich interessanter und realistischer, wenn wir zu gewichteten Graphen übergehen:

; Definition - kantengewichteter Graph
: Jeder Kante (s,t) des Graphen ist eine reelle oder natürliche Zahl wst zugeordnet, die üblicherweise als ''Kantengewicht'' bezeichnet wird.

; Definition - knotengewichteter Graph
: Jedem Knoten v des Graphen ist eine reelle oder natürliche Zahl wv zugeordnet, die üblicherweise als ''Knotengewicht'' bezeichnet wird.

Je nach Anwendung benötigt man Knoten- oder Kantengewichte oder auch beides zugleich. Wir beschränken uns in der Vorlesung auf kantengewichtete Graphen. Beispiele für die Informationen, die man durch Kantengewichte ausdrücken kann, sind
* wenn die Knoten Orte sind: Abstand von Anfangs- und Endknoten jeder Kante (z.B. Luftline oder Straßenentfernung), Fahrzeit zwischen den Orten
* wenn der Knoten ein Rohrnetzwerk beschreibt: Durchflusskapazität der einzelnen Rohre (für max-Flussprobleme), analog bei elektrischen Netzwerken: elektrischer Widerstand
* wenn die Knoten Währungen repräsentieren, können deren Wechselkurse durch Kantengewichte angegeben werden.
Bei einigen Beispielen ergeben sich unterschiedliche Kantengewichte, wenn eine Kante von s nach t anstatt von t nach s durchlaufen wird. Beispielsweise können sich die Fahrzeiten erheblich unterscheiden, wenn es in einer Richtung bergauf, in der anderen bergab geht, obwohl die Entfernung in beiden Fällen gleich ist. Hier ergibt sich natürlicherweise ein gerichteter Graph. In anderen Beispielen (z.B. bei Luftlinienentfernungen, in guter Näherung auch bei Straßenentfernungen) sind die Gewichte von der Richtung unabhängig, so dass wir ungerichtete Graphen verwenden können.

Die Repräsentation der Kantengewichte im Programm richtet sich nach der Repräsentation des Graphen selbst. Am einfachsten ist wiederum die Adjazenzmatrix, die aber nur für dichte Graphen (<math>E = O(V^2)</math>, mit E als Anzahl der Kanten und V als Anzahl der Knoten) effizient ist. Bei gewichteten Graphen gibt das Matrixelement aij das Gewicht der Kante i ⇒ j (wobei aij = 0 gesetzt wird, wenn diese Kante nicht existiert). Wie zuvor gilt für ungerichtete Graphen aij = aji (symmetrische Matrix), während dies für gerichtete Graphen nicht gelten muss.

Bei Graphen in Adjazenzlistendarstellung hat es sich bewährt, die Gewichte in einer property map zu speichern. Weiter oben haben wir bereits property maps für Knoteneigenschaften (z.B. <tt>visited</tt> und <tt>anchors</tt>) gesehen. Property maps für Kanten funktionieren ganz analog, allerdings muss man jetzt Paare von Knoten (nämlich Anfangs- und Endknoten der Kante) als Schlüssel verwenden und die Daten entsprechend in einem assoziativen Array ablegen:
w = weights[(i,j)] # Zugriff auf das Gewicht der Kante i ⇒ j
Alternativ könnte man auch die Graph-Datenstruktur selbst erweitern, aber dies ist weniger zu empfehlen, weil jeder Algorithmus andere Erwiterungen benötigt und damit die Datenstruktur sehr unübersichtlich würde.

Der kürzeste Weg ist nun definiert als der Weg, bei dem die Summe der Kantengewichte minimal ist:
;Definition - Problem des kürzesten Weges
: Sei P die Menge aller Wege von u nach v, und <math>p \in P</math> einer dieser Wege. Wenn der Grpah einfach ist (es also keine Mehrfachkanten zwischen denselben Knoten und keine Schleifen gibt), ist der Weg p durch die Folge der besuchten Knoten eindeutig bestimmt:
: <math>p : \ \ u = x_0 \rightarrow x_1 \rightarrow x_2 \rightarrow ... \rightarrow v = x_{n_p}</math>
:wo <math>n_p</math> die Anzahl der Kanten im Weg p ist. Seine Kosten Wp ergeben sich als Summer der Gewichte der einzelnen Kanten
: <math>W_p = \sum_{k=1}^{n_p} w_{x_{k-1}x_k}</math>
: und ein kürzester Weg <math>p^* \in P</math> ist ein Weg mit minimalen Kosten
: <math>p^* = \textrm{argmin}_{p\in P}\ \ W_p</math>
: Das Problem des kürzesten Weges besteht darin, einen optimalen Weg p* zwischen gegebenen Knoten u und v zu finden.
Die Lösung dieses Problems hängt davon ab, ob alle Kantengewichte positiv sind, oder ob es auch negative Kantengewichte gibt. In letzeren Fall ist es möglich, durch eine Verlängerung des Weges die Kosten zu redizieren, während sich im ersteren Fall die Kosten immer erhöhen, wenn man den Weg verlängert.

Negative Gewichte treten z.B. bei den Währungsgraphen auf. Auf den ersten Blick entsprechen diese Graphen nicht den Anforderungen an das Problem des kürzesten Weges, weil Wechselkurse miteinander (und mit Geldbeträgen) multipliziert anstatt addiert werden. Man beseitigt diese Schwierigkeit aber leicht, indem man die Logarithmen der Wechselkurse als Kantengewichte verwendet, wodurch sich die Multiplikation in eine Addition der Logarithmen verwandelt. Wechselkurse < 1 führen nun zu negativen Gewichten.

Interessant werden negative Gewichte vor allem in Graphen mit Zyklen. Dann kann es nämlich passieren, dass die Gesamtkosten eines Zyklus ebenfalls negativ sind. Jeder Weg, der den Zyklus enthält, hat dann Kosten von <math>-\infty</math>, weil man den Zyklus beliebig oft durchlaufen und dadurch die Gesamtkosten immer weiter verkleinern kann:

/\ 1. Durchlauf: Kosten -1
1 / \ -4 2. Durchlauf: Kosten -2
/____\ etc.
2

Um hier nicht in einer Endlosschleife zu landen, benötigt man spezielle Algorithmen, die mit dieser Situation umgehen können. Der [http://de.wikipedia.org/wiki/Bellman-Ford-Algorithmus Algorithmus von Bellmann und Ford] beispielsweise bricht die Suche nach dem kürzesten Weg ab, sobald er einen negativen Zyklus entdeckt, aber andernfalls kann er negative Gewichte problemlos verarbeiten.

Die Detektion negativer Zyklen hat wiederum eine interessante Anwendung bei Währungsgraphen: Ein Zyklus bedeutet hier, dass man Geld über mehrere Stufen von einer Währung in die nächste und am Schluß wieder in die Originalwährung umtauscht, und ein negativer Zyklus führt dazu, dass man am Ende mehr Geld besitzt als am Anfang (damit negative Zyklen wirklich einen Gewinn bedeuten und keinen Verlust, müssen die Wechselkurse vor der Logarithmierung in [http://de.wikipedia.org/wiki/Wechselkurs#Nominaler_Wechselkurs Preisnotierung] angegeben sein). Bei Privatpersonen ist dies ausgeschlossen, weil die Umtauschgebühren den möglichen Gewinn mehr als aufzehren. Banken mit direktem weltweitem Börsenzugang hingegen unternehmen große Anstrengungen, um solche negativen Zyklen möglichst schnell (nämlich vor der Konkurrenz) zu entdecken und auszunutzen. Diese Geschäftsmethode bezeichnet man als [http://de.wikipedia.org/wiki/Arbitrage Arbitrage] und die Existenz eines negativen Zyklus als Arbitragegelegenheit. Durch die Kursschwankungen (und durch die ausgleichende Wirkung der Arbitragegeschäfte selbst) existieren die Arbitragegelegenheiten nur für kurze Zeit, und ihre Detektion erfordert leistungsfähige Echtzeitalgorithmen.

In dieser Vorlesung beschränken wir uns hingegen auf Graphen mit ausschließlich positiven Gewichten. In diesem Fall ist der Algorithmus von Dijkstra die Methode der Wahl, weil er wesentlich schneller arbeitet als der Bellmann-Ford-Algorithmus.

=== Algorithmus von Dijkstra ===

==== Edsger Wybe Dijkstra ====

geb. 11. Mai 1930 in Rotterdam

ges. 06. August 2002

Dijkstra war ein niederländischer Informatiker und Wegbereiter der strukturierten Programmierung. 1972 erhielt er für seine Leistung in der Technik und Kunst der Programmiersprachen den Turing Award, der jährlich von der Association for Computing Machinery (ACM) an Personen verliehen wird, die sich besonders um die Entwicklung der Informatik verdient gemacht haben. Zu seinen Beiträgen zur Informatik gehören unter anderem der Dijkstra-Algorithmus zur Berechnung des kürzesten Weges in einem Graphen sowie eine Abhandlung über den go-to-Befehl und warum er nicht benutzt werden sollte. Der go-to-Befehl war in den 60er und 70er Jahren weit verbreitet, führte aber zu Spaghetti-Code. In seinem berühmten Paper "A Case against the GO TO Statement"[http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF], das als Brief mit dem Titel "Go-to statement considered harmful" veröffentlicht wurde, argumentiert Dijkstra, dass es umso schwieriger ist, dem Quellcode eines Programmes zu folgen, je mehr go-to-Befehle darin enthalten sind und zeigt, dass man auch ohne diesen Befehl gute Programme schreiben kann.

==== Algorithmus ====

Der Dijkstra-Algorithmus für kürzeste Wege ist dem oben vorgestellten Algorithmus <tt>shortestPath()</tt> auf der Basis von Breitensuche sehr ähnlich. Insbesondere gilt auch hier, dass neben dem kürzesten Weg vom Start zum Ziel auch alle kürzesten Wege gefunden werden, deren Endknoten dem Start näher sind als der Zielknoten. Aufgrund der Kantengewichte gibt es aber einen wichtigen Unterschied: Der erste gefundene Weg zu einem Knoten ist nicht mehr notwendigerweise der kürzeste. Wir bestimmen deshalb für jeden Knoten mehrere Kandidatenwege und verwenden eine Prioritätswarteschlange (statt einer einfachen First in - First out - Queue), um diese Wege nach ihrer Länge zu sortieren. Die Kandidatenwege für einen gegebenen Knoten werden unterschieden, indem wir auch den Vorgängerknoten im jeweiligen Weg speichern. Wenn ein Knoten erstmals an die Spitze der Prioritätswarteschlange gelangt, haben wir den kürzesten Weg zu diesem Knoten gefunden (das wird weiter unten formal bewiesen), und der Vorgänger des Knotens in diesem Weg wird zu seinem Vaterknoten. Erscheint derselbe Knoten später nochmals an der Spitze der Prioritätswarteschlange, handelt es sich um einen Kandidatenweg, der sich nicht als kürzester erwiesen hat und deshalb ignoriert werden kann. Wir erkennen dies leicht daran, dass der Vaterknoten in der property map <tt>parents</tt> bereits gesetzt ist.

Eine geeignete Datenstruktur für die Prioritätswarteschlange wird durch das Python-Modul [http://docs.python.org/library/heapq.html heapq] realisiert. Es verwendet ein normales Pythonarray als unterliegende Repräsentation für einen Heap und stellt effiziente <tt>heappush</tt> und <tt>heappop</tt>-Funktionen zur Verfügung. Dies entspricht genau unserer Vorgehensweise im Kapitel [[Prioritätswarteschlangen]]. Als Datenelement erwartet die Funktion <tt>heappush</tt> ein Tupel, dessen erstes Element die Priorität sein muss. Die übrigen Elemente des Tupels (und damit auch deren Anzahl) können je nach Anwendung frei festgelegt werden. Wir legen fest, dass das zweite Element den Endknoten des betrachteten Weges und das dritte den Vorgängerknoten speichert.

Die Kantengewichte werden dem Algorithmus in der property map <tt>weights</tt> übergeben:

<code python>
import heapq # heapq implementiert die Funktionen für Heaps

def dijkstra(graph, weights, startnode, destination):
parents = [None]*len(graph) # registriere für jeden Knoten den Vaterknoten im Pfadbaum

q = [] # Array q wird als Heap verwendet
heapq.heappush(q, (0.0, startnode, startnode)) # Startknoten in Heap einfügen

while len(q) > 0: # solange es noch Knoten im Heap gibt:
length, node, predecessor = heapq.heappop(q) # Knoten aus dem Heap nehmen
if parents[node] is not None: # parent ist schon gesetzt => es gab einen anderen, kürzeren Weg
continue # => wir können diesen Weg ignorieren
parents[node] = predecessor # parent setzen
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # die Nachbarn von node besuchen,
if parents[neighbor] is None: # aber nur, wenn ihr kürzester Weg noch nicht bekannt ist
newLength = length + weights[(node,neighbor)] # berechne Pfadlänge zu neighbor
heapq.heappush(q, (newLength, neighbor, node)) # und füge neighbor in den Heap ein

if parents[destination] is None: # Suche wurde beendet ohne den Zielknoten zu besuchen
return None, None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path, length # gefundenen Pfad und dessen Länge zurückgeben
</code>
Die wesentlichen Unterschiede zur Breitensuche sind im Code rot markiert: Anstelle der Queue verwenden wir jetzt einen Heap, und der Startknoten wird mit Pfadlänge 0 als erstes eingefügt. In der Schleife <tt>while len(q) > 0:</tt> wird jeweils der Knoten <tt>node</tt> mit der aktuell kürzesten Pfadlänge aus dem Heap entfernt. Die Pfadlänge vom Start zu diesem Knoten wird in der Variable <tt>length</tt> gespeichert, sein Vorgänger in der Variable <tt>predecessor</tt>. Wenn der aktuelle Weg nicht der kürzeste ist (<tt>parents[node]</tt> war bereits gesetzt), wird dieser Weg ignoriert. Andernfalls werden die property map <tt>parents</tt> aktualisiert und die Nachbarn von <tt>node</tt> besucht. Beim Scannen der Nachbarn berechnen wir zunächst die Länge <tt>newLength</tt> das Weges <tt>startnode => node => neighbor</tt> als Summe von <tt>length</tt> und dem Gewicht der Kante <tt>(node, neighbode)</tt>. Diese Länge wird beim Einfügen des Nachbarknotens in den Heap zur Priorität des aktuellen Weges.

Die wichtigsten Prinzipien des Dijkstra-Algorithmus noch einmal im Überblick:
* Der Dijkstra-Algorithmus ist Breitensuche mit Prioritätswarteschlange (Heap) statt einer einfache Warteschlange (Queue).
* Die Prioritätswarteschlange speichert alle Wege, die bereits gefunden worden sind und ordnet sie aufsteigend nach ihrer Länge.
* Das Sortieren (und damit der ganze Algorithmus) funktioniert nur mit positiven Kantengewichten korrekt.
* Da ein Knoten auf mehreren Wegen erreichbar sein kann, kann er auch mehrmals im Heap sein.
* Wenn ein Knoten erstmals aus der Prioritätswarteschlange entnommen wird, ist der gefundene Weg der kürzeste zu diesem Knoten. Andernfalls wird der Weg ignoriert.
* Wenn der Knoten <tt>destination</tt> aus dem Heap entnommen wird, ist der kürzeste Weg von Start nach Ziel gefunden, und die Suche kann beendet werden.
In unserer Implementation können, wie gesagt, mehrere Wege zum selben Knoten gleichzeitig in der Prioritätswarteschlange sein. Im Prinzip wäre es auch möglich, immer nur den besten zur Zeit bekannten Weg zu jedem Enknoten in der Prioritätswarteschlange zu halten - sobald ein besserer Kandidat gefunden wird, ersetzt er den bisherigen Kandidaten, anstatt zusätzlich eingefügt zu werden. Dies erfordert aber eine wesentlich kompliziertere Prioritätswarteschlange, die eine effiziente <tt>updatePriority</tt>-Funktion anbietet, ohne dass dadurch eine signifikante Beschleunigung erreicht wird. Deshalb verfolgen wir diesen Ansatz nicht.

==== Beispiel ====

under construction

[[Image:Bsp.jpg]]

==== Komplexität von Dijkstra ====

Zur Analyse der Komplexität nehmen wir an, dass der Graph V Knoten und E Kanten hat. Die Initialisierung der property map <tt>parents</tt> am Anfang der Funktion hat offensichtlich Komplexität O(V), weil Speicher für V Knoten allokiert wird. Der Code am Ende der Funktion, der aus der property map <tt>parents</tt> den Pfad extrahiert, hat ebenfalls die Komplexität O(V), weil der Pfad im ungünstigen Fall sämtliche Knoten des Graphen umfasst. Beides wird durch die Komplexität der Hauptschleife dominiert, zu deren Analyse wir den folgenden Codeausschnitt genauer anschauen wollen:

while len(q) > 0:
... # 1
if parents[node] is not None:
continue
parents[node] = predecessor
... # 2
Wir erkennen, dass der Codeabschnitt <tt># 2</tt> für jeden Knoten höchstens einmal erreicht werden kann: Da <tt>parents[node]</tt> beim ersten Durchlauf gesetzt wird, kann die <tt>if</tt>-Abfrage beim gleichen Knoten nie wieder <tt>False</tt> liefern, und das nachfolgende <tt>continue</tt> bewirkt, dass der Abschnitt <tt># 2</tt> dann übersprungen wird. Man sagt auch, dass jeder Knoten höchstens einmal expandiert wird, auch wenn er mehrmals im Heap war.

Der Codeabschnitt <tt># 2</tt> selbst enthält eine Schleife über alle ausgehenden Kanten des Knotens <tt>node</tt>. Im ungünstigsten Fall iterieren wir bei allen Knoten über alle ausgehenden Kanten, aber das sind gerade alle Kanten des Graphen je einmal in den beiden möglichen Richtungen. Die Funktion <tt>heappush</tt> wird sogar höchstens E Mal aufgerufen, weil eine Kante nur in den Heap eingefügt wird, wenn der kürzeste Weg der jeweiligen Endknotens noch nicht bekannt ist (siehe die <tt>if</tt>-Abfrage in der <tt>for</tt>-Schleife), und das ist nur ein einer Richtung möglich. Dies hat zwei Konsequenzen:
* Die Schleife <tt>while len(q) > 0:</tt> wird nur so oft ausgeführt, wie Elemente im Heap sind, also höchstens E Mal. Das gleiche gilt für den Codeabschnitt <tt># 1</tt>, der das <tt>heappop</tt> enthält.
* Die Operationen <tt>heappush</tt> und <tt>heappop</tt> haben logarithmische Komplexität in der Größe des Heaps, sind also in <math>O(\log\,E)</math>. In einfachen Graphen gilt aber <math>E = O(V^2)</math>, so dass sich die Komplexität der Heapoperationen vereinfacht zu <math>O(\log\,E)=O(\log\,V^2)=O(2\log\,V)=O(\log\,V)</math>.
Zusammenfassend gilt: <tt>heappush</tt> und <tt>heappop</tt> werden maximal E Mal aufgerufen und haben eine Komplexität in <math>O(\log\,V)</math>. Folglich hat der Algorithmus von Dijkstra die Komplexität:
:<math>O(E\,\log\,V)</math>

==== Vergleich mit Breitensuche und Tiefensuche ====

Der Dijkstra-Algorithmus ist eng mit der Breiten- und Tiefensuche verwandt - man kann diese Algorithmen aus dem Dijkstra-Algorithmus gewinnen, indem man einfach die Regel zur Festlegung der Prioritäten ändert. Anstelle der Länge des Pfades verwenden wir als Priorität den Wert eine Zählvariable <tt>count</tt>, die nach jeder Einfügung in den Heap (also nach jedem Aufruf von <tt>heappush</tt>) aktualisiert wird. Zählen wir die Variable hoch, haben die zuerst eingefügten Kanten die höchste Priorität, der Heap verhält sich also wie eine Queue (First in-First out), und wir erhalten eine Breitensuche. Zählen wir die Variable hingegen (von E beginnend) herunter, haben die zuletzt eingefügten Kanten höchste Priorität. Der Heap verhält sich dann wie ein Stack (Last in-First out), und wir bekommen Tiefensuche. Statt eines Heaps plus Zählvariable kann man jetzt natürlich direkt eine Queue bzw. einen Stack verwenden. Dadurch fällt der Aufwand <math>O(\log\,V)</math> für die Heapoperationen weg und wird durch die effizienten O(1)-Operationen von Queue bzw. Stack ersetzt. Damit erhalten wir für Breiten- und Tiefensuche die schon bekannte Komplexität O(E).

==== Korrektheit von Dijkstra ====

Wir beweisen mittels vollständiger Induktion die Schleifen-Invariante: Falls <tt>parents[node]</tt> gesetzt (also ungleich <tt>None</tt>) ist, dann liefert das Zurückverfolgen des Weges von <tt>node</tt> nach <tt>startnode</tt> den kürzesten Weg.
;Induktionsanfang: <tt>parents[startnode]</tt> ist als einziges gesetzt. Zurückverfolgen liefert den trivialen Weg <tt>[startnode]</tt>, der mit Länge 0 offensichtlich der kürzeste Pfad ist → die Bedingung ist erfüllt.
;Induktionsschritt: Wir zeigen mit einem indirektem Beweis, dass wir immer einen kürzesten Weg bekommen, wenn <tt>parents[node]</tt> gesetzt wird.
:Sei <math>S</math> = <tt>{v | parents[v] is not None}</tt> die Menge aller Knoten, von denen wir den kürzesten Weg schon kennen (Induktionsvoraussetzung), und <tt>node</tt> der Knoten, der sich gerade an der Spitze des Heaps befindet. Dann ist <tt>predecessor</tt> der Vorgänger von <tt>node</tt> im aktuellen Weg, und es muss <tt>predecessor</tt><math>\in S</math> gelten, weil die Nachbarn von <tt>predecessor</tt> (und damit auch der aktuelle <tt>node</tt>) erst in den Heap eingefügt werden, wenn der kürzeste Weg für <tt>predecessor</tt> gefunden wurde. Man beachte auch, dass alle Knoten, die noch nicht in <math>S</math> enthalten sind, weiter vom Start entfernt sind als alle Knoten in <math>S</math>, weil alle neu in den Heap eingefügten Wege länger sind als der kürzeste Weg des jeweiligen Vorgängers.
:Der indirekte Beweis nimmt jetzt an, dass der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> nicht der kürzeste Weg ist. Dann muss es einen anderen, kürzeren Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> geben. Für den Vorgänger <tt>x</tt> in diesem Weg unterscheiden wir zwei Fälle:
:* <tt>x</tt><math>\in S</math>: In diesem Fall ist die Länge des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> bereits bekannt, und dieser Weg ist in der Prioritätswarteschlange enthalten. Dann kann er aber nicht der kürzeste sein, denn an der Spitze der Warteschlange war nach Voraussetzung der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt>.
:* <tt>x</tt><math>\notin S</math>: Die Kosten des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> berechnen sich als <tt>Kosten(x → startnode) + weight[(x, node)]</tt>, und die Kosten des Weges <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> sind analog <tt>Kosten(predecessor → startnode) + weight[(predecessor, node)]</tt>. Aufgrund der Induktionsvoraussetzung gilt aber <tt>predecessor</tt><math>\in S</math>, und somit <tt>Kosten(predecessor → startnode) < Kosten(x → startnode)</tt>, weil <tt>x</tt> andernfalls vor <tt>predecessor</tt> an der Spitze des Heaps gewesen wäre, was mit der Annahme <tt>x</tt><math>\notin S</math> unverträglich ist. Damit der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> trotzdem der kürzeste Weg sein kann, müsste <tt>Kosten(x → startnode) < Kosten(node → startnode)</tt> gelten, denn durch die Kante <tt>(x, node)</tt> kommen ja noch Kosten hinzu. Das wäre aber nur möglich, wenn der Knoten <tt>x</tt> vor dem Knoten <tt>node</tt> an die Spitze des Heaps gelangt, im Widerspruch zur Annahme, dass <tt>node</tt> sich gerade an der Spitze des Heaps befindet. Somit kann die Behauptung, dass der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> der kürzeste Weg ist, nicht stimmen.
In beiden Fällen erhalten wir einen Widerspruch, und die Behauptung ist somit bewiesen. Da die Invariante insbesondere für den Weg zum Zielknoten <tt>destination</tt> erfüllt ist, folgt daraus auch die Korrektheit des Algorithmus von Dijkstra.

=== A*-Algorithmus - Wie kann man Dijkstra noch verbessern? ===

Eine wichtige Eigenschaft des Dijkstra-Algorithmus ist, dass neben dem kürzesten Weg vom Start zum Ziel auch die kürzesten Wege zu allen Knoten berechnet werden, die näher am Startknoten liegen als das Ziel, obwohl uns diese Wege gar nicht interessieren. Sucht man beispielsweise in einem Graphen mit den Straßenverbindungen in Deutschland den kürzesten Weg von Frankfurt (Main) nach Dresden (ca. 460 km), werden auch die kürzesten Wege von Frankfurt nach Köln (190 km), Dortmund (220 km) und Stuttgart (210 km) und vielen anderen Städten gefunden. Aufgrund der geographischen Lage dieser Städte ist eigentlich von vornherein klar, dass sie mit dem kürzesten Weg nach Dresden nicht das geringste zu tun haben. Anders sieht es mit Erfurt (260 km) oder Suhl (210 km) aus - diese Städte liegen zwischen Frankfurt und Dresden und kommen deshalb als Zwischenstationen des gesuchten Weges in Frage.

Damit Dijkstra korrekt funktioniert, würde es im Prinzip ausreichen, wenn man die kürzesten Wege nur für diejenigen Knoten ausrechnet, die auf dem kürzesten Weg vom Start zum Ziel liegen, denn nur diese Knoten braucht man, um den gesuchten Weg über die <tt>parent</tt>-Kette zurückzuverfolgen. Das Problem ist nur, dass man diese Knoten erst kennt, wenn der Algorithmus fertig durchgelaufen ist. Schließt man Knoten zu früh von der Betrachtung aus, kommt am Ende möglicherweise nicht der korrekte kürzeste Weg heraus.

Der A*-Algorithmus löst dieses Dilemma mit folgender Idee: Ändere die Prioritäten für den Heap so ab, dass unwichtige Knoten nur mit geringerer Wahscheinlichkeit expandiert werden, aber stelle gleichzeitig sicher, dass alle wichtigen Knoten (also diejenigen auf dem korrekten kürzesten Weg) auf jeden Fall expandiert werden. Es zeigt sich, dass man diese Idee umsetzen kann, wenn eine Schätzung für den Restweg (also für die noch verbleibende Entfernung von jedem Knoten zum Ziel) verfügbar ist:
rest = guess(neighbor, destination)
Diese Schätzung addiert man einfach zur wahren Länge des Weges <tt>startnode → node</tt> dazu, um die verbesserte Priorität zu erhalten:
priority = newLength + guess(neighbor, destination)
(Im originalen Dijkstra-Algorithmus wird als Priorität nur <tt>newLength</tt> allein verwendet. Man beachte, dass man <tt>newLength</tt> jetzt zusätzlich im Heap speichern muss, weil man es für die Expansion des Knotens später noch benötigt.)

Damit sicher gestellt ist, dass der A*-Algorithmus immer noch die korrekten kürzesten Wege findet, darf die Schätzung den wahren Restweg niemals überschätzen. Es muss immer gelten:
0 <= guess(node, destination) <= trueDistance(node, destination)
Damit gilt insbesondere <tt>guess(destination, destination) = trueDistance(destination, destination) = 0</tt>, an der Priorität des Knotens <tt>destination</tt> ändert sich also nichts. Die Prioritäten aller anderen Knoten veschlechtern sich hingegen, weil zur bisherigen Priorität noch atwas addiert wird. Für die wichtigen Knoten auf dem kürzesten Weg vom Start nach Ziel gilt jedoch, dass deren neue Priorität immer noch besser ist als die Priorität des Zielknotens selbst. Für diese Knoten gilt nämlich
falls node auf dem kürzesten Weg von startnode nach destination liegt:
trueDistance(startnode, node) + guess(node, destination) <= trueDistance(startnode, destination)
weil der Weg von Start nach <tt>node</tt> ein Teil des kürzesten Wegs von Start nach Ziel ist und die Restschätzung die wahre Entfernung immer unterschätzt. Diese Knoten werden deshalb stets vor dem Zielknoten expandiert, so dass wir die <tt>parent</tt>-Kette immer noch korrekt zurückverfolgen können. Für alle anderen Knoten gilt idealerweise, dass die neue Priorität schlechter ist als die Priorität von <tt>destination</tt>, so dass man sich diese irrelevanten Knotenexpansionen sparen kann.

Für das Beispiel eines Straßennetzwerks bietet sich als Schätzung die Luftlinienentfernung an, weil Straßen nie kürzer sein können als die Luftlinie. Damit erreicht man in der Praxis deutliche Einsparungen. Generell gilt, dass der A*-Algorithmus im typischen Fall schneller ist als der Algorithmus von Dijkstra, aber man kann immer pathologische Fälle konstruieren, wo die Änderung der Prioritäten nichts bringt. Die Komplexität des A*-Algorithmus im ungünstigen Fall ist deshalb nach wie vor <math>O(E\,\log\,V)</math>.

=='''Minimaler Spannbaum'''==
'''(engl.: minimum spanning tree; abgekürzt: MST)'''

[[Image:Minimum_spanning_tree.png‎ |thumb|200px|right|Ein minimal aufspannender Baum verbindet alle Punkte eines Graphen bei minimaler Kantenlänge ([http://de.wikipedia.org/wiki/Spannbaum Quelle])]]

:''gegeben'': gewichteter Graph G, zusammenhängend 
:''gesucht'': Untermenge <math>E'\subseteq E</math> der Kanten, so dass die Summe der Kantengewichte <math>\sum_{e\in E'} w_e</math> minimal und der entstehende Graph G' zusammenhängend ist. 
* G' definiert immer einen Baum, denn andernfalls könnte man eine Kante weglassen und dadurch die Summe <math>\sum_{e\in E'} w_e</math> verringern, ohne dass sich am Zusammenhang von G' etwas ändert. 
* Wenn der Graph G nicht zusammenhängend ist, kann man den Spannbaum für jede Zusammenhangskomponente getrennt ausrechnen. Man erhält dann einen aufspannenden Wald.
* Der MST ist ähnlich wie der Dijkstra-Algorithmus: Dort ist ein Pfad gesucht, bei dem die Summe der Gewichte über den Pfad minimal ist. Beim MST suchen wir eine Lösung, bei der die Summe der Gewichte über den ganzen Graphen minimal ist.
* Das Problem des MST ist nahe verwandt mit der Bestimmung der Zusammenhangskomponente, z.B. über den Tiefensuchbaum. Für die Zusammenhangskomponenten genügt allerdings ein beliebiger Baum, während beim MST ein minimaler Baum gesucht ist.

=== Anwendungen ===
==== Wie verbindet man n gegebene Punkte mit möglichst kurzen Straßen (Eisenbahnen, Drähten [bei Schaltungen] usw.)?====

 
{| class="wikitable" style="text-align:center" border="0" cellpadding="5" cellspacing="0"
|MST minimale Verbindung (Abb.1)
|MST = 2 (Länge = Kantengewicht)(Abb.2)
|- valign="top"
| [[Image:mst.png]]
| [[Image:Gleichseitigesdreieck.png]]
|}
*In der Praxis: Die Festlegung, dass man nur die gegebenen Punkte verwenden darf, ist eine ziemliche starke Einschränkung.

* Wenn man sich vorstellt, es sind drei Punkte gegeben, die als gleichseitiges Dreieck angeordnet sind, dann ist der MST (siehe Abb.2, schwarz gezeichnet) und hat die Länge 2. Man kann hier die Länge als Kantengewicht verwenden.

* Wenn es erlaubt ist zusätzliche Punkte einzufügen, dann kann man in der Mitte einen neuen Punkt setzen <math>\rightarrow</math> neuer MST (siehe Abb.2, orange gezeichnet). 

* Höhe = <math>\frac{1}{2}\sqrt{3}</math>, Schwerpunkt: teilt die Höhe des Dreiecks im Verhältnis 2:1; der Abstand von obersten Punkt bis zum neu eingeführten Punkt: <math>\frac{2}{3}h = \frac{\sqrt{3}}{3}</math>, davon insgesamt 3 Stück, damit (gilt für den MST in orange eingezeichnet): MST = <math>3\left(\frac{1}{3}\right) \sqrt{3} = \sqrt{3} \approx 1,7</math><br\>

* Damit ist der MST in orange kürzer als der schwarz gezeichnete MST. <br\>
<math>\Rightarrow</math>Folgerung: MST kann kürzer werden, wenn man einen Punkt dazu nimmt.
* Umgekehrt kann der MST auch kürzer werden, wenn man einen Punkt aus dem Graphen entfernt, aber wie das Beipiel des gleichseitigen Dreiecks zeigt, ist dies nicht immer der Fall.

[[Image: bahn.png|Bahnstrecke Verbindung (Abb.3)]]

* Methode der zusätzlichen Punkteinfügung hat man früher beim Bahnstreckenbau verwendet. Durch Einführung eines Knotenpunktes kann die Streckenlänge verkürzt werden (Dreiecksungleichung).

==== Bestimmung von Datenclustern ====

[[Image:cluster.png]]

* Daten (in der Abb.: Punkte) bilden Gruppen.

* In der Abbildung hat man 2 verschiedene Messungen gemacht (als x- und y-Achse aufgetragen), bspw. Größe und Gewicht von Personen. Für jede Person i wird ein Punkt an der Koordinate (Größei, Gewichti) gezeichnet (siehe Bild a). Dies bezeichnet man als ''Scatter Plot''. Wenn bestimmte Wertkombinationen häufiger auftreten als andere, bilden sich mitunter Gruppen aus, bspw. eine Gruppe für "klein und schwer" etc.

* Durch Verbinden der Punkte mittels eines MST (siehe Abbildung (b)) sieht man, dass es kurze (innerhalb der Gruppen) und lange Kanten (zwischen den Gruppen) gibt.

* Wenn man geschickt eine Schwelle einführt und alle Kanten löscht, die länger sind als die Schwelle, dann bekommt man als Zusammenhangskomponente die einzelnen Gruppen.

=== Algorithmen ===

Genau wie bei der Bestimmung von Zusammenhangskomponenten kann man auch das MST-Problem entweder nach dem Anlagerungsprinzip oder nach dem Verschmelzungsprinzip lösen (dazu gibt es noch weitere Möglichkeiten, z.B. den [http://de.wikipedia.org/wiki/Algorithmus_von_Bor%C5%AFvka Algorithmus von Boruvka]). Der Anlagerungsalgorithmus für MST wurde zuerst von Prim beschrieben und trägt deshalb seinen Namen, der Verschmelzungsalgorithmus stammt von Kruskal. Im Vergleich zu den Algorithmen für Zusammenhangskomponenten ändert sich im wesentlichen nur die Reihenfolge, in der die Kanten betrachtet werden: Eine Prioritätswarteschlange stellt jetzt sicher, dass am Ende wirklich der Baum mit den geringstmöglichen Kosten herauskommt.

====Algorithmus von Prim====
[http://de.wikipedia.org/wiki/Algorithmus_von_Prim Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]

Der Algorithmus von Prim geht nach dem Anlagerungsprinzip vor (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Tiefensuche|Zusammenhangskomponenten mit Tiefensuche]]): Starte an der Wurzel (ein willkürlich gewählter Knoten) und füge jeweils die günstigste Kante an die aktuellen Teillösung an, die keinen Zyklus verursacht. Die Sortierung der Kanten nach Priorität erfolgt analog zum Dijsktra-Algorithmus, aber die Definitionen, welche Kante die günstigste ist, unterscheiden sich. Die Konvention für die Bedeutung der Elemente des Heaps ist ebenfalls identisch: ein Tupel mit <tt>(priority, node, predecessor)</tt>. Die folgende Implementation verdeutlicht sehr schön die Ähnlichkeit der beiden Algorithmen. Das Ergebnis wird als property map <tt>parents</tt> zurückgegeben, in der für jeden Knoten sein Vorgänger im MST steht, wobei die Wurzel wie üblich auf sich selbst verweist.

import heapq

def prim(graph, weights): # Kantengewichte wie bei Dijkstra als property map
sum = 0.0 # wird später das Gewicht des Spannbaums sein
start = 0 # Knoten 0 wird willkürlich als Wurzel gewählt

parents = [None]*len(graph) # property map, die den resultierenden Baum kodiert
parents[start] = start # Wurzel zeigt auf sich selbst

heap = [] # Heap für die Kanten des Graphen
for neighbor in graph[start]: # besuche die Nachbarn von start
heapq.heappush(heap, (weights[(start, neighbor)], neighbor, start)) # und fülle Heap

while len(heap) > 0:
w, node, predecessor = heapq.heappop(heap) # hole billigste Kante aus dem Heap
if parents[node] is not None: # die Kante würde einen Zyklus verursachen
continue # => ignoriere diese Kante
parents[node] = predecessor # füge Kante in den MST ein
sum += w # und aktualisiere das Gesamtgewicht
for neighbor in graph[node]: # besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn kein Zyklus entsteht
heapq.heappush(heap, (weights[(node,neighbor)], neighbor, node)) # füge Kandidaten in Heap ein

return parents, sum # MST und Gesamtgewicht zurückgeben

====Algorithmus von Kruskal====
[http://de.wikipedia.org/wiki/Algorithmus_von_Kruskal Wikipedia (de)]
[http://en.wikipedia.org/wiki/Kruskal%27s_algorithm (en)]

Die alternative Vorgehensweise ist das Verschmelzungsprinzip (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]]), das der Algorithmus von Kruskal verwendet. Jeder Knoten wird zunächst als trivialer Baum mit nur einem Knoten betrachtet, und alle Kanten werden aufsteigend nach Gewicht sortiert. Dann wird die billigste noch nicht betrachtete Kante in den MST eingefügt, falls sich dadurch kein Zyklus bildet (erkennbar daran, dass die Endknoten in verschiedenen Zusammenhangskomponenten liegen, das heisst verschiedene Anker haben). Da der fertige Baum (V-1) Kanten haben muss, wird dies (V-1) Mal zutreffen. Andernfalls wird diese Kante ignoriert. Anders ausgedrückt: Der Algorithmus beginnt mit ''V'' Bäumen; in (''V''-1) Verschmelzungsschritten kombiniert er jeweils zwei Bäume (unter Verwendung der kürzesten möglichen Kante), bis nur noch ein Baum übrig bleibt. Der einzige Unterschied zum einfachen Union-Find besteht darin, dass die Kanten in aufsteigender Reihenfolge betrachtet werden müssen, was wir hier durch eine Prioritätswarteschlange realisieren. Der Algorithmus von J.Kruskal ist seit 1956 bekannt.

def kruskal(graph, weights):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker
results = [] # result wird später die Kanten des MST enthalten

heap = [] # Heap zum Sortieren der Kanten nach Gewicht
for edge, w in weights.iteritems(): # alle Kanten einfügen
heapq.heappush(heap, (w, edge))

while len(heap) > 0: # solange noch Kanten vorhanden sind
w, edge = heapq.heappop(heap) # billigste Kante aus dem Heap nehmen
a1 = findAnchor(anchors, edge[0]) # Anker von Startknoten der Kante
a2 = findAnchor(anchors, edge[1]) # ... und Endknoten bestimmen
if a1 != a2: # wenn die Knoten in verschiedenen Komponenten sind
anchors[a2] = a1 # Komponenten verschmelzen
result.append(edge) # ... und Kante in MST einfügen

return result # Kanten des MST zurückgeben

Die Funktion <tt>findAnchor()</tt> wurde im Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]] implementiert. Im Unterschied zum Algorithmus von Prim geben wir hier nicht die property map <tt>parents</tt> zurück, sondern einfach eine Liste der Kanten im MST.

Der Algorithmus eignet sich insbesondere für das Clusteringproblem, da der Schwellwert von vornerein als maximales Kantengewicht an den Algorithmus übergeben werden kann. Man hört mit dem Vereinigen auf, wenn das Gewicht der billigste Kante im Heap den Schwellwert überschreitet. Beim Algorithmus von Kruskal kann dann keine bessere Kante als der Schwellwert mehr kommen, da die Kanten vorher sortiert worden sind.

Komplexität: wie beim Dijkstra-Algorithmus, weil jede Kante genau einmal in den Heap kommt. Der Aufwand für das Sortieren ist somit <math>O\left(E\log E\right)</math>, was sich zu <math>O \left(E\,\log\,V\right)</math> reduziert, falls keine Mehrfachkanten vorhanden sind.

=> geeignet für Übungsaufgabe

====Verwendung einer BucketPriorityQueue====

Beide Algorithmen zur Bestimmung des minimalen Spannbaums benötigen eine Prioritätswarteschlange. Wenn die Kantengewichte ganze Zahlen im Bereich <tt>0...(m-1)</tt> sind, kann man die MST-Algorithmen deutlich beschleunigen, wenn man anstelle des Heaps eine [[Prioritätswarteschlangen#Prioritätssuche mit dem Bucket-Prinzip|<tt>BucketPriorityQueue</tt>]] verwendet. Die Operationen zum Einfügen einer Kante in die Queue und zum Entfernen der billibsten Kante aus der Queue beschleunigen sich dadurch auf O(1) statt O(log V) (außer wenn die Gewichte sehr ungünstig auf die Kanten verteilt sind). In der Praxis erreicht man durch diese Änderung typischerweise deutliche Verbesserungen. In der Bildverarbeitung können die Prioritäten beispielsweise die Wahrscheinlichkeit kodieren, dass zwei benachbarte Pixel zu verschiedenen Objekten gehören. Bildet man jetzt den MST, und bricht bei einer bestimmten Wahrscheinlichkeit ab, erhält man Cluster von Pixeln, die wahrscheinlich zum selben Objekt gehören (weil der MST ja die Kanten mit minimalem Gewicht bevorzugt, und kleine Gewichte bedeuten kleine Wahrscheinlichkeit, dass benachbarte Pixel von einander getrennt werden). Da man die Wahrscheinlichkeiten nur mit einer Genauigkeit von ca. 1% berechnen kann, reichen hiefür 100 bis 200 Quantisierungstufen aus. Durch Verwendung der schnellen <tt>BucketPriorityQueue</tt> kann man jetzt wesentlich größere Bilder in akzeptabler Zeit bearbeiten als dies mit einem Heap möglich wäre.

== Algorithmen für gerichtete Graphen ==

Zur Erinnerung: in einem gerichteten Graphen sind die Kanten (i → j) und (j → i) voneinander verschieden, und eventuell existiert nur eine der beiden Richtungen. Im allgemeinen unterscheidet sich der [[Graphen_und_Graphenalgorithmen#transposed_graph|transponierte Graph]] GT also vom Originalgraphen G. Beim Traversieren des Graphen und bei der Pfadsuche dürfen Kanten nur in passender Richtung verwendet werden. Bei gewichteten Graphen tritt häufig der Fall auf, dass zwar Kanten in beiden Richtungen existieren, diese aber unterschiedliche Gewichte haben.

Gerichtete Graphen ergeben sich in natürlicher Weise aus vielen Anwendungsproblemen:
* Routenplanung
** Bei Straßennetzwerken enstehen gerichtete Graphen, sobald es Einbahnstraßen gibt.
** Verwendet man Gewichte, um die erwarteten Fahrzeiten entlang einer Straße zu kodieren, gibt es Asymmetrien z.B. dann, wenn Straßen in einer Richtung bergab, in der anderen bergauf befahren werden. Hier existieren zwar Kanten in beiden Richtungen, sie haben aber unterschiedliche Gewichte. Ähnliches gilt für Flüge: Durch den Gegenwind des Jetstreams braucht man von Frankfurt nach New York länger als umgekehrt von New York nach Frankfurt.
* zeitliche oder kausale Abhängigkeiten
** Wenn die Knoten Ereignisse repräsentieren, von denen einige die Ursache von anderen sind, diese wiederum die Ursache der nächsten usw., verbindet man die Knoten zweckmäßig durch gerichtete Kanten, die die Kausalitätsbeziehungen kodieren. Handelt es sich um logische "wenn-dann"-Regeln, erhält man einen [[Graphen_und_Graphenalgorithmen#Anwendung:_Das_Erf.C3.BCllbarkeitsproblem_in_Implikationengraphen|Implikationengraph]] (siehe unten). Handelt es sich hingegen um Wahrscheinlichkeitsaussagen ("Wenn das Wetter schön ist, haben Studenten tendenziell gute Laune, wenn eine Prüfung bevorsteht eher schlechte usw."), erhält man ein [http://de.wikipedia.org/wiki/Bayessches_Netz Bayessches Netz].
** Wenn bestimmte Aufgaben erst begonnen werden können, nachdem andere Aufgaben erledigt sind, erhält man einen Abhängigkeitsgraphen. Beispielsweise dürfen Sie erst an der Klausur teilnehmen, nachdem Sie die Übungsaufgaben gelöst haben, und Sie dürfen erst die Abschlussarbeit beginnen, nachdem Sie bestimmte Prüfungen bestanden haben. Ein anderes schönes Beispiel liefern die Regeln für das [[Graphen_und_Graphenalgorithmen#Anwendung:_Abh.C3.A4ngigkeitsgraph|Ankleiden]] weiter unten.
** Gerichtete Graphen kodieren die Abhängigkeiten zwischen Programmbibliotheken. Beispielsweise benötigt das Pythonmodul <tt>json</tt> die internen Submodule <tt>json.encoder</tt> und <tt>json.decode</tt> sowie das externe Modul <tt>decimal</tt>. Die Submodule benötigen wiederum die externen Module <tt>re</tt> und <tt>sys</tt>, das Modul <tt>decimal</tt> braucht <tt>copy</tt> und <tt>collections</tt> usw.
** Das Internet kann als gerichteter Graph dargestellt werden, wobei die Webseiten die Knoten, und die Hyperlinks die Kanten sind.
* Sequence Alignment
** Eine gute Rechtschreibprüfung markiert nicht nur fehlerhafte Wörter, sondern macht auch plausible Vorschläge, was eigentlich gemeint gewesen sein könnte. Dazu muss sie das gegebene Wort mit den Wörtern eines Wörterbuchs vergleichen und die Ähnlichkeit bewerten. Ein analoges Problem ergibt sich, wenn man DNA Fragmente mit der Information in einer Genomdatenbank abgleichen will.

=== Anwendung: Sequence Alignment / Edit Distance ===

:gegeben: zwei Wörter (allgemein: beliebige Zeichenfolgen)
:gesucht: Wie kann man die Buchstaben am besten in Übereinstimmung bringen?

:Beispiel: WORTE – NORDEN

Zwei mögliche Alignments sind

WORTE. W.ORTE
NORDEN NORDEN

wobei der Punkt anzeigt, dass der untere Buchstabe keinen Partner hat, und rote Buchstaben oben und unten übereinstimmen. Jede Nicht-Übereinstimmung verursacht nun gewisse Kosten. Dabei unterscheiden wir zwei Fälle:
# Matche a[i] mit b[j]. Falls a[i] == b[j], ist das gut (rote Buchstaben), und es entstehen keine Kosten. Andernfalls entstehen Kosten U (schwarze Buchstaben).
# Wir überspringen a[i] oder b[j] (Buchstabe vs. Punkt). Dann entstehen Kosten V. (Manchmal unterscheidet man auch noch Kosten Va und Vb, wenn das Überspringen bei a und b unterschieldiche Signifikanz hat.)

Gesucht ist nun das Alignment mit minimalen Kosten

Diese Aufgabe kann man sehr schön als gerichteten Graphen darstellen: Wir definieren ein rechteckiges Gitter und schreiben das erste Wort über das Gitter und das andere links davon. Die Gitterpunkte verbinden wir mit Pfeilen (gerichteten Kanten), wobei ein Pfeil nach rechts bedeutet, dass wir beim oberen Wort einen Buchstaben überspringen, ein Pfeil nach unten, dass wir beim linken Wort einen Buchstaben überspringen, und ein diagonaler Pfeil, dass wir zwei Buchstaben matchen (und zwar die am Pfeilende). Die Farben der Pfeile symbolisieren die Kosten: rot für das Überspringen eines Buchstabens (Kosten V), blau für das Matchen, wenn die Buchstaben nicht übereinstimmen (Kosten U), und grün, wenn die Buchstaben übereinstimmen (keine Kosten).

[[Image:sequence-alignment.png|300px]]

Lösung:
:Suche den kürzesten Pfad vom Knoten "START" (oben links) nach unten rechts. Dazu kann der [[Graphen und Graphenalgorithmen#Algorithmus von Dijkstra|Algorithmus von Dijkstra]] verwendet werden, der auf gerichteten Graphen genauso funktioniert wie auf ungerichteten.

Für unser Beispiel von oben erhalten wir die folgenden Pfade:

[[Image:sequence-alignment-weg1.png|400px]]     [[Image:sequence-alignment-weg2.png|400px]]

Durch Addieren der Kosten entsprechend der Farben sieht man, dass der erste Weg die Kosten 2U+V und der zweite die Kosten 5U+V hat. Der erste Weg ist offensichtlich günstiger und entspricht dem besten Alignment.

=== Anwendung: Abhängigkeitsgraph ===

Beispiel: Wie erklärt man einem zerstreuten Professor, wie er sich morgens anziehen soll? Der folgende Graph enthält einen Knoten für jede Aktion, und eine Kante (i → j) bedeutet, dass die Aktion i vor der Aktion j abgeschlossen werden muss.

[[Image:anziehen-graph.png|600px]]

In derartigen Abhängigkeitsgraphen ist die wichtigste Frage immer, ob der Graph azyklisch ist. Wäre dies nämlich nicht der Fall, kann es keine Reihenfolge der Aktionen geben, die alle Abhängigkeiten erfüllt. Dies sieht man leicht, wenn man den einfachsten möglichen Zyklus betrachtet: es gibt sowohl eine Kante (i → j) als auch eine (j → i). Dann müsste man i vor j erledigen, aber ebenso j vor i, was offensichtlich unmöglich ist - das im Graph kodierte Problem ist dann unlösbar. Wegen ihrer Wichtigkeit wird für gerichtete azyklische Graphen oft die Abkürzung DAG (von directed acyclic graph) verwendet. Ein Graph ist genau dann ein DAG, wenn es eine topologische Sortierung gibt:
;topologische Sortierung: Zeichne die Knoten so auf eine Gerade, dass alle Kanten (Pfeile) nach rechts zeigen.
Arbeitet man die Aktionen nach einer (beliebigen) topologischen Sortierung ab, werden automatisch alle Abhängigkeiten eingehalten: Da alle Pfeile nach rechts zeigen, werden abhängige Aktionen immer später ausgeführt. Die topologische Sortierung ist im allgemeinen nicht eindeutig. Die folgende Skizze zeigt eine mögliche topologische Sortierung für das Anziehen:

[[Image:anziehen-topologische-sortierung.png|600px]]

Eine solche fest vorgegebene Reihenfolge ist für den zerstreuten Professor sicherlich eine größere Hilfe als der ursprüngliche Graph. Man erkennt, dass die Sortierung nicht eindeutig ist, beispielsweise bei der Uhr: Da für die Uhr keine Abhängigkeiten definiert sind, kann man diese Aktion an beliebiger Stelle einsortieren. Hier wurde willkürlich die letzte Stelle gewählt.

==== Zwei Algorithmen zum Finden der topologischen Sortierung ====

Die folgenden Algorithmen finden entweder eine topologische Sortierung, oder signalisieren, dass der Graph zyklisch ist.

===== Algorithmus 1 =====
# Suche einen Knoten mit Eingangsgrad 0 (ohne eingehende Pfeile) => in einem gerichteten azyklischen Graphen gibt es immer einen solchen Knoten
# Platziere diesen Knoten auf der Geraden (beliebig)
# Entferne den Knoten aus dem Graphen zusammen mit den ausgehenden Kanten
# Gehe zu 1., aber platziere in 2. immer rechts der Knoten, die schon auf der Geraden vorhanden sind.
: => Wenn noch Knoten übrig sind, aber keiner Eingangsgrad 0 hat, muss der Graph zyklisch sein.

[[Image:bild6.JPG]]

Beispiel für einen zyklischen Graphen: kein Knoten hat Eingangsgrad 0.

Um den Algorithmus zu implementieren, verwenden wir eine property map <tt>in_degree</tt>, die wir in einem ersten Durchlauf durch den Graphen füllen und die dann für jeden Knoten die Anzahl der eingehenden Kanten speichert. Dann gehen wir sukzessive zu allen Knoten mit <tt>in_degree == 0</tt>. Anstatt sie aber tatsächlich aus dem Graphen zu entfernen wie im obigen Pseudocode, dekrementieren wir nur den <tt>in_degree</tt> ihrer Nachbarn. Wird der <tt>in_degree</tt> eines Nachbarn dadurch 0, wird er ebenfalls in das Array der zu scannenden Knoten aufgenommen. Wenn der Graph azyklisch ist, enthält das Array am Ende alle Knoten des Graphen, und die Reihenfolge der Einfügungen definiert eine topologische Sortierung. Andernfalls ist das Array zu kurz, und wir signalisieren durch Zurückgeben von <tt>None</tt>, dass der Graph zyklisch ist:

def topological_sort(graph): # ein gerichteter Graph
in_degree = [0]*len(graph) # property map für den Eingangsgrad jeden Knotens
for node in xrange(len(graph)): # besuche alle Knoten
for neighbor in graph[node]: # ... und deren Nachbarn
in_degree[neighbor] += 1 # ... und inkrementiere den Eingangsgrad

result = [] # wird später die topologische Sortierung enthalten
for node in xrange(len(graph)):
if in_degree[node] == 0:
result.append(node) # füge alle Knoten mit Eingangsgrad 0 in result ein

k = 0
while k < len(result): # besuche alle Knoten mit Eingangsgrad 0
node = result[k]
k += 1
for neighbor in graph[node]: # besuche alle Nachbarn
in_degree[neighbor] -= 1 # entferne 'virtuell' die eingehende Kante
if in_degree[neighbor] == 0: # wenn neighbor jetzt Eingangsgrad 0 hat
result.append(neighbor) # ... füge ihn in result ein

if len(result) == len(graph): # wenn alle Knoten jetzt Eingangsgrad 0 haben
return result # ... ist result eine topologische Sortierung
else:
return None # andernfalls ist der Graph zyklisch

===== Algorithmus 2 =====
Der obige Algorithmus hat den Nachteil, dass er jeden Knoten zweimal expandiert. Man kann eine topologische Sortierung stattdessen auch mit Tiefensuche bestimmen. Es gilt nämlich der folgende
;Satz: Wird ein DAG mittels Tiefensuche traversiert, definiert die reverse post-order eine topologische Sortierung.
Zur Erinnerung: die post-order erhält man, indem man jeden Knoten ausgibt, nachdem die Rekursion zu allen seinen Nachbarn beendet ist, siehe unsere [[Graphen_und_Graphenalgorithmen#pre_and_post_order|Diskussion weiter oben]]. Die reverse post-order ist gerade die Umkehrung dieser Reihenfolge. Die folgende Implementation verwendet die rekursive Version der Tiefensuche, in der Praxis wird man meist die iterative Version mit Stack bevorzugen, weil bei großen Graphen die Aufruftiefe sehr groß werden kann:

def reverse_post_order(graph): # gerichteter Graph
result = [] # enthält später die reverse post-order
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node): # besuche node
if not visited[node]: # aber nur, wenn er noch nicht besucht wurde
visited[node] = True # markiere ihn als besucht
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor)
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order

for node in xrange(len(graph)): # besuche alle Knoten
visit(node)

result.reverse() # post-order => reverse post-order
return result

Die Tatsache, dass die reverse post-order tatsächlich eine topologische Sortierung liefert, leuchtet wahrscheinlich nicht unmittelbar ein. Bevor wir diese Tatsache beweisen. wollen wir uns anhand des Ankleidegraphen klar machen, dass die pre-order (die man intuitiv vielleicht eher wählen würde) keine topologische Sortierung ist. Startet man die Tiefensuche beim Knoten "Unterhemd", werden die Knoten in der Reihenfolge "Unterhemd", "Oberhemd", "Schlips", "Jackett", "Gürtel" gefunden. Da dann alle von "Unterhemd" erreichbaren Knoten erschöpft sind, startet man die Tiefensuche als nächstes bei "Unterhose" und erreicht von dort aus "Hose" und "Schuhe". Man erkennt sofort, dass diese Reihenfolge nicht funktioniert: "Hose" kommt nach "Gürtel", und "Jackett" kommt vor "Gürtel". Bei dieser Anordnung gibt es Pfeile nach links, die Abhängigkeitsbedingungen sind somit verletzt.

Damit die reverse post-order eine zulässige Sortierung sein kann, muss stets gelten, dass Knoten u vor Knoten v einsortiert wurde, wenn die Kante (u → v) existiert. Das ist aber äquivalent zur Forderung, dass in der ursprünglichen post-order (vor dem <tt>reverse</tt>) u hinter v stehen muss. Wir betrachten den <tt>visit</tt>-Aufruf, bei dem u expandiert wird. Gelangt man jetzt zu u's Nachbarn v, gibt es zwei Möglichkeiten: Wenn v bereits expandiert wurde, befindet es sich bereits im Array <tt>result</tt> und <tt>visit</tt> kehrt sofort zurück. Andernfalls wird v ebenfalls expandiert und demzufolge in <tt>result</tt> eingetragen, bevor der rekursive Aufruf <tt>visit(v)</tt> zurückkehrt. Knoten u wird aber erst in <tt>result</tt> eingefügt, nachdem alle rekursiven <tt>visit</tt>-Aufrufe seiner Nachbarn zurückgekehrt sind. In beiden Fällen steht u in der post-order wie gefordert hinter v, und daraus folgt die Behauptung.

Der obige Algorithmus liefert natürlich nur dann eine topologische Sortierung, wenn der Graph wirklich azyklisch ist (man kann ihn aber auch anwenden, um die reverse post-order für einen zyklischen Graphen zu bestimmen, siehe Abschnitt "[[Graphen_und_Graphenalgorithmen#Transitive Hülle und stark zusammenhängende Komponenten|Stark zusammenhängende Komponenten]]"). Dieser Fall tritt in der Praxis häufig auf, weil zyklische Graphen bei vielen Anwendungen gar nicht erst entstehen können. Weiß man allerdings nicht, ob der Graph azyklisch ist oder nicht, muss man einen zusätzlichen Test auf Zyklen in den Algorithmus einbauen.

Zyklische Graphen sind dadurch gekennzeichnet, dass es im obigen Beweis eine dritte Möglichkeit gibt: Während der Expansion von u wird rekursiv v expandiert, und es gibt eine Rückwärtskante (v → u). (Es spielt dabei keine Rolle, ob v von u aus direkt oder indirekt erreicht wurde.) Ein Zyklus wird also entdeckt, wenn die Tiefensuche zu u zurückkehrt, solange u noch aktiv ist, d.h. wenn die Rekursion von u aus gestartet und noch nicht beendet wurde. Dies kann man leicht feststellen, wenn man in der property map <tt>visited</tt> drei Werte zulässt: 0 für "noch nicht besucht", 1 für "aktiv" und 2 für "beendet". Wir signalisieren einen Zyklus, sobald <tt>visit</tt> für einen Knoten aufgerufen wird, der gerade aktiv ist:

def topological_sort_DFS(graph): # gerichteter Graph
result = [] # enthält später die topologische Sortierung

not_visited, active, finished = 0, 1, 2 # drei Zustände für visited
visited = [not_visited]*len(graph) # Flags für aktive und bereits besuchte Knoten

def visit(node): # besuche node (gibt "True" zurück, wenn Zyklus gefunden wurde)
if visited[node] == not_visited: # ... aber nur, wenn er noch nicht besucht wurde
visited[node] = active # markiere ihn als aktiv
for neighbor in graph[node]: # und besuche die Nachbarn
if visit(neighbor): # wenn rekursiv ein Zyklus gefunden wurde
return True # ... brechen wir ab und signalisieren den Zyklus
visited[node] = finished # Rekursion beendet, node ist nicht mehr aktiv
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order
return False # kein Zyklus gefunden
elif visited[node] == active: # Rekursion erreicht einen noch aktiven Knoten
return True # => Zyklus gefunden

for node in xrange(len(graph)): # besuche alle Knoten
if visit(node): # wenn Zyklus gefunden wurde
return None # ... gibt es keine topologische Sortierung

result.reverse() # post-order => reverse post-order (=topologische Sortierung)
return result

Man macht sich leicht klar, dass kein Zyklus vorliegt, wenn die Rekursion einen Knoten erreicht, der bereits auf <tt>finished</tt> gesetzt ist. Nehmen wir an, dass u gerade expandiert wird, und sein Nachbar v ist bereits <tt>finished</tt>. Wenn es einen Zyklus gäbe, müsste es einen Weg von v nach u geben. Dann wäre u aber bereits während der Expansion von v gefunden worden. Da v nicht mehr im Zustand <tt>active</tt> ist, muss die Expansion von v schon abgeschlossen gewesen sein, ohne dass u gefunden wurde. Folglich kann es keinen solchen Zyklus geben.

=== Transitive Hülle und stark zusammenhängende Komponenten ===

Auch bei gerichteten Graphen ist die Frage, welche Knoten miteinander zusammenhängen, von großem Interesse. Wir betrachten dazu wieder die Relation "Knoten v ist von Knoten u aus erreichbar", die anzeigt, ob es einen Weg von u nach v gibt oder nicht. In ungerichteten Graphen ist diese Relation immer symmetrisch, weil jeder Weg in beiden Richtungen benutzt werden kann. In gerichteten Graphen gilt dies nicht. Man muss hier zwei Arten von Zusammenhangskomponenten unterscheiden:
;Transitive Hülle: Die transitive Hülle eines Knotens u ist die Menge aller Knoten, die von u aus erreichbar sind:
:<math>T(u) = \{v\ |\ u \rightsquigarrow v\}</math>
;Stark zusammenhängende Komponenten: Die stark zusammenhängende Komponenten <math>C_i</math> eines gerichteten Graphen sind maximale Teilgraphen, so dass alle Knoten innerhalb einer Komponente von jedem anderen Knoten der selben Komponente aus erreichbar sind
:<math>u,v \in C_i\ \ \Leftrightarrow\ \ u \rightsquigarrow v \wedge v \rightsquigarrow u</math>
Die erste Definition betrachtet den Zusammenhang asymmetrisch, ohne Beachtung der Frage, ob es auch einen Rückweg von Knoten v nach u gibt, die zweite hingegen symmetrisch.

Die transitive Hülle benötigt man, wenn man Fragen der Erreichbarkeit besonders effizient beantworten will. Wir hatten bespielsweise oben erwähnt, dass das Python-Modul <tt>json</tt> direkt und indirekt von mehreren anderen Module abhängt, die vorher installiert werden müssen, damit <tt>json</tt> funktioniert. Bittet man den Systemadministrator, das <tt>json</tt>-Paket zu installieren, will er diese Abhängigkeiten wahrscheinlich nicht erst mühsam rekursiv heraussuchen, sonder er verlangt eine Liste aller Pakete, die installiert werden müssen. Dies ist gerade die transitive Hülle von <tt>json</tt> im Abhängigkeitsgraphen. Damit man diese nicht manuell bestimmen muss, verwendet man Installationsprogrammen wie z.B. [http://pypi.python.org/pypi/pip/ pip], die die Abhängigkeiten automatisch herausfinden und installieren.

Bei der Bestimmung der transitiven Hülle modifiziert man den gegebenen Graphen, indem man jedesmal eine neue Kante (u → v) einfügt, wenn diese Kante noch nicht existiert, aber v von u aus erreichbar ist. Dies gelingt mit einer sehr einfachen Variation der Tiefensuche: Wir rufen <tt>visit(k)</tt> für jeden Knoten k auf, aber setzen die property map <tt>visited</tt> zuvor auf <tt>False</tt> zurück. Alle Knoten, die während der Rekursion erreicht werden, sind im modifizierten Graphen Nachbarn von k. Ein etwas effizienterer Ansatz ist der [http://de.wikipedia.org/wiki/Algorithmus_von_Floyd_und_Warshall Algorithmus von Floyd und Warshall].

Die Bestimmung der stark zusammenhängenden Komponenten ist etwas schwieriger. Es existieren eine ganze Reihe von effizienten Algorithmen (siehe [http://en.wikipedia.org/wiki/Strongly_connected_component WikiPedia]), deren einfachster der Algorithmus von Kosaraju ist:

gegeben: gerichteter Graph

# Bestimme die reverse post-order (mit der Funktion <tt>reverse_post_order</tt>)
# Bilde den transponierten Graphen <math>G^T</math> (mit der Funktion <tt>transposeGraph</tt>)
# Bestimme die Zusammenhangskomponenten von <math>G^T</math> mittels Tiefensuche, aber betrachte die Knoten dabei in der reverse post-order aus Schritt 1 (dies kann mit einer minimalen Modifikation der Funktion <tt>connectedComponents</tt> geschehen, indem man die Zeile <tt>for node in xrange(len(graph)):</tt> einfach nach <tt>for node in ordered:</tt> abändert, wobei <tt>ordered</tt> das Ergebnis der Funktion <tt>reverse_post_order</tt> ist, also ein Array, das die Knoten in der gewünschten Reihenfolge enthält).
Die Zusammenhangskomponenten, die man in Schritt 3 findet, sind gerade die stark zusammenhängenden Komponenten des Originalgraphen G. Die folgende Skizze zeigt diese in grün für den schwarz gezeichneten gerichteten Graphen.

[[Image:strongly-connected-components.png|400px]]

Zum Beweis der Korrektheit des Algorithmus von Kosaraju zeigen wir zwei Implikationen: 1. Wenn die Knoten u und v in der selben stark zusammenhängenden Komponente liegen, werden sie in Schritt 3 des Algorithmus auch der selben Komponente zugewiesen. 2. Wenn die Knoten u und v in Schritt 3 der selben Komponente zugewiesen wurden, müssen sie auch in der selben stark zusammenhängenden Komponente liegen.
# Knoten u und v gehören zur selben stark zusammenhängenden Komponente von G. Per Definition gilt, dass u von v aus erreichbar ist und umgekehrt. Dies muss auch im transponierten Graphen GT gelten (der Weg <math>u \rightsquigarrow v</math> wird jetzt zum Weg <math>v \rightsquigarrow u</math> und umgekehrt). Wird u bei der Tiefensuche in Schritt 3 vor v expandiert, ist v von u aus erreichbar und gehört somit zur selben Komponente. Das umgekehrte gilt, wenn v vor u expandiert wird. Daraus folgt die Behauptung 1.
# Knoten u und v werden in Schritt 3 der selben Komponente zugewiesen: Sei x der Anker dieser Komponente. Da u in der gleichen Komponente wie x liegt, muss es in GT einen Weg <math>x \rightsquigarrow u</math>, und demnach in G einen Weg <math>u \rightsquigarrow x</math> geben. Da x der Anker seiner Komponente ist, wissen wir aber auch, dass x in der reverse post-order vor u liegt (denn der Anker ist der Knoten, mit dem eine neue Komponente gestartet wird; er muss deshalb im Array <tt>ordered</tt> als erster Konten seiner Komponente gefunden worden sein). Wir unterscheiden jetzt im Schritt 1 des Algorithmus zwei Fälle:
## u wurde bei der Bestimmung der post-order vor x expandiert. Dann kann x nur dann in der reverse post-order vor u liegen (oder, einfacher ausgedrückt, x kann nur dann in der post-order hinter u liegen), wenn x im Graphen G nicht von u aus erreichbar war. Das ist aber unmöglich, weil wir ja schon wissen, dass es in G einen Weg <math>u \rightsquigarrow x</math> gibt.
## Folglich wurde u bei der Bestimmung der post-order nach x expandiert. Da x in der post-order hinter u liegt, muss u während der Expansion von x erreicht worden sein. Deshalb muss es in G auch einen Weg <math>x \rightsquigarrow u</math> geben.
#:Somit sind x und u in der selben stark zusammenhängenden Komponente. Die gleiche Überlegung gilt für x und v. Wegen der Transitivität der relation "ist erreichbar" folgt daraus, dass auch u und v in der selben Komponente liegen, also die Behauptung 2.

Die folgende Skizze illustriert, dass der Komponentengraph stets azyklisch ist. Den Komponentengraph erhält man, indem man für jede Komponente <math>C_i</math> einen Knoten erzeugt (grün), und die Knoten i und j durch eine gerichtete Kante verbindet (rot), wenn es im Originalgraphen eine Kante (u → v) mit <math>u \in C_i</math> und <math>v \in C_j</math> gibt. Es ist dann garantiert, dass es keine Kante in umgekehrter Richtung geben kann. Daraus folgt insbesondere, dass ein DAG nur triviale stark verbundene Komponenten haben kann, die aus einzelnen Knoten bestehen.

[[Image:strongly-connected-components-graph.png|400px]]

=== Anwendung: Das Erfüllbarkeitsproblem in Implikationengraphen ===

Das Erfüllbarkeitsproblem hat auf den ersten Blick nichts mit Graphen zu tun, denn es geht um Wahrheitswerte logischer Ausdrücke. Man kann logische Ausdrücke jedoch unter bestimmten Bedingungen in eine Graphendarstellung überführen und somit das ursprüngliche Problem auf ein Problem der Graphentheorie reduzieren, für das bereits ein Lösungsverfahren bekannt ist. In diesem Abschnitt wollen wir dies für die sogenannten Implikationengraphen zeigen, ein weiteres Beispiel findet sich im Kapitel [[NP-Vollständigkeit]].

==== Das Erfüllbarkeitsproblem ====

(vgl. [http://de.wikipedia.org/wiki/Erfüllbarkeitsproblem_der_Aussagenlogik WikiPedia (de)])

Das Erfüllbarkeitsproblem (SAT-Problem, von satisfiability) befasst sich mit logischen (oder Booleschen) Funktionen: Gegeben sei eine Menge <math>\{x_1, ... ,x_n\}</math> Boolscher Variablen (d.h., die <math>x_i</math> können nur die Werte True oder False annehmen), sowie eine logische Formel, in der die Variablen mit den üblichen logischen Operatoren
:<math>\neg\quad</math>: Negation ("nicht", in Python: <tt>not</tt>)
:<math>\vee\quad</math>: Disjunktion ("oder", in Python: <tt>or</tt>)
:<math>\wedge\quad</math>: Konjuktion ("und", in Python: <tt>and</tt>)
:<math>\rightarrow\quad</math>: Implikation ("wenn, dann", in Python nicht als Operator definiert)
:<math>\leftrightarrow\quad</math>: Äquivalenz ("genau dann, wenn", in Python: <tt>==</tt>)
:<math>\neq\quad</math>: exklusive Disjunktion ("entweder oder", in Python: <tt>!=</tt>)
verknüpft sind. Klammern definieren die Reihenfolge der Auswertung der Operationen. Für jede Belegung der Variablen <math>x_i</math> mit True oder False liefert die Formel den Wert der Funktion, der natürlich auch nur True oder False sein kann. Wenn Formel und Belegung gegeben sind, ist die Auswertung der Funktion ein sehr einfaches Problem: Man transformiert die Formel in einen Parse-Baum (siehe Übungsaufgabe "Taschenrechner) und wertet jeden Knoten mit Hilfe der üblichen Wertetabellen für logische Operatoren aus, die wir hier zur Erinnerung noch einmal angeben:
{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>a</math>
|width="70px"| <math>b</math>
|width="70px"| <math>a \vee b </math>
|width="70px"| <math>a \wedge b</math>
|width="70px"| <math>a \rightarrow b</math>
|width="70px"| <math>b \rightarrow a</math>
|width="70px"| <math>a \leftrightarrow b</math>
|width="70px"| <math>a \neq b</math>
|- align="center"
| 0 || 0 || 0 || 0 || 1 || 1 || 1 || 0
|- align="center"
| 0 || 1 || 1 || 0 || 1 || 0 || 0 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 0 || 1 || 0 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1 || 0
|}

Beim Erfüllbarkeitsproblem wird die Frage umgekehrt gestellt:
:Gegeben sei eine logische Funktion. Ist es möglich, dass die Funktion jemals den Wert True annimmt?
Das heisst, kann man die Variablen <math>x_i</math> so mit True oder False belegen, dass die Formel am Ende wahr ist? Im Prinzip kann man diese Frage durch erschöpfende Suche leicht beantworten, indem man die Funktion für alle <math>2^n</math> möglichen Belegungen einfach ausrechnet, aber das dauert für große n (ab ca. <math>n\ge 40</math>) viel zu lange. Erstaunlicherweise ist es aber noch niemanden gelungen, einen Algorithmus zu finden, der für beliebige logische Funktionen schneller funktioniert. Im Gegenteil wurde gezeigt, dass das Erfüllbarkeitsproblem [[NP-Vollständigkeit|NP-vollständig]] ist, so dass wahrscheinlich kein solcher Algorithmus existiert. Trotz (oder gerade wegen) seiner Schwierigkeit hat das Erfüllbarkeitsproblem viele Anwendungen gefunden, vor allem beim Testen logischer Schaltkreise ("Gibt es eine Belegung der Eingänge, so dass am Ausgang der verbotene Wert X entsteht?") und bei der Planerstellung in der künstlichen Intelligenz ("Kann man ausschließen, dass der generierte Plan Konflikte enthält?"). Es ist außerdem ein beliebtes Modellproblem für die Erforschung neuer Ideen und Algorithmen für schwierige Probleme.

==== Normalformen für logische Ausdrücke ====

Um die Beschreibung von Erfüllbarkeitsproblemen zu vereinfachen und zu vereinheitlichen, hat man verschiedene Normalformen für logische Ausdrücke eingeführt. Die wichtigste ist die Konjuktionen-Normalform (CNF - conjunctive normal form). Ein Ausdruck in Konjuktionen-Normalform ist eine UND-Verknüpfung von M Klauseln:
(CLAUSE1) <math>\wedge</math> (CLAUSE2) <math>\wedge</math> ... <math>\wedge</math> (CLAUSEM)
Jede Klausel ist wiederum ein logischer Ausdruck, der aber sehr einfach sein muss: Er darf nur noch k Variablen enthalten, die nur mit den Operatoren NICHT und ODER verknüpft werden dürfen, z.B.
CLAUSE1 := <math>x_1 \vee \neg x_3 \vee x_8</math>
Je nachdem, wie viele Variablen pro Klausel erlaubt sind, spricht man von k-CNF und entsprechend von einem k-SAT Problem. Es ist außerdem üblich, die Menge der Variablen und die Menge der negierten Variablen zusammen als Menge der Literale zu bezeichnen:
LITERALS := <math>\{x_1,...,x_n\} \cup \{\neg x_1,...,\neg x_n\}</math>
Formal definiert man die k-Konjunktionen-Normalform (k-CNF) am besten durch eine Grammatik in [http://de.wikipedia.org/wiki/Backus-Naur-Form Backus-Naur-Form]:
k_CNF ::= CLAUSE | k_CNF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\vee</math> ... <math>\vee</math> LITERAL) # genau k Literale pro Klausel
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
Beispiele:
* 3-CNF: <math>(x_1 \vee \neg x_2 \vee x_4) \wedge (x_2 \vee x_3 \vee \neg x_4) \wedge (\neg x_1 \vee x_4 \vee \neg x_5)</math>
* 2-CNF: <math>(x_1 \vee \neg x_2) \wedge (x_3 \vee x_4)</math> ...
Gesucht ist eine Belegung der Variablen mit True und False, so dass der Ausdruck den Wert True hat. Aus den Eigenschaften der UND- und ODER-Verknüpfungen folgt, dass ein Ausdruck in k-CNF genau dann True ist, wenn jede einzelne Klausel True ist. In jeder Klausel wiederum hat man k Chancen, die Klausel True zu machen, indem man eins der Literale zu True macht. Eventuell werden dadurch aber andere Klauseln wieder zu False, was die Aufgabe so schwierig macht. Die Bedeutung der k-CNF ergibt sich aus folgendem
;Satz: Jeder logische Ausdruck kann effizient nach 3-CNF transformiert werden, jedoch im allgemeinen nicht nach 2-CNF.
Man kann sich also auf Algorithmen für 3-SAT-Probleme konzentrieren, ohne dabei an Ausdrucksmächtigkeit zu verlieren.

Leider gilt der entsprechende Satz nicht für k=2: Ausdrücke in 2-CNF sind weit weniger mächtig, weil man in jeder Klausel nur noch zwei Wahlmöglichkeiten hat. Bestimmte logische Ausdrücke sind aber auch nach 2-CNF transformierbar, beispielsweise die Bedingung, dass zwei Literale u und v immer den entgegegesetzten Wert haben müssen. Dies ergibt ein Paar von ODER-Verknüpfungen:
:<math>(u \leftrightarrow \neg v) \equiv (u \vee \neg v) \wedge (\neg u \vee v)</math>
Die 2-CNF hat den Vorteil, dass es effiziente Algorithmen für das 2-SAT-Problem gibt, die wir jetzt kennenlernen wollen. Es zeigt sich, dass man Ausdrücke in 2-CNF als Graphen repräsentieren kann, indem man sie zunächst in die Implikationen-Normalform (INF für implicative normal form) überführt. Die Implikationen-Normalform besteht ebenfalls aus einer Menge von Klauseln, die durch UND-Operationen verknüpft sind, aber jede Klausel ist jetzt eine Implikation.
Die Grammatik der Implikationen-Normalform (INF) lautet:
INF ::= CLAUSE | INF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\rightarrow</math> LITERAL) # genau 2 Literale pro Implikation
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
und ein gültiger Ausdruck wäre z.B.
:<math>(x_1 \to x_2) \wedge (x_2 \to \neg x_3) \wedge (x_4 \to x_3)</math>
Die Umwandlung von 2-CNF nach INF beruht auf folgender Äquivalenz, die man sich aus der obigen Wahrheitstabelle leicht herleitet:
:<math>(x \vee y) \equiv (\neg x \rightarrow y) \equiv (\neg y \rightarrow x)</math>
Aus dieser Äquivalenz folgt der
;Satz: Ein Ausdruck in 2-CNF kann nach INF transformiert werden, indem man jede Klausel <math>(x \vee y)</math> durch das Klauselpaar <math>(\neg x \rightarrow y) \wedge (\neg y \rightarrow x)</math> ersetzt.
Man beachte, dass man für jede ODER-Klausel des ursprünglichen Ausdrucks zwei Implikationen (eine für jede Richtung des "wenn, dann") einfügen muss, um die Symmetrie des Problems zu erhalten.

==== Lösung des 2-SAT-Problems mit Implikationgraphen ====

Jeder Ausdruck in INF kann als gerichteter Graph dargestellt werden:
# Für jedes Literal wird ein Knoten in den Graphen eingefügt. Es gibt also für jede Variable und für ihre Negation jeweils einen Knoten, d.h. 2n Knoten insgesamt.
# Jede Implikation ist eine gerichtete Kante.
Implikationengraphen eignen sich, um Ursache-Folge-Beziehungen oder Konflikte zwischen Aktionen auszudrücken. Beispielsweise kann man die Klausel <math>(x \rightarrow \neg y)</math> als "wenn man x tut, darf man y nicht tun" interpretieren. Ein anderes schönes Beispiel findet sich in Übung 12.

Für die Implementation eines Implikationengraphen in Python empfiehlt es sich, die Knoten geschickt zu numerieren: Ist die Variable <math>x_i</math> dem Knoten i zugeordnet, so sollte die negierte Variable <math>\neg x_i</math> dem Knoten (i+n) zugeordnet werden. Zu jedem gegebenen Knoten i findet man dann den negierten Partnerknoten j leicht durch die Formel <tt>j = (i + n ) % (2*n)</tt>.

Die Aufgabe besteht jetzt darin, folgende Fragen zu beantworten:
# Ist der durch den Implikationengraphen gegebene Ausdruck erfüllbar?
# Finde eine geeignete Belegung der Variablen, wenn der Ausduck erfüllbar ist.
Die erste Frage beantwortet man leicht, indem man die stark zusammenhängenden Komponenten des Implikationengraphen bildet. Dann gilt folgender
;Satz: Seien u und v zwei Literale, die sich in der selben stark zusammenhängenden Komponente befinden. Dann müssen u und v stets den selben Wert haben, damit der Ausdruck erfüllt sein kann.
Die Korrektheit des Satzes folgt aus der Definition der stark zusammenhängenden Komponenten: Da u und v in der selben Komponente liegen, gibt es im Implikationengraphen einen Weg <math>u \rightsquigarrow v</math> sowie einen Weg <math>v \rightsquigarrow u</math>. Wegen der Transitivität der "wenn, dann" Relation kann man die Wege zu zwei Implikationen verkürzen, die gleichzeitig gelten müssen: <math>(u \rightarrow v) \wedge (v \rightarrow u)</math> (die Verkürzung von Wegen zu direkten Kanten entspricht gerade der Bildung der transitiven Hülle für die Knoten u und v). In der obigen Wertetabelle für logische Operatoren erkennt mann, dass dies äquivalent zur Bedingung <math>(u \leftrightarrow v)</math> ist. Dies ist aber gerade die Behauptung des Satzes.

Die Erfüllbarkeit des Ausdrucks ist nun ein einfacher Spezialfall dieses Satzes.
;Korrolar: Der gegebene Ausdruck ist genau dann erfüllbar, wenn die Literale <math>x_i</math> und <math>\neg x_i</math> sich für kein i in derselben stark zusammenhängenden Komponente befinden.
Setzt man nämlich im Satz <math>u = x_i</math> und <math>v = \neg x_i</math>, und beide Knoten befinden sich in der selben Komponente, dann müsste gelten <math>x_i \leftrightarrow\neg x_i</math>, was offensichtlich ein Widerspruch ist. Damit kann der Ausdruck nicht erfüllbar sein. Umgekehrt gilt, dass der Ausdruck immer erfüllbar ist, wenn <math>x_i</math> und <math>\neg x_i</math> stets in verschiedenen Komponenten liegen, weil der folgende Algorithmus von Aspvall, Plass und Tarjan in diesem Fall stets eine gültige Belegung aller Variablen liefert:
# Bestimme die stark zusammenhängenden Komponenten und bilde den Komponentengraphen. Ordne die Knoten des Komponentengraphen (also die stark zusammenhängenden Komponenten des Originalgraphen) in topologische Sortierung an.
# Betrachte die Komponenten in der topologischen Sortierung von hinten nach vorn und weise ihnen einen Wert nach folgenden Regeln zu (zur Erinnerung: alle Literale in der selben Komponente haben den selben Wert):
#* Wenn die Komponente noch nicht betrachtet wurde, setze ihren Wert auf True, und den Wert der komplementären Komponente (derjenigen, die die negierten Literale enthält) auf False.
#* Andernfalls, gehe zur nächsten Komponente weiter.
Der Algorithmus beruht auf der Symmetrie des Implikationengraphen: Weil Kanten immer paarweise <math>(\neg u \rightarrow v) \wedge (\neg v \rightarrow u)</math> eingefügt werden, ist der Graph schiefsymmetrisch (skew symmetric): die eine Hälfte das Graphen ist die transponierte Spiegelung der anderen Hälfte. Enthält eine stark zusammenhängende Komponente <math>C_i</math> die Knoten <tt>i1, i2, ...</tt>, so gibt es stets eine komplementäre Komponente <math>C_j = \neg C_i</math>, die die komplementären Knoten <tt>j1 = (i1 + n) % (2*n), j2 = (i2 + n) % (2*n), ...</tt> enthält. Gilt <math>C_i = \neg C_i</math> für irgendein i, so ist der Ausdruck nicht erfüllbar. Den Beweis für die Korrektheit des Algorithmus findet man im [http://www.math.ucsd.edu/~sbuss/CourseWeb/Math268_2007WS/2SAT.pdf Originalartikel]. Leider funktioniert dies nicht für k-SAT-Probleme mit <math>k > 2</math>.

Will man nur die Erfüllbarkeit prüfen, vereinfacht sich der Algorithmus zu:
# Bestimme die stark zusammenhängenden Komponenten.
# Teste für alle <tt>i = 0,...,n-1</tt>, dass Knoten <tt>i</tt> und Knoten <tt>(i+n)</tt> in unterschiedlichen Komponenten liegen.
Ist der Ausdruck erfüllbar, kann man eine gültige Belegung der Variablen jetzt mit dem randomisierten Algorithmus bestimmen, den wir im Kapitel [[Randomisierte Algorithmen]] behandeln.

== Weitere wichtige Graphenalgorithmen ==

Eins der wichtigsten Einsatzgebiete für Graphen ist die Optimierung, also die Suche nach der besten Lösung für ein gegebenes Problem:
* Das interval scheduling befasst sich damit, aus einer gegebenen Menge von Aufträgen die richtigen auszuwählen und sie geschickt auf die zur Verfügung stehenden Ressourcen aufzuteilen. Damit beschäftigen wir uns im Kapitel [[Greedy-Algorithmen und Dynamische Programmierung]].
* Beim Problem des Handlungsreisenden sucht man nach der kürzesten Rundreise, die alle gegebenen Städte genau einmal besucht. Dieses Problem behandeln wir im Kapitel [[NP-Vollständigkeit]].
* Viele weitere Anwendungen können wir leider in der Vorlesung nicht mehr behandeln, z.B.
** Algorithmen für den [http://en.wikipedia.org/wiki/Maximum_flow_problem maximalen Fluss] beantworten die Frage, wie man die Durchflussmenge durch ein Netzwerk (z.B. von Ölpipelines) maximiert.
** Beim [http://en.wikipedia.org/wiki/Assignment_problem Problem der optimalen Paarung] ("matching problem" oder "assignment problem") sucht man nach einer Teilmenge der Kanten (also nach einem Teilgraphen), so dass jeder Knoten in diesem Teilgraphen höchstens den Grad 1 hat. Im neuen Graphen gruppieren die Kanten also je zwei Knoten zu einem Paar, und die Paarung soll nach jeweils anwendungsspezifischen Kriterien optimal sein. Dies benötigt man z.B. bei der optimalen Zuordnung von Gruppen, etwas beim Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot) und in der Universität (Zuordnung Studenten - Übungsgruppen).
** In Statistik und maschinellem Lernen haben in den letzten Jahren die [http://en.wikipedia.org/wiki/Graphical_model graphischen Modelle] große Bedeutung erlangt.
* usw. usf.

[[Randomisierte Algorithmen|Nächstes Thema]]

Graphen und Graphenalgorithmen

2012-07-25T17:04:53Z

Ukoethe: /* Algorithmus 2 */

== Einführung zu Graphen ==

=== Motivation -- Königsberger Brückenproblem ===
Leonhard Euler [http://de.wikipedia.org/wiki/Leonhard_Euler] erfand den Graphen-Formalismus 1736, um eine scheinbar banale Frage zu beantworten: Ist es möglich, in Königsberg (siehe Stadtplan von 1809 und die schematische Darstellung) einen Spaziergang zu unternehmen, bei dem jede der 7 Brücken genau einmal überquert wird?

[[Image:Koenigsberg1809.png]] 
[[Image:Koenigsberg.jpg]]

Ein Graph abstrahiert von der Geometrie des Problems und repräsentiert nur die Topologie. Jeder Stadtteil von Königsberg ist ein Knoten des Graphen, jede Brücke eine Kante. Der zum Brückenproblem gehörende Graph sieht also so aus:

O
/| \
\| \
O---O
/| /
\| /
O

Der gesuchte Spaziergang würde existieren, wenn es maximal 2 Knoten gäbe, an denen sich eine ungerade Zahl von Kanten trifft. Die Frage muss für Königsberg also verneint werden, denn hier gibt es vier solche Knoten. Ein leicht modifiziertes Problem ist allerdings lösbar: Im obigen Stadtplan erkennt man eine Fähre, die die Stadtteile Kneiphof und Altstadt verbindet. Bezieht man dieselbe in den Spaziergang ein, ergibt sich folgender Graph, bei dem nur noch zwei Knoten mit ungerader Kantenzahl existieren:

--O
/ /| \
\ \| \
--O---O
/| /
\| /
O

Inzwischen haben Graphen eine riesige Zahl weiterer Anwendungen gefunden. Einige Beispiele:

* Landkarten:
** Knoten: Länder
** Kanten: gemeinsame Grenzen

* Logische Schaltkreise:
** Knoten: Gatter
** Kanten: Verbindungen

* Chemie (Summenformeln):
** Knoten: chemische Elemente
** Kanten: Bindungen

* Soziologie (StudiVZ)
** Soziogramm
*** Knoten: Personen
*** Kanten: Freund von ...

=== Definitionen ===

;Ungerichteter Graph: Ein ungerichteter Graph G = ( V, E ) besteht aus
:* einer endliche Menge V von Knoten (vertices)
:* einer endlichen Menge <math>E \subset V \times V</math> von Kanten (edges)
:Die Paare (u,v) und (v,u) gelten dabei als nur ''eine'' Kante (somit gilt die Symmetriebeziehung: (u,v) ∈ E => (v,u) ∈ E ). Die Anzahl der Kanten, die sich an einem Knoten treffen, wird als ''Grad'' (engl. ''degree'') dieses Knotens bezeichnet:
:::degree(v) = |{v' ∈ V | (v,v') ∈ E}|
:(Die Syntax |{...}| bezeichnet dabei die Mächtigkeit der angegebenen Menge, also die Anzahl der Elemente in der Menge.)

Der Graph des Königsberger Brückenproblems ist ungerichtet. Bezeichnet man die Knoten entsprechend des folgenden Bildes
c
/| \
\| \
b---d
/| /
\| /
a

gilt für die Knotengrade: <tt>degree(a) == degree(c) == degree(d) == 3</tt> und <tt>degree(b) == 5</tt>. Genauer muss man bei diesem Graphen von einem ''Multigraphen'' sprechen, weil es zwischen einigen Knotenpaaren (nämlich (a, b) sowie (b, c)) mehrere Kanten ("Mehrfachkanten") gibt. Wir werden in dieser Vorlesung nicht näher auf Multigraphen eingehen.

;Gerichteter Graph: Ein Graph heißt ''gerichtet'', wenn die Kanten (u,v) und (v,u) unterschieden werden. Die Kante (u,v) ∈ E wird nun als Kante von u nach v (aber nicht umgekehrt) interpretiert. Entsprechend unterscheidet man jetzt den ''eingehenden'' und den ''ausgehenden Grad'' jedes Knotens:
:*out_degree(v) = |{v' ∈ V | (v,v') ∈ E}| 
:*in_degree(v) = |{v' ∈ V| (v',v) ∈ E}|

Das folgende Bild zeigt einen gerichteten Graphen. Hier gilt <tt>out_degree(1) == out_degree(3) == in_degree(2) == in_degree(4) == 2</tt> und
<tt>in_degree(1) == in_degree(3) == out_degree(2) == out_degree(4) == 0</tt>:

[[Image:digraph.png|gerichteter Graph]]

 

;Vollständiger Graph: Ein vollständiger Graph ist ein ungerichteter Graph, bei dem jeder Knoten mit allen anderen Knoten verbunden ist.
:::<math>E = \{ (v,w) | v \in V, w \in V, v \ne w \}</math>
:Ein vollständiger Graph mit |V| Knoten hat <math>|E| = \frac{|V|(|V|-1)}{2}</math> Kanten.

Die folgenden Abbildungen zeigen die vollständigen Graphen mit einem bis fünf Knoten (auch als K1 bis K5 bezeichnet).

{| border="0" cellspacing="0" cellpadding="0" style="margin: 1em auto 1em auto"
|-
| [[Image:k1.png|frame|k1]]
| [[Image:k2.png|frame|k2]]
| [[Image:k3.png|frame|k3]]
|-
| [[Image:k4.png|frame|k4]]
| [[Image:k5.png|frame|k5]]
|
|}

''Rätsel'' 
Auf einer Party sind Leute. Alle stoßen miteinander an. Es hat 78 mal "Pling" gemacht.
Wieviele Leute waren da? Antwort: Jede Person ist ein Knoten des Graphen, jedes Antoßen eine Kante.
Da alle miteinander angestoßen haben, handelt es sich um einen vollständigen Graphen. Mit
|V|(|V|-1)/2 = 78 folgt, dass es 13 Personen waren.

 

;Gewichteter Graph: Ein Graph heißt ''gewichtet'', wenn jeder Kante eine reelle Zahl zugeordnet ist. Bei vielen Anwendungen beschränkt man sich auch auf nichtnegative reelle Gewichte. In einem gerichteten Graphen können die Gewichte der Kanten (u,v) und (v,u) unterschiedlich sein.

Die Gewichte kodieren Eigenschaften der Kanten, die für die jeweilige Anwendung interessant sind. Bei der Berechnung des maximalen Flusses in einem Netzwerk sind die Gewichte z.B. die Durchflusskapazitäten jeder Kante, bei der Suche nach kürzesten Weges kodieren Sie den Abstand zwischen den Endknoten der Kante, bei Währungsnetzwerken (jeder Knoten ist eine Währung) geben sie die Wechselkurse an, usw..

 

;Teilgraphen: Ein Graph G' = (V',E') ist ein Teilgraph eines Graphen G, wenn gilt:
:* V' &sube; V
:* E' ⊂ E
:Er heißt ''(auf)spannender Teilgraph'', wenn gilt:
:* V' = V
:Er heißt ''induzierter Teilgraph'', wenn gilt:
:* e = (u,v) ∈ E' ⊂ E ⇔ u ∈ V' und v ∈ V'
:Den von V' induzierten Teilgraphen erhält man also, indem man aus G alle Knoten löscht, die nicht in V' sind, sowie alle Kanten (und nur diese Kanten), die einen der gelöschten Knoten als Endknoten haben.

 

;Wege, Pfade, Zyklen, Kreise, Erreichbarkeit: Sei G = (V,E) ein Graph (ungerichtet oder gerichteter) Graph. Dann gilt folgende rekursive Definition:
:* Für v ∈ V ist (v) ein Weg der Länge 0 in G
:* Falls <math>(v_0, v_1, ..., v_{n-1})</math> ein Weg ist, und eine Kante <math>(v_{n-1}, v_n)\in E</math> existiert, dann ist auch <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ein Weg, und er hat die Länge n.
: Ein Weg ist also eine nichtleere Folge von Knoten, so dass aufeinander folgende Knoten stets durch eine Kante verbunden sind. Die Länge des Weges entspricht der Anzahl der Kanten im Weg (= Anzahl der Knoten - 1).
:* Ein ''Pfad'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, bei dem alle Knoten vi verschieden sind.
:* ''Ein Zyklus'' <math>(v_0, v_1, ..., v_{n-1}, v_n)</math> ist ein Weg, der zum Ausgangspunkt zurückkehrt, wenn also v0 = vn gilt.
:* Ein ''Kreis'' ist ein Zyklus ohne Überkreuzungen. Das heisst, es gilt v0 = vn und <math>(v_0, v_1, ..., v_{n-1})</math> ist ein Pfad.
:* Ein Knoten w ∈ V ist von einem anderen Knoten v ∈ V aus ''erreichbar'' genau dann, wenn ein Weg (v, ..., w) existiert. Wir schreiben dann <math>v \rightsquigarrow w</math>.
In einem ungerichteten Graph ist die Erreichbarkeits-Relation stets symmetrisch, das heisst aus <math>v \rightsquigarrow w</math> folgt <math>w \rightsquigarrow v</math>. In einem gerichteten Graphen ist dies im allgemeinen nicht der Fall.

Bestimmte Wege haben spezielle Namen

;Eulerweg: Ein Eulerweg ist ein Weg, der alle '''Kanten''' genau einmal enthält.

Die eingangs erwähnte Frage des Königsberger Brückenproblems ist equivalent zu der Frage, ob der dazugehörige Graph einen Eulerweg besitzt (daher der Name). Ein anderes bekanntes Beispiel ist das "Haus vom Nikolaus": Wenn man diesen Graphen in üblicher Weise in einem Zug zeichnet, erhält man gerade den Eulerweg.

O
/ \
O----O
| \/ |
| /\ | "Das Haus vom Nikolaus": Alle ''Kanten'' werden nur ''einmal'' passiert
O----O

;Hamiltonweg: Ein Hamiltonweg ist ein Weg, der alle '''Knoten''' genau einmal enthält. Das "Haus vom Nikolaus" besitzt auch einen Hamiltonweg:

O
/
O----O
/
/ Alle ''Knoten'' werden nur ''einmal'' passiert
O----O

;Hamiltonkreis: Ein Hamiltonkreis ist ein Kreis, der alle '''Knoten''' genau einmal enthält. Auch ein solches Gebilde ist im Haus von Nilolaus enthalten:

O
/ \
O O
| | v0 = vn
| | vi != vj Für Alle i,j i !=j; i,j >0; i,j < n
O----O

Die folgende Skizze zeigt hingegen einen Zyklus: Der Knoten rechts unten sowie die untere Kante sind zweimal enthalten (die Kante einmal von links nach rechts und einmal von rechts nach links):

O
/ \
O O
\ |
\ | Zyklus
O====O

 

;Zusammenhang, Zusammenhangskomponenten: Ein ungerichteter Graph G heißt ''zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math>
:Ein gerichteter Graph G ist zusammenhängend, wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''oder''' <math>w \rightsquigarrow v</math>.
:Er ist ''stark zusammenhängend'', wenn für alle v,w ∈ V gilt:
:::<math>v \rightsquigarrow w</math> '''und''' <math>w \rightsquigarrow v</math>.
:Entsprechende Definitionen gelten für Teilgraphen G'. Ein Teilgraph G' heisst ''Zusammenhangskomponente'' von G, wenn er ein ''maximaler'' zusammenhängender Teilgraph ist, d.h. wenn G' zusammenhängend ist, und man keine Knoten und Kanten aus G mehr zu G' hinzufügen kann, so dass G' immer noch zusammenhängend bleibt. Entsprechend definiert man ''starke Zusammenhangskomponenten'' in einem gerichteten Graphen.

 

;Planarer Graph, ebener Graph: Ein Graph heißt ''planar'', wenn er so in einer Ebene gezeichnet werden ''kann'', dass sich die Kanten nicht schneiden (außer an den Knoten). Ein Graph heißt ''eben'', wenn er tatsächlich so gezeichnet ''ist'', dass sich die Kanten nicht schneiden. Die Einbettung in die Ebene ist im allgemeinen nicht eindeutig.

'''Beispiele:'''

Der folgende Graph ist planar und eben:

O
/|\
/ O \
/ / \ \
O O

Das "Haus vom Nikolaus" ist ebenfalls planar, wird aber üblicherweise nicht als ebener Graph gezeichnet, weil sich die Diagonalen auf der Wand überkreuzen:

O
/ \
O----O
| \/ |
| /\ |
O----O

Eine ebene Einbettung dieses Graphen wird erreicht, wenn man eine der Diagonalen ausserhalb des Hauses zeichnet. Der Graph (also die Menge der Knoten und Kanten) ändert sich dadurch nicht.

O
/ \
--O----O
/ | / |
| | / |
| O----O Das "Haus vom Nikolaus" als ebener Graph gezeichnet.
\ /
-----

Eine alternative Einbettung erhalten wir, wenn wir die andere Diagonale außerhalb des Hauses zeichnen:

O
/ \
O----O--|
| \ | |
| \ | |
O----O | Alternative Einbettung des "Haus vom Nikolaus".
| |
|-------|

Jede Einbettung eines planaren Graphen (also jeder ebene Graph) definiert eine eindeutige Menge von ''Regionen'':

|----O @
| /@ \
| O----O
| |@ / |
| | / @|
| O----O @ entspricht jeweils einer ''Region''. Auch ausserhalb der Figur ist eine Region (die sogenannte ''unendliche'' Region).
|@ |
|-------|

Der vollständige Graph K5 ist kein planarer Graph, da sich zwangsweise Kanten schneiden, wenn man diesen Graphen in der Ebene zeichnet.

 
;Dualer Graph: Jeder ebene Graph G = (V, E) hat einen ''dualen Graphen'' D = (VD, ED), dessen Knoten und Kanten wie folgt definiert sind:
:* VD enthält einen Knoten für jede Region des Graphen G
:* Für jede Kante e ∈ E gibt es eine duale Kante eD ∈ ED, die die an e angrenzenden Regionen (genauer: die entsprechenden Knoten in D) verbindet.

Die folgende Abbildung zeigt einen Graphen (grau) und seinen dualen Graphen (schwarz). Die Knoten des dualen Graphen sind mit Zahlen gekennzeichnet und entsprechen den Regionen des Originalgraphen. Jeder (grauen) Kante des Originalgraphen entspricht eine (schwarze) Kante des dualen Graphen.

 
[[Image:dual-graphs.png]]
 

Für duale Graphen gilt: Wenn der Originalgraph zusammenhängend ist, enthält jede Region des dualen Graphen genau einen Knoten des Originalgraphen. Deshalb ist der duale Graph des dualen Graphen wieder der Originalgraph. Bei nicht-zusammenhängenden Graphen gilt dies nicht (vgl. das Fenster bei obigem Bild). In diesem Fall hat der duale Graph mehrere mögliche Einbettungen in die Ebene (man kann z.B. die rechte Kante zwischen Knoten 2 und 4 auch links vom Fenster einzeichnen), und man erhält nicht notwendigerweise den Originalgraphen, wenn man den dualen Graphen des dualen berechnet.

;Baum: Ein ''Baum'' ist ein zusammenhängender, kreisfreier Graph.

Beispiel: Binärer Suchbaum

;Spannbaum: Ein ''Spannbaum'' eines zusammenhängenden Graphen G ist ein zusammenhängender, kreisfreier Teilgraph von G, der alle Knoten von G enthält

Beispiel: Spannbaum für das "Haus des Nikolaus"

O
/
O O
| /
| /
O----O

Der Spannbaum eines Graphen mit |V| Knoten hat stets |V| - 1 Kanten.

;Wald: Ein ''Wald'' ist ein unzusammenhängender, kreisfreier Graph.
: Jede Zusammenhangskomponente eines Waldes ist ein Baum.

=== Repräsentation von Graphen ===

Sei G = ( V, E ) gegeben und liege V in einer linearen Sortierung vor. 
:::<math>V = \{ v_1, ...., v_n \}</math>

;Adjazenzmatrix: Ein Graph kann durch eine Adjazenzmatrix repräsentiert werden, die soviele Zeilen und Spalten enthält, wie der Graph Knoten hat. Die Elemente der Adjazenzmatrix sind "1", falls eine Kante zwischen den zugehörigen Knoten existiert:
:::<math>\mathrm{\bold A} = a_{ij} =
\begin{cases}
1 & \mathrm{falls}\quad (v_i, v_j) \in E \\
0 & \mathrm{sonst}
\end{cases}
</math>
:Die Indizes der Matrix entsprechen also den Indizes der Knoten gemäß der gegebenen Sortierung. Im Falle eines ungerichteten Graphen ist die Adjazenzmatrix stets symmetrisch (d.h. es gilt <math>a_{ij}=a_{ji}</math>), bei einem gerichteten Graphen ist sie im allgemeinen unsymmetrisch.

Beispiel für einen ungerichteten Graphen:

v = { a,b,c,d } b d
| \ / |
| \/ |
| /\ |
| / \ |
a c

a b c d
-----------
(0 1 0 1) |a
A = (1 0 1 0) |b
(0 1 0 1) |c
(1 0 1 0) |d

Die Adjazenzmatrixdarstellung eignet sich besonders für dichte Graphen (d.h. wenn die Zahl der Kanten in O(|V|2) ist.

;Adjazenzlisten: In der Adjazenzlistendarstellung wird der Graph als Liste von Knoten repräsentiert, die für jeden Knoten einen Eintrag enthält. Der Eintrag für jeden Knoten ist wiederum eine Liste, die die Nachbarknoten dieses Knotens enthält:
:* graph = {adjazencyList(v) | v ∈ V}
:* adjazencyList(v) = {v' ∈ V | (v, v') ∈ E}

In Python implementieren wir Adjazenzlisten zweckmäßig als Array von Arrays:

graph = [[...],[...],...,[...]]
Adjazenzliste für Knoten => 0 1 n

Wenn wir bei dem Graphen oben die Knoten wie bei der Adjazenzmatrix indizieren (also <tt>a => 0</tt>, <tt>b => 1</tt>, <tt>c => 2</tt>, <tt>d => 3</tt>), erhalten wir die Adjazenzlistendarstellung:

graph = [[b, d], [a, c],[b, d], [a, c]]

Auf die Nachbarknoten eines durch seinen Index <tt>node</tt> gegebenen Knotens können wir also wie folgt zugreifen:

for neighbors in graph[node]:
... # do something with neighbor

Die Adjazenzlistendarstellung ist effizienter, wenn der Graph nicht dicht ist, so dass viele Einträge der Adjazenzmatrix Null wären. In der Vorlesung werden wir nur diese Darstellung verwenden.

;<div id="transposed_graph">Transponierter Graph</div>: Den ''transponierten Graphen'' GT eines gerichteten Graphen G erhält man, wenn man alle Kantenrichtungen umkehrt.

Bei ungerichteten Graphen hat die Transposition offensichtlich keinen Effekt, weil alle Kanten bereits in beiden Richtungen vorhanden sind, so dass GT = G gilt. Bei gerichteten Graphen ist die Transposition einfach, wenn der Graph als Adjazenzmatrix implementiert ist, weil man einfach die transponierte Adjazenzmatrix verwenden muss (beachte, dass sich die Reihenfolge der Indizes umkehrt):
:::AT = aji
Ist der Graph hingegen durch eine Adjazenzliste repräsentiert, muss etwas mehr Aufwand getrieben werden:

def transposeGraph(graph):
gt = [[] for k in graph] # zunächst leere Adjazenzlisten von GT
for node in range(len(graph)):
for neighbor in graph[node]:
gt[neighbor].append(node) # füge die umgekehrte Kante in GT ein
return gt

== Durchlaufen von Graphen (Graph Traversal) ==

Wir betrachten zunächst ungerichtete Graphen mit V Knoten und E Kanten. Eine grundlegende Aufgabe in diesen Graphen besteht darin, alle Knoten in einer bestimmten Reihenfolge genau einmal zu besuchen. Hierbei darf man sich von einem gegebenen Startknoten aus nur entlang der Kanten des Graphen bewegen. Die beim Traversieren benutzen Kanten bilden einen Baum, dessen Wurzel der Startknoten ist und der den gesamten Graphen aufspannt, falls der Graph zusammenhängend ist. (Beweis: Da jeder Knoten nur einmal besucht wird, gibt es für jeden besuchten Knoten [mit Ausnahme des Startknotens] genau eine eingehende Kante. Ist der Graph zusammenhängend, wird jeder Knoten tatsächlich erreicht und es gibt genau (V-1) Kanten, exakt soviele wie für einen Baum mit V Knoten notwendig sind.) Ist der Graph nicht zusammenhängend, wird jeder zusammenhängende Teilgraph (jede Zusammenhangskomponente) getrennt traversiert, und man erhält einen sogenannten Wald mit einem Baum pro Zusammenhangskomponente. Die beiden grundlegenden Traversierungsmethoden Tiefensuche und Breitensuche werden im folgenden vorgestellt.

=== Tiefensuche in Graphen (Depth First Search, DFS) ===

Die Idee der Tiefensuche besteht darin, jeden besuchten Knoten sofort über die erste Kante wieder zu verlassen, die zu einem noch nicht besuchten Knoten führt. Man findet dadurch schnell einen möglichst langen Pfad durch den Graphen, und der Traversierungs-Baum wird zunächst in die Tiefe verfolgt, daher der Name des Verfahrens. Hat ein Knoten keine unbesuchten Nachbarknoten mehr, geht man im Baum zurück (sogenanntes back tracking), bis man einen Knoten findet, der noch eine unbesuchte Nachbarn besitzt, und traversiert diese nach dem gleichen Muster. Gibt es gar keine unbesuchten Knoten mehr, kehrt die Suche zum Startknoten zurück und endet dort.

WDie folgende rekursive Implementation der Tiefensuche erwartet den Graphen in Adjazenzlistendarstellung und beginnt die Suche beim Knoten <tt>startnode</tt>. Die Information, ob ein Knoten bereits besucht wurde, wird im Array <tt>visited</tt> gespeichert. Ein solches Array, das zusätzliche Informationen über die Knoten des Graphen bereitstellt, wir häufig property map genannt.

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
print node # Ausgabe der Knotennummer - pre-order
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)

visit(startnode)

[[Image:Tiefens.jpg]]

Ausgabe für den Graphen in diesem Bild (es handelt sich um einen ungerichteten Graphen, die Pfeile symbolisieren nur die Suchrichtung beim Traversal):

>>> dfs(graph, 1)
1
2
4
3
6
7
5

<div id="pre_and_post_order">In dieser Version des Algorithmus werden die Knotennummern ausgegeben, bevor die Nachbarknoten besucht werden. Man bezeichnet die resultierende Sortierung der Knoten als pre-order oder als discovery order. Alternativ kann man die Knotennummern erst ausgeben, nachdem alle Nachbarn besucht wurden, also auf dem Rückweg der Rekursion. In diesem Fall spricht man von post-order oder finishing order:</div>

def dfs(graph, startnode):
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

def visit(node): # rekursive Hilfsfunktion, die den gegebenen Knoten und dessen Nachbarn besucht
if not visited[node]: # Besuche node, wenn er noch nicht besucht wurde
visited[node] = True # Markiere node als besucht
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn
visit(neighbor)
print node # Ausgabe der Knotennummer - post-order

visit(startnode)

Es ergibt sich jetzt die Ausgabe:

>>> dfs(graph, 1)
6
7
3
4
5
2
1

In realem Code ersetzt man die print-Ausgaben natürlich durch anwendungsspezifische Aktionen und Berechnungen. Einige Anwendungen sind uns im Kapitel [[Suchen]] bereits begegnet.
; Anwendungen der Pre-Order Traversierung
* Kopieren eines Graphen: kopiere zuerst den besuchten Knoten, dann seine Nachbarn und die dazugehörigen Kanten (sowie die Kanten zu bereits besuchten Knoten, die in der Grundversion der Tiefensuche ignoriert werden).
* Bestimmen der Zusammenhangskomponenten eines Graphen (siehe unten)
* In einem Zeichenprogramm: fülle eine Region mit einer Farbe ("flood fill"). Dabei ist jedes Pixel ein Knoten des Graphen und wird mit seinen 4 Nachbarpixceln verbunden. Die Tiefensuche startet bei der Mausposition und endet am Rand des betreffendcen Gebiets.
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von der Wurzel
* Falls der Graph ein Parse-Baum ist, wobei innere Knoten Funktionsaufrufe, Kindknoten Funktionsargumente, und Blattknoten Werte repräsentieren: drucke den zugehörigen Ausdruck aus (also immer zuerst den Funktionsnamen, dann die Argumente, die wiederum geschachtelte Funktionsaufrufe sein können).
; Anwendungen der Post-Order Traversierung
* Löschen eines Graphen: lösche zuerst die Nachbarn, dann den Knoten selbst
* Bestimmen einer topologischen Sortierung eines azyklischen gerichteten Graphens (siehe unten)
* Falls der Graph ein Baum ist: bestimme den Abstand jedes Knotens von den Blättern (also die Tiefe des Baumes, siehe Übung 5)
* Falls der Graph ein Parse-Baum ist: führe die zugehörige Berechnung aus (d.h. berechne zuerst die geschachtelten inneren Funktionen, dann mit diesen Ergebnissen die nächst äußeren usw., siehe Übung 5).
; Anwendungen, die Pre- und Post-Order benötigen
* Weg aus einem Labyrinth: die Pre-Order dokumentiert die Suche nach dem Weg, die Post-Order zeigt den Rückweg aus Sackgassen (siehe Übung 9).
Im Spezialfall, wenn der Graph ein Binärbaum ist, unterscheidet man noch eine dritte Variante der Traversierung, nämlich die in-order Traversierung. In diesem Fall behandelt man den Vaterknoten nach den linken, aber vor den rechten Kindern. Diese Reihenfolge wird beim [[Suchen#Beziehungen zwischen dem Suchproblem und dem Sortierproblem|Tree Sort Algorithmus]] verwendet. Diese Sortierung verwendet man auch, wenn man einen Parse-Baum mit binären Operatoren (statt Funktionsaufrufen) ausgeben will, siehe Übung 5.

Eine nützliche Erweiterung der Tiefensuche besteht darin, in der property map <tt>visited</tt> nicht nur zu dokumentieren, dass ein Knoten bereits besucht wurde, sondern auch, von welchem Knoten aus man den jeweiligen Knoten zuerst erreicht hat. Im entstehenden Tiefensuchbaum ist dies gerade der Vaterknoten, weshalb wir die verbesserte property map zweckmäßigerweise in <tt>parents</tt> umbenennen. Für den Startknoten, also die Wurzel des Baumes, wählen wir die Konvention, dass er sein eigener Vaterknoten ist (die Konvention, dafür den Wert <tt>None</tt> zu verwenden, scheidet aus, weil dies bereits die Tatsache signalisiert, dass ein Knoten noch nicht besucht wurde):

def dfs(graph, startnode):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Tiefensuchbaum

def visit(node, parent): # rekursive Hilfsfunktion
if parents[node] is None: # Besuche node, wenn er noch nicht besucht wurde
parents[node] = parent # Markiere node als besucht und speichere seinen Vaterknoten
for neighbor in graph[node]: # Besuche rekursiv die Nachbarn ...
visit(neighbor, node) # ... wobei node zu deren Vaterknoten wird

visit(startnode, startnode) # Konvention für Wurzel: startnode ist sein eigener Vater

return parents # Rückgabe des berechneten Tiefensuch-Baums

Die Ausgabe für den obigen Beispielgraphen lautet:
Knotennummer | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
--------------+-----+-----+-----+-----+-----+-----+-----+-----
Vaterknoten | None| 1 | 1 | 4 | 2 | 2 | 3 | 3

Dabei ist die Knotennummer der Index im Array <tt>parents</tt>, und der Vaterknoten ist der dazugehörige Arrayeintrag. Beachte, dass Knoten 0 in diesem Graphen nicht existiert, daher ist sein Eintrag <tt>None</tt>. Per Konvention hat der Wurzelknoten 1 sich selbst als Vater.

=== Breitensuche in Graphen (Breadth First Search, BFS) ===

Im Gegensatz zur Tiefensuche werden bei der Breitensuche alle Nachbarnknoten abgearbeitet, bevor man rekursiv deren Nachbarn besucht. Man betrachtet somit zuerst alle Knoten, die den Abstand 1 von Startknoten haben, dann diejenigen mit dem Abstand 2 usw. Diese Reihenfolge bezeichnet man als level-order. Wir sind ihr beispielsweise in Übung 6 begegnet, als die ersten 7 Ebenen eines Treap ausgegeben werden sollten. Man implementiert Breitensuche zweckmäßig mit Hilfe einer Queue, die die Knoten in First In - First Out - Reihenfolge bearbeitet. Eine geeignete Datenstruktur hierfür ist die Klasse <tt>[http://docs.python.org/library/collections.html#collections.deque deque]</tt> aus dem Python-Modul <tt>[http://docs.python.org/library/collections.html collections]</tt> (eine Deque implementiert sowohl die Funktionalität einer Queue wie auch die eines Stacks, siehe Übung 3):

from collections import deque

def bfs(graph, startnode)
visited = [False]*len(graph) # Flags, welche Knoten bereits besucht wurden

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if not visited[node]: # Falls node noch nicht (auf einem anderen Weg) besucht wurde
visited[node] = True # Markiere node als besucht
print node # Drucke Knotennummer
for neighbor in graph[node]: # Füge Nachbarn in die Queue ein
q.append(neighbor)

[[Image:Breitens.jpg]]

Der Aufruf dieser Funktion liefert die Knoten des obigen Graphens ebenenweise, also zufällig genau in der Reihenfolge der Knotennummern:
>>> bfs(graph, 1)
1
2
3
4
5
6
7

Neben der ebenenweisen Ausgabe hat die Breitensuche viele weitere wichtige Anwendungen, z.B. beim Testen, ob ein gegebener Graph bi-partit ist (siehe [http://en.wikipedia.org/wiki/Breadth-first_search#Testing_bipartiteness WikiPedia]), sowie bei der Suche nach kürzesten Wegen (siehe unten) und kürzesten Zyklen.

== Weitere Anwendungen der Tiefensuche ==

Die Tiefensuche hat zahlreiche Anwendungen, wobei der grundlegende Algorithmus immer wieder leicht modifiziert und an die jeweilige Aufgabe angepasst wird. Wir beschreiben im folgenden einige Beispiele.

=== Damenproblem ===

Tiefensuche wird häufig verwendet, um systematisch nach der Lösung eines logischen Rätsels (oder allgemeiner nach der Lösung eines diskreten Optimierungsproblems) zu suchen. Besonders anschaulich hierfür ist das Damenproblem. Die Aufgabe besteht darin, <math>k</math> Damen auf einem Schachbrett der Größe <math>k \times k</math> so zu platzieren, dass sie sich (nach den üblichen Schach-Regeln) nicht gegenseitig schlagen können. Das folgende Diagramm zeigt eine Lösung für den Fall <math>k=4</math>. Die Positionen der Damen werden dabei wie üblich durch die Angabe der Spalte (Linie) mit Buchstaben und der Zeile (Reihe) mit Zahlen kodiert, hier also A2, B4, C1, D3:

---------------
| | X | | | 4
|---|---|---|---|
| | | | X | 3
|---|---|---|---|
| X | | | | 2
|---|---|---|---|
| | | X | | 1
---------------
A B C D

Um das Problem systematisch zu lösen, konstruieren wir einen gerichteten Graphen, dessen Knoten die möglichen Positionen der Damen kodieren. Wir verbinden Knoten, die zu benachbarten Linien gehören, genau dann mit einer Kante, wenn die zugehörigen Positionen kompatibel sind, also wenn sich die dort positionierten Damen nicht schlagen können. Der resultierende Graph für <math>k=4</math> hat folgende Gestalt:

[[Image:damenproblem-graph.png|500px|center]]

Knoten, die zur selben Reihe oder Linie gehören, sind beispielsweise nicht direkt verbunden, weil zwei Damen niemals in derselben Linie oder Reihe stehen dürfen. Um eine erlaubte Konfiguration zu finden, verwenden wir nun eine angepasste Version der Tiefensuche: Wir beginnen die Suche beim Knoten <tt>START</tt>. Sobald wir den Knoten <tt>STOP</tt> erreichen, beenden wir die Suche und lesen die Lösung am gerade gefundenen Weg von Start nach Stop ab. Zwei kleine Modifikationen des Grundalgorithmus stellen sicher, dass die Bedingungen der Aufgabe eingehalten werden: Wir dürfen bei der Tiefensuche nur dann zu einem Nachbarn weitergehen, wenn die betreffende Position mit allen im Pfad bereits gesetzten Positionen kompatibel ist, andernfalls ist diese Kante tabu. Landen wir aufgrund dieser Regel in einer Sackgasse (also in einem Knoten, wo keine der ausgehenden Kanten erlaubt ist), müssen wir zur nächsten erlaubten Abzweigung zurückgehen (Backtracking). Beim Zurückgehen müssen wir das <tt>parent</tt>-Flag wieder auf <tt>None</tt> zurücksetzen, weil der betreffende Knoten ja möglicherweise auf einem anderen erlaubten Weg erreichbar ist.

Der folgende Graph zeigt einen solchen Fall: Wir haben zwei Damen auf die Felder A1 und B3 positioniert (grüne Pfeile). Die einzig ausgehende Kante von B3 führt zum Knoten C1, welcher aber mit der Position A1 inkompatibel ist, so dass diese Kante nicht verwendet werden darf (roter Pfeil). Das Backtracking muss jetzt zu Knoten A1 zurückgehen (dabei wird das <tt>parent</tt>-Flag von B3 wieder auf <tt>None</tt> gesetzt), weil A1 mit der Kante nach B4 eine weitere Option hat, die geprüft werden muss (die allerdings hier auch nicht zum Ziel führt).

[[Image:damenproblem-graph-failure.png|500px|center]]

Nach einigen weiteren Sackgassen findet man schließlich den Pfad A2, B4, C1, D3, der im folgenden Graphen grün markiert ist und der obigen Lösung entspricht:

[[Image:damenproblem-graph-success.png|500px|center]]

=== Test, ob ein ungerichteter Graph azyklisch ist ===

Ein zusammenhängender ungerichteter Graph ist azyklisch (also ein Baum) genau dann, wenn es nur einen möglichen Weg von jedem Knoten zu jedem anderen gibt. (Bei gerichteten Graphen sind die Verhältnisse komplizierter. Wir behandeln dies weiter unten.) Das kann man mittels Tiefensuche leicht feststellen: Die Kante, über die wir einen Knoten erstmals erreichen, ist eine Baumkante des Tiefensuchbaums. Erreichen wir einen bereits besuchten Knoten nochmals über eine andere Kante, haben wir einen Zyklus gefunden. Dabei müssen wir allerdings beachten, dass in einem ungerichteten Graphen jede Baumkante zweimal gefunden wird, einmal in Richtung vom Vater zum Kind und einmal in umgekehrter Richtung. Im zweiten Fall endet die Kante zwar in einem bereits besuchten Knoten (dem Vater), aber es entsteht dadurch kein Zyklus. Den Vaterknoten müssen wir deshalb überspringen, wenn wir über die Nachbarn iterieren:

def undirected_cycle_test(graph): # Annahme: der Graph ist zusammenhängend
# (andernfalls führe den Algorithmus für jede Zusammenhangskomponente aus)
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node, from_node): # rekursive Hilfsfunktion: gibt True zurück, wenn Zyklus gefunden wurde
if not visited[node]: # wenn node noch nicht besucht wurde
visited[node] = True # markiere node als besucht
for neighbor in graph[node]: # besuche die Nachbarn ...
if neighbor == from_node: # ... aber überspringe den Vaterknoten
continue
if visit(neighbor, node): # ... signalisiere, wenn rekursiv ein Zyklus gefunden wurde
return True
return False # kein Zyklus gefunden
else:
return True # Knoten schon besucht => Zyklus

startnode = 0 # starte bei beliebigem Knoten (hier: Knoten 0)
return visit(startnode, startnode) # gebe True zurück, wenn ein Zyklus gefunden wurde

Wenn wir einen Zyklus finden, wird das weitere Traversieren das Graphen abgebrochen, denn ein Graph, der einmal zyklisch war, kann später nicht wieder azyklisch werden. Die notwendige Modifikation für unzusammenhängende Graphen erfolgt analog zum Algorithmus für die Detektion von Zusammenhangskomponenten, der im nächsten Abschnitt beschrieben wird.

=== Finden von Zusammenhangskomponenten ===

Das Auffinden und Markieren von Zusammenhangskomponenten (also maximalen zusammenhängenden Teilgraphen) ist eine grundlegende Aufgabe in ungerichteten, unzusammenhängenden Graphen (bei gerichteten Graphen sind die Verhältnisse wiederum komplizierter, siehe unten). Zwei Knoten u und v gehören zur selben Zusammenhangskomponente genau dann, wenn es einen Pfad von u nach v gibt (da der Graph ungerichtet ist, gibt es dann auch einen Pfad von v nach u). Man sagt auch, dass "v von u aus erreichbar" ist. Unzusammenhängende Graphen entstehen in der Praxis häufig, wenn die Kanten gewisse Relationen zwischen den Knoten kodieren:
* Wenn die Knoten Städte sind und die Kanten Straßen, sind diejenigen Städte in einer Zusammenhangskomponente, die per Auto von einander erreichbar sind. Unzusammenhängende Graphen entstehen hier beispielsweise, wenn eine Insel nicht durch eine Brücke erschlossen ist, wenn Grenzen gesperrt sind oder wenn ein Gebirge zu unwegsam ist, um Straßen zu bauen.
* Wenn Knoten Personen sind, und Kanten die Eltern-Kind-Relation beschreiben, so umfasst jede Zusammenhangskomponenten die Verwandten (auch wenn sie nur über viele "Ecken" verwandt sind).
* In der Bildverarbeitung entsprechen Knoten den Pixeln, und dieselben werden durch eine Kante verbunden, wenn sie zum selben Objekt gehören. Die Zusammenhangskomponenten entsprechen somit den Objekten im Bild (siehe Übungsaufgabe).
Die Zusammenhangskomponenten bilden eine Äquivalenzrelation. Folglich kann für jede Komponente ein Reprässentant bestimmt werden, der sogenannte "Anker". Kennt jeder Knoten seinen Anker, ist das Problem der Zusammenhangskomponenten gelöst.

==== Lösung mittels Tiefensuche ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden. Anstelle der property map <tt>visited</tt> verwenden wir diesmal eine property map <tt>anchors</tt>, die für jeden Knoten die Knotennummer des zugehörigen Ankers angibt, oder <tt>None</tt>, wenn der Knoten noch nicht besucht wurde. Dabei verwenden wir wieder die Konvention, dass Anker auf sich selbst zeigen. Für viele Anwendungen ist es außerdem (oder stattdessen) zweckmäßig, die Zusammenhangskomponenten mit einer laufenden Nummer, einem sogenannten Label, durchzuzählen. Dann kann man zusätzliche Informationen zu jeder Komponente (beispielsweise deren Größe) einfach in einem Array speichern, das über die Labels indexiert wird. Die folgende Version der Tiefensuche bestimmt sowohl die Anker als auch die Labels für jeden Knoten:

def connectedComponents(graph):
anchors = [None] * len(graph) # property map für Anker jedes Knotens
labels = [None] * len(graph) # property map für Label jedes Knotens

def visit(node, anchor):
"""anchor ist der Anker der aktuellen ZK"""
if anchors[node] is None: # wenn node noch nicht besucht wurde:
anchors[node] = anchor # setze seinen Anker
labels[node] = labels[anchor] # und sein Label
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor, anchor)

current_label = 0 # Zählung der ZK beginnt bei 0
for node in xrange(len(graph)):
if anchors[node] is None: # Anker noch nicht bekannt => neue ZK gefunden
labels[node] = current_label # Label des Ankers setzen
visit(node, node) # Knoten der neuen ZK rekursiv suchen
current_label += 1 # Label für die nächste ZK hochzählen
return anchors, labels
Interessant ist hier die Schleife über alle Knoten des Graphen am Ende des Algorithmus, die bei den bisherigen Versionen der Tiefensuche nicht vorhanden war. Um ihre Funktionsweise zu verstehen, nehmen wir für den Moment an, dass der Graph zusammenhängend ist. Dann findet diese Schleife den ersten Knoten des Graphen und führt die Tiefensuche mit diesem Knoten als Startknoten aus. Sobald die Rekursion zurückkehrt, sind alle Knoten des Graphen besucht (weil der Graph ja zusammenhängend war), so dass die Schleife alle weiteren Knoten überspringt (die if-Anweisung liefert für keinen weiteren Knoten True). Bei unzusammenhängenden Graphen dagegen erreicht die Tiefensuche nur die Knoten derselben Komponente, die im weiteren Verlauf der Schleife übersprungen werden. Findet die if-Anweisung jetzt einen noch nicht besuchten Knoten, muss dieser folglich in einer neuen Komponente liegen. Wir verwenden diesen Knoten als Anker und bestimmen die übrigen Knoten dieser Komponente wiederum mit Tiefensuche.

* Beispiel: ... under construction 

Man erkennt, dass die Tiefensuche nach dem Anlagerungsprinzip vorgeht: Beginnend vom einem Startknoten (dem Anker) werden die Knoten der aktuellen Komponente nach und nach an den Tiefensuchbaum angehangen. Erst, wenn nichts mehr angelagert werden kann, geht der Algorithmus zur nächsten Komponente über.

==== Lösung mittels Union-Find-Algorithmus ====

Im Gegensatz zum Anlagerungsprinzip sucht der Union-Find-Algorithmus die Zusammenhangskomponenten mit dem Verschmelzungsprinzip: Eingangs wird jeder Knoten als ein Teilgraph für sich betrachtet. Dann iteriert man über alle Kanten und verbindet deren Endknoten jeweils zu einem gemeinsamen Teilgraphen (falls die beiden Enden einer Kante bereits im selben Teilgraphen liegen, wird diese Kante ignoriert). Solange noch Kanten vorhanden sind, werden dadurch immer wieder Teilgraphen in größere Teilgraphen verschmolzen. Am Ende bleiben die maximalen zusammenhängenden Teilgraphen (also gerade die Zusammenhangskomponenten) übrig. Dieser Algorithmus kommt ohne Tiefensuche aus und ist daher in der Praxis oft schneller, allerdings auch etwas komplizierter zu implementieren.

Der Schlüssel des Algorithmus ist eine Funktion <tt>findAnchor()</tt>, die zu jedem Knoten den aktuellen Anker sucht. Der Anker existiert immer, da jeder Knoten von Anfang an zu einem Teilgraphen gehört (anfangs ist jeder Teilgraph trivial und besteht nur aus dem Knoten selbst). Die Verschmelzung wird realisiert, indem der Anker des einen Teilgraphen seine Rolle verliert und stattdessen der Anker des anderen Teilgraphen eingesetzt wird.

Zur Verwaltung der Anker verwenden wir wieder eine property map <tt>anchors</tt> mit der Konvention, dass die Anker auf sich selbst verweisen. Es wäre jedoch zu teuer, wenn man bei jeder Verschmelzung alle Anker-Einträge der beteiligten Knoten aktualisieren müsste, da jeder Knoten im Laufe des Algorithmus mehrmals seinen Anker wechseln kann. Statt dessen definiert man Anker rekursiv: Verweist ein Knoten auf einen Anker, der mittlerweile diese Rolle verloren hat, folgt man dem Verweis von diesem Knoten (dem ehemaligen Anker) weiter, bis man einen tatsächlichen Anker gefunden hat - erkennbar daran, dass er auf sich selbst verweist. Diese Suchfunktion kann folgendermassen implementiert werden:

def findAnchor(anchors, node):
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
return node

Allerdings kann diese Kette im Laufe vieler Verschmelzungen sehr lang werden, so dass das Verfolgen der Kette teuer wird. Man vermeidet dies durch die sogenannte Pfadkompression: Immer, wenn man den Anker gefunden hat, aktualisiert man den Eintrag am Anfang der Kette. Die Funktion <tt>findAnchor()</tt> wird dadurch nur wenig komplizierter:

def findAnchor(anchors, node):
start = node # wir merken uns den Anfang der Kette
while node != anchors[node]: # wenn node kein Anker ist
node = anchors[node] # ... verfolge die Ankerkette weiter
anchors[start] = node # Pfadkompression: aktualisiere den Eintrag am Anfang der Kette
return node

Man kann zeigen, dass die Ankersuche mit Pfadkompression zu einer fast konstanten amortisierten Laufzeit pro Aufruf führt.

Um mit jeder Kante des (ungerichteten) Graphen nur maximal einmal eine Verschmelzung durchzuführen, betrachten wir jede Kante nur in der Richtung von der kleineren zur größeren Knotennummer, die umgekehrte Richtung wird ignoriert. Außerdem ist es zweckmäßig, bei jeder Verschmelzung denjenigen Anker mit der kleineren Knotennummer als neuen Anker zu übernehmen. Dann gilt für jede Zusammenhangskomponente, dass gerade der Knoten mit der kleinsten Knotennummer der Anker ist (genau wie bei der Lösung mittels Tiefensuche), was die weitere Analyse vereinfacht, z.B. die Zuordnung der Labels zu den Komponenten am Ende des Algorithmus.

def unionFindConnectedComponents(graph):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker

for node in xrange(len(graph)): # iteriere über alle Knoten
for neighbor in graph[node]: # ... und über deren ausgehende Kanten
if neighbor < node: # ignoriere Kanten, die in falscher Richtung verlaufen
continue
# hier landen wir für jede Kante des Graphen genau einmal
a1 = findAnchor(anchors, node) # finde Anker ...
a2 = findAnchor(anchors, neighbor) # ... der beiden Endknoten
if a1 < a2: # Verschmelze die beiden Teilgraphen
anchors[a2] = a1 # (verwende den kleineren der beiden Anker als Anker des
elif a2 < a1: # entstehenden Teilgraphen. Falls node und neighbor
anchors[a1] = a2 # den gleichen Anker haben, waren sie bereits im gleichen
# Teilgraphen, und es passiert hier nichts.)
# Bestimme jetzt noch die Labels der Komponenten
labels = [None]*len(graph) # Initialisierung der property map für Labels
current_label = 0 # die Zählung beginnt bei 0
for node in xrange(len(graph)):
a = findAnchor(anchors, node) # wegen der Pfadkompression zeigt jeder Knoten jetzt direkt auf seinen Anker
if a == node: # node ist ein Anker
labels[a] = current_label # => beginne eine neue Komponente
current_label += 1 # und zähle Label für die nächste ZK hoch
else:
labels[node] = labels[a] # node ist kein Anker => setzte das Label des Ankers
# (wir wissen, dass labels[a] bereits gesetzt ist, weil
# der Anker immer der Knoten mit der kleinsten Nummer ist)
return anchors, labels

* Beispiel: ... under construction

== Kürzeste Wege (Pfade) ==

Eine weitere grundlegende Aufgabe in Graphen ist die Bestimmung eines kürzesten Weges zwischen zwei gegebenen Knoten. Dies hat offensichtliche Anwendungen bei Routenplanern und Navigationssystemen und ist darüber hinaus wichtiger Bestandteil anderer Algorithmen, z.B. bei der Berechnung eines maximalen Flusses mit der [http://en.wikipedia.org/wiki/Edmonds%E2%80%93Karp_algorithm Methode von Edmonds und Karp].

=== Kürzeste Wege in ungewichteten Graphen mittels Breitensuche ===

Im Fall eines ungewichteten Graphen ist die Länge eines Weges einfach durch die Anzahl der durchlaufenen Kanten definiert. Daraus folgt, dass kürzeste Pfade mit einer leicht angepassten Version der Breitensuche gefunden werden können: Aufgrund des first in-first out-Verhaltens der Queue betrachtet die Breitensuche alle (erreichbaren) Knoten in der Reihenfolge ihres Abstandes vom Startknoten. Wenn wir den Zielknoten zum ersten Mal erreichen, und der gerade gefundene Weg vom Start zum Ziel hat die Länge L, muss dies der kürzeste Weg sein: Alle möglichen Wege der Länge L' < L hat die Breitensuche ja bereits betrachtet, ohne dass dabei der Zielknoten erreicht wurde. Daraus folgt übrigens eine allgemeine Eigenschaft aller Algorithmen für kürzeste Wege: Wenn der kürzeste Weg vom Start zum Ziel die Länge L hat, finden diese Algorithmen als Nebenprodukt auch die kürzesten Wege zu allen Knoten, für die L' < L gilt.

Um den Algorithmus zu implementieren, passen wir die Breitensuche so an, dass anstelle der property map <tt>visited</tt> eine property map <tt>parents</tt> verwendet wird, die für jeden besuchten Knoten den Vaterknoten im Breitensuchbaum speichert. Durch Rückverfolgen der <tt>parent</tt>-Kette können wir den Pfad vom Ziel zum Start rekonstruieren, und durch Umdrehen der Reihenfolge erhalten wir den gesuchten Pfad vom Start zum Ziel. Sobald der Zielknoten erreicht wurde, können wir die Breitensuche abbrechen (<tt>break</tt>-Befehl in der ersten <tt>while</tt>-Schleife). Falls der gegebene Graph unzusammenhängend ist, kann es passieren, dass gar kein Weg gefunden wird, weil Start und Ziel in verschiedenen Zusammenhangskomponenten liegen. Dies erkennen wir daran, dass die Breitensuche beendet wurde, ohne den Zielknoten zu besuchen. Dann gibt die Funktion statt eines Pfades dern Wert <tt>None</tt> zurück:

from collections import deque

def shortestPath(graph, startnode, destination):
parents = [None]*len(graph) # Registriere für jeden Knoten den Vaterknoten im Breitensuchbaum
parents[startnode] = startnode # startnode ist die Wurzel des Baums => verweist auf sich selbst

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # Solange es noch unbesuchte Knoten gibt
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # Besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn sie noch nicht besucht wurden
parents[neighbor] = node # setze node als Vaterknoten
q.append(neighbor) # und füge neighbor in die Queue ein

if parents[destination] is None: # Breitensuche wurde beendet ohne den Zielknoten zu besuchen
return None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path # gefundenen Pfad zurückgeben

=== Gewichtete Graphen ===

Das Problem der Suche nach kürzesten Wegen wird wesentlich interessanter und realistischer, wenn wir zu gewichteten Graphen übergehen:

; Definition - kantengewichteter Graph
: Jeder Kante (s,t) des Graphen ist eine reelle oder natürliche Zahl wst zugeordnet, die üblicherweise als ''Kantengewicht'' bezeichnet wird.

; Definition - knotengewichteter Graph
: Jedem Knoten v des Graphen ist eine reelle oder natürliche Zahl wv zugeordnet, die üblicherweise als ''Knotengewicht'' bezeichnet wird.

Je nach Anwendung benötigt man Knoten- oder Kantengewichte oder auch beides zugleich. Wir beschränken uns in der Vorlesung auf kantengewichtete Graphen. Beispiele für die Informationen, die man durch Kantengewichte ausdrücken kann, sind
* wenn die Knoten Orte sind: Abstand von Anfangs- und Endknoten jeder Kante (z.B. Luftline oder Straßenentfernung), Fahrzeit zwischen den Orten
* wenn der Knoten ein Rohrnetzwerk beschreibt: Durchflusskapazität der einzelnen Rohre (für max-Flussprobleme), analog bei elektrischen Netzwerken: elektrischer Widerstand
* wenn die Knoten Währungen repräsentieren, können deren Wechselkurse durch Kantengewichte angegeben werden.
Bei einigen Beispielen ergeben sich unterschiedliche Kantengewichte, wenn eine Kante von s nach t anstatt von t nach s durchlaufen wird. Beispielsweise können sich die Fahrzeiten erheblich unterscheiden, wenn es in einer Richtung bergauf, in der anderen bergab geht, obwohl die Entfernung in beiden Fällen gleich ist. Hier ergibt sich natürlicherweise ein gerichteter Graph. In anderen Beispielen (z.B. bei Luftlinienentfernungen, in guter Näherung auch bei Straßenentfernungen) sind die Gewichte von der Richtung unabhängig, so dass wir ungerichtete Graphen verwenden können.

Die Repräsentation der Kantengewichte im Programm richtet sich nach der Repräsentation des Graphen selbst. Am einfachsten ist wiederum die Adjazenzmatrix, die aber nur für dichte Graphen (<math>E = O(V^2)</math>, mit E als Anzahl der Kanten und V als Anzahl der Knoten) effizient ist. Bei gewichteten Graphen gibt das Matrixelement aij das Gewicht der Kante i ⇒ j (wobei aij = 0 gesetzt wird, wenn diese Kante nicht existiert). Wie zuvor gilt für ungerichtete Graphen aij = aji (symmetrische Matrix), während dies für gerichtete Graphen nicht gelten muss.

Bei Graphen in Adjazenzlistendarstellung hat es sich bewährt, die Gewichte in einer property map zu speichern. Weiter oben haben wir bereits property maps für Knoteneigenschaften (z.B. <tt>visited</tt> und <tt>anchors</tt>) gesehen. Property maps für Kanten funktionieren ganz analog, allerdings muss man jetzt Paare von Knoten (nämlich Anfangs- und Endknoten der Kante) als Schlüssel verwenden und die Daten entsprechend in einem assoziativen Array ablegen:
w = weights[(i,j)] # Zugriff auf das Gewicht der Kante i ⇒ j
Alternativ könnte man auch die Graph-Datenstruktur selbst erweitern, aber dies ist weniger zu empfehlen, weil jeder Algorithmus andere Erwiterungen benötigt und damit die Datenstruktur sehr unübersichtlich würde.

Der kürzeste Weg ist nun definiert als der Weg, bei dem die Summe der Kantengewichte minimal ist:
;Definition - Problem des kürzesten Weges
: Sei P die Menge aller Wege von u nach v, und <math>p \in P</math> einer dieser Wege. Wenn der Grpah einfach ist (es also keine Mehrfachkanten zwischen denselben Knoten und keine Schleifen gibt), ist der Weg p durch die Folge der besuchten Knoten eindeutig bestimmt:
: <math>p : \ \ u = x_0 \rightarrow x_1 \rightarrow x_2 \rightarrow ... \rightarrow v = x_{n_p}</math>
:wo <math>n_p</math> die Anzahl der Kanten im Weg p ist. Seine Kosten Wp ergeben sich als Summer der Gewichte der einzelnen Kanten
: <math>W_p = \sum_{k=1}^{n_p} w_{x_{k-1}x_k}</math>
: und ein kürzester Weg <math>p^* \in P</math> ist ein Weg mit minimalen Kosten
: <math>p^* = \textrm{argmin}_{p\in P}\ \ W_p</math>
: Das Problem des kürzesten Weges besteht darin, einen optimalen Weg p* zwischen gegebenen Knoten u und v zu finden.
Die Lösung dieses Problems hängt davon ab, ob alle Kantengewichte positiv sind, oder ob es auch negative Kantengewichte gibt. In letzeren Fall ist es möglich, durch eine Verlängerung des Weges die Kosten zu redizieren, während sich im ersteren Fall die Kosten immer erhöhen, wenn man den Weg verlängert.

Negative Gewichte treten z.B. bei den Währungsgraphen auf. Auf den ersten Blick entsprechen diese Graphen nicht den Anforderungen an das Problem des kürzesten Weges, weil Wechselkurse miteinander (und mit Geldbeträgen) multipliziert anstatt addiert werden. Man beseitigt diese Schwierigkeit aber leicht, indem man die Logarithmen der Wechselkurse als Kantengewichte verwendet, wodurch sich die Multiplikation in eine Addition der Logarithmen verwandelt. Wechselkurse < 1 führen nun zu negativen Gewichten.

Interessant werden negative Gewichte vor allem in Graphen mit Zyklen. Dann kann es nämlich passieren, dass die Gesamtkosten eines Zyklus ebenfalls negativ sind. Jeder Weg, der den Zyklus enthält, hat dann Kosten von <math>-\infty</math>, weil man den Zyklus beliebig oft durchlaufen und dadurch die Gesamtkosten immer weiter verkleinern kann:

/\ 1. Durchlauf: Kosten -1
1 / \ -4 2. Durchlauf: Kosten -2
/____\ etc.
2

Um hier nicht in einer Endlosschleife zu landen, benötigt man spezielle Algorithmen, die mit dieser Situation umgehen können. Der [http://de.wikipedia.org/wiki/Bellman-Ford-Algorithmus Algorithmus von Bellmann und Ford] beispielsweise bricht die Suche nach dem kürzesten Weg ab, sobald er einen negativen Zyklus entdeckt, aber andernfalls kann er negative Gewichte problemlos verarbeiten.

Die Detektion negativer Zyklen hat wiederum eine interessante Anwendung bei Währungsgraphen: Ein Zyklus bedeutet hier, dass man Geld über mehrere Stufen von einer Währung in die nächste und am Schluß wieder in die Originalwährung umtauscht, und ein negativer Zyklus führt dazu, dass man am Ende mehr Geld besitzt als am Anfang (damit negative Zyklen wirklich einen Gewinn bedeuten und keinen Verlust, müssen die Wechselkurse vor der Logarithmierung in [http://de.wikipedia.org/wiki/Wechselkurs#Nominaler_Wechselkurs Preisnotierung] angegeben sein). Bei Privatpersonen ist dies ausgeschlossen, weil die Umtauschgebühren den möglichen Gewinn mehr als aufzehren. Banken mit direktem weltweitem Börsenzugang hingegen unternehmen große Anstrengungen, um solche negativen Zyklen möglichst schnell (nämlich vor der Konkurrenz) zu entdecken und auszunutzen. Diese Geschäftsmethode bezeichnet man als [http://de.wikipedia.org/wiki/Arbitrage Arbitrage] und die Existenz eines negativen Zyklus als Arbitragegelegenheit. Durch die Kursschwankungen (und durch die ausgleichende Wirkung der Arbitragegeschäfte selbst) existieren die Arbitragegelegenheiten nur für kurze Zeit, und ihre Detektion erfordert leistungsfähige Echtzeitalgorithmen.

In dieser Vorlesung beschränken wir uns hingegen auf Graphen mit ausschließlich positiven Gewichten. In diesem Fall ist der Algorithmus von Dijkstra die Methode der Wahl, weil er wesentlich schneller arbeitet als der Bellmann-Ford-Algorithmus.

=== Algorithmus von Dijkstra ===

==== Edsger Wybe Dijkstra ====

geb. 11. Mai 1930 in Rotterdam

ges. 06. August 2002

Dijkstra war ein niederländischer Informatiker und Wegbereiter der strukturierten Programmierung. 1972 erhielt er für seine Leistung in der Technik und Kunst der Programmiersprachen den Turing Award, der jährlich von der Association for Computing Machinery (ACM) an Personen verliehen wird, die sich besonders um die Entwicklung der Informatik verdient gemacht haben. Zu seinen Beiträgen zur Informatik gehören unter anderem der Dijkstra-Algorithmus zur Berechnung des kürzesten Weges in einem Graphen sowie eine Abhandlung über den go-to-Befehl und warum er nicht benutzt werden sollte. Der go-to-Befehl war in den 60er und 70er Jahren weit verbreitet, führte aber zu Spaghetti-Code. In seinem berühmten Paper "A Case against the GO TO Statement"[http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF], das als Brief mit dem Titel "Go-to statement considered harmful" veröffentlicht wurde, argumentiert Dijkstra, dass es umso schwieriger ist, dem Quellcode eines Programmes zu folgen, je mehr go-to-Befehle darin enthalten sind und zeigt, dass man auch ohne diesen Befehl gute Programme schreiben kann.

==== Algorithmus ====

Der Dijkstra-Algorithmus für kürzeste Wege ist dem oben vorgestellten Algorithmus <tt>shortestPath()</tt> auf der Basis von Breitensuche sehr ähnlich. Insbesondere gilt auch hier, dass neben dem kürzesten Weg vom Start zum Ziel auch alle kürzesten Wege gefunden werden, deren Endknoten dem Start näher sind als der Zielknoten. Aufgrund der Kantengewichte gibt es aber einen wichtigen Unterschied: Der erste gefundene Weg zu einem Knoten ist nicht mehr notwendigerweise der kürzeste. Wir bestimmen deshalb für jeden Knoten mehrere Kandidatenwege und verwenden eine Prioritätswarteschlange (statt einer einfachen First in - First out - Queue), um diese Wege nach ihrer Länge zu sortieren. Die Kandidatenwege für einen gegebenen Knoten werden unterschieden, indem wir auch den Vorgängerknoten im jeweiligen Weg speichern. Wenn ein Knoten erstmals an die Spitze der Prioritätswarteschlange gelangt, haben wir den kürzesten Weg zu diesem Knoten gefunden (das wird weiter unten formal bewiesen), und der Vorgänger des Knotens in diesem Weg wird zu seinem Vaterknoten. Erscheint derselbe Knoten später nochmals an der Spitze der Prioritätswarteschlange, handelt es sich um einen Kandidatenweg, der sich nicht als kürzester erwiesen hat und deshalb ignoriert werden kann. Wir erkennen dies leicht daran, dass der Vaterknoten in der property map <tt>parents</tt> bereits gesetzt ist.

Eine geeignete Datenstruktur für die Prioritätswarteschlange wird durch das Python-Modul [http://docs.python.org/library/heapq.html heapq] realisiert. Es verwendet ein normales Pythonarray als unterliegende Repräsentation für einen Heap und stellt effiziente <tt>heappush</tt> und <tt>heappop</tt>-Funktionen zur Verfügung. Dies entspricht genau unserer Vorgehensweise im Kapitel [[Prioritätswarteschlangen]]. Als Datenelement erwartet die Funktion <tt>heappush</tt> ein Tupel, dessen erstes Element die Priorität sein muss. Die übrigen Elemente des Tupels (und damit auch deren Anzahl) können je nach Anwendung frei festgelegt werden. Wir legen fest, dass das zweite Element den Endknoten des betrachteten Weges und das dritte den Vorgängerknoten speichert.

Die Kantengewichte werden dem Algorithmus in der property map <tt>weights</tt> übergeben:

<code python>
import heapq # heapq implementiert die Funktionen für Heaps

def dijkstra(graph, weights, startnode, destination):
parents = [None]*len(graph) # registriere für jeden Knoten den Vaterknoten im Pfadbaum

q = [] # Array q wird als Heap verwendet
heapq.heappush(q, (0.0, startnode, startnode)) # Startknoten in Heap einfügen

while len(q) > 0: # solange es noch Knoten im Heap gibt:
length, node, predecessor = heapq.heappop(q) # Knoten aus dem Heap nehmen
if parents[node] is not None: # parent ist schon gesetzt => es gab einen anderen, kürzeren Weg
continue # => wir können diesen Weg ignorieren
parents[node] = predecessor # parent setzen
if node == destination: # Zielknoten erreicht
break # => Suche beenden
for neighbor in graph[node]: # die Nachbarn von node besuchen,
if parents[neighbor] is None: # aber nur, wenn ihr kürzester Weg noch nicht bekannt ist
newLength = length + weights[(node,neighbor)] # berechne Pfadlänge zu neighbor
heapq.heappush(q, (newLength, neighbor, node)) # und füge neighbor in den Heap ein

if parents[destination] is None: # Suche wurde beendet ohne den Zielknoten zu besuchen
return None, None # => kein Pfad gefunden (unzusammenhängender Graph)

# Pfad durch die parents-Kette zurückverfolgen und speichern
path = [destination]
while path[-1] != startnode:
path.append(parents[path[-1]])
path.reverse() # Reihenfolge umdrehen (Ziel => Start wird zu Start => Ziel)
return path, length # gefundenen Pfad und dessen Länge zurückgeben
</code>
Die wesentlichen Unterschiede zur Breitensuche sind im Code rot markiert: Anstelle der Queue verwenden wir jetzt einen Heap, und der Startknoten wird mit Pfadlänge 0 als erstes eingefügt. In der Schleife <tt>while len(q) > 0:</tt> wird jeweils der Knoten <tt>node</tt> mit der aktuell kürzesten Pfadlänge aus dem Heap entfernt. Die Pfadlänge vom Start zu diesem Knoten wird in der Variable <tt>length</tt> gespeichert, sein Vorgänger in der Variable <tt>predecessor</tt>. Wenn der aktuelle Weg nicht der kürzeste ist (<tt>parents[node]</tt> war bereits gesetzt), wird dieser Weg ignoriert. Andernfalls werden die property map <tt>parents</tt> aktualisiert und die Nachbarn von <tt>node</tt> besucht. Beim Scannen der Nachbarn berechnen wir zunächst die Länge <tt>newLength</tt> das Weges <tt>startnode => node => neighbor</tt> als Summe von <tt>length</tt> und dem Gewicht der Kante <tt>(node, neighbode)</tt>. Diese Länge wird beim Einfügen des Nachbarknotens in den Heap zur Priorität des aktuellen Weges.

Die wichtigsten Prinzipien des Dijkstra-Algorithmus noch einmal im Überblick:
* Der Dijkstra-Algorithmus ist Breitensuche mit Prioritätswarteschlange (Heap) statt einer einfache Warteschlange (Queue).
* Die Prioritätswarteschlange speichert alle Wege, die bereits gefunden worden sind und ordnet sie aufsteigend nach ihrer Länge.
* Das Sortieren (und damit der ganze Algorithmus) funktioniert nur mit positiven Kantengewichten korrekt.
* Da ein Knoten auf mehreren Wegen erreichbar sein kann, kann er auch mehrmals im Heap sein.
* Wenn ein Knoten erstmals aus der Prioritätswarteschlange entnommen wird, ist der gefundene Weg der kürzeste zu diesem Knoten. Andernfalls wird der Weg ignoriert.
* Wenn der Knoten <tt>destination</tt> aus dem Heap entnommen wird, ist der kürzeste Weg von Start nach Ziel gefunden, und die Suche kann beendet werden.
In unserer Implementation können, wie gesagt, mehrere Wege zum selben Knoten gleichzeitig in der Prioritätswarteschlange sein. Im Prinzip wäre es auch möglich, immer nur den besten zur Zeit bekannten Weg zu jedem Enknoten in der Prioritätswarteschlange zu halten - sobald ein besserer Kandidat gefunden wird, ersetzt er den bisherigen Kandidaten, anstatt zusätzlich eingefügt zu werden. Dies erfordert aber eine wesentlich kompliziertere Prioritätswarteschlange, die eine effiziente <tt>updatePriority</tt>-Funktion anbietet, ohne dass dadurch eine signifikante Beschleunigung erreicht wird. Deshalb verfolgen wir diesen Ansatz nicht.

==== Beispiel ====

under construction

[[Image:Bsp.jpg]]

==== Komplexität von Dijkstra ====

Zur Analyse der Komplexität nehmen wir an, dass der Graph V Knoten und E Kanten hat. Die Initialisierung der property map <tt>parents</tt> am Anfang der Funktion hat offensichtlich Komplexität O(V), weil Speicher für V Knoten allokiert wird. Der Code am Ende der Funktion, der aus der property map <tt>parents</tt> den Pfad extrahiert, hat ebenfalls die Komplexität O(V), weil der Pfad im ungünstigen Fall sämtliche Knoten des Graphen umfasst. Beides wird durch die Komplexität der Hauptschleife dominiert, zu deren Analyse wir den folgenden Codeausschnitt genauer anschauen wollen:

while len(q) > 0:
... # 1
if parents[node] is not None:
continue
parents[node] = predecessor
... # 2
Wir erkennen, dass der Codeabschnitt <tt># 2</tt> für jeden Knoten höchstens einmal erreicht werden kann: Da <tt>parents[node]</tt> beim ersten Durchlauf gesetzt wird, kann die <tt>if</tt>-Abfrage beim gleichen Knoten nie wieder <tt>False</tt> liefern, und das nachfolgende <tt>continue</tt> bewirkt, dass der Abschnitt <tt># 2</tt> dann übersprungen wird. Man sagt auch, dass jeder Knoten höchstens einmal expandiert wird, auch wenn er mehrmals im Heap war.

Der Codeabschnitt <tt># 2</tt> selbst enthält eine Schleife über alle ausgehenden Kanten des Knotens <tt>node</tt>. Im ungünstigsten Fall iterieren wir bei allen Knoten über alle ausgehenden Kanten, aber das sind gerade alle Kanten des Graphen je einmal in den beiden möglichen Richtungen. Die Funktion <tt>heappush</tt> wird sogar höchstens E Mal aufgerufen, weil eine Kante nur in den Heap eingefügt wird, wenn der kürzeste Weg der jeweiligen Endknotens noch nicht bekannt ist (siehe die <tt>if</tt>-Abfrage in der <tt>for</tt>-Schleife), und das ist nur ein einer Richtung möglich. Dies hat zwei Konsequenzen:
* Die Schleife <tt>while len(q) > 0:</tt> wird nur so oft ausgeführt, wie Elemente im Heap sind, also höchstens E Mal. Das gleiche gilt für den Codeabschnitt <tt># 1</tt>, der das <tt>heappop</tt> enthält.
* Die Operationen <tt>heappush</tt> und <tt>heappop</tt> haben logarithmische Komplexität in der Größe des Heaps, sind also in <math>O(\log\,E)</math>. In einfachen Graphen gilt aber <math>E = O(V^2)</math>, so dass sich die Komplexität der Heapoperationen vereinfacht zu <math>O(\log\,E)=O(\log\,V^2)=O(2\log\,V)=O(\log\,V)</math>.
Zusammenfassend gilt: <tt>heappush</tt> und <tt>heappop</tt> werden maximal E Mal aufgerufen und haben eine Komplexität in <math>O(\log\,V)</math>. Folglich hat der Algorithmus von Dijkstra die Komplexität:
:<math>O(E\,\log\,V)</math>

==== Vergleich mit Breitensuche und Tiefensuche ====

Der Dijkstra-Algorithmus ist eng mit der Breiten- und Tiefensuche verwandt - man kann diese Algorithmen aus dem Dijkstra-Algorithmus gewinnen, indem man einfach die Regel zur Festlegung der Prioritäten ändert. Anstelle der Länge des Pfades verwenden wir als Priorität den Wert eine Zählvariable <tt>count</tt>, die nach jeder Einfügung in den Heap (also nach jedem Aufruf von <tt>heappush</tt>) aktualisiert wird. Zählen wir die Variable hoch, haben die zuerst eingefügten Kanten die höchste Priorität, der Heap verhält sich also wie eine Queue (First in-First out), und wir erhalten eine Breitensuche. Zählen wir die Variable hingegen (von E beginnend) herunter, haben die zuletzt eingefügten Kanten höchste Priorität. Der Heap verhält sich dann wie ein Stack (Last in-First out), und wir bekommen Tiefensuche. Statt eines Heaps plus Zählvariable kann man jetzt natürlich direkt eine Queue bzw. einen Stack verwenden. Dadurch fällt der Aufwand <math>O(\log\,V)</math> für die Heapoperationen weg und wird durch die effizienten O(1)-Operationen von Queue bzw. Stack ersetzt. Damit erhalten wir für Breiten- und Tiefensuche die schon bekannte Komplexität O(E).

==== Korrektheit von Dijkstra ====

Wir beweisen mittels vollständiger Induktion die Schleifen-Invariante: Falls <tt>parents[node]</tt> gesetzt (also ungleich <tt>None</tt>) ist, dann liefert das Zurückverfolgen des Weges von <tt>node</tt> nach <tt>startnode</tt> den kürzesten Weg.
;Induktionsanfang: <tt>parents[startnode]</tt> ist als einziges gesetzt. Zurückverfolgen liefert den trivialen Weg <tt>[startnode]</tt>, der mit Länge 0 offensichtlich der kürzeste Pfad ist → die Bedingung ist erfüllt.
;Induktionsschritt: Wir zeigen mit einem indirektem Beweis, dass wir immer einen kürzesten Weg bekommen, wenn <tt>parents[node]</tt> gesetzt wird.
:Sei <math>S</math> = <tt>{v | parents[v] is not None}</tt> die Menge aller Knoten, von denen wir den kürzesten Weg schon kennen (Induktionsvoraussetzung), und <tt>node</tt> der Knoten, der sich gerade an der Spitze des Heaps befindet. Dann ist <tt>predecessor</tt> der Vorgänger von <tt>node</tt> im aktuellen Weg, und es muss <tt>predecessor</tt><math>\in S</math> gelten, weil die Nachbarn von <tt>predecessor</tt> (und damit auch der aktuelle <tt>node</tt>) erst in den Heap eingefügt werden, wenn der kürzeste Weg für <tt>predecessor</tt> gefunden wurde. Man beachte auch, dass alle Knoten, die noch nicht in <math>S</math> enthalten sind, weiter vom Start entfernt sind als alle Knoten in <math>S</math>, weil alle neu in den Heap eingefügten Wege länger sind als der kürzeste Weg des jeweiligen Vorgängers.
:Der indirekte Beweis nimmt jetzt an, dass der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> nicht der kürzeste Weg ist. Dann muss es einen anderen, kürzeren Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> geben. Für den Vorgänger <tt>x</tt> in diesem Weg unterscheiden wir zwei Fälle:
:* <tt>x</tt><math>\in S</math>: In diesem Fall ist die Länge des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> bereits bekannt, und dieser Weg ist in der Prioritätswarteschlange enthalten. Dann kann er aber nicht der kürzeste sein, denn an der Spitze der Warteschlange war nach Voraussetzung der Weg <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt>.
:* <tt>x</tt><math>\notin S</math>: Die Kosten des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> berechnen sich als <tt>Kosten(x → startnode) + weight[(x, node)]</tt>, und die Kosten des Weges <tt>node</tt> → <tt>predecessor</tt> → <tt>startnode</tt> sind analog <tt>Kosten(predecessor → startnode) + weight[(predecessor, node)]</tt>. Aufgrund der Induktionsvoraussetzung gilt aber <tt>predecessor</tt><math>\in S</math>, und somit <tt>Kosten(predecessor → startnode) < Kosten(x → startnode)</tt>, weil <tt>x</tt> andernfalls vor <tt>predecessor</tt> an der Spitze des Heaps gewesen wäre, was mit der Annahme <tt>x</tt><math>\notin S</math> unverträglich ist. Damit der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> trotzdem der kürzeste Weg sein kann, müsste <tt>Kosten(x → startnode) < Kosten(node → startnode)</tt> gelten, denn durch die Kante <tt>(x, node)</tt> kommen ja noch Kosten hinzu. Das wäre aber nur möglich, wenn der Knoten <tt>x</tt> vor dem Knoten <tt>node</tt> an die Spitze des Heaps gelangt, im Widerspruch zur Annahme, dass <tt>node</tt> sich gerade an der Spitze des Heaps befindet. Somit kann die Behauptung, dass der Weg <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> der kürzeste Weg ist, nicht stimmen.
In beiden Fällen erhalten wir einen Widerspruch, und die Behauptung ist somit bewiesen. Da die Invariante insbesondere für den Weg zum Zielknoten <tt>destination</tt> erfüllt ist, folgt daraus auch die Korrektheit des Algorithmus von Dijkstra.

=== A*-Algorithmus - Wie kann man Dijkstra noch verbessern? ===

Eine wichtige Eigenschaft des Dijkstra-Algorithmus ist, dass neben dem kürzesten Weg vom Start zum Ziel auch die kürzesten Wege zu allen Knoten berechnet werden, die näher am Startknoten liegen als das Ziel, obwohl uns diese Wege gar nicht interessieren. Sucht man beispielsweise in einem Graphen mit den Straßenverbindungen in Deutschland den kürzesten Weg von Frankfurt (Main) nach Dresden (ca. 460 km), werden auch die kürzesten Wege von Frankfurt nach Köln (190 km), Dortmund (220 km) und Stuttgart (210 km) und vielen anderen Städten gefunden. Aufgrund der geographischen Lage dieser Städte ist eigentlich von vornherein klar, dass sie mit dem kürzesten Weg nach Dresden nicht das geringste zu tun haben. Anders sieht es mit Erfurt (260 km) oder Suhl (210 km) aus - diese Städte liegen zwischen Frankfurt und Dresden und kommen deshalb als Zwischenstationen des gesuchten Weges in Frage.

Damit Dijkstra korrekt funktioniert, würde es im Prinzip ausreichen, wenn man die kürzesten Wege nur für diejenigen Knoten ausrechnet, die auf dem kürzesten Weg vom Start zum Ziel liegen, denn nur diese Knoten braucht man, um den gesuchten Weg über die <tt>parent</tt>-Kette zurückzuverfolgen. Das Problem ist nur, dass man diese Knoten erst kennt, wenn der Algorithmus fertig durchgelaufen ist. Schließt man Knoten zu früh von der Betrachtung aus, kommt am Ende möglicherweise nicht der korrekte kürzeste Weg heraus.

Der A*-Algorithmus löst dieses Dilemma mit folgender Idee: Ändere die Prioritäten für den Heap so ab, dass unwichtige Knoten nur mit geringerer Wahscheinlichkeit expandiert werden, aber stelle gleichzeitig sicher, dass alle wichtigen Knoten (also diejenigen auf dem korrekten kürzesten Weg) auf jeden Fall expandiert werden. Es zeigt sich, dass man diese Idee umsetzen kann, wenn eine Schätzung für den Restweg (also für die noch verbleibende Entfernung von jedem Knoten zum Ziel) verfügbar ist:
rest = guess(neighbor, destination)
Diese Schätzung addiert man einfach zur wahren Länge des Weges <tt>startnode → node</tt> dazu, um die verbesserte Priorität zu erhalten:
priority = newLength + guess(neighbor, destination)
(Im originalen Dijkstra-Algorithmus wird als Priorität nur <tt>newLength</tt> allein verwendet. Man beachte, dass man <tt>newLength</tt> jetzt zusätzlich im Heap speichern muss, weil man es für die Expansion des Knotens später noch benötigt.)

Damit sicher gestellt ist, dass der A*-Algorithmus immer noch die korrekten kürzesten Wege findet, darf die Schätzung den wahren Restweg niemals überschätzen. Es muss immer gelten:
0 <= guess(node, destination) <= trueDistance(node, destination)
Damit gilt insbesondere <tt>guess(destination, destination) = trueDistance(destination, destination) = 0</tt>, an der Priorität des Knotens <tt>destination</tt> ändert sich also nichts. Die Prioritäten aller anderen Knoten veschlechtern sich hingegen, weil zur bisherigen Priorität noch atwas addiert wird. Für die wichtigen Knoten auf dem kürzesten Weg vom Start nach Ziel gilt jedoch, dass deren neue Priorität immer noch besser ist als die Priorität des Zielknotens selbst. Für diese Knoten gilt nämlich
falls node auf dem kürzesten Weg von startnode nach destination liegt:
trueDistance(startnode, node) + guess(node, destination) <= trueDistance(startnode, destination)
weil der Weg von Start nach <tt>node</tt> ein Teil des kürzesten Wegs von Start nach Ziel ist und die Restschätzung die wahre Entfernung immer unterschätzt. Diese Knoten werden deshalb stets vor dem Zielknoten expandiert, so dass wir die <tt>parent</tt>-Kette immer noch korrekt zurückverfolgen können. Für alle anderen Knoten gilt idealerweise, dass die neue Priorität schlechter ist als die Priorität von <tt>destination</tt>, so dass man sich diese irrelevanten Knotenexpansionen sparen kann.

Für das Beispiel eines Straßennetzwerks bietet sich als Schätzung die Luftlinienentfernung an, weil Straßen nie kürzer sein können als die Luftlinie. Damit erreicht man in der Praxis deutliche Einsparungen. Generell gilt, dass der A*-Algorithmus im typischen Fall schneller ist als der Algorithmus von Dijkstra, aber man kann immer pathologische Fälle konstruieren, wo die Änderung der Prioritäten nichts bringt. Die Komplexität des A*-Algorithmus im ungünstigen Fall ist deshalb nach wie vor <math>O(E\,\log\,V)</math>.

=='''Minimaler Spannbaum'''==
'''(engl.: minimum spanning tree; abgekürzt: MST)'''

[[Image:Minimum_spanning_tree.png‎ |thumb|200px|right|Ein minimal aufspannender Baum verbindet alle Punkte eines Graphen bei minimaler Kantenlänge ([http://de.wikipedia.org/wiki/Spannbaum Quelle])]]

:''gegeben'': gewichteter Graph G, zusammenhängend 
:''gesucht'': Untermenge <math>E'\subseteq E</math> der Kanten, so dass die Summe der Kantengewichte <math>\sum_{e\in E'} w_e</math> minimal und der entstehende Graph G' zusammenhängend ist. 
* G' definiert immer einen Baum, denn andernfalls könnte man eine Kante weglassen und dadurch die Summe <math>\sum_{e\in E'} w_e</math> verringern, ohne dass sich am Zusammenhang von G' etwas ändert. 
* Wenn der Graph G nicht zusammenhängend ist, kann man den Spannbaum für jede Zusammenhangskomponente getrennt ausrechnen. Man erhält dann einen aufspannenden Wald.
* Der MST ist ähnlich wie der Dijkstra-Algorithmus: Dort ist ein Pfad gesucht, bei dem die Summe der Gewichte über den Pfad minimal ist. Beim MST suchen wir eine Lösung, bei der die Summe der Gewichte über den ganzen Graphen minimal ist.
* Das Problem des MST ist nahe verwandt mit der Bestimmung der Zusammenhangskomponente, z.B. über den Tiefensuchbaum. Für die Zusammenhangskomponenten genügt allerdings ein beliebiger Baum, während beim MST ein minimaler Baum gesucht ist.

=== Anwendungen ===
==== Wie verbindet man n gegebene Punkte mit möglichst kurzen Straßen (Eisenbahnen, Drähten [bei Schaltungen] usw.)?====

 
{| class="wikitable" style="text-align:center" border="0" cellpadding="5" cellspacing="0"
|MST minimale Verbindung (Abb.1)
|MST = 2 (Länge = Kantengewicht)(Abb.2)
|- valign="top"
| [[Image:mst.png]]
| [[Image:Gleichseitigesdreieck.png]]
|}
*In der Praxis: Die Festlegung, dass man nur die gegebenen Punkte verwenden darf, ist eine ziemliche starke Einschränkung.

* Wenn man sich vorstellt, es sind drei Punkte gegeben, die als gleichseitiges Dreieck angeordnet sind, dann ist der MST (siehe Abb.2, schwarz gezeichnet) und hat die Länge 2. Man kann hier die Länge als Kantengewicht verwenden.

* Wenn es erlaubt ist zusätzliche Punkte einzufügen, dann kann man in der Mitte einen neuen Punkt setzen <math>\rightarrow</math> neuer MST (siehe Abb.2, orange gezeichnet). 

* Höhe = <math>\frac{1}{2}\sqrt{3}</math>, Schwerpunkt: teilt die Höhe des Dreiecks im Verhältnis 2:1; der Abstand von obersten Punkt bis zum neu eingeführten Punkt: <math>\frac{2}{3}h = \frac{\sqrt{3}}{3}</math>, davon insgesamt 3 Stück, damit (gilt für den MST in orange eingezeichnet): MST = <math>3\left(\frac{1}{3}\right) \sqrt{3} = \sqrt{3} \approx 1,7</math><br\>

* Damit ist der MST in orange kürzer als der schwarz gezeichnete MST. <br\>
<math>\Rightarrow</math>Folgerung: MST kann kürzer werden, wenn man einen Punkt dazu nimmt.
* Umgekehrt kann der MST auch kürzer werden, wenn man einen Punkt aus dem Graphen entfernt, aber wie das Beipiel des gleichseitigen Dreiecks zeigt, ist dies nicht immer der Fall.

[[Image: bahn.png|Bahnstrecke Verbindung (Abb.3)]]

* Methode der zusätzlichen Punkteinfügung hat man früher beim Bahnstreckenbau verwendet. Durch Einführung eines Knotenpunktes kann die Streckenlänge verkürzt werden (Dreiecksungleichung).

==== Bestimmung von Datenclustern ====

[[Image:cluster.png]]

* Daten (in der Abb.: Punkte) bilden Gruppen.

* In der Abbildung hat man 2 verschiedene Messungen gemacht (als x- und y-Achse aufgetragen), bspw. Größe und Gewicht von Personen. Für jede Person i wird ein Punkt an der Koordinate (Größei, Gewichti) gezeichnet (siehe Bild a). Dies bezeichnet man als ''Scatter Plot''. Wenn bestimmte Wertkombinationen häufiger auftreten als andere, bilden sich mitunter Gruppen aus, bspw. eine Gruppe für "klein und schwer" etc.

* Durch Verbinden der Punkte mittels eines MST (siehe Abbildung (b)) sieht man, dass es kurze (innerhalb der Gruppen) und lange Kanten (zwischen den Gruppen) gibt.

* Wenn man geschickt eine Schwelle einführt und alle Kanten löscht, die länger sind als die Schwelle, dann bekommt man als Zusammenhangskomponente die einzelnen Gruppen.

=== Algorithmen ===

Genau wie bei der Bestimmung von Zusammenhangskomponenten kann man auch das MST-Problem entweder nach dem Anlagerungsprinzip oder nach dem Verschmelzungsprinzip lösen (dazu gibt es noch weitere Möglichkeiten, z.B. den [http://de.wikipedia.org/wiki/Algorithmus_von_Bor%C5%AFvka Algorithmus von Boruvka]). Der Anlagerungsalgorithmus für MST wurde zuerst von Prim beschrieben und trägt deshalb seinen Namen, der Verschmelzungsalgorithmus stammt von Kruskal. Im Vergleich zu den Algorithmen für Zusammenhangskomponenten ändert sich im wesentlichen nur die Reihenfolge, in der die Kanten betrachtet werden: Eine Prioritätswarteschlange stellt jetzt sicher, dass am Ende wirklich der Baum mit den geringstmöglichen Kosten herauskommt.

====Algorithmus von Prim====
[http://de.wikipedia.org/wiki/Algorithmus_von_Prim Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]

Der Algorithmus von Prim geht nach dem Anlagerungsprinzip vor (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Tiefensuche|Zusammenhangskomponenten mit Tiefensuche]]): Starte an der Wurzel (ein willkürlich gewählter Knoten) und füge jeweils die günstigste Kante an die aktuellen Teillösung an, die keinen Zyklus verursacht. Die Sortierung der Kanten nach Priorität erfolgt analog zum Dijsktra-Algorithmus, aber die Definitionen, welche Kante die günstigste ist, unterscheiden sich. Die Konvention für die Bedeutung der Elemente des Heaps ist ebenfalls identisch: ein Tupel mit <tt>(priority, node, predecessor)</tt>. Die folgende Implementation verdeutlicht sehr schön die Ähnlichkeit der beiden Algorithmen. Das Ergebnis wird als property map <tt>parents</tt> zurückgegeben, in der für jeden Knoten sein Vorgänger im MST steht, wobei die Wurzel wie üblich auf sich selbst verweist.

import heapq

def prim(graph, weights): # Kantengewichte wie bei Dijkstra als property map
sum = 0.0 # wird später das Gewicht des Spannbaums sein
start = 0 # Knoten 0 wird willkürlich als Wurzel gewählt

parents = [None]*len(graph) # property map, die den resultierenden Baum kodiert
parents[start] = start # Wurzel zeigt auf sich selbst

heap = [] # Heap für die Kanten des Graphen
for neighbor in graph[start]: # besuche die Nachbarn von start
heapq.heappush(heap, (weights[(start, neighbor)], neighbor, start)) # und fülle Heap

while len(heap) > 0:
w, node, predecessor = heapq.heappop(heap) # hole billigste Kante aus dem Heap
if parents[node] is not None: # die Kante würde einen Zyklus verursachen
continue # => ignoriere diese Kante
parents[node] = predecessor # füge Kante in den MST ein
sum += w # und aktualisiere das Gesamtgewicht
for neighbor in graph[node]: # besuche die Nachbarn von node
if parents[neighbor] is None: # aber nur, wenn kein Zyklus entsteht
heapq.heappush(heap, (weights[(node,neighbor)], neighbor, node)) # füge Kandidaten in Heap ein

return parents, sum # MST und Gesamtgewicht zurückgeben

====Algorithmus von Kruskal====
[http://de.wikipedia.org/wiki/Algorithmus_von_Kruskal Wikipedia (de)]
[http://en.wikipedia.org/wiki/Kruskal%27s_algorithm (en)]

Die alternative Vorgehensweise ist das Verschmelzungsprinzip (vgl. den Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]]), das der Algorithmus von Kruskal verwendet. Jeder Knoten wird zunächst als trivialer Baum mit nur einem Knoten betrachtet, und alle Kanten werden aufsteigend nach Gewicht sortiert. Dann wird die billigste noch nicht betrachtete Kante in den MST eingefügt, falls sich dadurch kein Zyklus bildet (erkennbar daran, dass die Endknoten in verschiedenen Zusammenhangskomponenten liegen, das heisst verschiedene Anker haben). Da der fertige Baum (V-1) Kanten haben muss, wird dies (V-1) Mal zutreffen. Andernfalls wird diese Kante ignoriert. Anders ausgedrückt: Der Algorithmus beginnt mit ''V'' Bäumen; in (''V''-1) Verschmelzungsschritten kombiniert er jeweils zwei Bäume (unter Verwendung der kürzesten möglichen Kante), bis nur noch ein Baum übrig bleibt. Der einzige Unterschied zum einfachen Union-Find besteht darin, dass die Kanten in aufsteigender Reihenfolge betrachtet werden müssen, was wir hier durch eine Prioritätswarteschlange realisieren. Der Algorithmus von J.Kruskal ist seit 1956 bekannt.

def kruskal(graph, weights):
anchors = range(len(graph)) # Initialisierung der property map: jeder Knoten ist sein eigener Anker
results = [] # result wird später die Kanten des MST enthalten

heap = [] # Heap zum Sortieren der Kanten nach Gewicht
for edge, w in weights.iteritems(): # alle Kanten einfügen
heapq.heappush(heap, (w, edge))

while len(heap) > 0: # solange noch Kanten vorhanden sind
w, edge = heapq.heappop(heap) # billigste Kante aus dem Heap nehmen
a1 = findAnchor(anchors, edge[0]) # Anker von Startknoten der Kante
a2 = findAnchor(anchors, edge[1]) # ... und Endknoten bestimmen
if a1 != a2: # wenn die Knoten in verschiedenen Komponenten sind
anchors[a2] = a1 # Komponenten verschmelzen
result.append(edge) # ... und Kante in MST einfügen

return result # Kanten des MST zurückgeben

Die Funktion <tt>findAnchor()</tt> wurde im Abschnitt [[Graphen_und_Graphenalgorithmen#Lösung mittels Union-Find-Algorithmus|Zusammenhangskomponenten mit Union-Find-Algorithmus]] implementiert. Im Unterschied zum Algorithmus von Prim geben wir hier nicht die property map <tt>parents</tt> zurück, sondern einfach eine Liste der Kanten im MST.

Der Algorithmus eignet sich insbesondere für das Clusteringproblem, da der Schwellwert von vornerein als maximales Kantengewicht an den Algorithmus übergeben werden kann. Man hört mit dem Vereinigen auf, wenn das Gewicht der billigste Kante im Heap den Schwellwert überschreitet. Beim Algorithmus von Kruskal kann dann keine bessere Kante als der Schwellwert mehr kommen, da die Kanten vorher sortiert worden sind.

Komplexität: wie beim Dijkstra-Algorithmus, weil jede Kante genau einmal in den Heap kommt. Der Aufwand für das Sortieren ist somit <math>O\left(E\log E\right)</math>, was sich zu <math>O \left(E\,\log\,V\right)</math> reduziert, falls keine Mehrfachkanten vorhanden sind.

=> geeignet für Übungsaufgabe

====Verwendung einer BucketPriorityQueue====

Beide Algorithmen zur Bestimmung des minimalen Spannbaums benötigen eine Prioritätswarteschlange. Wenn die Kantengewichte ganze Zahlen im Bereich <tt>0...(m-1)</tt> sind, kann man die MST-Algorithmen deutlich beschleunigen, wenn man anstelle des Heaps eine [[Prioritätswarteschlangen#Prioritätssuche mit dem Bucket-Prinzip|<tt>BucketPriorityQueue</tt>]] verwendet. Die Operationen zum Einfügen einer Kante in die Queue und zum Entfernen der billibsten Kante aus der Queue beschleunigen sich dadurch auf O(1) statt O(log V) (außer wenn die Gewichte sehr ungünstig auf die Kanten verteilt sind). In der Praxis erreicht man durch diese Änderung typischerweise deutliche Verbesserungen. In der Bildverarbeitung können die Prioritäten beispielsweise die Wahrscheinlichkeit kodieren, dass zwei benachbarte Pixel zu verschiedenen Objekten gehören. Bildet man jetzt den MST, und bricht bei einer bestimmten Wahrscheinlichkeit ab, erhält man Cluster von Pixeln, die wahrscheinlich zum selben Objekt gehören (weil der MST ja die Kanten mit minimalem Gewicht bevorzugt, und kleine Gewichte bedeuten kleine Wahrscheinlichkeit, dass benachbarte Pixel von einander getrennt werden). Da man die Wahrscheinlichkeiten nur mit einer Genauigkeit von ca. 1% berechnen kann, reichen hiefür 100 bis 200 Quantisierungstufen aus. Durch Verwendung der schnellen <tt>BucketPriorityQueue</tt> kann man jetzt wesentlich größere Bilder in akzeptabler Zeit bearbeiten als dies mit einem Heap möglich wäre.

== Algorithmen für gerichtete Graphen ==

Zur Erinnerung: in einem gerichteten Graphen sind die Kanten (i → j) und (j → i) voneinander verschieden, und eventuell existiert nur eine der beiden Richtungen. Im allgemeinen unterscheidet sich der [[Graphen_und_Graphenalgorithmen#transposed_graph|transponierte Graph]] GT also vom Originalgraphen G. Beim Traversieren des Graphen und bei der Pfadsuche dürfen Kanten nur in passender Richtung verwendet werden. Bei gewichteten Graphen tritt häufig der Fall auf, dass zwar Kanten in beiden Richtungen existieren, diese aber unterschiedliche Gewichte haben.

Gerichtete Graphen ergeben sich in natürlicher Weise aus vielen Anwendungsproblemen:
* Routenplanung
** Bei Straßennetzwerken enstehen gerichtete Graphen, sobald es Einbahnstraßen gibt.
** Verwendet man Gewichte, um die erwarteten Fahrzeiten entlang einer Straße zu kodieren, gibt es Asymmetrien z.B. dann, wenn Straßen in einer Richtung bergab, in der anderen bergauf befahren werden. Hier existieren zwar Kanten in beiden Richtungen, sie haben aber unterschiedliche Gewichte. Ähnliches gilt für Flüge: Durch den Gegenwind des Jetstreams braucht man von Frankfurt nach New York länger als umgekehrt von New York nach Frankfurt.
* zeitliche oder kausale Abhängigkeiten
** Wenn die Knoten Ereignisse repräsentieren, von denen einige die Ursache von anderen sind, diese wiederum die Ursache der nächsten usw., verbindet man die Knoten zweckmäßig durch gerichtete Kanten, die die Kausalitätsbeziehungen kodieren. Handelt es sich um logische "wenn-dann"-Regeln, erhält man einen [[Graphen_und_Graphenalgorithmen#Anwendung:_Das_Erf.C3.BCllbarkeitsproblem_in_Implikationengraphen|Implikationengraph]] (siehe unten). Handelt es sich hingegen um Wahrscheinlichkeitsaussagen ("Wenn das Wetter schön ist, haben Studenten tendenziell gute Laune, wenn eine Prüfung bevorsteht eher schlechte usw."), erhält man ein [http://de.wikipedia.org/wiki/Bayessches_Netz Bayessches Netz].
** Wenn bestimmte Aufgaben erst begonnen werden können, nachdem andere Aufgaben erledigt sind, erhält man einen Abhängigkeitsgraphen. Beispielsweise dürfen Sie erst an der Klausur teilnehmen, nachdem Sie die Übungsaufgaben gelöst haben, und Sie dürfen erst die Abschlussarbeit beginnen, nachdem Sie bestimmte Prüfungen bestanden haben. Ein anderes schönes Beispiel liefern die Regeln für das [[Graphen_und_Graphenalgorithmen#Anwendung:_Abh.C3.A4ngigkeitsgraph|Ankleiden]] weiter unten.
** Gerichtete Graphen kodieren die Abhängigkeiten zwischen Programmbibliotheken. Beispielsweise benötigt das Pythonmodul <tt>json</tt> die internen Submodule <tt>json.encoder</tt> und <tt>json.decode</tt> sowie das externe Modul <tt>decimal</tt>. Die Submodule benötigen wiederum die externen Module <tt>re</tt> und <tt>sys</tt>, das Modul <tt>decimal</tt> braucht <tt>copy</tt> und <tt>collections</tt> usw.
** Das Internet kann als gerichteter Graph dargestellt werden, wobei die Webseiten die Knoten, und die Hyperlinks die Kanten sind.
* Sequence Alignment
** Eine gute Rechtschreibprüfung markiert nicht nur fehlerhafte Wörter, sondern macht auch plausible Vorschläge, was eigentlich gemeint gewesen sein könnte. Dazu muss sie das gegebene Wort mit den Wörtern eines Wörterbuchs vergleichen und die Ähnlichkeit bewerten. Ein analoges Problem ergibt sich, wenn man DNA Fragmente mit der Information in einer Genomdatenbank abgleichen will.

=== Anwendung: Sequence Alignment / Edit Distance ===

:gegeben: zwei Wörter (allgemein: beliebige Zeichenfolgen)
:gesucht: Wie kann man die Buchstaben am besten in Übereinstimmung bringen?

:Beispiel: WORTE – NORDEN

Zwei mögliche Alignments sind

WORTE. W.ORTE
NORDEN NORDEN

wobei der Punkt anzeigt, dass der untere Buchstabe keinen Partner hat, und rote Buchstaben oben und unten übereinstimmen. Jede Nicht-Übereinstimmung verursacht nun gewisse Kosten. Dabei unterscheiden wir zwei Fälle:
# Matche a[i] mit b[j]. Falls a[i] == b[j], ist das gut (rote Buchstaben), und es entstehen keine Kosten. Andernfalls entstehen Kosten U (schwarze Buchstaben).
# Wir überspringen a[i] oder b[j] (Buchstabe vs. Punkt). Dann entstehen Kosten V. (Manchmal unterscheidet man auch noch Kosten Va und Vb, wenn das Überspringen bei a und b unterschieldiche Signifikanz hat.)

Gesucht ist nun das Alignment mit minimalen Kosten

Diese Aufgabe kann man sehr schön als gerichteten Graphen darstellen: Wir definieren ein rechteckiges Gitter und schreiben das erste Wort über das Gitter und das andere links davon. Die Gitterpunkte verbinden wir mit Pfeilen (gerichteten Kanten), wobei ein Pfeil nach rechts bedeutet, dass wir beim oberen Wort einen Buchstaben überspringen, ein Pfeil nach unten, dass wir beim linken Wort einen Buchstaben überspringen, und ein diagonaler Pfeil, dass wir zwei Buchstaben matchen (und zwar die am Pfeilende). Die Farben der Pfeile symbolisieren die Kosten: rot für das Überspringen eines Buchstabens (Kosten V), blau für das Matchen, wenn die Buchstaben nicht übereinstimmen (Kosten U), und grün, wenn die Buchstaben übereinstimmen (keine Kosten).

[[Image:sequence-alignment.png|300px]]

Lösung:
:Suche den kürzesten Pfad vom Knoten "START" (oben links) nach unten rechts. Dazu kann der [[Graphen und Graphenalgorithmen#Algorithmus von Dijkstra|Algorithmus von Dijkstra]] verwendet werden, der auf gerichteten Graphen genauso funktioniert wie auf ungerichteten.

Für unser Beispiel von oben erhalten wir die folgenden Pfade:

[[Image:sequence-alignment-weg1.png|400px]]     [[Image:sequence-alignment-weg2.png|400px]]

Durch Addieren der Kosten entsprechend der Farben sieht man, dass der erste Weg die Kosten 2U+V und der zweite die Kosten 5U+V hat. Der erste Weg ist offensichtlich günstiger und entspricht dem besten Alignment.

=== Anwendung: Abhängigkeitsgraph ===

Beispiel: Wie erklärt man einem zerstreuten Professor, wie er sich morgens anziehen soll? Der folgende Graph enthält einen Knoten für jede Aktion, und eine Kante (i → j) bedeutet, dass die Aktion i vor der Aktion j abgeschlossen werden muss.

[[Image:anziehen-graph.png|600px]]

In derartigen Abhängigkeitsgraphen ist die wichtigste Frage immer, ob der Graph azyklisch ist. Wäre dies nämlich nicht der Fall, kann es keine Reihenfolge der Aktionen geben, die alle Abhängigkeiten erfüllt. Dies sieht man leicht, wenn man den einfachsten möglichen Zyklus betrachtet: es gibt sowohl eine Kante (i → j) als auch eine (j → i). Dann müsste man i vor j erledigen, aber ebenso j vor i, was offensichtlich unmöglich ist - das im Graph kodierte Problem ist dann unlösbar. Wegen ihrer Wichtigkeit wird für gerichtete azyklische Graphen oft die Abkürzung DAG (von directed acyclic graph) verwendet. Ein Graph ist genau dann ein DAG, wenn es eine topologische Sortierung gibt:
;topologische Sortierung: Zeichne die Knoten so auf eine Gerade, dass alle Kanten (Pfeile) nach rechts zeigen.
Arbeitet man die Aktionen nach einer (beliebigen) topologischen Sortierung ab, werden automatisch alle Abhängigkeiten eingehalten: Da alle Pfeile nach rechts zeigen, werden abhängige Aktionen immer später ausgeführt. Die topologische Sortierung ist im allgemeinen nicht eindeutig. Die folgende Skizze zeigt eine mögliche topologische Sortierung für das Anziehen:

[[Image:anziehen-topologische-sortierung.png|600px]]

Eine solche fest vorgegebene Reihenfolge ist für den zerstreuten Professor sicherlich eine größere Hilfe als der ursprüngliche Graph. Man erkennt, dass die Sortierung nicht eindeutig ist, beispielsweise bei der Uhr: Da für die Uhr keine Abhängigkeiten definiert sind, kann man diese Aktion an beliebiger Stelle einsortieren. Hier wurde willkürlich die letzte Stelle gewählt.

==== Zwei Algorithmen zum Finden der topologischen Sortierung ====

Die folgenden Algorithmen finden entweder eine topologische Sortierung, oder signalisieren, dass der Graph zyklisch ist.

===== Algorithmus 1 =====
# Suche einen Knoten mit Eingangsgrad 0 (ohne eingehende Pfeile) => in einem gerichteten azyklischen Graphen gibt es immer einen solchen Knoten
# Platziere diesen Knoten auf der Geraden (beliebig)
# Entferne den Knoten aus dem Graphen zusammen mit den ausgehenden Kanten
# Gehe zu 1., aber platziere in 2. immer rechts der Knoten, die schon auf der Geraden vorhanden sind.
: => Wenn noch Knoten übrig sind, aber keiner Eingangsgrad 0 hat, muss der Graph zyklisch sein.

[[Image:bild6.JPG]]

Beispiel für einen zyklischen Graphen: kein Knoten hat Eingangsgrad 0.

Um den Algorithmus zu implementieren, verwenden wir eine property map <tt>in_degree</tt>, die wir in einem ersten Durchlauf durch den Graphen füllen und die dann für jeden Knoten die Anzahl der eingehenden Kanten speichert. Dann gehen wir sukzessive zu allen Knoten mit <tt>in_degree == 0</tt>. Anstatt sie aber tatsächlich aus dem Graphen zu entfernen wie im obigen Pseudocode, dekrementieren wir nur den <tt>in_degree</tt> ihrer Nachbarn. Wird der <tt>in_degree</tt> eines Nachbarn dadurch 0, wird er ebenfalls in das Array der zu scannenden Knoten aufgenommen. Wenn der Graph azyklisch ist, enthält das Array am Ende alle Knoten des Graphen, und die Reihenfolge der Einfügungen definiert eine topologische Sortierung. Andernfalls ist das Array zu kurz, und wir signalisieren durch Zurückgeben von <tt>None</tt>, dass der Graph zyklisch ist:

def topological_sort(graph): # ein gerichteter Graph
in_degree = [0]*len(graph) # property map für den Eingangsgrad jeden Knotens
for node in xrange(len(graph)): # besuche alle Knoten
for neighbor in graph[node]: # ... und deren Nachbarn
in_degree[neighbor] += 1 # ... und inkrementiere den Eingangsgrad

result = [] # wird später die topologische Sortierung enthalten
for node in xrange(len(graph)):
if in_degree[node] == 0:
result.append(node) # füge alle Knoten mit Eingangsgrad 0 in result ein

k = 0
while k < len(result): # besuche alle Knoten mit Eingangsgrad 0
node = result[k]
k += 1
for neighbor in graph[node]: # besuche alle Nachbarn
in_degree[neighbor] -= 1 # entferne 'virtuell' die eingehende Kante
if in_degree[neighbor] == 0: # wenn neighbor jetzt Eingangsgrad 0 hat
result.append(neighbor) # ... füge ihn in result ein

if len(result) == len(graph): # wenn alle Knoten jetzt Eingangsgrad 0 haben
return result # ... ist result eine topologische Sortierung
else:
return None # andernfalls ist der Graph zyklisch

===== Algorithmus 2 =====
Der obige Algorithmus hat den Nachteil, dass er jeden Knoten zweimal expandiert. Man kann eine topologische Sortierung stattdessen auch mit Tiefensuche bestimmen. Es gilt nämlich der folgende
;Satz: Wird ein DAG mittels Tiefensuche traversiert, definiert die reverse post-order eine topologische Sortierung.
Zur Erinnerung: die post-order erhält man, indem man jeden Knoten ausgibt, nachdem die Rekursion zu allen seinen Nachbarn beendet ist, siehe unsere [[Graphen_und_Graphenalgorithmen#pre_and_post_order|Diskussion weiter oben]]. Die reverse post-order ist gerade die Umkehrung dieser Reihenfolge. Die folgende Implementation verwendet die rekursive Version der Tiefensuche, in der Praxis wird man meist die iterative Version mit Stack bevorzugen, weil bei großen Graphen die Aufruftiefe sehr groß werden kann:

def reverse_post_order(graph): # gerichteter Graph
result = [] # enthält später die reverse post-order
visited = [False]*len(graph) # Flags für bereits besuchte Knoten

def visit(node): # besuche node
if not visited[node]: # aber nur, wenn er noch nicht besucht wurde
visited[node] = True # markiere ihn als besucht
for neighbor in graph[node]: # und besuche die Nachbarn
visit(neighbor)
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order

for node in xrange(len(graph)): # besuche alle Knoten
visit(node)

result.reverse() # post-order => reverse post-order
return result

Die Tatsache, dass die reverse post-order tatsächlich eine topologische Sortierung liefert, leuchtet wahrscheinlich nicht unmittelbar ein. Bevor wir diese Tatsache beweisen. wollen wir uns anhand des Ankleidegraphen klar machen, dass die pre-order (die man intuitiv vielleicht eher wählen würde) keine topologische Sortierung ist. Startet man die Tiefensuche beim Knoten "Unterhemd", werden die Knoten in der Reihenfolge "Unterhemd", "Oberhemd", "Schlips", "Jackett", "Gürtel" gefunden. Da dann alle von "Unterhemd" erreichbaren Knoten erschöpft sind, startet man die Tiefensuche als nächstes bei "Unterhose" und erreicht von dort aus "Hose" und "Schuhe". Man erkennt sofort, dass diese Reihenfolge nicht funktioniert: "Hose" kommt nach "Gürtel", und "Jackett" kommt vor "Gürtel". Bei dieser Anordnung gibt es Pfeile nach links, die Abhängigkeitsbedingungen sind somit verletzt.

Damit die reverse post-order eine zulässige Sortierung sein kann, muss stets gelten, dass Knoten u vor Knoten v einsortiert wurde, wenn die Kante (u → v) existiert. Das ist aber äquivalent zur Forderung, dass in der ursprünglichen post-order (vor dem <tt>reverse</tt>) u hinter v stehen muss. Wir betrachten den <tt>visit</tt>-Aufruf, bei dem u expandiert wird. Gelangt man jetzt zu u's Nachbarn v, gibt es zwei Möglichkeiten: Wenn v bereits expandiert wurde, befindet es sich bereits im Array <tt>result</tt> und <tt>visit</tt> kehrt sofort zurück. Andernfalls wird v ebenfalls expandiert und demzufolge in <tt>result</tt> eingetragen, bevor der rekursive Aufruf <tt>visit(v)</tt> zurückkehrt. Knoten u wird aber erst in <tt>result</tt> eingefügt, nachdem alle rekursiven <tt>visit</tt>-Aufrufe seiner Nachbarn zurückgekehrt sind. In beiden Fällen steht u in der post-order wie gefordert hinter v, und daraus folgt die Behauptung.

Der obige Algorithmus liefert natürlich nur dann eine topologische Sortierung, wenn der Graph wirklich azyklisch ist (man kann ihn aber auch anwenden, um die reverse post-order für einen zyklischen Graphen zu bestimmen, siehe Abschnitt "[[Graphen_und_Graphenalgorithmen#Transitive Hülle und stark zusammenhängende Komponenten|Stark zusammenhängende Komponenten]]"). Dieser Fall tritt in der Praxis häufig auf, weil zyklische Graphen bei vielen Anwendungen gar nicht erst entstehen können. Weiß man allerdings nicht, ob der Graph azyklisch ist oder nicht, muss man einen zusätzlichen Test auf Zyklen in den Algorithmus einbauen.

Zyklische Graphen sind dadurch gekennzeichnet, dass es im obigen Beweis eine dritte Möglichkeit gibt: Während der Expansion von u wird rekursiv v expandiert, und es gibt eine Rückwärtskante (v → u). (Es spielt dabei keine Rolle, ob v von u aus direkt oder indirekt erreicht wurde.) Ein Zyklus wird also entdeckt, wenn die Tiefensuche zu u zurückkehrt, solange u noch aktiv ist, d.h. wenn die Rekursion von u aus gestartet und noch nicht beendet wurde. Dies kann man leicht feststellen, wenn man in der property map <tt>visited</tt> drei Werte zulässt: 0 für "noch nicht besucht", 1 für "aktiv" und 2 für "beendet". Wir signalisieren einen Zyklus, sobald <tt>visit</tt> für einen Knoten aufgerufen wird, der gerade aktiv ist:

def topological_sort_DFS(graph): # gerichteter Graph
result = [] # enthält später die topologische Sortierung

not_visited, active, finished = 0, 1, 2 # drei Zustände für visited
visited = [not_visited]*len(graph) # Flags für aktive und bereits besuchte Knoten

def visit(node): # besuche node (gibt "True" zurück, wenn Zyklus gefunden wurde)
if not visited[node]: # ... aber nur, wenn er noch nicht besucht wurde
visited[node] = active # markiere ihn als aktiv
for neighbor in graph[node]: # und besuche die Nachbarn
if visit(neighbor): # wenn rekursiv ein Zyklus gefunden wurde
return True # ... brechen wir ab und signalisieren den Zyklus
visited[node] = finished # Rekursion beendet, node ist nicht mehr aktiv
result.append(node) # alle Nachbarn besucht => Anhängen an result liefert post-order
return False # kein Zyklus gefunden
elif visited[node] == active: # Rekursion erreicht einen noch aktiven Knoten
return True # => Zyklus gefunden

for node in xrange(len(graph)): # besuche alle Knoten
if visit(node): # wenn Zyklus gefunden wurde
return None # ... gibt es keine topologische Sortierung

result.reverse() # post-order => reverse post-order (=topologische Sortierung)
return result

Man macht sich leicht klar, dass kein Zyklus vorliegt, wenn die Rekursion einen Knoten erreicht, der bereits auf <tt>finished</tt> gesetzt ist. Nehmen wir an, dass u gerade expandiert wird, und sein Nachbar v ist bereits <tt>finished</tt>. Wenn es einen Zyklus gäbe, müsste es einen Weg von v nach u geben. Dann wäre u aber bereits während der Expansion von v gefunden worden. Da v nicht mehr im Zustand <tt>active</tt> ist, muss die Expansion von v schon abgeschlossen gewesen sein, ohne dass u gefunden wurde. Folglich kann es keinen solchen Zyklus geben.

=== Transitive Hülle und stark zusammenhängende Komponenten ===

Auch bei gerichteten Graphen ist die Frage, welche Knoten miteinander zusammenhängen, von großem Interesse. Wir betrachten dazu wieder die Relation "Knoten v ist von Knoten u aus erreichbar", die anzeigt, ob es einen Weg von u nach v gibt oder nicht. In ungerichteten Graphen ist diese Relation immer symmetrisch, weil jeder Weg in beiden Richtungen benutzt werden kann. In gerichteten Graphen gilt dies nicht. Man muss hier zwei Arten von Zusammenhangskomponenten unterscheiden:
;Transitive Hülle: Die transitive Hülle eines Knotens u ist die Menge aller Knoten, die von u aus erreichbar sind:
:<math>T(u) = \{v\ |\ u \rightsquigarrow v\}</math>
;Stark zusammenhängende Komponenten: Die stark zusammenhängende Komponenten <math>C_i</math> eines gerichteten Graphen sind maximale Teilgraphen, so dass alle Knoten innerhalb einer Komponente von jedem anderen Knoten der selben Komponente aus erreichbar sind
:<math>u,v \in C_i\ \ \Leftrightarrow\ \ u \rightsquigarrow v \wedge v \rightsquigarrow u</math>
Die erste Definition betrachtet den Zusammenhang asymmetrisch, ohne Beachtung der Frage, ob es auch einen Rückweg von Knoten v nach u gibt, die zweite hingegen symmetrisch.

Die transitive Hülle benötigt man, wenn man Fragen der Erreichbarkeit besonders effizient beantworten will. Wir hatten bespielsweise oben erwähnt, dass das Python-Modul <tt>json</tt> direkt und indirekt von mehreren anderen Module abhängt, die vorher installiert werden müssen, damit <tt>json</tt> funktioniert. Bittet man den Systemadministrator, das <tt>json</tt>-Paket zu installieren, will er diese Abhängigkeiten wahrscheinlich nicht erst mühsam rekursiv heraussuchen, sonder er verlangt eine Liste aller Pakete, die installiert werden müssen. Dies ist gerade die transitive Hülle von <tt>json</tt> im Abhängigkeitsgraphen. Damit man diese nicht manuell bestimmen muss, verwendet man Installationsprogrammen wie z.B. [http://pypi.python.org/pypi/pip/ pip], die die Abhängigkeiten automatisch herausfinden und installieren.

Bei der Bestimmung der transitiven Hülle modifiziert man den gegebenen Graphen, indem man jedesmal eine neue Kante (u → v) einfügt, wenn diese Kante noch nicht existiert, aber v von u aus erreichbar ist. Dies gelingt mit einer sehr einfachen Variation der Tiefensuche: Wir rufen <tt>visit(k)</tt> für jeden Knoten k auf, aber setzen die property map <tt>visited</tt> zuvor auf <tt>False</tt> zurück. Alle Knoten, die während der Rekursion erreicht werden, sind im modifizierten Graphen Nachbarn von k. Ein etwas effizienterer Ansatz ist der [http://de.wikipedia.org/wiki/Algorithmus_von_Floyd_und_Warshall Algorithmus von Floyd und Warshall].

Die Bestimmung der stark zusammenhängenden Komponenten ist etwas schwieriger. Es existieren eine ganze Reihe von effizienten Algorithmen (siehe [http://en.wikipedia.org/wiki/Strongly_connected_component WikiPedia]), deren einfachster der Algorithmus von Kosaraju ist:

gegeben: gerichteter Graph

# Bestimme die reverse post-order (mit der Funktion <tt>reverse_post_order</tt>)
# Bilde den transponierten Graphen <math>G^T</math> (mit der Funktion <tt>transposeGraph</tt>)
# Bestimme die Zusammenhangskomponenten von <math>G^T</math> mittels Tiefensuche, aber betrachte die Knoten dabei in der reverse post-order aus Schritt 1 (dies kann mit einer minimalen Modifikation der Funktion <tt>connectedComponents</tt> geschehen, indem man die Zeile <tt>for node in xrange(len(graph)):</tt> einfach nach <tt>for node in ordered:</tt> abändert, wobei <tt>ordered</tt> das Ergebnis der Funktion <tt>reverse_post_order</tt> ist, also ein Array, das die Knoten in der gewünschten Reihenfolge enthält).
Die Zusammenhangskomponenten, die man in Schritt 3 findet, sind gerade die stark zusammenhängenden Komponenten des Originalgraphen G. Die folgende Skizze zeigt diese in grün für den schwarz gezeichneten gerichteten Graphen.

[[Image:strongly-connected-components.png|400px]]

Zum Beweis der Korrektheit des Algorithmus von Kosaraju zeigen wir zwei Implikationen: 1. Wenn die Knoten u und v in der selben stark zusammenhängenden Komponente liegen, werden sie in Schritt 3 des Algorithmus auch der selben Komponente zugewiesen. 2. Wenn die Knoten u und v in Schritt 3 der selben Komponente zugewiesen wurden, müssen sie auch in der selben stark zusammenhängenden Komponente liegen.
# Knoten u und v gehören zur selben stark zusammenhängenden Komponente von G. Per Definition gilt, dass u von v aus erreichbar ist und umgekehrt. Dies muss auch im transponierten Graphen GT gelten (der Weg <math>u \rightsquigarrow v</math> wird jetzt zum Weg <math>v \rightsquigarrow u</math> und umgekehrt). Wird u bei der Tiefensuche in Schritt 3 vor v expandiert, ist v von u aus erreichbar und gehört somit zur selben Komponente. Das umgekehrte gilt, wenn v vor u expandiert wird. Daraus folgt die Behauptung 1.
# Knoten u und v werden in Schritt 3 der selben Komponente zugewiesen: Sei x der Anker dieser Komponente. Da u in der gleichen Komponente wie x liegt, muss es in GT einen Weg <math>x \rightsquigarrow u</math>, und demnach in G einen Weg <math>u \rightsquigarrow x</math> geben. Da x der Anker seiner Komponente ist, wissen wir aber auch, dass x in der reverse post-order vor u liegt (denn der Anker ist der Knoten, mit dem eine neue Komponente gestartet wird; er muss deshalb im Array <tt>ordered</tt> als erster Konten seiner Komponente gefunden worden sein). Wir unterscheiden jetzt im Schritt 1 des Algorithmus zwei Fälle:
## u wurde bei der Bestimmung der post-order vor x expandiert. Dann kann x nur dann in der reverse post-order vor u liegen (oder, einfacher ausgedrückt, x kann nur dann in der post-order hinter u liegen), wenn x im Graphen G nicht von u aus erreichbar war. Das ist aber unmöglich, weil wir ja schon wissen, dass es in G einen Weg <math>u \rightsquigarrow x</math> gibt.
## Folglich wurde u bei der Bestimmung der post-order nach x expandiert. Da x in der post-order hinter u liegt, muss u während der Expansion von x erreicht worden sein. Deshalb muss es in G auch einen Weg <math>x \rightsquigarrow u</math> geben.
#:Somit sind x und u in der selben stark zusammenhängenden Komponente. Die gleiche Überlegung gilt für x und v. Wegen der Transitivität der relation "ist erreichbar" folgt daraus, dass auch u und v in der selben Komponente liegen, also die Behauptung 2.

Die folgende Skizze illustriert, dass der Komponentengraph stets azyklisch ist. Den Komponentengraph erhält man, indem man für jede Komponente <math>C_i</math> einen Knoten erzeugt (grün), und die Knoten i und j durch eine gerichtete Kante verbindet (rot), wenn es im Originalgraphen eine Kante (u → v) mit <math>u \in C_i</math> und <math>v \in C_j</math> gibt. Es ist dann garantiert, dass es keine Kante in umgekehrter Richtung geben kann. Daraus folgt insbesondere, dass ein DAG nur triviale stark verbundene Komponenten haben kann, die aus einzelnen Knoten bestehen.

[[Image:strongly-connected-components-graph.png|400px]]

=== Anwendung: Das Erfüllbarkeitsproblem in Implikationengraphen ===

Das Erfüllbarkeitsproblem hat auf den ersten Blick nichts mit Graphen zu tun, denn es geht um Wahrheitswerte logischer Ausdrücke. Man kann logische Ausdrücke jedoch unter bestimmten Bedingungen in eine Graphendarstellung überführen und somit das ursprüngliche Problem auf ein Problem der Graphentheorie reduzieren, für das bereits ein Lösungsverfahren bekannt ist. In diesem Abschnitt wollen wir dies für die sogenannten Implikationengraphen zeigen, ein weiteres Beispiel findet sich im Kapitel [[NP-Vollständigkeit]].

==== Das Erfüllbarkeitsproblem ====

(vgl. [http://de.wikipedia.org/wiki/Erfüllbarkeitsproblem_der_Aussagenlogik WikiPedia (de)])

Das Erfüllbarkeitsproblem (SAT-Problem, von satisfiability) befasst sich mit logischen (oder Booleschen) Funktionen: Gegeben sei eine Menge <math>\{x_1, ... ,x_n\}</math> Boolscher Variablen (d.h., die <math>x_i</math> können nur die Werte True oder False annehmen), sowie eine logische Formel, in der die Variablen mit den üblichen logischen Operatoren
:<math>\neg\quad</math>: Negation ("nicht", in Python: <tt>not</tt>)
:<math>\vee\quad</math>: Disjunktion ("oder", in Python: <tt>or</tt>)
:<math>\wedge\quad</math>: Konjuktion ("und", in Python: <tt>and</tt>)
:<math>\rightarrow\quad</math>: Implikation ("wenn, dann", in Python nicht als Operator definiert)
:<math>\leftrightarrow\quad</math>: Äquivalenz ("genau dann, wenn", in Python: <tt>==</tt>)
:<math>\neq\quad</math>: exklusive Disjunktion ("entweder oder", in Python: <tt>!=</tt>)
verknüpft sind. Klammern definieren die Reihenfolge der Auswertung der Operationen. Für jede Belegung der Variablen <math>x_i</math> mit True oder False liefert die Formel den Wert der Funktion, der natürlich auch nur True oder False sein kann. Wenn Formel und Belegung gegeben sind, ist die Auswertung der Funktion ein sehr einfaches Problem: Man transformiert die Formel in einen Parse-Baum (siehe Übungsaufgabe "Taschenrechner) und wertet jeden Knoten mit Hilfe der üblichen Wertetabellen für logische Operatoren aus, die wir hier zur Erinnerung noch einmal angeben:
{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>a</math>
|width="70px"| <math>b</math>
|width="70px"| <math>a \vee b </math>
|width="70px"| <math>a \wedge b</math>
|width="70px"| <math>a \rightarrow b</math>
|width="70px"| <math>b \rightarrow a</math>
|width="70px"| <math>a \leftrightarrow b</math>
|width="70px"| <math>a \neq b</math>
|- align="center"
| 0 || 0 || 0 || 0 || 1 || 1 || 1 || 0
|- align="center"
| 0 || 1 || 1 || 0 || 1 || 0 || 0 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 0 || 1 || 0 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1 || 0
|}

Beim Erfüllbarkeitsproblem wird die Frage umgekehrt gestellt:
:Gegeben sei eine logische Funktion. Ist es möglich, dass die Funktion jemals den Wert True annimmt?
Das heisst, kann man die Variablen <math>x_i</math> so mit True oder False belegen, dass die Formel am Ende wahr ist? Im Prinzip kann man diese Frage durch erschöpfende Suche leicht beantworten, indem man die Funktion für alle <math>2^n</math> möglichen Belegungen einfach ausrechnet, aber das dauert für große n (ab ca. <math>n\ge 40</math>) viel zu lange. Erstaunlicherweise ist es aber noch niemanden gelungen, einen Algorithmus zu finden, der für beliebige logische Funktionen schneller funktioniert. Im Gegenteil wurde gezeigt, dass das Erfüllbarkeitsproblem [[NP-Vollständigkeit|NP-vollständig]] ist, so dass wahrscheinlich kein solcher Algorithmus existiert. Trotz (oder gerade wegen) seiner Schwierigkeit hat das Erfüllbarkeitsproblem viele Anwendungen gefunden, vor allem beim Testen logischer Schaltkreise ("Gibt es eine Belegung der Eingänge, so dass am Ausgang der verbotene Wert X entsteht?") und bei der Planerstellung in der künstlichen Intelligenz ("Kann man ausschließen, dass der generierte Plan Konflikte enthält?"). Es ist außerdem ein beliebtes Modellproblem für die Erforschung neuer Ideen und Algorithmen für schwierige Probleme.

==== Normalformen für logische Ausdrücke ====

Um die Beschreibung von Erfüllbarkeitsproblemen zu vereinfachen und zu vereinheitlichen, hat man verschiedene Normalformen für logische Ausdrücke eingeführt. Die wichtigste ist die Konjuktionen-Normalform (CNF - conjunctive normal form). Ein Ausdruck in Konjuktionen-Normalform ist eine UND-Verknüpfung von M Klauseln:
(CLAUSE1) <math>\wedge</math> (CLAUSE2) <math>\wedge</math> ... <math>\wedge</math> (CLAUSEM)
Jede Klausel ist wiederum ein logischer Ausdruck, der aber sehr einfach sein muss: Er darf nur noch k Variablen enthalten, die nur mit den Operatoren NICHT und ODER verknüpft werden dürfen, z.B.
CLAUSE1 := <math>x_1 \vee \neg x_3 \vee x_8</math>
Je nachdem, wie viele Variablen pro Klausel erlaubt sind, spricht man von k-CNF und entsprechend von einem k-SAT Problem. Es ist außerdem üblich, die Menge der Variablen und die Menge der negierten Variablen zusammen als Menge der Literale zu bezeichnen:
LITERALS := <math>\{x_1,...,x_n\} \cup \{\neg x_1,...,\neg x_n\}</math>
Formal definiert man die k-Konjunktionen-Normalform (k-CNF) am besten durch eine Grammatik in [http://de.wikipedia.org/wiki/Backus-Naur-Form Backus-Naur-Form]:
k_CNF ::= CLAUSE | k_CNF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\vee</math> ... <math>\vee</math> LITERAL) # genau k Literale pro Klausel
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
Beispiele:
* 3-CNF: <math>(x_1 \vee \neg x_2 \vee x_4) \wedge (x_2 \vee x_3 \vee \neg x_4) \wedge (\neg x_1 \vee x_4 \vee \neg x_5)</math>
* 2-CNF: <math>(x_1 \vee \neg x_2) \wedge (x_3 \vee x_4)</math> ...
Gesucht ist eine Belegung der Variablen mit True und False, so dass der Ausdruck den Wert True hat. Aus den Eigenschaften der UND- und ODER-Verknüpfungen folgt, dass ein Ausdruck in k-CNF genau dann True ist, wenn jede einzelne Klausel True ist. In jeder Klausel wiederum hat man k Chancen, die Klausel True zu machen, indem man eins der Literale zu True macht. Eventuell werden dadurch aber andere Klauseln wieder zu False, was die Aufgabe so schwierig macht. Die Bedeutung der k-CNF ergibt sich aus folgendem
;Satz: Jeder logische Ausdruck kann effizient nach 3-CNF transformiert werden, jedoch im allgemeinen nicht nach 2-CNF.
Man kann sich also auf Algorithmen für 3-SAT-Probleme konzentrieren, ohne dabei an Ausdrucksmächtigkeit zu verlieren.

Leider gilt der entsprechende Satz nicht für k=2: Ausdrücke in 2-CNF sind weit weniger mächtig, weil man in jeder Klausel nur noch zwei Wahlmöglichkeiten hat. Bestimmte logische Ausdrücke sind aber auch nach 2-CNF transformierbar, beispielsweise die Bedingung, dass zwei Literale u und v immer den entgegegesetzten Wert haben müssen. Dies ergibt ein Paar von ODER-Verknüpfungen:
:<math>(u \leftrightarrow \neg v) \equiv (u \vee \neg v) \wedge (\neg u \vee v)</math>
Die 2-CNF hat den Vorteil, dass es effiziente Algorithmen für das 2-SAT-Problem gibt, die wir jetzt kennenlernen wollen. Es zeigt sich, dass man Ausdrücke in 2-CNF als Graphen repräsentieren kann, indem man sie zunächst in die Implikationen-Normalform (INF für implicative normal form) überführt. Die Implikationen-Normalform besteht ebenfalls aus einer Menge von Klauseln, die durch UND-Operationen verknüpft sind, aber jede Klausel ist jetzt eine Implikation.
Die Grammatik der Implikationen-Normalform (INF) lautet:
INF ::= CLAUSE | INF <math>\wedge</math> CLAUSE
CLAUSE ::= (LITERAL <math>\rightarrow</math> LITERAL) # genau 2 Literale pro Implikation
LITERAL ::= VARIABLE | <math>\neg</math>VARIABLE
VARIABLE ::= <math>x_1</math> | ... | <math>x_n</math>
und ein gültiger Ausdruck wäre z.B.
:<math>(x_1 \to x_2) \wedge (x_2 \to \neg x_3) \wedge (x_4 \to x_3)</math>
Die Umwandlung von 2-CNF nach INF beruht auf folgender Äquivalenz, die man sich aus der obigen Wahrheitstabelle leicht herleitet:
:<math>(x \vee y) \equiv (\neg x \rightarrow y) \equiv (\neg y \rightarrow x)</math>
Aus dieser Äquivalenz folgt der
;Satz: Ein Ausdruck in 2-CNF kann nach INF transformiert werden, indem man jede Klausel <math>(x \vee y)</math> durch das Klauselpaar <math>(\neg x \rightarrow y) \wedge (\neg y \rightarrow x)</math> ersetzt.
Man beachte, dass man für jede ODER-Klausel des ursprünglichen Ausdrucks zwei Implikationen (eine für jede Richtung des "wenn, dann") einfügen muss, um die Symmetrie des Problems zu erhalten.

==== Lösung des 2-SAT-Problems mit Implikationgraphen ====

Jeder Ausdruck in INF kann als gerichteter Graph dargestellt werden:
# Für jedes Literal wird ein Knoten in den Graphen eingefügt. Es gibt also für jede Variable und für ihre Negation jeweils einen Knoten, d.h. 2n Knoten insgesamt.
# Jede Implikation ist eine gerichtete Kante.
Implikationengraphen eignen sich, um Ursache-Folge-Beziehungen oder Konflikte zwischen Aktionen auszudrücken. Beispielsweise kann man die Klausel <math>(x \rightarrow \neg y)</math> als "wenn man x tut, darf man y nicht tun" interpretieren. Ein anderes schönes Beispiel findet sich in Übung 12.

Für die Implementation eines Implikationengraphen in Python empfiehlt es sich, die Knoten geschickt zu numerieren: Ist die Variable <math>x_i</math> dem Knoten i zugeordnet, so sollte die negierte Variable <math>\neg x_i</math> dem Knoten (i+n) zugeordnet werden. Zu jedem gegebenen Knoten i findet man dann den negierten Partnerknoten j leicht durch die Formel <tt>j = (i + n ) % (2*n)</tt>.

Die Aufgabe besteht jetzt darin, folgende Fragen zu beantworten:
# Ist der durch den Implikationengraphen gegebene Ausdruck erfüllbar?
# Finde eine geeignete Belegung der Variablen, wenn der Ausduck erfüllbar ist.
Die erste Frage beantwortet man leicht, indem man die stark zusammenhängenden Komponenten des Implikationengraphen bildet. Dann gilt folgender
;Satz: Seien u und v zwei Literale, die sich in der selben stark zusammenhängenden Komponente befinden. Dann müssen u und v stets den selben Wert haben, damit der Ausdruck erfüllt sein kann.
Die Korrektheit des Satzes folgt aus der Definition der stark zusammenhängenden Komponenten: Da u und v in der selben Komponente liegen, gibt es im Implikationengraphen einen Weg <math>u \rightsquigarrow v</math> sowie einen Weg <math>v \rightsquigarrow u</math>. Wegen der Transitivität der "wenn, dann" Relation kann man die Wege zu zwei Implikationen verkürzen, die gleichzeitig gelten müssen: <math>(u \rightarrow v) \wedge (v \rightarrow u)</math> (die Verkürzung von Wegen zu direkten Kanten entspricht gerade der Bildung der transitiven Hülle für die Knoten u und v). In der obigen Wertetabelle für logische Operatoren erkennt mann, dass dies äquivalent zur Bedingung <math>(u \leftrightarrow v)</math> ist. Dies ist aber gerade die Behauptung des Satzes.

Die Erfüllbarkeit des Ausdrucks ist nun ein einfacher Spezialfall dieses Satzes.
;Korrolar: Der gegebene Ausdruck ist genau dann erfüllbar, wenn die Literale <math>x_i</math> und <math>\neg x_i</math> sich für kein i in derselben stark zusammenhängenden Komponente befinden.
Setzt man nämlich im Satz <math>u = x_i</math> und <math>v = \neg x_i</math>, und beide Knoten befinden sich in der selben Komponente, dann müsste gelten <math>x_i \leftrightarrow\neg x_i</math>, was offensichtlich ein Widerspruch ist. Damit kann der Ausdruck nicht erfüllbar sein. Umgekehrt gilt, dass der Ausdruck immer erfüllbar ist, wenn <math>x_i</math> und <math>\neg x_i</math> stets in verschiedenen Komponenten liegen, weil der folgende Algorithmus von Aspvall, Plass und Tarjan in diesem Fall stets eine gültige Belegung aller Variablen liefert:
# Bestimme die stark zusammenhängenden Komponenten und bilde den Komponentengraphen. Ordne die Knoten des Komponentengraphen (also die stark zusammenhängenden Komponenten des Originalgraphen) in topologische Sortierung an.
# Betrachte die Komponenten in der topologischen Sortierung von hinten nach vorn und weise ihnen einen Wert nach folgenden Regeln zu (zur Erinnerung: alle Literale in der selben Komponente haben den selben Wert):
#* Wenn die Komponente noch nicht betrachtet wurde, setze ihren Wert auf True, und den Wert der komplementären Komponente (derjenigen, die die negierten Literale enthält) auf False.
#* Andernfalls, gehe zur nächsten Komponente weiter.
Der Algorithmus beruht auf der Symmetrie des Implikationengraphen: Weil Kanten immer paarweise <math>(\neg u \rightarrow v) \wedge (\neg v \rightarrow u)</math> eingefügt werden, ist der Graph schiefsymmetrisch (skew symmetric): die eine Hälfte das Graphen ist die transponierte Spiegelung der anderen Hälfte. Enthält eine stark zusammenhängende Komponente <math>C_i</math> die Knoten <tt>i1, i2, ...</tt>, so gibt es stets eine komplementäre Komponente <math>C_j = \neg C_i</math>, die die komplementären Knoten <tt>j1 = (i1 + n) % (2*n), j2 = (i2 + n) % (2*n), ...</tt> enthält. Gilt <math>C_i = \neg C_i</math> für irgendein i, so ist der Ausdruck nicht erfüllbar. Den Beweis für die Korrektheit des Algorithmus findet man im [http://www.math.ucsd.edu/~sbuss/CourseWeb/Math268_2007WS/2SAT.pdf Originalartikel]. Leider funktioniert dies nicht für k-SAT-Probleme mit <math>k > 2</math>.

Will man nur die Erfüllbarkeit prüfen, vereinfacht sich der Algorithmus zu:
# Bestimme die stark zusammenhängenden Komponenten.
# Teste für alle <tt>i = 0,...,n-1</tt>, dass Knoten <tt>i</tt> und Knoten <tt>(i+n)</tt> in unterschiedlichen Komponenten liegen.
Ist der Ausdruck erfüllbar, kann man eine gültige Belegung der Variablen jetzt mit dem randomisierten Algorithmus bestimmen, den wir im Kapitel [[Randomisierte Algorithmen]] behandeln.

== Weitere wichtige Graphenalgorithmen ==

Eins der wichtigsten Einsatzgebiete für Graphen ist die Optimierung, also die Suche nach der besten Lösung für ein gegebenes Problem:
* Das interval scheduling befasst sich damit, aus einer gegebenen Menge von Aufträgen die richtigen auszuwählen und sie geschickt auf die zur Verfügung stehenden Ressourcen aufzuteilen. Damit beschäftigen wir uns im Kapitel [[Greedy-Algorithmen und Dynamische Programmierung]].
* Beim Problem des Handlungsreisenden sucht man nach der kürzesten Rundreise, die alle gegebenen Städte genau einmal besucht. Dieses Problem behandeln wir im Kapitel [[NP-Vollständigkeit]].
* Viele weitere Anwendungen können wir leider in der Vorlesung nicht mehr behandeln, z.B.
** Algorithmen für den [http://en.wikipedia.org/wiki/Maximum_flow_problem maximalen Fluss] beantworten die Frage, wie man die Durchflussmenge durch ein Netzwerk (z.B. von Ölpipelines) maximiert.
** Beim [http://en.wikipedia.org/wiki/Assignment_problem Problem der optimalen Paarung] ("matching problem" oder "assignment problem") sucht man nach einer Teilmenge der Kanten (also nach einem Teilgraphen), so dass jeder Knoten in diesem Teilgraphen höchstens den Grad 1 hat. Im neuen Graphen gruppieren die Kanten also je zwei Knoten zu einem Paar, und die Paarung soll nach jeweils anwendungsspezifischen Kriterien optimal sein. Dies benötigt man z.B. bei der optimalen Zuordnung von Gruppen, etwas beim Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot) und in der Universität (Zuordnung Studenten - Übungsgruppen).
** In Statistik und maschinellem Lernen haben in den letzten Jahren die [http://en.wikipedia.org/wiki/Graphical_model graphischen Modelle] große Bedeutung erlangt.
* usw. usf.

[[Randomisierte Algorithmen|Nächstes Thema]]