Alda - User contributions [en]

Einführung

2021-02-11T16:02:19Z

Alda: /* Zur Frage der elementaren Schritte */

== Definition von Algorithmen ==

Es gibt viele Definitionen von Algorithmen. Hier sind die Ergebnisse einer Google-Suche auf [http://www.google.de/search?hl=de&defl=en&q=define:Algorithm&sa=X&oi=glossary_definition&ct=title englisch] und auf
[http://www.google.de/search?hl=de&defl=de&q=define:Algorithmus&sa=X&oi=glossary_definition&ct=title deutsch]. Die Grundidee ist aber immer gleich:

Ein '''Algorithmus''' ist eine Problemlösung durch endlich viele elementare Schritte. Die Teile der Definition bedürfen näherer Erläuterung:

;Problemlösung: Damit ein Algorithmus ein Problem (genauer: eine Menge von gleichartigen Problemen) lösen kann, muss das Problem zunächst definiert (''spezifiziert'') werden. Die '''Spezifikation''' legt fest, ''was'' der Algorithmus erreichen soll, sagt aber nichts über das ''wie''. Die Spezifikation beschreibt somit relevante Eigenschaften des Systemzustands ''vor'' und ''nach'' der Ausführung des Algorithmus (sogenannte '''Vor-''' und '''Nachbedingungen'''), während der Algorithmus einen bestimmten ''Lösungsweg'' repräsentiert. Mit Hilfe der Spezifikation kann getestet werden, ob der Algorithmus tatsächlich eine Lösung des gestellten Problems liefert. Diese Frage untersuchen wir im Kapitel [[Korrektheit]].
;Endlich viele Schritte: Die Forderung nach endlich vielen Schritten unterstellt, dass jeder einzelne Schritt eine gewisse Zeit benötigt, also nicht unendlich schnell ausgeführt werden kann. Damit ist diese Forderung äquivalent zu der Forderung, dass der Algorithmus in endlicher Zeit zum Ergebnis kommen muss. Der Sinn einer solchen Forderung leuchtet aus praktischer Sicht unmittelbar ein. Interessant ist darüber hinaus die Frage, wie man mit möglichst wenigen Schritten, also möglichst schnell, zur Lösung kommt. Diese Frage untersuchen wir im Kapitel [[Effizienz]].
;Elementare Schritte: Im weiteren Sinne verstehen wir unter einem elementaren Schritt ein Teilproblem, für das bereits ein Algorithmus bekannt ist. Im engeren Sinne ist die Menge der elementaren Schritte durch die Hilfsmittel vorgegeben, mit denen der Algorithmus ausgeführt werden soll, also z.B. durch die Hardware oder die Programmiersprache. Wir gehen darauf im nächsten Abschnitt näher ein.

=== Zur Frage der elementaren Schritte ===

Welche Schritte als elementar angesehen werden können, hängt sehr stark vom Kontext der Aufgabe und den Hilfsmitteln zu ihrer Lösung ab. Ein interessantes Beispiel ist die Geometrie der alten Griechen, wo geometrische Probleme in der Ebene allein mit Zirkel und Lineal gelöst werden. In diesem Fall sind folgende elementare Operationen erlaubt:
* das Markieren eines Punktes (beliebig in der Ebene oder als Schnittpunkt zwischen bereits gezeichneten Linien),
* das Zeichnen einer Geraden durch zwei Punkte,
* das Zeichnen eines Kreises um einen Punkt,
* das Abgreifen des Abstands zwischen zwei Punkten mit dem Zirkel.
Auf der Basis dieser Operationen kann zum Beispiel kein Algorithmus für die Dreiteilung eines beliebigen Winkels definiert werden, während der Algorithmus für die Zweiteilung sehr einfach ist.

Eine völlig andere Menge von elementaren Operationen ergibt sich für arithmetische Berechnungen mit Hilfe des Abacus (Rechenbrett), der seit der Römerzeit in Europa weit verbreitet war. Hier werden Zahlen durch die Positionen von Perlen auf Rillen oder Drähten dargestellt und Berechnungen durch deren Verschiebung. Eine ausführliche Beschreibung der wichtigsten Abacus-Algorithmen findet sich unter [http://totton.idirect.com/abacus/ The Bead Unbaffled] von Totton Heffelfinger und Gary Flom.

Die moderne Auffassung von elementaren Operationen wird durch die Berechenbarkeitstheorie (ein Teilgebiet der theoretischen Informatik) bestimmt. Verschiedene Mathematiker (darunter die Pioniere Alan Turing, Alonso Church, Kurt Gödel, Stephen Kleene und Emil Post) haben seit den 1930er Jahren versucht, den intuitiven Begriff der Berechenbarkeit einer Funktion zu formalisieren und sind dabei zu völlig verschiedenen Lösungen gelangt (z.B. Turingmaschine, Lambda-Kalkül, μ-Rekursion und WHILE-Programm). Interessanterweise stellte sich heraus, dass diese Lösungen alle die gleiche Mächtigkeit haben: Obwohl die elementaren Operationen jeweils ganz anders definiert sind, ist die Menge der damit berechenbaren Funktionen immer gleich. Die [http://en.wikipedia.org/wiki/Church_thesis Church-Turing-These] besagt, dass es prinzipiell unmöglich ist, eine mächtigere Definition von elementaren Operationen zu finden, aber dies ist unbewiesen. Am bequemsten für die Praxis sind die [http://de.wikipedia.org/wiki/WHILE-Programm WHILE-Programme], da sie sich direkt auf die heute gebräuchliche Hardware-Architektur abbilden lassen. Die elementaren Operationen eines WHILE-Programms lauten in erweiterter Backus-Naur Notation:
P ::= x[i] = x[j] + c # Addition einer Konstanten zur Variable x[i]
| x[i] = x[j] - c # Subtraktion einer Konstanten von x[i]
| P; P # Nacheinanderausführung von zwei Anweisungen
| WHILE x[i] != 0 DO P DONE # Wiederholte Ausführung der Anweisung(en) P
# (x[i] muss sich innerhalb von P ändern, um eine Endlosschleife zu vermeiden)
wobei <tt>c</tt> eine beliebige ganzahlige Konstante (eine ausgeschriebene ganze Zahl) und <tt>x[i]</tt> die Speicherzelle <tt>i</tt> bezeichnen. Alle Speicherzellen können ganze Zahlen aufnehmen und sind anfangs mit Null belegt. Darüber hinaus wird vorausgesetzt, dass mindestens soviele Speicherzellen vorhanden sind, wie der gegebene Algorithmus benötigt, und jede Speicherzelle groß genug ist, um die größte auftretende Zahl aufzunehmen. Beide Annahmen sind in der Praxis nicht immer erfüllt.

In einem WHILE-Programm gibt es keine elementare Funktion, um die Summe von zwei Variablen zu berechnen. Diese Operation muss man bereits als Algorithmus implementieren. Der folgende Code berechnet die Summe unter der Voraussetzung, dass <tt>x[j]</tt> nicht negativ ist, indem <tt>x[j]</tt> solange dekrementiert (um 1 erniedrigt) wird, bis es den Wert 0 annimmt, und <tt>x[i]</tt> entsprechend bei jedem Schritt inkrementiert (um 1 erhöht) wird. Die alten Werte der Variablen gehen bei der Berechnung verloren:
Algorithmus: x[i] = x[i] + x[j] als WHILE-Programm (Vorbedingung: x[j] >= 0)
WHILE x[j] != 0 DO
x[i] = x[i] + 1;
x[j] = x[j] - 1
DONE
Man erkennt, dass tatsächlich nur die vier elementaren Operationen (Addition/Subtraktion einer Konstanten, Nacheinanderausführung von Anweisungen, WHILE-Schleife) vorkommen. Allerdings ist dieser Algorithmus sehr langsam. Außerdem ist die Zerlegung in Form eines WHILE-Programms (oder eines äquivalenten Formalismus der Berechenbarkeitstheorie) für unsere Zwecke zu feinkörnig: Sie würde bedeuten, dass alle Algorithmen auf einem extrem einfachen Prozessor in Assembler programmiert werden müssten. Bereits eine so einfache Operation wie die Summe von zwei Variablen erfordert vier Codezeilen!

Deshalb definiert man ''höhere Programmiersprachen'', die wichtige Algorithmen wie z.B. die arithmetischen Operationen mit ganzen Zahlen und Gleitkomma-Zahlen bereits als elementare Operationen enthalten. Weitere nicht ganz so wichtige Funktionen wie die Wurzel oder der Logarithmus werden in Programmbibliotheken angeboten, die standardmäßig mitgeliefert werden. In der Praxis betrachtet man eine Operation deshalb als elementar, wenn sie von einer typischen Programmiersprache oder einer typischen Standardbibliothek unterstützt wird. In dieser Vorlesung wählen wir die Operationen und Bibliotheken der Programmiersprache [http://www.python.org Python]. Wenn ein Algorithmus Anforderungen stellt, die nicht selbstverständlich sind, müssen sie als ''Requirements'' explizit angegeben werden. Wir werden darauf im Kapitel [[Generizität]] zurückkommen.

=== Zur Geschichte ===

{| border="0" cellspacing="0" cellpadding="5"
|-valign="top"
| Algorithmen wurden bereits im Altertum verwendet. Besonders die alten Griechen haben Pionierarbeit geleistet, z.B. auf dem Gebiet der Arithmetik (Euklidischer Algorithmus für den größten gemeinsamen Teiler von zwei Zahlen, Sieb des Eratosthenes zur Bestimmung von Primzahlen) und der Geometrie (Teilung einer Strecke oder eines Winkels nur mit Zirkel und Lineal). Der Begriff ''Algorithmus'' ist vom Namen des arabischen Gelehrten Muhammed Al Chwarizmi (ca. 783-850) abgeleitet, der in seinem Werk „Über das Rechnen mit indischen Ziffern“ (um 825) grundlegende Verfahren für das Rechnen im dekadischen Positionssystem beschrieben hat. Im 12. Jahrhundert wurde dieses Buch ins Lateinische übersetzt, und die Einleitung begann mit den Worten „Dixit Algorismi“ (Al Chwarizmi hat gesagt). Ab etwa 1200 wurden die neuen Rechenmethoden als „Algorismus de integris“ bzw. „Algorismus vulgaris“ (Rechnen mit ganzen Zahlen, d.h. Grundrechenarten und Wurzelziehen) sowie „Algorismus de minutiis“ (Bruchrechnung) zum festen Bestandteil der mathematischen Ausbildung im Rahmen der sieben freien Künste. Dabei diente der Begriff Algorithmus ursprünglich vor allem zur Abgrenzung des schriftlichen Rechnens mit indischen/arabischen Zahlen (wie wir es noch heute in der Schule lernen) vom traditionellen mechanischen Rechnen mit Abacus und römischen Zahlen, das noch bis ca. 1500 in Europa vorherrschend blieb.

Die allgemeinere Bedeutung des Wortes Algorithmus als systematische Rechenvorschrift war jedoch ebenfalls schon früh gebräuchlich. Dies zeigt zum Beispiel der Titel des Buches „Algorismus proportionum“ (Rechenkunst mit Proportionen, ca. 1350) von Nicole Oresme, wo erstmals die Rechenregeln für Potenzen mit rationalen Exponenten beschrieben werden. Durch die steigenden Anforderungen des kaufmännischen Rechnens und der Navigation verbreitete sich die algorithmische Denkweise ab etwa 1500 rasch. Der Buchdruck machte mit Werken wie Adam Ries' „Rechenung auff der linihen und federn“ (d.h. mit Abacus und mit indischen/arabischen Zahlen, zuerst 1522) die grundlegenden Rechenalgorithmen einem breiten Bevölkerungskreis bekannt. Umfangreiche gedruckte Tafelwerke, z.B. der „Canon“ von G.J. Rhaeticus (1551) mit bis zu siebenstelligen Tabellen der trigonometrischen Funktionen, erlaubten es, komplizierte Berechnungen auf einfache Schritte (Addition, Subtraktion sowie Nachschlagen in der Tabelle) zurückzuführen. Unsere heutige Verwendung des Begriffs geht wohl auf Alonso Church's Aufsatz „An Unsolvable Problem of Elementary Number Theory“ (1936) zurück, wo die Berechenbarkeit einer Funktion mit der Existenz eines terminierenden Berechnungsalgorithmus gleichgesetzt wird.
| [[Image:Al-Khwarizmi.jpg]] Al Chwarizmi-Denkmal in Teheran
|}

== Definition von Datenstrukturen ==

=== Beispiele für Datenformate ===

Der Speicher eines Computers enthält eine Folge von Zeichen aus einem gegebenen Alphabet. Bei fast allen heutigen Computern ist dies eine Folge von Bits aus dem Alphabet {0,1}. Ein '''Datenformat''' ordnet eine Bitfolge in Gruppen und gibt jeder Gruppe eine Bedeutung. Der Gruppierungsprozess kann dann hierarchisch fortgesetzt werden.

Die selben Bits können somit völlig verschiedene Bedeutungen annehmen, ja nachdem in welchem Datenformat sie sich befinden. Man betrachte z.B. die Folge von 16 Bits:
1101011001101100
Wenn wir diese Folge als eine zusammengehörende Gruppe betrachten und als positive ganze Zahl in Binärdarstellung interpretieren (unsigned integer, <tt>uint16</tt>), ergibt sich die Dezimalzahl
54892 = 1*215 + ... + 1*23 + 1*22 + 0*21 + 0*20
Interpretieren wir dieselbe Gruppe als vorzeichenbehaftete ganze Zahl in [http://de.wikipedia.org/wiki/Zweierkomplement Zweierkomplement]-Darstellung (signed integer, <tt>int16</tt>), ergibt sich eine andere Dezimalzahl: Da das linke (höchstwertige) Bit Eins ist, handelt es sich um eine negative Zahl. Das Zweierkomplement erhält man durch Negieren aller Bits und nachfolgende Addition von 1:
Zweierkomplement von 1101011001101100:
0010100110010011 + 1 = 0010100110010100
Die resultierende Dezimalzahl ist somit
-10644 = -(0*215 + ... + 0*23 + 1*22 + 0*21 + 0*20)
Alternativ können wir die Folge in zwei Gruppen zu 8 Bit gruppieren, und die Gruppen als Zeichencodes im Windows-Zeichensatz interpretieren. Wir erhalten die Zeichenkette "Öl":
11010110 01101100 = char[214] char[108] => Öl
Eine weitere Interpretation ist diejenige als 16-Bit Gleitkommazahl (<tt>float16</tt>) gemäß [http://en.wikipedia.org/wiki/IEEE_floating-point_standard IEEE Standard 754]. Dabei wird die Folge in Gruppen zu 1 Bit, 5 Bit und 10 Bit eingeteilt:
1 10101 1001101100
Die Gruppen werden als nicht-negative Binärzahlen gelesen, wobei die erste Gruppe das Vorzeichen <tt>s</tt> der Gleitkommazahl ist (0 bedeutet "+", 1 bedeutet "-"), die zweite ist ihr Exponent <tt>exp</tt> und die dritte die Mantisse <tt>m</tt>. In unserem Beispiel gilt <tt>s = 1</tt>, <tt>exp = 21</tt> und <tt>m = 620</tt>). Die Umrechnung in eine Gleitkommazahl erfolgt, gemäß IEEE Standard, nach folgender Formel: 
<tt>z = (1 - 2*s) * 2exp-15 * (1 + m * 2-10)</tt>. 
In Dezimaldarstellung ist dies <tt>-102.75</tt>.

Das analoge Beispiel für eine Folge von 32 Bits ist vielleicht realistischer, weil 32-bit Zahlen (integer und float) in der Praxis häufiger vorkommen. Wir betrachten die Bitfolge:
11111100011000100110010101101110
Als positive ganze Zahl in Binärdarstellung (unsigned integer, <tt>uint32</tt>) ergibt sich die Dezimalzahl 4234306926. Dieselben Bits als vorzeichenbehaftete ganze Zahl in Zweierkomplement-Darstellung (signed integer, <tt>int32</tt>) ergiben die Dezimalzahl -60660370. Als Zeichenfolge (vier Gruppen zu 8 Bit) bekommen wir die Zeichenkette "üben". Eine weitere mögliche Interpretation ist diejenige als Farbe im RGBA System (8 Bit pro Farbkanal, 8 Bit Transparenzwert), und wir erhalten ein halbtransparentes Rosa (Rot: 252, Grün: 98, Blau: 101, Alpha: 110). 
Eine 32-Bit Gleitkommazahl (<tt>float32</tt>) ist gemäß IEEE Standard 754 definiert durch Gruppen zu 1 Bit für das Vorzeichen, 8 Bit für den Exponenten und 23 Bit für die Mantisse, d.h:
1 11111000 11000100110010101101110
Hier gilt also <tt>s = 1</tt>, <tt>exp = 248</tt> und <tt>m = 6448494</tt>). Die Umrechnung in eine Gleitkommazahl erfolgt jetzt nach der Formel: 
<tt>z = (1 - 2*s) * 2exp-127 * (1 + m * 2-23)</tt>. 
In Dezimaldarstellung ist dies rund <tt>-4.7020653*1036</tt>.

Im Sinne einer hierarchischen Gruppierung können wir jetzt z.B. eine Datenstruktur "Farbbild" definieren, indem wir viele RGBA-Werte zu einem 2-dimensionalen Array zusammenfassen. Eine Datenstruktur "komplexe Zahl" wird durch ein geordnetes Paar von Gleitkommazahlen gebildet, eine "Meßreihe" als Liste von ganzen Zahlen oder Gleitkommawerten (je nach Art der Messung), usw.

=== Varianten der Datenstrukturdefinition ===

{| border="0" cellspacing="0" cellpadding="5"
|-valign="bottom"
| Bei den Beispielen im vorigen Abschnitt habe wir das Speicherlayout und die Bedeutung der einzelnen Bits bzw. Bit-Gruppen festgelegt. Wir bezeichnen eine auf diese Weise definierte Datenstruktur als Datenformat. Datenformate werden vor allem verwendet, um Datenstrukturen auf Festplatte oder in einer Datenbank zu speichern und Daten über ein Netzwerk auszutauschen (vgl. den Eintrag [http://de.wikipedia.org/wiki/Dateitypen Dateityp] in der WikiPedia). Aus Sicht des Betriebssystems ist ein File einfach eine Folge von Bits, deren Bedeutung aus anderen Informationen geschlossen werden muss, z.B. aus der Endung des Filenames (.jpg, .png, .xml usw.) oder aus dem mit dem File assoziierten [http://de.wikipedia.org/wiki/Internet_Media_Type MIME-Type]. Viele Fileformate beginnen zudem mit bestimmten Bitfolgen ("[http://de.wikipedia.org/wiki/Magische_Zahl_%28Informatik%29 magischen Zahlen]"), die für das betreffende Fileformat charakteristisch sind. Jedes JPEG-File beginnt z.B. mit dem Bytemuster <tt>255 216 255</tt>, jedes PNG-File mit der Folge <tt>137 80 78 71</tt>, jedes XML-File mit dem String <tt>"<?xml version="1.0" encoding="utf-8" ?></tt> (wobei Versionsnummer und Zeichensatzdefinition natürlich verschieden sein können, je nach Fileinhalt). Wann immer möglich sollte man bei der Verwendung von Datenformaten auf vorhandene Standards (wie z.B. IEEE 754 für Gleitkommazahlen oder XML für hierarchisch strukturierte Dokumente) zurückgreifen, weil sonst beim Einlesen und Interpretieren der gespeicherten Bitfolgen sehr leicht Fehler passieren.

Innerhalb einer Programmiersprache werden Datenstrukturen typischerweise nicht als Datenformate definiert, sondern durch die Verknüpfung eines Speicherlayouts mit einer Menge erlaubter Operationen auf diesen Daten. Die Interpretation ergibt sich implizit aus der Definition dieser Operationen. Verwendet man beispielsweise eine Folge von 32 Bits zusammen mit den arithmetischen Operationen für natürliche Zahlen (inklusive der zugehörigen Vor- und Nachbedingungen), ist die Interpretation als <tt>uint32</tt> dadurch gegeben. Eine Folge von Bytes mit den Operationen <tt>print</tt>, <tt>append</tt>, <tt>toLowerCase</tt>, <tt>toUpperCase</tt> usw. weist auf die Interpretation "Zeichenkette" (<tt>string</tt>). Eine solche Verknüpfung von Datenrepräsentation mit Operationen bezeichnen wir als '''(Daten-)Typ''' oder '''Klasse'''. Klassen sind für den Programmierer das wichtigste Mittel, um eigene Datenstrukturen zu definieren, und wir werden in der Vorlesung ausführlich darauf eingehen.

Die dritte Möglichkeit ist schließlich die Kombination einer Interpretation mit einer Menge erlaubter Operationen, ohne ein bestimmtes Speicherlayout oder eine konkrete Implementation der Operationen festzulegen. In diesem Fall sprechen wir von '''Abstrakten Datentypen''' (ADTs). Diese spielen beim Entwurf von anwendungsübergreifenden Programmierschnittstellen und bei der theoretischen Analyse von Algorithmen und Datenstrukturen eine wichtige Rolle. Da von den Besonderheiten einer bestimmten Implementation und eines bestimmten Computers abstrahiert wird, sind die gewonnen Erkenntnisse auf viele Anwendungen übertragbar. Konzepte, die als abstrakte Datentypen definiert sind, können je nach Kontext immer wieder anders implementiert werden, ohne dass die übergreifenden (abstrakten) Eigenschaften verloren gehen. Viele der konkreten Datenstrukturen, die wir behandeln werden, kann man zu abstrakten Datenstrukturen verallgemeinern. Dies ist eine Schlüsselaufgabe beim Entwurf wiederverwendbarer Programmbibliotheken. Wir kommen im Kapitel [[Generizität]] auf ADTs zurück.

Man kann sich die drei Möglichkeiten "Speicherlayout", "Bedeutung" und "Menge der darauf ausführbaren Operatoren" als Ecken eines Dreiecks wie in der nebenstehenden Skizze vorstellen. Definiert man zwei Ecken des Dreiecks, ist auch die dritte weitgehend (oder zumindest zu einem gewissen Grade, wie bei ADTs) festgelegt. Die drei Kanten entsprechen den drei Arten der Datenstrukturen: Legt man "Speicherlayout" und "Bedeutung" fest, erhalten wir ein Datenformat, bei "Speicherlayout" plus "Operatoren" einen Klasse bzw. einen Typ, und aus "Operatoren" plus "Bedeutung" folgt ein abstrakter Datentyp.
| [[Image:Dt dreieck.png|400px]] <center>Datenstruktur-Dreieck</center>
|}

=== Wichtige Begriffe ===

Programmiersprachen, die ausgereifte Mechanismen zur Definition von Klassen bieten, werden als ''objekt-orientiert'' bezeichnet. Sprachen heißen ''streng typisiert'', wenn der Compiler bzw. Interpreter der Sprache sicherstellt, dass auf jeder Datenstruktur nur die jeweils explizit erlaubten Operationen ausgeführt werden (jeder Versuch, eine illegale Operation auszuführen, wird hier als Fehler signalisiert). Erfolgt diese Prüfung während der Compilierung (also während der Übersetzung des Quellcodes in eine Maschinensprache), spricht man von einer ''statisch typisierten Sprache''. Wird die Prüfung hingegen während der Ausführung des Programms durchgeführt, handelt es sich um eine ''dynamisch typisierte Sprache''. Python ist eine dynamisch-typisierte, objekt-orientierte Sprache. Streng typisiert ist sie allerdings nur für die vordefinierten Klassen. Bei benutzerdefinierten Klassen gibt es (wie bei den meisten anderen Programmiersprachen auch) Möglichkeiten, die erlaubten Operationen zu umgehen. Dies sollte man allerdings nur dann tun, wenn es einen wichtigen Grund gibt. Solange man sich nämlich auf die erlaubten Operationen beschränkt, ist eine große Menge von Fehlerquellen von vornherein ausgeschlossen.

Ein bestimmter Speicherbereich, der den Anforderungen an eine Klasse genügt (wo also die Bits in entsprechender Weise gruppiert und interpretiert werden), wird als '''Objekt''' dieser Klasse oder als '''Instanz''' bezeichnet. Jede Instanz hat eine eindeutige Identität, einen ''Schlüssel''. Innerhalb eines Programms wird dafür gewöhnlich die Speicheradresse des ersten Bytes der Instanz (also der Index der ersten Speicherzelle) verwendet. Dies ist besonders effizient, weil die Speicheradresse für jedes Objekt eindeutig und leicht feststellbar ist. Ist das Objekt hingegen als Datei gespeichert, benötigt man einen expliziten Schlüssel, z.B. den Dateinamen oder die URL.

Das Bitmuster selbst bzw. die daraus folgende Interpretation wird als '''Zustand''' oder '''Wert''' der Instanz bezeichnet. Daraus folgt, dass verschiedene Instanzen einer Klasse dennoch gleiche Werte haben können. Die Menge aller legalen Werte bilden den ''Wertebereich'' der Klasse. Werden Instanzen ausschließlich mit den explizit erlaubten Operationen ihrer Klasse manipuliert, können niemals illegale Werte entstehen. Es liegt auf der Hand, dass illegale Werte schwerwiegende Programmfehler darstellen, die man auf diese Weise vermeidet. [Computerviren tun genau das Gegenteil: Sie verwenden absichtlich verbotene Operationen, um das Programm in einen illegalen, vom Angreifer gewünschten Zustand zu bringen. Dies ist möglich, weil nicht alle verbotenen Operationen automatisch als Fehler erkannt werden, siehe oben.]

Die meisten Programmiersprachen haben einen oder mehrere spezielle Typen für das Speichern von Objektschlüsseln. Die gebräuchlichsten Namen für diese Typen sind ''Zeiger'' (pointer), ''Referenz'' (reference) und ''Handle''. Wir verwenden das Wort '''Referenz'''. Ein Objekt der Klasse Referenz enthält also den Schlüssel eines anderen Objekts. Man sagt, dass die Referenz ''auf das andere Objekt verweist''. Diese Art der Indirektion ist uns heutzutage durch das Internet bestens vertraut: Jede WWW-Seite ist ein Objekt, und seine URL ist der dazugehörige Schlüssel. Hyperlinks und Lesezeichen (bookmarks) hingegen sind Referenzen, die mittels der URL auf andere Seiten verweisen.

Aus der Unterscheidung von Werten und Referenzen ergibt sich die wichtige Unterscheidung von ''Wertsemantik'' und ''Referenzsemantik''. Wird nämlich ein Objekt an eine Variable zugewiesen
x = anObject
so hängt die korrekte Verwendung der Variablen <tt>x</tt> davon ab, ob sie das Objekt in Form eines Wertes oder einer Referenz speichert. Im ersten Fall wird das Objekt selbst kopiert, und es entsteht ein neues Objekt mit neuer Identität, aber gleichem Zustand. Im anderen Fall wird nur der Schlüssel kopiert, und die Referenz verweist nach wie vor auf das ursprüngliche Objekt. Ist <tt>x</tt> ein Wert, so verändert eine Manipulation von <tt>x</tt> nur das neue Objekt (das ursprüngliche bleibt erhalten). Ist <tt>x</tt> hingegen eine Referenz, wird immer das ürsprüngliche Objekt manipuliert (denn es gibt ja keine Kopie). Ob eine Variable einen Wert oder eine Referenz enthält, wird in jeder Programmiersprache anderes festgelegt. In Python gilt
* Zahlen (Typen <tt>bool</tt>, <tt>int</tt>, und <tt>float</tt>) werden immer als Werte gespeichert und kopiert.
* Alle anderen Typen werden als Referenzen gespeichert und kopiert.
* Für alle Typen kann Wertsemantik mit Hilfe des Python-Moduls [http://docs.python.org/lib/module-copy.html copy] erzwungen werden.
Das Verständnis von Werten und Referenzen wird in der 1. Übung vertieft.

Der Entwurf von Datentypen bzw. Klassen wird uns im Laufe der Vorlesung immer wieder beschäftigen.

== Fundamentale Algorithmen ==

Einige Algorithmen werden praktisch bei jeder Klasse benötigt, unabhängig vom eigentlichem Verwendungszweck der Klasse. Es ist wichtig, diese fundamentalen Algorithmen zu kennen. Außerdem eignen sie sich gut zur Einführung der Grundprinzipien der Algorithmen-Spezifikation mittels Vor- und Nachbedingungen. Diese Bedingungen beschreiben Eigenschaften, die die Variablen des Systems ''vor'' bzw. ''nach'' der Ausführung des Algorithmus haben sollen. Damit man außerdem die Veränderungen durch den Algorithmus beschreiben kann, führt man zu jeder Variablen (z.B. <tt>x</tt>) eine Hilfsvariable (z.B. <tt>xo</tt>, sprich "x-old") ein. In den Hilfsvariablen wird der Zustand ''vor'' der Ausführung des Algorithmus gespeichert, so dass man diesen noch abfragen kann, wenn Variablen durch den Algorithmus verändert werden. Wenn der Algorithmus beispielsweise die Variable <tt>x</tt> inkrementiert (um eins erhöht), gilt die Nachbedingung <tt>x == xo + 1</tt> (darin ist <tt>x</tt> der neue, und <tt>xo</tt> der alte Wert der Variablen). Falls <tt>x</tt> hingegen nicht verändert wird, gilt <tt>x == xo</tt>. (Man beachte, dass dies in der Literatur nicht einheitlich gehandhabt wird -- einige Autoren verwenden z.B. <tt>x</tt> für den Zustand vor Ausführung des Algorithmus, und <tt>x'</tt> für denjenigen danach. Diese Syntax ist jedoch mit den meisten Programmiersprachen inkompatibel.)

Die wichtigste Gruppe von fundamentalen Funktionen sind die '''Konstruktoren''', die einen vorher unbenutzten Speicherbereich in eine Datenstruktur mit einem wohldefinierten Anfangswert transformieren. In Python haben die Konstruktoren im allgemeinen den gleichen Namen wie die dazugehörige Klasse, also z.B.
i = int() # erzeuge eine ganze Zahl mit Anfangswert 0
f = float() # erzeuge eine Gleitkommazahl mit Anfangswert 0
a = list() # erzeuge ein leeres Array
usw. (Man beachte, dass das Python-Array den Klassennamen <tt>list</tt> hat. Dies hat nichts mit verketteten Listen zu tun.) Konstruktoren ohne Argumente bezeichnet man als ''Standard-Konstruktoren'' (default constructors). Ja nach Typ gibt es meist noch weitere Konstruktoren, die Objekte mit anderen Anfangswerten erzeugen, z.B.
i = int(2) # erzeuge eine ganze Zahl mit Anfangswert 2
i = 2 # ebenso (abgekürzte Schreibweise)
f = float(1.5) # erzeuge eine Gleitkommazahl mit Anfangswert 1.5
f = 1.5 # ebenso (abgekürzte Schreibweise)
a = [i, f] # erzeuge ein Array mit Kopien der Werte von i und f
(Das Array <tt>a</tt> enthält Kopien der Werte, weil Zahlen immer mit Wertsemantik zugewiesen werden.) Die allgemeine Spezifikation eines Standard-Konstruktors lautet

<math>\begin{array}{ll}
\mathrm{Precondition: } & T \in \mathrm{Types}\\
\mathrm{Constructor: } & t = T() \\
\mathrm{Postcondition: } & t \in T
\end{array}</math>

Der Ausdruck <math>t \in T</math> besagt, dass t nach Ausführung des Konstruktors eine legale Instanz des Typs T (oder eine Referenz auf einen solche Instanz) sein muss. In Pythonsyntax kann dies folgendermassen geschrieben werden
import inspect # wir brauchen das inspect-Modul

if inspect.isclass(T): # prüfe, dass T ein Type ist
t = T()
assert isinstance(t, T)
Natürlich funktioniert der Code nur, wenn die Klasse <tt>T</tt> tatsächlich existiert und dafür ein Standardkonstruktor definiert wurde. Das Gegenstück zu Konstruktoren sind die '''Destruktoren''', die den Speicher der Datenstruktur wieder frei geben. Da Python automatisches Speichermanagment unterstützt, werden die Destruktoren automatisch aufgerufen. Wir können sie deshalb hier übergehen.

Sehr wichtig sind auch die '''Vergleichsoperatoren'''. Wir müssen dabei unterscheiden, ob auf Gleichheit der Referenzen (''identity'') oder auf Gleichkeit der Werte (''equality'') geprüft werden soll. In Python werden dazu die Operatoren <tt>is</tt> bzw. <tt>==</tt> verwendet. Die Negation erhält man durch <tt>is not</tt> bzw.
<tt>!=</tt>
a = [1, 2]
b = [1, 2]

a == b # True weil gleiche Werte
a != b # False weil Negation
a is b # False weil unterschiedliche Identität
a is not b # True weil Negation

(Beachte: beim Vergleich von Zahlen des gleichen Typs liefern <tt>is</tt> und <tt>==</tt> immer dasselbe Ergebnis.) Natürlich impliziert die Gleichheit der Schlüssel (Identität der Objekte) die Gleichheit der Werte.

Ebenso wichtig sind die '''Zuweisungen'''. Hier zeigt sich besonders der Unterschied zwischen Wert- und Referenzsemantik. Im Falle von Wertsemantik gilt

<math>\begin{array}{ll}
\mathrm{Preconditions: } & s,t \in T \\
& s \mathrm{\ is\ not\ } t \\
\mathrm{Assign\ by\ value: } & s = t \\
\mathrm{Postconditions: } & t \mathrm{\ is\ } t_o \\
& s \mathrm{\ is\ not\ } t \\
& s == t
\end{array}</math>

Das heisst, t darf sich nicht verändern, und s hat nach der Zuweisung den gleichen Wert wie t. Bei Referenzsemantik gilt sogar

<math>\begin{array}{ll}
\mathrm{Precondition: } & t \in T \\
\mathrm{Assign\ by\ reference: } & s = t \\
\mathrm{Postconditions: } & t \mathrm{\ is\ } t_o \\
& s \mathrm{\ is\ } t
\end{array}</math>

Dies entspricht dem Pythoncode
x = y
assert x is y
Die Wertsemantik muss man in Python explizit erzwingen
import copy # wir brauchen das copy-Modul

x = copy.deepcopy(y)
assert x == y
assert x is not y

Mit der Zuweisung eng verwandt ist die Funktion <tt>swap</tt>, die den Inhalt von zwei Variablen vertauscht:

<math>\begin{array}{ll}
\mathrm{Precondition: } & t \in T, s \in S \\
\mathrm{Algorithm\ swap: } & \mathrm{swap}(s, t) \\
\mathrm{Postconditions: } & t \mathrm{\ is\ } s_o \\
& s \mathrm{\ is\ } t_o
\end{array}</math>

Diese Funktion wird sich beim Sortieren als sehr nützlich erweisen, weil dort das Vertauschen von zwei Datenelementen eine Grundoperation ist. In Python kann man dies so implementieren:
t, s = s, t # swap
Dabei macht man sich zunutze, dass Python mehrere Variablen in einem einzigen Statement zuweisen kann.

[[Container|Nächstes Thema]]

Einführung

2021-02-11T16:01:52Z

Alda: /* Zur Frage der elementaren Schritte */

== Definition von Algorithmen ==

Es gibt viele Definitionen von Algorithmen. Hier sind die Ergebnisse einer Google-Suche auf [http://www.google.de/search?hl=de&defl=en&q=define:Algorithm&sa=X&oi=glossary_definition&ct=title englisch] und auf
[http://www.google.de/search?hl=de&defl=de&q=define:Algorithmus&sa=X&oi=glossary_definition&ct=title deutsch]. Die Grundidee ist aber immer gleich:

Ein '''Algorithmus''' ist eine Problemlösung durch endlich viele elementare Schritte. Die Teile der Definition bedürfen näherer Erläuterung:

;Problemlösung: Damit ein Algorithmus ein Problem (genauer: eine Menge von gleichartigen Problemen) lösen kann, muss das Problem zunächst definiert (''spezifiziert'') werden. Die '''Spezifikation''' legt fest, ''was'' der Algorithmus erreichen soll, sagt aber nichts über das ''wie''. Die Spezifikation beschreibt somit relevante Eigenschaften des Systemzustands ''vor'' und ''nach'' der Ausführung des Algorithmus (sogenannte '''Vor-''' und '''Nachbedingungen'''), während der Algorithmus einen bestimmten ''Lösungsweg'' repräsentiert. Mit Hilfe der Spezifikation kann getestet werden, ob der Algorithmus tatsächlich eine Lösung des gestellten Problems liefert. Diese Frage untersuchen wir im Kapitel [[Korrektheit]].
;Endlich viele Schritte: Die Forderung nach endlich vielen Schritten unterstellt, dass jeder einzelne Schritt eine gewisse Zeit benötigt, also nicht unendlich schnell ausgeführt werden kann. Damit ist diese Forderung äquivalent zu der Forderung, dass der Algorithmus in endlicher Zeit zum Ergebnis kommen muss. Der Sinn einer solchen Forderung leuchtet aus praktischer Sicht unmittelbar ein. Interessant ist darüber hinaus die Frage, wie man mit möglichst wenigen Schritten, also möglichst schnell, zur Lösung kommt. Diese Frage untersuchen wir im Kapitel [[Effizienz]].
;Elementare Schritte: Im weiteren Sinne verstehen wir unter einem elementaren Schritt ein Teilproblem, für das bereits ein Algorithmus bekannt ist. Im engeren Sinne ist die Menge der elementaren Schritte durch die Hilfsmittel vorgegeben, mit denen der Algorithmus ausgeführt werden soll, also z.B. durch die Hardware oder die Programmiersprache. Wir gehen darauf im nächsten Abschnitt näher ein.

=== Zur Frage der elementaren Schritte ===

Welche Schritte als elementar angesehen werden können, hängt sehr stark vom Kontext der Aufgabe und den Hilfsmitteln zu ihrer Lösung ab. Ein interessantes Beispiel ist die Geometrie der alten Griechen, wo geometrische Probleme in der Ebene allein mit Zirkel und Lineal gelöst werden. In diesem Fall sind folgende elementare Operationen erlaubt:
* das Markieren eines Punktes (beliebig in der Ebene oder als Schnittpunkt zwischen bereits gezeichneten Linien),
* das Zeichnen einer Geraden durch zwei Punkte,
* das Zeichnen eines Kreises um einen Punkt,
* das Abgreifen des Abstands zwischen zwei Punkten mit dem Zirkel.
Auf der Basis dieser Operationen kann zum Beispiel kein Algorithmus für die Dreiteilung eines beliebigen Winkels definiert werden, während der Algorithmus für die Zweiteilung sehr einfach ist.

Eine völlig andere Menge von elementaren Operationen ergibt sich für arithmetische Berechnungen mit Hilfe des Abacus (Rechenbrett), der seit der Römerzeit in Europa weit verbreitet war. Hier werden Zahlen durch die Positionen von Perlen auf Rillen oder Drähten dargestellt und Berechnungen durch deren Verschiebung. Eine ausführliche Beschreibung der wichtigsten Abacus-Algorithmen findet sich unter [http://totton.idirect.com/abacus/ The Bead Unbuffled] von Totton Heffelfinger und Gary Flom.

Die moderne Auffassung von elementaren Operationen wird durch die Berechenbarkeitstheorie (ein Teilgebiet der theoretischen Informatik) bestimmt. Verschiedene Mathematiker (darunter die Pioniere Alan Turing, Alonso Church, Kurt Gödel, Stephen Kleene und Emil Post) haben seit den 1930er Jahren versucht, den intuitiven Begriff der Berechenbarkeit einer Funktion zu formalisieren und sind dabei zu völlig verschiedenen Lösungen gelangt (z.B. Turingmaschine, Lambda-Kalkül, μ-Rekursion und WHILE-Programm). Interessanterweise stellte sich heraus, dass diese Lösungen alle die gleiche Mächtigkeit haben: Obwohl die elementaren Operationen jeweils ganz anders definiert sind, ist die Menge der damit berechenbaren Funktionen immer gleich. Die [http://en.wikipedia.org/wiki/Church_thesis Church-Turing-These] besagt, dass es prinzipiell unmöglich ist, eine mächtigere Definition von elementaren Operationen zu finden, aber dies ist unbewiesen. Am bequemsten für die Praxis sind die [http://de.wikipedia.org/wiki/WHILE-Programm WHILE-Programme], da sie sich direkt auf die heute gebräuchliche Hardware-Architektur abbilden lassen. Die elementaren Operationen eines WHILE-Programms lauten in erweiterter Backus-Naur Notation:
P ::= x[i] = x[j] + c # Addition einer Konstanten zur Variable x[i]
| x[i] = x[j] - c # Subtraktion einer Konstanten von x[i]
| P; P # Nacheinanderausführung von zwei Anweisungen
| WHILE x[i] != 0 DO P DONE # Wiederholte Ausführung der Anweisung(en) P
# (x[i] muss sich innerhalb von P ändern, um eine Endlosschleife zu vermeiden)
wobei <tt>c</tt> eine beliebige ganzahlige Konstante (eine ausgeschriebene ganze Zahl) und <tt>x[i]</tt> die Speicherzelle <tt>i</tt> bezeichnen. Alle Speicherzellen können ganze Zahlen aufnehmen und sind anfangs mit Null belegt. Darüber hinaus wird vorausgesetzt, dass mindestens soviele Speicherzellen vorhanden sind, wie der gegebene Algorithmus benötigt, und jede Speicherzelle groß genug ist, um die größte auftretende Zahl aufzunehmen. Beide Annahmen sind in der Praxis nicht immer erfüllt.

In einem WHILE-Programm gibt es keine elementare Funktion, um die Summe von zwei Variablen zu berechnen. Diese Operation muss man bereits als Algorithmus implementieren. Der folgende Code berechnet die Summe unter der Voraussetzung, dass <tt>x[j]</tt> nicht negativ ist, indem <tt>x[j]</tt> solange dekrementiert (um 1 erniedrigt) wird, bis es den Wert 0 annimmt, und <tt>x[i]</tt> entsprechend bei jedem Schritt inkrementiert (um 1 erhöht) wird. Die alten Werte der Variablen gehen bei der Berechnung verloren:
Algorithmus: x[i] = x[i] + x[j] als WHILE-Programm (Vorbedingung: x[j] >= 0)
WHILE x[j] != 0 DO
x[i] = x[i] + 1;
x[j] = x[j] - 1
DONE
Man erkennt, dass tatsächlich nur die vier elementaren Operationen (Addition/Subtraktion einer Konstanten, Nacheinanderausführung von Anweisungen, WHILE-Schleife) vorkommen. Allerdings ist dieser Algorithmus sehr langsam. Außerdem ist die Zerlegung in Form eines WHILE-Programms (oder eines äquivalenten Formalismus der Berechenbarkeitstheorie) für unsere Zwecke zu feinkörnig: Sie würde bedeuten, dass alle Algorithmen auf einem extrem einfachen Prozessor in Assembler programmiert werden müssten. Bereits eine so einfache Operation wie die Summe von zwei Variablen erfordert vier Codezeilen!

Deshalb definiert man ''höhere Programmiersprachen'', die wichtige Algorithmen wie z.B. die arithmetischen Operationen mit ganzen Zahlen und Gleitkomma-Zahlen bereits als elementare Operationen enthalten. Weitere nicht ganz so wichtige Funktionen wie die Wurzel oder der Logarithmus werden in Programmbibliotheken angeboten, die standardmäßig mitgeliefert werden. In der Praxis betrachtet man eine Operation deshalb als elementar, wenn sie von einer typischen Programmiersprache oder einer typischen Standardbibliothek unterstützt wird. In dieser Vorlesung wählen wir die Operationen und Bibliotheken der Programmiersprache [http://www.python.org Python]. Wenn ein Algorithmus Anforderungen stellt, die nicht selbstverständlich sind, müssen sie als ''Requirements'' explizit angegeben werden. Wir werden darauf im Kapitel [[Generizität]] zurückkommen.

=== Zur Geschichte ===

{| border="0" cellspacing="0" cellpadding="5"
|-valign="top"
| Algorithmen wurden bereits im Altertum verwendet. Besonders die alten Griechen haben Pionierarbeit geleistet, z.B. auf dem Gebiet der Arithmetik (Euklidischer Algorithmus für den größten gemeinsamen Teiler von zwei Zahlen, Sieb des Eratosthenes zur Bestimmung von Primzahlen) und der Geometrie (Teilung einer Strecke oder eines Winkels nur mit Zirkel und Lineal). Der Begriff ''Algorithmus'' ist vom Namen des arabischen Gelehrten Muhammed Al Chwarizmi (ca. 783-850) abgeleitet, der in seinem Werk „Über das Rechnen mit indischen Ziffern“ (um 825) grundlegende Verfahren für das Rechnen im dekadischen Positionssystem beschrieben hat. Im 12. Jahrhundert wurde dieses Buch ins Lateinische übersetzt, und die Einleitung begann mit den Worten „Dixit Algorismi“ (Al Chwarizmi hat gesagt). Ab etwa 1200 wurden die neuen Rechenmethoden als „Algorismus de integris“ bzw. „Algorismus vulgaris“ (Rechnen mit ganzen Zahlen, d.h. Grundrechenarten und Wurzelziehen) sowie „Algorismus de minutiis“ (Bruchrechnung) zum festen Bestandteil der mathematischen Ausbildung im Rahmen der sieben freien Künste. Dabei diente der Begriff Algorithmus ursprünglich vor allem zur Abgrenzung des schriftlichen Rechnens mit indischen/arabischen Zahlen (wie wir es noch heute in der Schule lernen) vom traditionellen mechanischen Rechnen mit Abacus und römischen Zahlen, das noch bis ca. 1500 in Europa vorherrschend blieb.

Die allgemeinere Bedeutung des Wortes Algorithmus als systematische Rechenvorschrift war jedoch ebenfalls schon früh gebräuchlich. Dies zeigt zum Beispiel der Titel des Buches „Algorismus proportionum“ (Rechenkunst mit Proportionen, ca. 1350) von Nicole Oresme, wo erstmals die Rechenregeln für Potenzen mit rationalen Exponenten beschrieben werden. Durch die steigenden Anforderungen des kaufmännischen Rechnens und der Navigation verbreitete sich die algorithmische Denkweise ab etwa 1500 rasch. Der Buchdruck machte mit Werken wie Adam Ries' „Rechenung auff der linihen und federn“ (d.h. mit Abacus und mit indischen/arabischen Zahlen, zuerst 1522) die grundlegenden Rechenalgorithmen einem breiten Bevölkerungskreis bekannt. Umfangreiche gedruckte Tafelwerke, z.B. der „Canon“ von G.J. Rhaeticus (1551) mit bis zu siebenstelligen Tabellen der trigonometrischen Funktionen, erlaubten es, komplizierte Berechnungen auf einfache Schritte (Addition, Subtraktion sowie Nachschlagen in der Tabelle) zurückzuführen. Unsere heutige Verwendung des Begriffs geht wohl auf Alonso Church's Aufsatz „An Unsolvable Problem of Elementary Number Theory“ (1936) zurück, wo die Berechenbarkeit einer Funktion mit der Existenz eines terminierenden Berechnungsalgorithmus gleichgesetzt wird.
| [[Image:Al-Khwarizmi.jpg]] Al Chwarizmi-Denkmal in Teheran
|}

== Definition von Datenstrukturen ==

=== Beispiele für Datenformate ===

Der Speicher eines Computers enthält eine Folge von Zeichen aus einem gegebenen Alphabet. Bei fast allen heutigen Computern ist dies eine Folge von Bits aus dem Alphabet {0,1}. Ein '''Datenformat''' ordnet eine Bitfolge in Gruppen und gibt jeder Gruppe eine Bedeutung. Der Gruppierungsprozess kann dann hierarchisch fortgesetzt werden.

Die selben Bits können somit völlig verschiedene Bedeutungen annehmen, ja nachdem in welchem Datenformat sie sich befinden. Man betrachte z.B. die Folge von 16 Bits:
1101011001101100
Wenn wir diese Folge als eine zusammengehörende Gruppe betrachten und als positive ganze Zahl in Binärdarstellung interpretieren (unsigned integer, <tt>uint16</tt>), ergibt sich die Dezimalzahl
54892 = 1*215 + ... + 1*23 + 1*22 + 0*21 + 0*20
Interpretieren wir dieselbe Gruppe als vorzeichenbehaftete ganze Zahl in [http://de.wikipedia.org/wiki/Zweierkomplement Zweierkomplement]-Darstellung (signed integer, <tt>int16</tt>), ergibt sich eine andere Dezimalzahl: Da das linke (höchstwertige) Bit Eins ist, handelt es sich um eine negative Zahl. Das Zweierkomplement erhält man durch Negieren aller Bits und nachfolgende Addition von 1:
Zweierkomplement von 1101011001101100:
0010100110010011 + 1 = 0010100110010100
Die resultierende Dezimalzahl ist somit
-10644 = -(0*215 + ... + 0*23 + 1*22 + 0*21 + 0*20)
Alternativ können wir die Folge in zwei Gruppen zu 8 Bit gruppieren, und die Gruppen als Zeichencodes im Windows-Zeichensatz interpretieren. Wir erhalten die Zeichenkette "Öl":
11010110 01101100 = char[214] char[108] => Öl
Eine weitere Interpretation ist diejenige als 16-Bit Gleitkommazahl (<tt>float16</tt>) gemäß [http://en.wikipedia.org/wiki/IEEE_floating-point_standard IEEE Standard 754]. Dabei wird die Folge in Gruppen zu 1 Bit, 5 Bit und 10 Bit eingeteilt:
1 10101 1001101100
Die Gruppen werden als nicht-negative Binärzahlen gelesen, wobei die erste Gruppe das Vorzeichen <tt>s</tt> der Gleitkommazahl ist (0 bedeutet "+", 1 bedeutet "-"), die zweite ist ihr Exponent <tt>exp</tt> und die dritte die Mantisse <tt>m</tt>. In unserem Beispiel gilt <tt>s = 1</tt>, <tt>exp = 21</tt> und <tt>m = 620</tt>). Die Umrechnung in eine Gleitkommazahl erfolgt, gemäß IEEE Standard, nach folgender Formel: 
<tt>z = (1 - 2*s) * 2exp-15 * (1 + m * 2-10)</tt>. 
In Dezimaldarstellung ist dies <tt>-102.75</tt>.

Das analoge Beispiel für eine Folge von 32 Bits ist vielleicht realistischer, weil 32-bit Zahlen (integer und float) in der Praxis häufiger vorkommen. Wir betrachten die Bitfolge:
11111100011000100110010101101110
Als positive ganze Zahl in Binärdarstellung (unsigned integer, <tt>uint32</tt>) ergibt sich die Dezimalzahl 4234306926. Dieselben Bits als vorzeichenbehaftete ganze Zahl in Zweierkomplement-Darstellung (signed integer, <tt>int32</tt>) ergiben die Dezimalzahl -60660370. Als Zeichenfolge (vier Gruppen zu 8 Bit) bekommen wir die Zeichenkette "üben". Eine weitere mögliche Interpretation ist diejenige als Farbe im RGBA System (8 Bit pro Farbkanal, 8 Bit Transparenzwert), und wir erhalten ein halbtransparentes Rosa (Rot: 252, Grün: 98, Blau: 101, Alpha: 110). 
Eine 32-Bit Gleitkommazahl (<tt>float32</tt>) ist gemäß IEEE Standard 754 definiert durch Gruppen zu 1 Bit für das Vorzeichen, 8 Bit für den Exponenten und 23 Bit für die Mantisse, d.h:
1 11111000 11000100110010101101110
Hier gilt also <tt>s = 1</tt>, <tt>exp = 248</tt> und <tt>m = 6448494</tt>). Die Umrechnung in eine Gleitkommazahl erfolgt jetzt nach der Formel: 
<tt>z = (1 - 2*s) * 2exp-127 * (1 + m * 2-23)</tt>. 
In Dezimaldarstellung ist dies rund <tt>-4.7020653*1036</tt>.

Im Sinne einer hierarchischen Gruppierung können wir jetzt z.B. eine Datenstruktur "Farbbild" definieren, indem wir viele RGBA-Werte zu einem 2-dimensionalen Array zusammenfassen. Eine Datenstruktur "komplexe Zahl" wird durch ein geordnetes Paar von Gleitkommazahlen gebildet, eine "Meßreihe" als Liste von ganzen Zahlen oder Gleitkommawerten (je nach Art der Messung), usw.

=== Varianten der Datenstrukturdefinition ===

{| border="0" cellspacing="0" cellpadding="5"
|-valign="bottom"
| Bei den Beispielen im vorigen Abschnitt habe wir das Speicherlayout und die Bedeutung der einzelnen Bits bzw. Bit-Gruppen festgelegt. Wir bezeichnen eine auf diese Weise definierte Datenstruktur als Datenformat. Datenformate werden vor allem verwendet, um Datenstrukturen auf Festplatte oder in einer Datenbank zu speichern und Daten über ein Netzwerk auszutauschen (vgl. den Eintrag [http://de.wikipedia.org/wiki/Dateitypen Dateityp] in der WikiPedia). Aus Sicht des Betriebssystems ist ein File einfach eine Folge von Bits, deren Bedeutung aus anderen Informationen geschlossen werden muss, z.B. aus der Endung des Filenames (.jpg, .png, .xml usw.) oder aus dem mit dem File assoziierten [http://de.wikipedia.org/wiki/Internet_Media_Type MIME-Type]. Viele Fileformate beginnen zudem mit bestimmten Bitfolgen ("[http://de.wikipedia.org/wiki/Magische_Zahl_%28Informatik%29 magischen Zahlen]"), die für das betreffende Fileformat charakteristisch sind. Jedes JPEG-File beginnt z.B. mit dem Bytemuster <tt>255 216 255</tt>, jedes PNG-File mit der Folge <tt>137 80 78 71</tt>, jedes XML-File mit dem String <tt>"<?xml version="1.0" encoding="utf-8" ?></tt> (wobei Versionsnummer und Zeichensatzdefinition natürlich verschieden sein können, je nach Fileinhalt). Wann immer möglich sollte man bei der Verwendung von Datenformaten auf vorhandene Standards (wie z.B. IEEE 754 für Gleitkommazahlen oder XML für hierarchisch strukturierte Dokumente) zurückgreifen, weil sonst beim Einlesen und Interpretieren der gespeicherten Bitfolgen sehr leicht Fehler passieren.

Innerhalb einer Programmiersprache werden Datenstrukturen typischerweise nicht als Datenformate definiert, sondern durch die Verknüpfung eines Speicherlayouts mit einer Menge erlaubter Operationen auf diesen Daten. Die Interpretation ergibt sich implizit aus der Definition dieser Operationen. Verwendet man beispielsweise eine Folge von 32 Bits zusammen mit den arithmetischen Operationen für natürliche Zahlen (inklusive der zugehörigen Vor- und Nachbedingungen), ist die Interpretation als <tt>uint32</tt> dadurch gegeben. Eine Folge von Bytes mit den Operationen <tt>print</tt>, <tt>append</tt>, <tt>toLowerCase</tt>, <tt>toUpperCase</tt> usw. weist auf die Interpretation "Zeichenkette" (<tt>string</tt>). Eine solche Verknüpfung von Datenrepräsentation mit Operationen bezeichnen wir als '''(Daten-)Typ''' oder '''Klasse'''. Klassen sind für den Programmierer das wichtigste Mittel, um eigene Datenstrukturen zu definieren, und wir werden in der Vorlesung ausführlich darauf eingehen.

Die dritte Möglichkeit ist schließlich die Kombination einer Interpretation mit einer Menge erlaubter Operationen, ohne ein bestimmtes Speicherlayout oder eine konkrete Implementation der Operationen festzulegen. In diesem Fall sprechen wir von '''Abstrakten Datentypen''' (ADTs). Diese spielen beim Entwurf von anwendungsübergreifenden Programmierschnittstellen und bei der theoretischen Analyse von Algorithmen und Datenstrukturen eine wichtige Rolle. Da von den Besonderheiten einer bestimmten Implementation und eines bestimmten Computers abstrahiert wird, sind die gewonnen Erkenntnisse auf viele Anwendungen übertragbar. Konzepte, die als abstrakte Datentypen definiert sind, können je nach Kontext immer wieder anders implementiert werden, ohne dass die übergreifenden (abstrakten) Eigenschaften verloren gehen. Viele der konkreten Datenstrukturen, die wir behandeln werden, kann man zu abstrakten Datenstrukturen verallgemeinern. Dies ist eine Schlüsselaufgabe beim Entwurf wiederverwendbarer Programmbibliotheken. Wir kommen im Kapitel [[Generizität]] auf ADTs zurück.

Man kann sich die drei Möglichkeiten "Speicherlayout", "Bedeutung" und "Menge der darauf ausführbaren Operatoren" als Ecken eines Dreiecks wie in der nebenstehenden Skizze vorstellen. Definiert man zwei Ecken des Dreiecks, ist auch die dritte weitgehend (oder zumindest zu einem gewissen Grade, wie bei ADTs) festgelegt. Die drei Kanten entsprechen den drei Arten der Datenstrukturen: Legt man "Speicherlayout" und "Bedeutung" fest, erhalten wir ein Datenformat, bei "Speicherlayout" plus "Operatoren" einen Klasse bzw. einen Typ, und aus "Operatoren" plus "Bedeutung" folgt ein abstrakter Datentyp.
| [[Image:Dt dreieck.png|400px]] <center>Datenstruktur-Dreieck</center>
|}

=== Wichtige Begriffe ===

Programmiersprachen, die ausgereifte Mechanismen zur Definition von Klassen bieten, werden als ''objekt-orientiert'' bezeichnet. Sprachen heißen ''streng typisiert'', wenn der Compiler bzw. Interpreter der Sprache sicherstellt, dass auf jeder Datenstruktur nur die jeweils explizit erlaubten Operationen ausgeführt werden (jeder Versuch, eine illegale Operation auszuführen, wird hier als Fehler signalisiert). Erfolgt diese Prüfung während der Compilierung (also während der Übersetzung des Quellcodes in eine Maschinensprache), spricht man von einer ''statisch typisierten Sprache''. Wird die Prüfung hingegen während der Ausführung des Programms durchgeführt, handelt es sich um eine ''dynamisch typisierte Sprache''. Python ist eine dynamisch-typisierte, objekt-orientierte Sprache. Streng typisiert ist sie allerdings nur für die vordefinierten Klassen. Bei benutzerdefinierten Klassen gibt es (wie bei den meisten anderen Programmiersprachen auch) Möglichkeiten, die erlaubten Operationen zu umgehen. Dies sollte man allerdings nur dann tun, wenn es einen wichtigen Grund gibt. Solange man sich nämlich auf die erlaubten Operationen beschränkt, ist eine große Menge von Fehlerquellen von vornherein ausgeschlossen.

Ein bestimmter Speicherbereich, der den Anforderungen an eine Klasse genügt (wo also die Bits in entsprechender Weise gruppiert und interpretiert werden), wird als '''Objekt''' dieser Klasse oder als '''Instanz''' bezeichnet. Jede Instanz hat eine eindeutige Identität, einen ''Schlüssel''. Innerhalb eines Programms wird dafür gewöhnlich die Speicheradresse des ersten Bytes der Instanz (also der Index der ersten Speicherzelle) verwendet. Dies ist besonders effizient, weil die Speicheradresse für jedes Objekt eindeutig und leicht feststellbar ist. Ist das Objekt hingegen als Datei gespeichert, benötigt man einen expliziten Schlüssel, z.B. den Dateinamen oder die URL.

Das Bitmuster selbst bzw. die daraus folgende Interpretation wird als '''Zustand''' oder '''Wert''' der Instanz bezeichnet. Daraus folgt, dass verschiedene Instanzen einer Klasse dennoch gleiche Werte haben können. Die Menge aller legalen Werte bilden den ''Wertebereich'' der Klasse. Werden Instanzen ausschließlich mit den explizit erlaubten Operationen ihrer Klasse manipuliert, können niemals illegale Werte entstehen. Es liegt auf der Hand, dass illegale Werte schwerwiegende Programmfehler darstellen, die man auf diese Weise vermeidet. [Computerviren tun genau das Gegenteil: Sie verwenden absichtlich verbotene Operationen, um das Programm in einen illegalen, vom Angreifer gewünschten Zustand zu bringen. Dies ist möglich, weil nicht alle verbotenen Operationen automatisch als Fehler erkannt werden, siehe oben.]

Die meisten Programmiersprachen haben einen oder mehrere spezielle Typen für das Speichern von Objektschlüsseln. Die gebräuchlichsten Namen für diese Typen sind ''Zeiger'' (pointer), ''Referenz'' (reference) und ''Handle''. Wir verwenden das Wort '''Referenz'''. Ein Objekt der Klasse Referenz enthält also den Schlüssel eines anderen Objekts. Man sagt, dass die Referenz ''auf das andere Objekt verweist''. Diese Art der Indirektion ist uns heutzutage durch das Internet bestens vertraut: Jede WWW-Seite ist ein Objekt, und seine URL ist der dazugehörige Schlüssel. Hyperlinks und Lesezeichen (bookmarks) hingegen sind Referenzen, die mittels der URL auf andere Seiten verweisen.

Aus der Unterscheidung von Werten und Referenzen ergibt sich die wichtige Unterscheidung von ''Wertsemantik'' und ''Referenzsemantik''. Wird nämlich ein Objekt an eine Variable zugewiesen
x = anObject
so hängt die korrekte Verwendung der Variablen <tt>x</tt> davon ab, ob sie das Objekt in Form eines Wertes oder einer Referenz speichert. Im ersten Fall wird das Objekt selbst kopiert, und es entsteht ein neues Objekt mit neuer Identität, aber gleichem Zustand. Im anderen Fall wird nur der Schlüssel kopiert, und die Referenz verweist nach wie vor auf das ursprüngliche Objekt. Ist <tt>x</tt> ein Wert, so verändert eine Manipulation von <tt>x</tt> nur das neue Objekt (das ursprüngliche bleibt erhalten). Ist <tt>x</tt> hingegen eine Referenz, wird immer das ürsprüngliche Objekt manipuliert (denn es gibt ja keine Kopie). Ob eine Variable einen Wert oder eine Referenz enthält, wird in jeder Programmiersprache anderes festgelegt. In Python gilt
* Zahlen (Typen <tt>bool</tt>, <tt>int</tt>, und <tt>float</tt>) werden immer als Werte gespeichert und kopiert.
* Alle anderen Typen werden als Referenzen gespeichert und kopiert.
* Für alle Typen kann Wertsemantik mit Hilfe des Python-Moduls [http://docs.python.org/lib/module-copy.html copy] erzwungen werden.
Das Verständnis von Werten und Referenzen wird in der 1. Übung vertieft.

Der Entwurf von Datentypen bzw. Klassen wird uns im Laufe der Vorlesung immer wieder beschäftigen.

== Fundamentale Algorithmen ==

Einige Algorithmen werden praktisch bei jeder Klasse benötigt, unabhängig vom eigentlichem Verwendungszweck der Klasse. Es ist wichtig, diese fundamentalen Algorithmen zu kennen. Außerdem eignen sie sich gut zur Einführung der Grundprinzipien der Algorithmen-Spezifikation mittels Vor- und Nachbedingungen. Diese Bedingungen beschreiben Eigenschaften, die die Variablen des Systems ''vor'' bzw. ''nach'' der Ausführung des Algorithmus haben sollen. Damit man außerdem die Veränderungen durch den Algorithmus beschreiben kann, führt man zu jeder Variablen (z.B. <tt>x</tt>) eine Hilfsvariable (z.B. <tt>xo</tt>, sprich "x-old") ein. In den Hilfsvariablen wird der Zustand ''vor'' der Ausführung des Algorithmus gespeichert, so dass man diesen noch abfragen kann, wenn Variablen durch den Algorithmus verändert werden. Wenn der Algorithmus beispielsweise die Variable <tt>x</tt> inkrementiert (um eins erhöht), gilt die Nachbedingung <tt>x == xo + 1</tt> (darin ist <tt>x</tt> der neue, und <tt>xo</tt> der alte Wert der Variablen). Falls <tt>x</tt> hingegen nicht verändert wird, gilt <tt>x == xo</tt>. (Man beachte, dass dies in der Literatur nicht einheitlich gehandhabt wird -- einige Autoren verwenden z.B. <tt>x</tt> für den Zustand vor Ausführung des Algorithmus, und <tt>x'</tt> für denjenigen danach. Diese Syntax ist jedoch mit den meisten Programmiersprachen inkompatibel.)

Die wichtigste Gruppe von fundamentalen Funktionen sind die '''Konstruktoren''', die einen vorher unbenutzten Speicherbereich in eine Datenstruktur mit einem wohldefinierten Anfangswert transformieren. In Python haben die Konstruktoren im allgemeinen den gleichen Namen wie die dazugehörige Klasse, also z.B.
i = int() # erzeuge eine ganze Zahl mit Anfangswert 0
f = float() # erzeuge eine Gleitkommazahl mit Anfangswert 0
a = list() # erzeuge ein leeres Array
usw. (Man beachte, dass das Python-Array den Klassennamen <tt>list</tt> hat. Dies hat nichts mit verketteten Listen zu tun.) Konstruktoren ohne Argumente bezeichnet man als ''Standard-Konstruktoren'' (default constructors). Ja nach Typ gibt es meist noch weitere Konstruktoren, die Objekte mit anderen Anfangswerten erzeugen, z.B.
i = int(2) # erzeuge eine ganze Zahl mit Anfangswert 2
i = 2 # ebenso (abgekürzte Schreibweise)
f = float(1.5) # erzeuge eine Gleitkommazahl mit Anfangswert 1.5
f = 1.5 # ebenso (abgekürzte Schreibweise)
a = [i, f] # erzeuge ein Array mit Kopien der Werte von i und f
(Das Array <tt>a</tt> enthält Kopien der Werte, weil Zahlen immer mit Wertsemantik zugewiesen werden.) Die allgemeine Spezifikation eines Standard-Konstruktors lautet

<math>\begin{array}{ll}
\mathrm{Precondition: } & T \in \mathrm{Types}\\
\mathrm{Constructor: } & t = T() \\
\mathrm{Postcondition: } & t \in T
\end{array}</math>

Der Ausdruck <math>t \in T</math> besagt, dass t nach Ausführung des Konstruktors eine legale Instanz des Typs T (oder eine Referenz auf einen solche Instanz) sein muss. In Pythonsyntax kann dies folgendermassen geschrieben werden
import inspect # wir brauchen das inspect-Modul

if inspect.isclass(T): # prüfe, dass T ein Type ist
t = T()
assert isinstance(t, T)
Natürlich funktioniert der Code nur, wenn die Klasse <tt>T</tt> tatsächlich existiert und dafür ein Standardkonstruktor definiert wurde. Das Gegenstück zu Konstruktoren sind die '''Destruktoren''', die den Speicher der Datenstruktur wieder frei geben. Da Python automatisches Speichermanagment unterstützt, werden die Destruktoren automatisch aufgerufen. Wir können sie deshalb hier übergehen.

Sehr wichtig sind auch die '''Vergleichsoperatoren'''. Wir müssen dabei unterscheiden, ob auf Gleichheit der Referenzen (''identity'') oder auf Gleichkeit der Werte (''equality'') geprüft werden soll. In Python werden dazu die Operatoren <tt>is</tt> bzw. <tt>==</tt> verwendet. Die Negation erhält man durch <tt>is not</tt> bzw.
<tt>!=</tt>
a = [1, 2]
b = [1, 2]

a == b # True weil gleiche Werte
a != b # False weil Negation
a is b # False weil unterschiedliche Identität
a is not b # True weil Negation

(Beachte: beim Vergleich von Zahlen des gleichen Typs liefern <tt>is</tt> und <tt>==</tt> immer dasselbe Ergebnis.) Natürlich impliziert die Gleichheit der Schlüssel (Identität der Objekte) die Gleichheit der Werte.

Ebenso wichtig sind die '''Zuweisungen'''. Hier zeigt sich besonders der Unterschied zwischen Wert- und Referenzsemantik. Im Falle von Wertsemantik gilt

<math>\begin{array}{ll}
\mathrm{Preconditions: } & s,t \in T \\
& s \mathrm{\ is\ not\ } t \\
\mathrm{Assign\ by\ value: } & s = t \\
\mathrm{Postconditions: } & t \mathrm{\ is\ } t_o \\
& s \mathrm{\ is\ not\ } t \\
& s == t
\end{array}</math>

Das heisst, t darf sich nicht verändern, und s hat nach der Zuweisung den gleichen Wert wie t. Bei Referenzsemantik gilt sogar

<math>\begin{array}{ll}
\mathrm{Precondition: } & t \in T \\
\mathrm{Assign\ by\ reference: } & s = t \\
\mathrm{Postconditions: } & t \mathrm{\ is\ } t_o \\
& s \mathrm{\ is\ } t
\end{array}</math>

Dies entspricht dem Pythoncode
x = y
assert x is y
Die Wertsemantik muss man in Python explizit erzwingen
import copy # wir brauchen das copy-Modul

x = copy.deepcopy(y)
assert x == y
assert x is not y

Mit der Zuweisung eng verwandt ist die Funktion <tt>swap</tt>, die den Inhalt von zwei Variablen vertauscht:

<math>\begin{array}{ll}
\mathrm{Precondition: } & t \in T, s \in S \\
\mathrm{Algorithm\ swap: } & \mathrm{swap}(s, t) \\
\mathrm{Postconditions: } & t \mathrm{\ is\ } s_o \\
& s \mathrm{\ is\ } t_o
\end{array}</math>

Diese Funktion wird sich beim Sortieren als sehr nützlich erweisen, weil dort das Vertauschen von zwei Datenelementen eine Grundoperation ist. In Python kann man dies so implementieren:
t, s = s, t # swap
Dabei macht man sich zunutze, dass Python mehrere Variablen in einem einzigen Statement zuweisen kann.

[[Container|Nächstes Thema]]

Main Page

2020-10-23T11:21:02Z

Alda: /* Gliederung der Vorlesung */

== Vorlesung Algorithmen und Datenstrukturen ==

apl. Prof. Dr. Ullrich Köthe, Universität Heidelberg, Sommersemester 2020

Die Vorlesung findet '''dienstags''' um 14:15 Uhr und '''donnerstags''' um 16:15 Uhr online auf Discord und Twitch statt. Die Links haben in Müsli angemeldete Teilnehmer per Email erhalten.

=== Klausur und Nachprüfung ===

Der Termin der '''Abschlussklausur''' steht noch nicht fest.




=== Übungsbetrieb ===

* Die Übungsgruppen werden über [https://muesli.mathi.uni-heidelberg.de/lecture/view/1171 MÜSLI] verwaltet.
* Übungsblätter werden auf [https://moodle.uni-heidelberg.de/course/view.php?id=2239 Moodle] veröffentlicht.

=== 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 ===
(Termine werden nach und nach aktualisiert)

# [[Einführung]] (21. und 23.4.2020)
#* Definition von Algorithmen und Datenstrukturen, Geschichte
#* Fundamentale Algorithmen: Konstruktoren, Kopierfunktionen, swap.
#* Fundamentale Datenstrukturen: Zahlen, Container, Handles
#* Python-Grundlagen

# [[Container]] (28.4.2020)
#* Abstrakte Datentypen und algebraische Spezifikation
#* Grundlegende Container: Array, Stack, Queue, assoziatives Array

# [[Sortieren]] (some day in 2020)
#* Spezifikation des Sortierproblems
#* Selection Sort und Insertion Sort
#* Merge Sort
#* Quick Sort und seine Varianten
#* Anzahl der benötigten Vergleiche

# [[Korrektheit]] (29.4. und 6.5.2014 -- ab hier altes Datum)
#* 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]] (8. und 13.5.2014)
#* 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]] (15. und 20.5.2014)
#* 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]] (22.5.2014)
#* Permutationen
#* Sortieren als Suchproblem
#* Bucket Prinzip, Bucket Sort

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

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

# [[Hashing und Hashtabellen]] (5. und 10.6.2014)
#* 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]] (12.6.2014)
#* Typen der Rekursion und ihre Umwandlung in Iteration
#* Auflösung rekursiver Formeln mittels Master-Methode und Substitutionsmethode

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

# [[Graphen und Graphenalgorithmen]] (24.6. bis 10.7.2014)
#* 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 15.7.2014)
#* 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.2014)
#* 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]] (22.7.2014)
#* die Klassen P und NP
#* NP-Vollständigkeit und Problemreduktion

# Wiederholung (24.7.2014)

== Übungsaufgaben ==

(im PDF Format). Die Abgabe erfolgt am angegebenen Tag bis 14:00 Uhr per Email an den jeweiligen Übungsgruppenleiter. Bei verspäteter Abgabe bis zu drei Tagen werden noch 50% der erreichten Punkte angerechnet. Danach wird die Musterlösung freigeschaltet.

Die Übungsaufgaben sind zur Zeit nicht freigeschaltet.



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

NP-Vollständigkeit

2020-07-21T22:40:52Z

Alda: /* Systematisches Erzeugen aller Permutationen */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann mit dem Algorithmus von Pandita (Indien, 1325-1400) -- dem (mehrmals wiederentdeckten) Standardalgorithmus für diese Aufgabe -- implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i+1] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden.
: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

=== k-SAT, k=2 in pol. Zeit lösbar ===

==== Alg. 1 ====
(f. bei k) (nur für k=2 effizient) '''Randomisiert'''
* (0) initialisiere <math>x_i</math> beliebig
* (1) wiederhole <math>T_{max}</math> - mal
** (a) wenn das aktuelle x den Ausdruck erfüllt: return x (x=[<math> x_1</math>, ... , <math>x_N</math>])
** (b) wähle zufällig eine Klausel, die nicht erfüllt ist
** (c) wähle in dieser Klausel zufällig eine der k Variablen und invertiere sie => Klausel ist jetzt erfüllt
::: (andere können jetzt false geworden sein)
::: (<math>x_1 \or x_2 ) \and ( x_1 \or \lnot x_2 )</math>      <math> x_1 = 0, x_2 = 0,</math>      <math> x_2</math> auf 1 => 1. Klausel wahr, 2. falsch
* (2) return "keine Lösung gefunden"

Nach wie vielen Iterationen wird im Mittel eine Lösung gefunden?
* Ausdruck unerfüllbar => Endlosschleife, Timeout nach <math>T_{max}</math> Iterationen
* Ausrduck erfüllbar:
** falls k<math>\geq</math>3: nach <math>O((\frac{2(k-1)}{k})^N)</math> Iterationen wird Lösung gefunden
** k=3: <math>O((\frac{4}{3})^N)</math> exponentielle Zeit, wie zu erwarten für NP-vollständiges Problem
** k=2: <math>O(N^2)</math> Iterationen bis Lösung

Beweis: Algorithmus entspricht im Wesentlichen dem '''Random Walk'''
: Sei <math>x^*</math> die korrekte Lösung und x die aktuelle Belegung
: RW: Stuhl i <math>\mathrel{\hat=}</math> i Variablen zwischen <math>x^*</math> und x stimmen überein => Ziel: erreiche Stuhl N
* (c):
** Fall 1: beide Variablen falsch => egal welche wir invertieren, bewegen wir uns von Stuhl i zu i+1
** Fall 2: eine Variable ist falsch:
*** mit Wahrscheinlichkeit 1/2 wählen wir diese und gehen von i nach i+1
*** mit Wahrscheinlichkeit 1/2 wählen wir die andere und gehen von i nach i-1

schlechtester Fall: Es existiert keine Lösung <math>x^*</math> und wir haben immer Fall 2
: =>RW braucht <math>O(N^2 - i^2)</math> Schritte zum Stuhl N <math>\mathrel{\hat=} O(N^2)</math> falls i anfangs zufällig ist

==== Alg. 2 (det. Alg. für k=2 mittels SZK in gerichtetem Graphen) ====
: geg.: Ausdruck 2-CNF
* (1) wandle nach INF: ersetze jede Klausel <math>(x_i \or x_j)</math> durch <math>(\lnot x_i \Rightarrow x_j) \and (\lnot x_j \Rightarrow x_i)</math>
: (entsprechend, wenn in Originalklausel <math>\lnot</math> vorkommen)
* (2) repräsentiere den Ausdruck als Graph:
** (a) 2 Knoten pro Var:<math>v_i \mathrel{\hat=} x_i , v_{i+N} \mathrel{\hat=} \lnot x_i </math>
** (b) Verbindung für jede Implikation durch korrespondierenden Knoten durch gerichtete Kante

Bsp.:
<math>C_1 \and C_2 \Leftrightarrow (\lnot x_1 \Rightarrow x_2 ) \and (\lnot x_2 \Rightarrow x_1) \and (x_2 \Rightarrow x_3) \and (\lnot x_3 \Rightarrow \lnot x_2)</math>

* (3) Prüfe ob der Ausdruck erfüllbar ist. Bilde SZK des Graphen
: '''Satz''': Ausdruck erfüllbar <math>\Leftrightarrow \forall</math>i: <math> v_i</math> und <math>v_{i+N}</math> sind in verschiedenen Komponenten

Beweis: in jeder SZK gilt: <math>u,v \in SZK: \exists u \rightsquigarrow v und v \rightsquigarrow u</math>
: Kanten <math>\to</math> Implikationen, Implikationen sind transitiv
: <math>\Rightarrow u \rightsquigarrow v \mathrel{\hat=} u \to v </math>           <math>\to u \leftrightarrow v</math>   bzw.   u == v
:: <math> v \rightsquigarrow u \mathrel{\hat=} v \to u </math>
: <math>\Rightarrow</math> alle Knoten in einer SZK haben den gleichen Wahrheitswert true oder false
: aber <math>v_i</math> und <math>v_{i+N} \mathrel{\hat=} x_i</math> und <math>\lnot x_i</math> haben immer verschiedene Werte
: <math>\Rightarrow v_i</math> und <math>v_{i+N}</math> dürfen nicht in selber SZK sein, andernfalls fordert der Graph <math>x_i == \lnot x_i</math>, was unmöglich ist.

* (4) Bilde den Komponentengraphen <math>\to</math> azyklisch (zu jedem Knoten existiert Komplementärknoten mit negierter Variable)[jede SZK in je 1 Knoten kontrahieren]
** (b) bestehende topologische Sortierung
** (c) gehe in topologischer Sortierung von hinten nach vorne
*** (I) wenn aktueller Knoten noch keinen Wert hat: setze ihn auf true und Komplementoren false
*** (II) sonst: überspringe Knoten

Beweis, dass ein Problem aus NP auch NP-vollständig ist
* Möglichkeit 1: z.B. 3-SAT (Satz von Cook): mühsam, aber mindestens für ein Problem unbermeidbar (für erstes)
* Möglichkeit 2: zeige dass jedes Problem vom Typ A in eines von Typ B umwandelbar (in pol. Zeit)
** <math>\Rightarrow</math> Problem Type B nicht einfacher als Typ A
** falls Typ A NP-vollständig <math>\Rightarrow</math> Typ B auch

==== Anwendung auf TSP ====
3-SAT <math>\le</math> Hamiltonzyklus im gerichteten Graph <math>\le</math> Hamiltonzyklus im ungerichteten Graph <math>\le</math> TSP im gerwichteten ungerichteten Graph

NP-Vollständigkeit

2020-07-21T22:40:17Z

Alda: /* Systematisches Erzeugen aller Permutationen */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann mit dem Algorithmus von Pandita (Indien, 1325-1400) -- dem (mehrmals wiederentdeckten) Standardalgorithmus für diese Aufgabe -- implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden.
: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

=== k-SAT, k=2 in pol. Zeit lösbar ===

==== Alg. 1 ====
(f. bei k) (nur für k=2 effizient) '''Randomisiert'''
* (0) initialisiere <math>x_i</math> beliebig
* (1) wiederhole <math>T_{max}</math> - mal
** (a) wenn das aktuelle x den Ausdruck erfüllt: return x (x=[<math> x_1</math>, ... , <math>x_N</math>])
** (b) wähle zufällig eine Klausel, die nicht erfüllt ist
** (c) wähle in dieser Klausel zufällig eine der k Variablen und invertiere sie => Klausel ist jetzt erfüllt
::: (andere können jetzt false geworden sein)
::: (<math>x_1 \or x_2 ) \and ( x_1 \or \lnot x_2 )</math>      <math> x_1 = 0, x_2 = 0,</math>      <math> x_2</math> auf 1 => 1. Klausel wahr, 2. falsch
* (2) return "keine Lösung gefunden"

Nach wie vielen Iterationen wird im Mittel eine Lösung gefunden?
* Ausdruck unerfüllbar => Endlosschleife, Timeout nach <math>T_{max}</math> Iterationen
* Ausrduck erfüllbar:
** falls k<math>\geq</math>3: nach <math>O((\frac{2(k-1)}{k})^N)</math> Iterationen wird Lösung gefunden
** k=3: <math>O((\frac{4}{3})^N)</math> exponentielle Zeit, wie zu erwarten für NP-vollständiges Problem
** k=2: <math>O(N^2)</math> Iterationen bis Lösung

Beweis: Algorithmus entspricht im Wesentlichen dem '''Random Walk'''
: Sei <math>x^*</math> die korrekte Lösung und x die aktuelle Belegung
: RW: Stuhl i <math>\mathrel{\hat=}</math> i Variablen zwischen <math>x^*</math> und x stimmen überein => Ziel: erreiche Stuhl N
* (c):
** Fall 1: beide Variablen falsch => egal welche wir invertieren, bewegen wir uns von Stuhl i zu i+1
** Fall 2: eine Variable ist falsch:
*** mit Wahrscheinlichkeit 1/2 wählen wir diese und gehen von i nach i+1
*** mit Wahrscheinlichkeit 1/2 wählen wir die andere und gehen von i nach i-1

schlechtester Fall: Es existiert keine Lösung <math>x^*</math> und wir haben immer Fall 2
: =>RW braucht <math>O(N^2 - i^2)</math> Schritte zum Stuhl N <math>\mathrel{\hat=} O(N^2)</math> falls i anfangs zufällig ist

==== Alg. 2 (det. Alg. für k=2 mittels SZK in gerichtetem Graphen) ====
: geg.: Ausdruck 2-CNF
* (1) wandle nach INF: ersetze jede Klausel <math>(x_i \or x_j)</math> durch <math>(\lnot x_i \Rightarrow x_j) \and (\lnot x_j \Rightarrow x_i)</math>
: (entsprechend, wenn in Originalklausel <math>\lnot</math> vorkommen)
* (2) repräsentiere den Ausdruck als Graph:
** (a) 2 Knoten pro Var:<math>v_i \mathrel{\hat=} x_i , v_{i+N} \mathrel{\hat=} \lnot x_i </math>
** (b) Verbindung für jede Implikation durch korrespondierenden Knoten durch gerichtete Kante

Bsp.:
<math>C_1 \and C_2 \Leftrightarrow (\lnot x_1 \Rightarrow x_2 ) \and (\lnot x_2 \Rightarrow x_1) \and (x_2 \Rightarrow x_3) \and (\lnot x_3 \Rightarrow \lnot x_2)</math>

* (3) Prüfe ob der Ausdruck erfüllbar ist. Bilde SZK des Graphen
: '''Satz''': Ausdruck erfüllbar <math>\Leftrightarrow \forall</math>i: <math> v_i</math> und <math>v_{i+N}</math> sind in verschiedenen Komponenten

Beweis: in jeder SZK gilt: <math>u,v \in SZK: \exists u \rightsquigarrow v und v \rightsquigarrow u</math>
: Kanten <math>\to</math> Implikationen, Implikationen sind transitiv
: <math>\Rightarrow u \rightsquigarrow v \mathrel{\hat=} u \to v </math>           <math>\to u \leftrightarrow v</math>   bzw.   u == v
:: <math> v \rightsquigarrow u \mathrel{\hat=} v \to u </math>
: <math>\Rightarrow</math> alle Knoten in einer SZK haben den gleichen Wahrheitswert true oder false
: aber <math>v_i</math> und <math>v_{i+N} \mathrel{\hat=} x_i</math> und <math>\lnot x_i</math> haben immer verschiedene Werte
: <math>\Rightarrow v_i</math> und <math>v_{i+N}</math> dürfen nicht in selber SZK sein, andernfalls fordert der Graph <math>x_i == \lnot x_i</math>, was unmöglich ist.

* (4) Bilde den Komponentengraphen <math>\to</math> azyklisch (zu jedem Knoten existiert Komplementärknoten mit negierter Variable)[jede SZK in je 1 Knoten kontrahieren]
** (b) bestehende topologische Sortierung
** (c) gehe in topologischer Sortierung von hinten nach vorne
*** (I) wenn aktueller Knoten noch keinen Wert hat: setze ihn auf true und Komplementoren false
*** (II) sonst: überspringe Knoten

Beweis, dass ein Problem aus NP auch NP-vollständig ist
* Möglichkeit 1: z.B. 3-SAT (Satz von Cook): mühsam, aber mindestens für ein Problem unbermeidbar (für erstes)
* Möglichkeit 2: zeige dass jedes Problem vom Typ A in eines von Typ B umwandelbar (in pol. Zeit)
** <math>\Rightarrow</math> Problem Type B nicht einfacher als Typ A
** falls Typ A NP-vollständig <math>\Rightarrow</math> Typ B auch

==== Anwendung auf TSP ====
3-SAT <math>\le</math> Hamiltonzyklus im gerichteten Graph <math>\le</math> Hamiltonzyklus im ungerichteten Graph <math>\le</math> TSP im gerwichteten ungerichteten Graph

NP-Vollständigkeit

2020-07-21T22:37:26Z

Alda: /* Systematisches Erzeugen aller Permutationen */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann mit dem Algorithmus von Pandit (Indien, 1325-1400) -- dem (mehrmals wiederentdeckten) Standardalgorithmus für diese Aufgabe -- implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden.
: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

=== k-SAT, k=2 in pol. Zeit lösbar ===

==== Alg. 1 ====
(f. bei k) (nur für k=2 effizient) '''Randomisiert'''
* (0) initialisiere <math>x_i</math> beliebig
* (1) wiederhole <math>T_{max}</math> - mal
** (a) wenn das aktuelle x den Ausdruck erfüllt: return x (x=[<math> x_1</math>, ... , <math>x_N</math>])
** (b) wähle zufällig eine Klausel, die nicht erfüllt ist
** (c) wähle in dieser Klausel zufällig eine der k Variablen und invertiere sie => Klausel ist jetzt erfüllt
::: (andere können jetzt false geworden sein)
::: (<math>x_1 \or x_2 ) \and ( x_1 \or \lnot x_2 )</math>      <math> x_1 = 0, x_2 = 0,</math>      <math> x_2</math> auf 1 => 1. Klausel wahr, 2. falsch
* (2) return "keine Lösung gefunden"

Nach wie vielen Iterationen wird im Mittel eine Lösung gefunden?
* Ausdruck unerfüllbar => Endlosschleife, Timeout nach <math>T_{max}</math> Iterationen
* Ausrduck erfüllbar:
** falls k<math>\geq</math>3: nach <math>O((\frac{2(k-1)}{k})^N)</math> Iterationen wird Lösung gefunden
** k=3: <math>O((\frac{4}{3})^N)</math> exponentielle Zeit, wie zu erwarten für NP-vollständiges Problem
** k=2: <math>O(N^2)</math> Iterationen bis Lösung

Beweis: Algorithmus entspricht im Wesentlichen dem '''Random Walk'''
: Sei <math>x^*</math> die korrekte Lösung und x die aktuelle Belegung
: RW: Stuhl i <math>\mathrel{\hat=}</math> i Variablen zwischen <math>x^*</math> und x stimmen überein => Ziel: erreiche Stuhl N
* (c):
** Fall 1: beide Variablen falsch => egal welche wir invertieren, bewegen wir uns von Stuhl i zu i+1
** Fall 2: eine Variable ist falsch:
*** mit Wahrscheinlichkeit 1/2 wählen wir diese und gehen von i nach i+1
*** mit Wahrscheinlichkeit 1/2 wählen wir die andere und gehen von i nach i-1

schlechtester Fall: Es existiert keine Lösung <math>x^*</math> und wir haben immer Fall 2
: =>RW braucht <math>O(N^2 - i^2)</math> Schritte zum Stuhl N <math>\mathrel{\hat=} O(N^2)</math> falls i anfangs zufällig ist

==== Alg. 2 (det. Alg. für k=2 mittels SZK in gerichtetem Graphen) ====
: geg.: Ausdruck 2-CNF
* (1) wandle nach INF: ersetze jede Klausel <math>(x_i \or x_j)</math> durch <math>(\lnot x_i \Rightarrow x_j) \and (\lnot x_j \Rightarrow x_i)</math>
: (entsprechend, wenn in Originalklausel <math>\lnot</math> vorkommen)
* (2) repräsentiere den Ausdruck als Graph:
** (a) 2 Knoten pro Var:<math>v_i \mathrel{\hat=} x_i , v_{i+N} \mathrel{\hat=} \lnot x_i </math>
** (b) Verbindung für jede Implikation durch korrespondierenden Knoten durch gerichtete Kante

Bsp.:
<math>C_1 \and C_2 \Leftrightarrow (\lnot x_1 \Rightarrow x_2 ) \and (\lnot x_2 \Rightarrow x_1) \and (x_2 \Rightarrow x_3) \and (\lnot x_3 \Rightarrow \lnot x_2)</math>

* (3) Prüfe ob der Ausdruck erfüllbar ist. Bilde SZK des Graphen
: '''Satz''': Ausdruck erfüllbar <math>\Leftrightarrow \forall</math>i: <math> v_i</math> und <math>v_{i+N}</math> sind in verschiedenen Komponenten

Beweis: in jeder SZK gilt: <math>u,v \in SZK: \exists u \rightsquigarrow v und v \rightsquigarrow u</math>
: Kanten <math>\to</math> Implikationen, Implikationen sind transitiv
: <math>\Rightarrow u \rightsquigarrow v \mathrel{\hat=} u \to v </math>           <math>\to u \leftrightarrow v</math>   bzw.   u == v
:: <math> v \rightsquigarrow u \mathrel{\hat=} v \to u </math>
: <math>\Rightarrow</math> alle Knoten in einer SZK haben den gleichen Wahrheitswert true oder false
: aber <math>v_i</math> und <math>v_{i+N} \mathrel{\hat=} x_i</math> und <math>\lnot x_i</math> haben immer verschiedene Werte
: <math>\Rightarrow v_i</math> und <math>v_{i+N}</math> dürfen nicht in selber SZK sein, andernfalls fordert der Graph <math>x_i == \lnot x_i</math>, was unmöglich ist.

* (4) Bilde den Komponentengraphen <math>\to</math> azyklisch (zu jedem Knoten existiert Komplementärknoten mit negierter Variable)[jede SZK in je 1 Knoten kontrahieren]
** (b) bestehende topologische Sortierung
** (c) gehe in topologischer Sortierung von hinten nach vorne
*** (I) wenn aktueller Knoten noch keinen Wert hat: setze ihn auf true und Komplementoren false
*** (II) sonst: überspringe Knoten

Beweis, dass ein Problem aus NP auch NP-vollständig ist
* Möglichkeit 1: z.B. 3-SAT (Satz von Cook): mühsam, aber mindestens für ein Problem unbermeidbar (für erstes)
* Möglichkeit 2: zeige dass jedes Problem vom Typ A in eines von Typ B umwandelbar (in pol. Zeit)
** <math>\Rightarrow</math> Problem Type B nicht einfacher als Typ A
** falls Typ A NP-vollständig <math>\Rightarrow</math> Typ B auch

==== Anwendung auf TSP ====
3-SAT <math>\le</math> Hamiltonzyklus im gerichteten Graph <math>\le</math> Hamiltonzyklus im ungerichteten Graph <math>\le</math> TSP im gerwichteten ungerichteten Graph

Assoziative Arrays

2020-07-09T19:09:19Z

Alda: /* Das JSON-Datenformat */

== Datenstruktur-Dreieck für assoziative Arrays ==

Assoziative Arrays sind eine der wichtigsten Anwendungen für Suchalgorithmen und Suchbäume. Bevor wir dies im Detail erklären, wollen wir jedoch noch einmal einen Blick auf das Datenstruktur-Dreieck aus der ersten Vorlesung werfen, das am Beispiel der assoziativen Arrays sehr schön illustriert werden kann. Wir zeigen es hier noch einmal:

[[Image:Dt dreieck.png|300px]]

Wir erinnern daran, dass man zwei Ecken des Dreicks wählen muss, um eine Datenstruktur zu definieren. Wir werden im Folgenden zeigen, wie Python durch Festlegen der erlaubten Operationen und deren Bedeutung den abstrakten Datentyp "Assoziatives Array" definiert, wie durch Festlegen eines Speicherlayouts und der Bedeutung der gespeicherten Entitäten das Standard-Datenformat "JSON" definiert ist, und wie durch effiziente Implementation der festgelegten Operationen mit jeweils passendem Speicherlayout die Datenstruktur auf unterschiedliche Arten realisiert werden kann.

== Definition des abstrakten Datentyps ==

Assoziative Arrays können genau wie gewöhnliche Arrays benutzt werden, sie unterstützen also den lesenden und schreibenden Zugriff über den Indexoperator <tt>a[...]</tt>. Im Unterschied zum gewöhnlichen Array, wo die Indizes ganze Zahlen im Bereich <math> i \in 0 \ldots N-1</math> sein muss, kann der Typ der Indizes jetzt ''beliebig'' sein. Wir verwenden dafür den Begriff "Schlüssel" (engl.: key):
a[key] = value # Speichern des Wertes 'value' unter dem Schlüssel 'key'
value = a[key] # Auslesen des unter dem Schlüssel 'key' gespeicherten Wertes
Eine typische Anwendung ist ein Wörterbuch
x = toEnglish['Baum'] # ergibt 'tree'
In diesem Fall ist der Typ des Schlüssels <tt>string</tt>. Dies ist in der Praxis der häufigste Fall, weshalb assoziative Arrays oft als ''Dictionary'' bezeichnet werden (so auch in Python, hier heißt der Typ <tt>dict</tt>). Im allgemeinen kann aber jeder Typ als Schlüssel benutzt werden, der eine der folgenden Anforderungen erfüllt:

{| border="1" cellspacing="0" cellpadding="7"
|-align="center"
! unterstützte Vergleichsoperationen für Schlüssel
! mögliche Implementation des assoziativen Arrays
|-
| Identitätstest: <tt>key1 == key2</tt>
| sequentielle Suche
|-
| Ordnungsrelation: <tt>key1 < key2</tt> oder <tt>cmp(key1, key2)</tt>
| Suchbaum (auch binäre Suche, falls keine neuen Schlüssel eingefügt und keine gelöscht werden)
|-
| Identitätstest und Hashfunktion: <tt>key1 == key2</tt> und <tt>hash(key1) == hash(key2)</tt>
| Hashtabelle
|}

Wenn über die Schlüssel mehr bekannt ist (eine Ordnungsrelation oder eine Hashfunktion statt einer bloßen Indentitätsprüfung), kann man entsprechend bessere Datenstrukturen (Suchbäume oder Hashtabellen statt sequentieller Suche) verwenden, deren Zugriffsfunktionen wesentlich effizienter sind (sequentielle Suche ist ja nur in O(N)).

Zu den beiden obigen Zugriffsfunktionen treten in Python noch drei weitere Funktionen hinzu: eine um zu testen, ob ein Schlüssel vorhanden ist, eine um einen Schlüssel und die darunter gespeicherten Daten zu löschen, sowie eine, die die Größe des Arrays (Anzahl der gespeicherten Schlüssel/Wert-Paare) zurückgibt:
if a.has_key(key): # Testen, ob Schlüssel 'key' existiert
del a[key] # Schlüssel 'key' und zugehörige Daten aus dem Array entfernen
print len(a) # Größe des Arrays ausgeben

Die Syntax der aufgeführten Funktionen gilt für die ''Benutzung'' eines assoziativen Arrays. Will man einen solchen Datentyp implementieren, muss man die entsprechende Funktionalität als Methoden der jeweiligen Klasse zur Verfügung stellen. Der Python-Interpreter transformiert den Index-/Schlüsselzugriff <tt>a[key]</tt> sowie die <tt>len</tt>- und <tt>del</tt>-Operatoren automatisch in Aufrufe der jeweiligen Methode, wie die folgende Tabelle verdeutlicht. Zur vollständigen Definition der Bedeutung der einzelnen Operationen (wie vom Datenstruktur-Dreieck gefordert) gehört außerdem die Spezifikation des Verhaltens im Fehlerfall (wenn z.B. ein angeforderter Schlüssel nicht existiert).

{| border="1" cellspacing="0" cellpadding="7"
|-align="center"
! Operation
! von Python intern generierter Methodenaufruf
! zu implementierende Methodensignatur
! Bedeutung
|-
| <tt>a[key] = value</tt>
| <tt>a.__setitem__(key, value)</tt>
| <tt>def __setitem__(self, key, value):</tt>
| * wenn <tt>key</tt> bereits existiert: ersetze die zugehörigen Daten durch <tt>value</tt> * wenn <tt>key</tt> noch nicht existiert: lege einen neuen Schlüssel an und speichere <tt>value</tt> als zugehörigeaten
|-
| <tt>value = a[key]</tt>
| <tt>a.__getitem__(key)</tt>
| <tt>def __getitem__(self, key):</tt>
| * wenn <tt>key</tt> existiert: gebe die zugehörigen Daten zurück * wenn <tt>key</tt> nicht existiert: löse <tt>KeyError</tt>-Exception aus
|-
| <tt>a.has_key(key)</tt>
| <tt>a.has_key(key)</tt>
| <tt>def has_key(self, key):</tt>
| gibt <tt>True</tt> zurück wenn <tt>key</tt> existiert, sonst <tt>False</tt>
|-
| <tt>del a[key]</tt>
| <tt>a.__delitem__(key)</tt>
| <tt>def __delitem__(self, key):</tt>
| * wenn <tt>key</tt> existiert: entferne diesen Schlüssel und die zugehörigen Daten * wenn <tt>key</tt> nicht existiert: löse <tt>KeyError</tt>-Exception aus
|-
| <tt>len(a)</tt>
| <tt>a.__len__()</tt>
| <tt>def __len__(self):</tt>
| gibt die Größe des Arrays zurück
|}

Aufgrund der Definition ist klar, das jeder Schlüssel nur einmal im Array vorkommen kann. Die Definition des Abstrakten Datentyps "assoziatives Array" erlaubt es uns, derartige Arrays auf verschiedenste Art zu implementieren, ohne dass sich an der Benutzung (also daran, wie man die Arrayfunktionalität später aufruft) irgend etwas ändert.

== Das JSON-Datenformat ==

Die zweite Kante des Datenstruktur-Dreiecks ist das "Datenformat". Hier legt man Speicherlayout und Bedeutung fest. Ein Datenformat dient vor allem zum Speichern von Daten auf Festplatte und zum Austausch von Daten zwischen verschiedenen Programmen bzw. Internetseiten. Im Fall von assoziativen Arrays setzt sich dafür das [http://www.json.org/ JSON-Format] immer mehr durch, weil es einfach und trotzdem mächtig ist. Es eignet sich sehr gut zum Speichern von assoziativen Arrays (also von Schlüssel/Wert Paaren) und unterstützt außerdem gewöhnliche Arrays und hierarchische Strukturen, weil die Werte wiederum (gewöhnliche oder assoziative) Arrays sein dürfen.

Das Speicherlayout einer JSON-Dateien ist definiert als eine Bytefolge, die als Zeichenfolge gemäß [http://de.wikipedia.org/wiki/UTF-8 UTF-8-Standard] interpretiert wird. Dies hat zwei Vorteile: einerseits ist das Format dadurch mit allen gängigen Systemen kompatibel und überall gleich, andererseits kann jedes JSON-File einfach in einem Texteditor geöffnet und editiert werden und ist für Menschen und Maschinen gleichermaßen leicht lesbar.

Die Zuordung einer Bedeutung zu einem gegebenen Speicherinhalt erfolgt in JSON mit Hilfe einer Grammatik. Ein JSON-File enthält entweder ein gewöhnliches Array oder ein assoziatives Array (Dictionary):
JSON_file := array
| dictionary
Ein gewöhnliches Array wird als Folge von einem oder mehreren Elementen geschrieben, die durch Komma getrennt und in eckigen Klammern eingeschlossen sind (Zeichen, die in der Grammatik in einfache Anführungszeichen eingeschlossen sind, müssen explizit im JSON-File stehen). Leere Arrays sind ebenfalls erlaubt:
array := '[' elements ']'
| '[' ']'
elements := value
| value ',' elements
Ein Dictionary wird in ähnlicher Weise als Folge von Schlüssel/Wert-Paaren geschrieben, die durch Komma getrennt und in geschweiften Klammern eingeschlossen sind. Leere Dictionaries sind erlaubt. Die Schlüssel müssen immer Strings sein, gefolgt von einem Doppelpunkt:
dictionary := '{' pairs '}'
| '{' '}'
pairs := string ':' value
| string ':' value ',' pairs
Strings sind Zeichenfolgen (inklusive einiger Sonderzeichen wie "\n" für einen Zeilenumbruch), die in doppelte Anführungszeichen eingeschlossen sind, oder der Leerstring:
string := '"' '"'
| '"'characters'"'
Werte können Zahlen (ganze oder reelle Zahlen, definiert wie in Python), Boolesche Werte ('true' oder 'false'), Strings oder 'null' sein. Außerdem können Arrays und Dictionaries wiederum als Werte verwendet werden, wodurch sich beliebig tief geschachtelte, hierarchische Datenstrukturen ergeben:
value := number | string | boolean | null | array | dictionary
Hier ist ein einfaches Beispiel für ein JSON-File, das Ausschnitte aus einer Studenten-Datenbank enthält:
{
"Müller, Friedrich" : {
"Mathematik" : 2.0,
"ALDA" : 1.3
},
"Weise, Anna" : {
"Mathematik" : 1.0,
"Philosophie": 1.3
}
}
Das JSON-Format ist syntaktisch der Sprache Python sehr nahe, und kann mit einigen verherigen Definitionen direkt durch die <tt>eval()</tt>-Funktion in ein Python-Dictionary oder -Array umgewandelt werden.
# don't do this - it is highly '''unsafe''' and dangerous
true, false, null = True, False, None # fehlende Konstanten defininieren
res = eval(file("test.json").read().decode("utf_8")) # File einlesen und als Python-Code ausführen
Dies sollte man jedoch '''auf keinen Fall''' tun, weil ein Hacker dadurch beliebigen Code ausführen könnte, den er vorher in das File 'test.json' eingeschmuggelt hat. Da die Funktion <tt>eval()</tt> nur prüft, ob der Ausdruck gültiges Python ist, aber nicht, ob das File gültiges JSON (also nur Daten, aber keinen ausführbaren Code) enthält, kann man dies nicht erkennen oder verhindern. Deshalb sollte man zum Einlesen von JSON stets das Python-Modul [http://docs.python.org/library/json.html json] verwenden, das ein manipuliertes File einfach zurückweisen würde:
# sicheres Einlesen und Konvertieren
import json

with open('test.json', encoding='utf-8') as f: # File im UTF-8 Format öffnen
res = json.load(f) # und als json einlesen

==Implementation von assoziativen Array-Klassen==

Die dritte Kante des Datenstruktur-Dreiecks bezieht sich schließlich auf die Realisierung der Datenstruktur als Klasse, indem man auf geeignet organisiertem Speicher die geforderten Operationen implementiert. In Python ist mit der Klasse <tt>dict</tt> eine sehr leistungsfähige Implementation eines assoziativen Arrays integraler Bestandteil der Sprache. Diese Implementation beruht auf dem Konzept der Hashtabellen, das wir in der Vorlesung [[Hashing und Hashtabellen|später behandeln]]. Man benötigt dafür eine Funktion <tt>hash(key)</tt>, die in Python für alle Standarddatentypen bereits implementiert ist. In diesem Abschnitt wollen wir zwei alternative Implementationen auf der Basis von sequentieller Suche und auf der Basis von Suchbäumen betrachten.

=== Realisierung durch sequentielle Suche===

Wenn für die Schlüssel nur ein Identitätsvergleich
key1 == key2
definiert ist, hat man keine Möglichkeit, die Schlüsselsuche durch eine spezielle Datenstruktur zu beschleunigen. Man speichert die Schlüssel/Wert-Paare dann einfach in einem gewöhnlichen Array, das man sequentiell durchsucht. Dazu implementieren wir zunächst eine Hilfsklasse, die Schlüssel/Wert-Paare aufnimmt:
class KeyValuePair:
def __init__(self, key, value):
self.key = key
self.value = value
Die Arrayklasse speichert die Paare in einem Array <tt>self.data</tt>, dessen aktuelle Länge der Größe des assoziativen Arrays entspricht. Damit ist das Speicherlayout der Klasse festgelegt:
class SequentialSearchArray:
def __init__(self):
self.data = []
def __len__(self):
return len(self.data)
Um auf die Daten zugreifen zu können, müssen wir nach dem richtigen Schlüssel suchen. Dazu implementieren wir die Hilfsfunktion <tt>findKey</tt>, die den Index des Schlüssels zurückgibt, oder <tt>None</tt>, wenn der Schlüssel nicht existiert:
def findKey(self, key):
for k in xrange(len(self.data)):
if key == self.data[k].key:
return k
return None
Beim Einfügen eines Elements müssen wir zuerst prüfen, ob es den Schlüssel schon gibt, und dann entweder die daten überschreiben oder ein neues Element anfügen:
def __setitem__(self, key, value):
k = self.findKey(key)
if k is None:
self.data.append(KeyValuePair(key, value)) # neues Paar einfügen
else:
self.data[k].value = value # Daten ersetzen
Die Suche hingegen löst eine Exception aus, wenn der Schlüssel nicht gefunden wurde:
def __getitem__(self, key):
k = self.findKey(key)
if k is None:
raise KeyError(key) # Schlüssel nicht gefunden => Fehler
else:
return self.data[k].value # Schlüssel gefunden => Daten zurückgeben
Die übrigen geforderten Funktionen sind ebenso einfach zu implementieren:
def has_key(self, key):
return (self.findKey(key) is not None)

def __delitem__(self, key):
k = self.findKey(key)
if k is None:
raise KeyError(key) # Schlüssel nicht gefunden => Fehler
else:
del self.data[k] # Schlüssel gefunden => löschen
Wegen der sequentiellen Suche hat der Zugriff auf ein Element in dieser Datenstruktur die Komplexität O(len(a)).

=== Realisierung als Suchbaum ===

Wenn für den Schlüsseltyp des assoziativen Arrays eine Ordnung definiert ist (wenn also <tt>key1 < key2</tt> oder <tt>cmp(key1, key2)</tt> unterstützt werden), kann man das Indexierungsproblem auf das Suchproblem zurückführen. Dann kann das assoziative Array effizient als selbst-balancierender Suchbaum imlementiert werden, so dass die Zugriffsfunktionen nur noch eine Komplexität in O(log(len(a))) haben. Die Datenstruktur des Suchbaums muss dafür so erweitert werden, dass zu jedem Schlüssel auch die zugehörigen Daten gespeichert werden. Man erweitert die Node-Klasse deshalb um ein Feld "value":
class Node:
def __init__(self, key, value):
self.key = key
self.data = value
self.left = self.right = None
Dann kann man eine Klasse <tt>TreeSearchArray</tt> realisieren, deren Konstruktor einen leeren Suchbaum initialisiert:
class TreeSearchArray:
def __init__(self):
self.root = None
self.size = 0
def __len__(self):
return self.size
Die Funktion <tt>__setitem__</tt> schaut nach, ob ein Eintrag mit dem betreffenden Schlüssel bereits existiert. Wenn ja, werden seine Daten mit den neuen Daten überschrieben, andernfalls wird ein neuer Eintrag angelegt. Intern werden dazu die bereits bekannten Funktionen <tt>treeSearch</tt> und <tt>treeInsert</tt> verwendet (siehe Abschnitt [[Suchen#Suchbäume|Suchbäume]]):
def __setitem__(self, key, value):
node = treeSearch(self.root, key)
if node is None:
self.root = treeInsert(self.root, key)
self.size += 1
node = treeSearch(self.root, key)
node.value = value
(Eine geschicktere Implementation würde natürlich den zweiten Aufruf von <tt>treeSearch</tt> eliminieren und das Setzen der Daten gleich in <tt>treeInsert</tt> erledigen. Dies ändert aber nichts an der Komplexität der Funktion.) Die Funktion <tt>__getitem__</tt> sucht ebenfalls einen Eintrag mit dem gegebenen Schlüssel. Wenn er gefunden wird, gibt sie die zugehörigen Daten zurück, andernfalls eine Fehlermeldung:
def __getitem__(self, key):
node = treeSearch(self.root, key)
if node is None:
raise KeyError(key)
else:
return node.value
Die Indexoperationen haben bei der Realisierung mit Baumsuche eine Komplexität in O(log n).

Ein wichtiges Beispiel für ein assoziatives Array, das auf diese Weise realisiert wurde, ist die C++ Standardklasse <tt>[http://www.sgi.com/tech/stl/Map.html std::map]</tt>.

[[Hashing und Hashtabellen|Nächstes Thema]]

Assoziative Arrays

2020-07-09T19:07:57Z

Alda:

== Datenstruktur-Dreieck für assoziative Arrays ==

Assoziative Arrays sind eine der wichtigsten Anwendungen für Suchalgorithmen und Suchbäume. Bevor wir dies im Detail erklären, wollen wir jedoch noch einmal einen Blick auf das Datenstruktur-Dreieck aus der ersten Vorlesung werfen, das am Beispiel der assoziativen Arrays sehr schön illustriert werden kann. Wir zeigen es hier noch einmal:

[[Image:Dt dreieck.png|300px]]

Wir erinnern daran, dass man zwei Ecken des Dreicks wählen muss, um eine Datenstruktur zu definieren. Wir werden im Folgenden zeigen, wie Python durch Festlegen der erlaubten Operationen und deren Bedeutung den abstrakten Datentyp "Assoziatives Array" definiert, wie durch Festlegen eines Speicherlayouts und der Bedeutung der gespeicherten Entitäten das Standard-Datenformat "JSON" definiert ist, und wie durch effiziente Implementation der festgelegten Operationen mit jeweils passendem Speicherlayout die Datenstruktur auf unterschiedliche Arten realisiert werden kann.

== Definition des abstrakten Datentyps ==

Assoziative Arrays können genau wie gewöhnliche Arrays benutzt werden, sie unterstützen also den lesenden und schreibenden Zugriff über den Indexoperator <tt>a[...]</tt>. Im Unterschied zum gewöhnlichen Array, wo die Indizes ganze Zahlen im Bereich <math> i \in 0 \ldots N-1</math> sein muss, kann der Typ der Indizes jetzt ''beliebig'' sein. Wir verwenden dafür den Begriff "Schlüssel" (engl.: key):
a[key] = value # Speichern des Wertes 'value' unter dem Schlüssel 'key'
value = a[key] # Auslesen des unter dem Schlüssel 'key' gespeicherten Wertes
Eine typische Anwendung ist ein Wörterbuch
x = toEnglish['Baum'] # ergibt 'tree'
In diesem Fall ist der Typ des Schlüssels <tt>string</tt>. Dies ist in der Praxis der häufigste Fall, weshalb assoziative Arrays oft als ''Dictionary'' bezeichnet werden (so auch in Python, hier heißt der Typ <tt>dict</tt>). Im allgemeinen kann aber jeder Typ als Schlüssel benutzt werden, der eine der folgenden Anforderungen erfüllt:

{| border="1" cellspacing="0" cellpadding="7"
|-align="center"
! unterstützte Vergleichsoperationen für Schlüssel
! mögliche Implementation des assoziativen Arrays
|-
| Identitätstest: <tt>key1 == key2</tt>
| sequentielle Suche
|-
| Ordnungsrelation: <tt>key1 < key2</tt> oder <tt>cmp(key1, key2)</tt>
| Suchbaum (auch binäre Suche, falls keine neuen Schlüssel eingefügt und keine gelöscht werden)
|-
| Identitätstest und Hashfunktion: <tt>key1 == key2</tt> und <tt>hash(key1) == hash(key2)</tt>
| Hashtabelle
|}

Wenn über die Schlüssel mehr bekannt ist (eine Ordnungsrelation oder eine Hashfunktion statt einer bloßen Indentitätsprüfung), kann man entsprechend bessere Datenstrukturen (Suchbäume oder Hashtabellen statt sequentieller Suche) verwenden, deren Zugriffsfunktionen wesentlich effizienter sind (sequentielle Suche ist ja nur in O(N)).

Zu den beiden obigen Zugriffsfunktionen treten in Python noch drei weitere Funktionen hinzu: eine um zu testen, ob ein Schlüssel vorhanden ist, eine um einen Schlüssel und die darunter gespeicherten Daten zu löschen, sowie eine, die die Größe des Arrays (Anzahl der gespeicherten Schlüssel/Wert-Paare) zurückgibt:
if a.has_key(key): # Testen, ob Schlüssel 'key' existiert
del a[key] # Schlüssel 'key' und zugehörige Daten aus dem Array entfernen
print len(a) # Größe des Arrays ausgeben

Die Syntax der aufgeführten Funktionen gilt für die ''Benutzung'' eines assoziativen Arrays. Will man einen solchen Datentyp implementieren, muss man die entsprechende Funktionalität als Methoden der jeweiligen Klasse zur Verfügung stellen. Der Python-Interpreter transformiert den Index-/Schlüsselzugriff <tt>a[key]</tt> sowie die <tt>len</tt>- und <tt>del</tt>-Operatoren automatisch in Aufrufe der jeweiligen Methode, wie die folgende Tabelle verdeutlicht. Zur vollständigen Definition der Bedeutung der einzelnen Operationen (wie vom Datenstruktur-Dreieck gefordert) gehört außerdem die Spezifikation des Verhaltens im Fehlerfall (wenn z.B. ein angeforderter Schlüssel nicht existiert).

{| border="1" cellspacing="0" cellpadding="7"
|-align="center"
! Operation
! von Python intern generierter Methodenaufruf
! zu implementierende Methodensignatur
! Bedeutung
|-
| <tt>a[key] = value</tt>
| <tt>a.__setitem__(key, value)</tt>
| <tt>def __setitem__(self, key, value):</tt>
| * wenn <tt>key</tt> bereits existiert: ersetze die zugehörigen Daten durch <tt>value</tt> * wenn <tt>key</tt> noch nicht existiert: lege einen neuen Schlüssel an und speichere <tt>value</tt> als zugehörigeaten
|-
| <tt>value = a[key]</tt>
| <tt>a.__getitem__(key)</tt>
| <tt>def __getitem__(self, key):</tt>
| * wenn <tt>key</tt> existiert: gebe die zugehörigen Daten zurück * wenn <tt>key</tt> nicht existiert: löse <tt>KeyError</tt>-Exception aus
|-
| <tt>a.has_key(key)</tt>
| <tt>a.has_key(key)</tt>
| <tt>def has_key(self, key):</tt>
| gibt <tt>True</tt> zurück wenn <tt>key</tt> existiert, sonst <tt>False</tt>
|-
| <tt>del a[key]</tt>
| <tt>a.__delitem__(key)</tt>
| <tt>def __delitem__(self, key):</tt>
| * wenn <tt>key</tt> existiert: entferne diesen Schlüssel und die zugehörigen Daten * wenn <tt>key</tt> nicht existiert: löse <tt>KeyError</tt>-Exception aus
|-
| <tt>len(a)</tt>
| <tt>a.__len__()</tt>
| <tt>def __len__(self):</tt>
| gibt die Größe des Arrays zurück
|}

Aufgrund der Definition ist klar, das jeder Schlüssel nur einmal im Array vorkommen kann. Die Definition des Abstrakten Datentyps "assoziatives Array" erlaubt es uns, derartige Arrays auf verschiedenste Art zu implementieren, ohne dass sich an der Benutzung (also daran, wie man die Arrayfunktionalität später aufruft) irgend etwas ändert.

== Das JSON-Datenformat ==

Die zweite Kante des Datenstruktur-Dreiecks ist das "Datenformat". Hier legt man Speicherlayout und Bedeutung fest. Ein Datenformat dient vor allem zum Speichern von Daten auf Festplatte und zum Austausch von Daten zwischen verschiedenen Programmen bzw. Internetseiten. Im Fall von assoziativen Arrays setzt sich dafür das [http://www.json.org/ JSON-Format] immer mehr durch, weil es einfach und trotzdem mächtig ist. Es eignet sich sehr gut zum Speichern von assoziativen Arrays (also von Schlüssel/Wert Paaren) und unterstützt außerdem gewöhnliche Arrays und hierarchische Strukturen, weil die Werte wiederum (gewöhnliche oder assoziative) Arrays sein dürfen.

Das Speicherlayout einer JSON-Dateien ist definiert als eine Bytefolge, die als Zeichenfolge gemäß [http://de.wikipedia.org/wiki/UTF-8 UTF-8-Standard] interpretiert wird. Dies hat zwei Vorteile: einerseits ist das Format dadurch mit allen gängigen Systemen kompatibel und überall gleich, andererseits kann jedes JSON-File einfach in einem Texteditor geöffnet und editiert werden und ist für Menschen und Maschinen gleichermaßen leicht lesbar.

Die Zuordung einer Bedeutung zu einem gegebenen Speicherinhalt erfolgt in JSON mit Hilfe einer Grammatik. Ein JSON-File enthält entweder ein gewöhnliches Array oder ein assoziatives Array (Dictionary):
JSON_file := array
| dictionary
Ein gewöhnliches Array wird als Folge von einem oder mehreren Elementen geschrieben, die durch Komma getrennt und in eckigen Klammern eingeschlossen sind (Zeichen, die in der Grammatik in einfache Anführungszeichen eingeschlossen sind, müssen explizit im JSON-File stehen). Leere Arrays sind ebenfalls erlaubt:
array := '[' elements ']'
| '[' ']'
elements := value
| value ',' elements
Ein Dictionary wird in ähnlicher Weise als Folge von Schlüssel/Wert-Paaren geschrieben, die durch Komma getrennt und in geschweiften Klammern eingeschlossen sind. Leere Dictionaries sind erlaubt. Die Schlüssel müssen immer Strings sein, gefolgt von einem Doppelpunkt:
dictionary := '{' pairs '}'
| '{' '}'
pairs := string ':' value
| string ':' value ',' pairs
Strings sind Zeichenfolgen (inklusive einiger Sonderzeichen wie "\n" für einen Zeilenumbruch), die in doppelte Anführungszeichen eingeschlossen sind, oder der Leerstring:
string := '"' '"'
| '"'characters'"'
Werte können Zahlen (ganze oder reelle Zahlen, definiert wie in Python), Boolesche Werte ('true' oder 'false'), Strings oder 'null' sein. Außerdem können Arrays und Dictionaries wiederum als Werte verwendet werden, wodurch sich beliebig tief geschachtelte, hierarchische Datenstrukturen ergeben:
value := number | string | boolean | null | array | dictionary
Hier ist ein einfaches Beispiel für ein JSON-File, das Ausschnitte aus einer Studenten-Datenbank enthält:
{
"Müller, Friedrich" : {
"Mathematik" : 2.0,
"ALDA" : 1.3
},
"Weise, Anna" : {
"Mathematik" : 1.0,
"Philosophie": 1.3
}
}
Das JSON-Format ist syntaktisch der Sprache Python sehr nahe, und kann mit einigen verherigen Definitionen direkt durch die <tt>eval()</tt>-Funktion in ein Python-Dictionary oder -Array umgewandelt werden.
# don't do this - it is highly '''unsafe''' and dangerous
true, false, null = True, False, None # fehlende Konstanten defininieren
res = eval(file("test.json").read().decode("utf_8")) # File einlesen und nach Python konvertieren
Dies sollte man jedoch '''auf keinen Fall''' tun, weil ein Hacker dadurch beliebigen Code ausführen könnte, den er vorher in das File 'test.json' eingeschmuggelt hat. Da die Funktion <tt>eval()</tt> nur prüft, ob der Ausdruck gültiges Python ist, aber nicht, ob das File gültiges JSON (also nur Daten, aber keinen ausführbaren Code) enthält, kann man dies nicht erkennen oder verhindern. Deshalb sollte man zum Einlesen von JSON stets das Python-Modul [http://docs.python.org/library/json.html json] verwenden, das ein manipuliertes File einfach zurückweisen würde:
# sicheres Einlesen und Konvertieren
import json

with open('test.json', encoding='utf-8') as f: # File im UTF-8 Format öffnen
res = json.load(f) # und als json einlesen

==Implementation von assoziativen Array-Klassen==

Die dritte Kante des Datenstruktur-Dreiecks bezieht sich schließlich auf die Realisierung der Datenstruktur als Klasse, indem man auf geeignet organisiertem Speicher die geforderten Operationen implementiert. In Python ist mit der Klasse <tt>dict</tt> eine sehr leistungsfähige Implementation eines assoziativen Arrays integraler Bestandteil der Sprache. Diese Implementation beruht auf dem Konzept der Hashtabellen, das wir in der Vorlesung [[Hashing und Hashtabellen|später behandeln]]. Man benötigt dafür eine Funktion <tt>hash(key)</tt>, die in Python für alle Standarddatentypen bereits implementiert ist. In diesem Abschnitt wollen wir zwei alternative Implementationen auf der Basis von sequentieller Suche und auf der Basis von Suchbäumen betrachten.

=== Realisierung durch sequentielle Suche===

Wenn für die Schlüssel nur ein Identitätsvergleich
key1 == key2
definiert ist, hat man keine Möglichkeit, die Schlüsselsuche durch eine spezielle Datenstruktur zu beschleunigen. Man speichert die Schlüssel/Wert-Paare dann einfach in einem gewöhnlichen Array, das man sequentiell durchsucht. Dazu implementieren wir zunächst eine Hilfsklasse, die Schlüssel/Wert-Paare aufnimmt:
class KeyValuePair:
def __init__(self, key, value):
self.key = key
self.value = value
Die Arrayklasse speichert die Paare in einem Array <tt>self.data</tt>, dessen aktuelle Länge der Größe des assoziativen Arrays entspricht. Damit ist das Speicherlayout der Klasse festgelegt:
class SequentialSearchArray:
def __init__(self):
self.data = []
def __len__(self):
return len(self.data)
Um auf die Daten zugreifen zu können, müssen wir nach dem richtigen Schlüssel suchen. Dazu implementieren wir die Hilfsfunktion <tt>findKey</tt>, die den Index des Schlüssels zurückgibt, oder <tt>None</tt>, wenn der Schlüssel nicht existiert:
def findKey(self, key):
for k in xrange(len(self.data)):
if key == self.data[k].key:
return k
return None
Beim Einfügen eines Elements müssen wir zuerst prüfen, ob es den Schlüssel schon gibt, und dann entweder die daten überschreiben oder ein neues Element anfügen:
def __setitem__(self, key, value):
k = self.findKey(key)
if k is None:
self.data.append(KeyValuePair(key, value)) # neues Paar einfügen
else:
self.data[k].value = value # Daten ersetzen
Die Suche hingegen löst eine Exception aus, wenn der Schlüssel nicht gefunden wurde:
def __getitem__(self, key):
k = self.findKey(key)
if k is None:
raise KeyError(key) # Schlüssel nicht gefunden => Fehler
else:
return self.data[k].value # Schlüssel gefunden => Daten zurückgeben
Die übrigen geforderten Funktionen sind ebenso einfach zu implementieren:
def has_key(self, key):
return (self.findKey(key) is not None)

def __delitem__(self, key):
k = self.findKey(key)
if k is None:
raise KeyError(key) # Schlüssel nicht gefunden => Fehler
else:
del self.data[k] # Schlüssel gefunden => löschen
Wegen der sequentiellen Suche hat der Zugriff auf ein Element in dieser Datenstruktur die Komplexität O(len(a)).

=== Realisierung als Suchbaum ===

Wenn für den Schlüsseltyp des assoziativen Arrays eine Ordnung definiert ist (wenn also <tt>key1 < key2</tt> oder <tt>cmp(key1, key2)</tt> unterstützt werden), kann man das Indexierungsproblem auf das Suchproblem zurückführen. Dann kann das assoziative Array effizient als selbst-balancierender Suchbaum imlementiert werden, so dass die Zugriffsfunktionen nur noch eine Komplexität in O(log(len(a))) haben. Die Datenstruktur des Suchbaums muss dafür so erweitert werden, dass zu jedem Schlüssel auch die zugehörigen Daten gespeichert werden. Man erweitert die Node-Klasse deshalb um ein Feld "value":
class Node:
def __init__(self, key, value):
self.key = key
self.data = value
self.left = self.right = None
Dann kann man eine Klasse <tt>TreeSearchArray</tt> realisieren, deren Konstruktor einen leeren Suchbaum initialisiert:
class TreeSearchArray:
def __init__(self):
self.root = None
self.size = 0
def __len__(self):
return self.size
Die Funktion <tt>__setitem__</tt> schaut nach, ob ein Eintrag mit dem betreffenden Schlüssel bereits existiert. Wenn ja, werden seine Daten mit den neuen Daten überschrieben, andernfalls wird ein neuer Eintrag angelegt. Intern werden dazu die bereits bekannten Funktionen <tt>treeSearch</tt> und <tt>treeInsert</tt> verwendet (siehe Abschnitt [[Suchen#Suchbäume|Suchbäume]]):
def __setitem__(self, key, value):
node = treeSearch(self.root, key)
if node is None:
self.root = treeInsert(self.root, key)
self.size += 1
node = treeSearch(self.root, key)
node.value = value
(Eine geschicktere Implementation würde natürlich den zweiten Aufruf von <tt>treeSearch</tt> eliminieren und das Setzen der Daten gleich in <tt>treeInsert</tt> erledigen. Dies ändert aber nichts an der Komplexität der Funktion.) Die Funktion <tt>__getitem__</tt> sucht ebenfalls einen Eintrag mit dem gegebenen Schlüssel. Wenn er gefunden wird, gibt sie die zugehörigen Daten zurück, andernfalls eine Fehlermeldung:
def __getitem__(self, key):
node = treeSearch(self.root, key)
if node is None:
raise KeyError(key)
else:
return node.value
Die Indexoperationen haben bei der Realisierung mit Baumsuche eine Komplexität in O(log n).

Ein wichtiges Beispiel für ein assoziatives Array, das auf diese Weise realisiert wurde, ist die C++ Standardklasse <tt>[http://www.sgi.com/tech/stl/Map.html std::map]</tt>.

[[Hashing und Hashtabellen|Nächstes Thema]]

Graphen und Graphenalgorithmen

2020-07-02T18:26:53Z

Alda: /* Breitensuche in Graphen (Breadth First Search, BFS) */

== 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 auf demselben Weg zurück (sogenanntes back tracking), bis man einen Knoten findet, der noch einen unbesuchten 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.

Die 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 property map genannt. (Die Verwendung von property maps hat sich gegenüber der alternativen Idee durchgesetzt, solche Eigenschaften in speziellen Knotenklassen zu speichern. Im letzteren Fall braucht man nämlich für jede Anwendung eine angepasste Knotenklasse mit den jeweils gewünschten Attributen und damit auch angepasste Implementationen der Graphenfunktionen, was sich als sehr aufwändig erwiesen hat.)

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 Nachbarpixeln 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, Informationen über den Verlauf der Suche zu sammeln und am Ende zurückzugeben, so dass andere Algorithmen diese Information nutzen können. Typische Beispiele dafür sind eine Reihenfolge der Knoten (in discovery oder finishing order) oder die Vorgänger jedes Knotens im Tiefensuchbaum (also von welchem Knoten aus man den jeweiligen Knoten zuerst erreicht hat). Wir führen dafür drei neue Arrays ein.

def dfs(graph, startnode):
visited = [False]*len(graph) # wurde ein Knoten bereits besucht?
parents = [None]*len(graph) # registriere für jeden Knoten den Vorgänger im Tiefensuchbaum
discovery_order = [] # enthält am Ende die pre-order Sortierung
finishing_order = [] # enthält am Ende die post-order Sortierung

def visit(node, parent): # rekursive Hilfsfunktion
if not visited[node]: # besuche 'node', wenn noch nicht besucht wurde
visited[node] = True # markiere 'node' als besucht
parents[node] = parent # speichere den Vorgänger von 'node'
discovery_order.append(node) # registriere, dass 'node' jetzt entdeckt wurde
for neighbor in graph[node]: # besuche rekursiv die Nachbarn ...
visit(neighbor, node) # ... wobei 'node' zu deren Vorgänger wird
finishing_order.append(node) # registriere, dass 'node' jetzt fertiggestellt wurde

visit(startnode, None) # beginne bei 'startnode', der keinen Vorgänger hat

return parents, discovery_order, finishing_order # gib die zusätzliche Informationen zurück

Beginnt man die Suche bei Knoten 1, entsprechen die Inhalte der Arrays <tt>discovery_order</tt> und <tt>finishing_order</tt> für den obigen Beispielgraphen gerade den vorher angeführten <tt>print</tt>-Ausgaben. Die Vorgänger im Array <tt>parents</tt> lauten:
Knotennummer | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
--------------+-----+-----+-----+-----+-----+-----+-----+-----
Vorgänger | None| None| 1 | 4 | 2 | 2 | 3 | 3

Die Knotennummern dienen hier als Array-Indizes, und die dazugehörigen Arrayeinträge verweisen auf die Vorgänger. Man kann mit diesen Informationen den Weg von jedem Knoten zur Wurzel zurückverfolgen und damit den Tiefensuchbaum von unten nach oben rekonstruieren. Man beachte, dass <tt>parents</tt> den Eintrag <tt>None</tt> für die Knoten 0 umd 1 enthält, weil Knoten 0 in diesem Graphen nicht existiert und Knoten 1 als Wurzel der Suche keinen Vorgänger hat.

Wird das Array <tt>parents</tt> verwendet, kann man den Code vereinfachen, indem man das Array <tt>visited</tt> einspart: Sobald ein Knoten erstmals besucht wurde, ist sein Vorgänger bekannt und damit ungleich <tt>None</tt>. Die Abfrage <tt>if parents[node] is None:</tt> liefert damit das gleiche Resultat wie die Abfrage <tt>if not visited[node]:</tt>. Einzige Ausnahme ist der Startknoten der Suche, dessen Vorgänger bisher <tt>None</tt> war. Dieses Problem löst man leicht mit der Konvention, dass man den Startknoten zu seinem eigenen Vorgänger erklärt. Man startet die Suche also mit <tt>visit(startnode, startnode)</tt> statt mit <tt>visit(startnode, None)</tt>.

=== Breitensuche in Graphen (Breadth First Search, BFS) ===

Im Gegensatz zur Tiefensuche werden bei der Breitensuche alle Nachbarknoten 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):
parents = [None]*len(graph) # speichere für jeden Knoten den Vorgänger im Breitensuchbaum
parents[startnode] = startnode # Konvention: der Startknoten hat sich selbst als Vorgänger

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # solange noch Knoten zu bearbeiten sind
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
 # Beachte: mit q.pop() bekommen wir DFS
print(node) # den Knoten bearbeiten (hier: Knotennummer drucken)
for neighbor in graph[node]: # die Nachbarn expandieren
if parents[neighbor] is None: # Nachbar wurde noch nicht besucht
parents[neighbor] = node # => Vorgänger merken, Knoten dadurch als "besucht" markieren
q.append(neighbor) # und in die Queue aufnehmen

[[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.

=== 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.

=== 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]]

=== 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 range(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 = list(range(len(graph))) # Initialisierung der property map: jeder Knoten ist sein eigener Anker

for node in range(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 range(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 zunächst eine wichtige Eigenschaft des Algorithmus: Die Priorität (=Pfadlänge) des Knotens an der Spitze des Heaps wächst im Laufe des Algorithmus monoton an (aber nicht notwendigerweise streng monoton). Mit anderen Worten: liefert <tt>heappop</tt> in der i-ten Iteration der <tt>while</tt>-Schleife den Knoten u mit der Pfadlänge lu, und in der (i+1)-ten Iteration den Knoten v mit der Pfadlänge lv, so gilt stets lv ≥ lu. Wir zeigen dies mit der Technik des indirekten Beweises, d.h. wir nehmen das Gegenteil an und führen diese Annahme zum Widerspruch. Wäre also lv < lu, gäbe es zwei Möglichkeiten:
<ol>
<li>Der Weg nach v mit der Länge lv war in der i-ten Iteration schon bekannt und somit bereits im Heap enthalten. Dann hätte <tt>heappop</tt> in dieser Iteration aber v zurückgegeben, im Widerspruch zur Annahme, dass u zurückgegeben wurde.</li>
<li>Der Weg wurde erst bei der Expansion von u in der i-ten Iteration gefunden. Dann muss v ein Nachbar von u sein, und seine Weglänge berechnet sich als lv = lu + wu,v. Da für die Kantengewichte aber wu,v ≥ 0 gefordert ist, kann lv < lu nicht gelten.</li>
</ol>
Diese Monotonieeigenschaft hat eine interessante Konsequenz: Beträgt der Abstand vom Start zum Zielknoten lz, so findet Dijsktra's Algorithmus als Nebenprodukt auch die kürzesten Wege zu allen näher gelegenen Knoten, also zu allen Knoten u, für deren Abstand lu < lz gilt. Dies trifft auch dann zu, wenn diese Wege für den Benutzer gar nicht von Interesse sind. Der A*-Algorithmus, der weiter unten erklärt wird, versucht dem abzuhelfen.

Wir können nun mittels vollständiger Induktion die folgende Schleifen-Invariante beweisen: 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 wieder 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 dem Momemnt in den Heap eingefügt werden, wo der kürzeste Weg für <tt>predecessor</tt> gefunden wurde. Man beachte auch, dass wegen der Monotonieeigenschaft alle Knoten, die noch nicht in <math>S</math> enthalten sind, weiter vom Start entfernt sind als die Knoten in <math>S</math>.
: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 im Heap 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>: Wegen der Monotonieeigenschaft muss jetzt <tt>Kosten(x → startnode) > Kosten(node → predecessor → startnode)</tt> gelten. Die Kosten des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> berechnen sich aber als <tt>Kosten(x → startnode) + weight[(x, node)]</tt>, und deshalb kann dieser Weg keinesfalls kürzer sein.
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 range(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 range(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 range(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: # neuer Knoten gefunden:
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
else:
return False # node war bereits 'finished' => kein Zyklus

for node in range(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 range(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]]

== 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]]

Assoziative Arrays

2020-07-02T16:27:41Z

Alda: /* Das JSON-Datenformat */

== Datenstruktur-Dreieck für assoziative Arrays ==

Assoziative Arrays sind eine der wichtigsten Anwendungen für Suchalgorithmen und Suchbäume. Bevor wir dies im Detail erklären, wollen wir jedoch noch einmal einen Blick auf das Datenstruktur-Dreieck aus der ersten Vorlesung werfen, das am Beispiel der assoziativen Arrays sehr schön illustriert werden kann. Wir zeigen es hier noch einmal:

[[Image:Dt dreieck.png|300px]]

Wir erinnern daran, dass man zwei Ecken des Dreicks wählen muss, um eine Datenstruktur zu definieren. Wir werden im Folgenden zeigen, wie Python durch Festlegen der erlaubten Operationen und deren Bedeutung den abstrakten Datentyp "Assoziatives Array" definiert, wie durch Festlegen eines Speicherlayouts und der Bedeutung der gespeicherten Entitäten das Standard-Datenformat "JSON" definiert ist, und wie durch effiziente Implementation der festgelegten Operationen mit jeweils passendem Speicherlayout die Datenstruktur auf unterschiedliche Arten realisiert werden kann.

== Definition des abstrakten Datentyps ==

Assoziative Arrays können genau wie gewöhnliche Arrays benutzt werden, sie unterstützen also den lesenden und schreibenden Zugriff über den Indexoperator <tt>a[...]</tt>. Im Unterschied zum gewöhnlichen Array, wo die Indizes ganze Zahlen im Bereich <math> i \in 0 \ldots N-1</math> sein muss, kann der Typ der Indizes jetzt ''beliebig'' sein. Wir verwenden dafür den Begriff "Schlüssel" (engl.: key):
a[key] = value # Speichern des Wertes 'value' unter dem Schlüssel 'key'
value = a[key] # Auslesen des unter dem Schlüssel 'key' gespeicherten Wertes
Eine typische Anwendung ist ein Wörterbuch
x = toEnglish['Baum'] # ergibt 'tree'
In diesem Fall ist der Typ des Schlüssels <tt>string</tt>. Dies ist in der Praxis der häufigste Fall, weshalb assoziative Arrays oft als ''Dictionary'' bezeichnet werden (so auch in Python, hier heißt der Typ <tt>dict</tt>). Im allgemeinen kann aber jeder Typ als Schlüssel benutzt werden, der eine der folgenden Anforderungen erfüllt:

{| border="1" cellspacing="0" cellpadding="7"
|-align="center"
! unterstützte Vergleichsoperationen für Schlüssel
! mögliche Implementation des assoziativen Arrays
|-
| Identitätstest: <tt>key1 == key2</tt>
| sequentielle Suche
|-
| Ordnungsrelation: <tt>key1 < key2</tt> oder <tt>cmp(key1, key2)</tt>
| Suchbaum (auch binäre Suche, falls keine neuen Schlüssel eingefügt und keine gelöscht werden)
|-
| Identitätstest und Hashfunktion: <tt>key1 == key2</tt> und <tt>hash(key1) == hash(key2)</tt>
| Hashtabelle
|}

Wenn über die Schlüssel mehr bekannt ist (eine Ordnungsrelation oder eine Hashfunktion statt einer bloßen Indentitätsprüfung), kann man entsprechend bessere Datenstrukturen (Suchbäume oder Hashtabellen statt sequentieller Suche) verwenden, deren Zugriffsfunktionen wesentlich effizienter sind (sequentielle Suche ist ja nur in O(N)).

Zu den beiden obigen Zugriffsfunktionen treten in Python noch drei weitere Funktionen hinzu: eine um zu testen, ob ein Schlüssel vorhanden ist, eine um einen Schlüssel und die darunter gespeicherten Daten zu löschen, sowie eine, die die Größe des Arrays (Anzahl der gespeicherten Schlüssel/Wert-Paare) zurückgibt:
if a.has_key(key): # Testen, ob Schlüssel 'key' existiert
del a[key] # Schlüssel 'key' und zugehörige Daten aus dem Array entfernen
print len(a) # Größe des Arrays ausgeben

Die Syntax der aufgeführten Funktionen gilt für die ''Benutzung'' eines assoziativen Arrays. Will man einen solchen Datentyp implementieren, muss man die entsprechende Funktionalität als Methoden der jeweiligen Klasse zur Verfügung stellen. Der Python-Interpreter transformiert den Index-/Schlüsselzugriff <tt>a[key]</tt> sowie die <tt>len</tt>- und <tt>del</tt>-Operatoren automatisch in Aufrufe der jeweiligen Methode, wie die folgende Tabelle verdeutlicht. Zur vollständigen Definition der Bedeutung der einzelnen Operationen (wie vom Datenstruktur-Dreieck gefordert) gehört außerdem die Spezifikation des Verhaltens im Fehlerfall (wenn z.B. ein angeforderter Schlüssel nicht existiert).

{| border="1" cellspacing="0" cellpadding="7"
|-align="center"
! Operation
! von Python intern generierter Methodenaufruf
! zu implementierende Methodensignatur
! Bedeutung
|-
| <tt>a[key] = value</tt>
| <tt>a.__setitem__(key, value)</tt>
| <tt>def __setitem__(self, key, value):</tt>
| * wenn <tt>key</tt> bereits existiert: ersetze die zugehörigen Daten durch <tt>value</tt> * wenn <tt>key</tt> noch nicht existiert: lege einen neuen Schlüssel an und speichere <tt>value</tt> als zugehörigeaten
|-
| <tt>value = a[key]</tt>
| <tt>a.__getitem__(key)</tt>
| <tt>def __getitem__(self, key):</tt>
| * wenn <tt>key</tt> existiert: gebe die zugehörigen Daten zurück * wenn <tt>key</tt> nicht existiert: löse <tt>KeyError</tt>-Exception aus
|-
| <tt>a.has_key(key)</tt>
| <tt>a.has_key(key)</tt>
| <tt>def has_key(self, key):</tt>
| gibt <tt>True</tt> zurück wenn <tt>key</tt> existiert, sonst <tt>False</tt>
|-
| <tt>del a[key]</tt>
| <tt>a.__delitem__(key)</tt>
| <tt>def __delitem__(self, key):</tt>
| * wenn <tt>key</tt> existiert: entferne diesen Schlüssel und die zugehörigen Daten * wenn <tt>key</tt> nicht existiert: löse <tt>KeyError</tt>-Exception aus
|-
| <tt>len(a)</tt>
| <tt>a.__len__()</tt>
| <tt>def __len__(self):</tt>
| gibt die Größe des Arrays zurück
|}

Aufgrund der Definition ist klar, das jeder Schlüssel nur einmal im Array vorkommen kann. Die Definition des Abstrakten Datentyps "assoziatives Array" erlaubt es uns, derartige Arrays auf verschiedenste Art zu implementieren, ohne dass sich an der Benutzung (also daran, wie man die Arrayfunktionalität später aufruft) irgend etwas ändert.

== Das JSON-Datenformat ==

Die zweite Kante des Datenstruktur-Dreiecks ist das "Datenformat". Hier legt man Speicherlayout und Bedeutung fest. Ein Datenformat dient vor allem zum Speichern von Daten auf Festplatte und zum Austausch von Daten zwischen verschiedenen Programmen bzw. Internetseiten. Im Fall von assoziativen Arrays setzt sich dafür das [http://www.json.org/ JSON-Format] immer mehr durch, weil es einfach und trotzdem mächtig ist. Es eignet sich sehr gut zum Speichern von assoziativen Arrays (also von Schlüssel/Wert Paaren) und unterstützt außerdem gewöhnliche Arrays und hierarchische Strukturen, weil die Werte wiederum (gewöhnliche oder assoziative) Arrays sein dürfen.

Das Speicherlayout einer JSON-Dateien ist definiert als eine Bytefolge, die als Zeichenfolge gemäß [http://de.wikipedia.org/wiki/UTF-8 UTF-8-Standard] interpretiert wird. Dies hat zwei Vorteile: einerseits ist das Format dadurch mit allen gängigen Systemen kompatibel und überall gleich, andererseits kann jedes JSON-File einfach in einem Texteditor geöffnet und editiert werden und ist für Menschen und Maschinen gleichermaßen leicht lesbar.

Die Zuordung einer Bedeutung zu einem gegebenen Speicherinhalt erfolgt in JSON mit Hilfe einer Grammatik. Ein JSON-File enthält entweder ein gewöhnliches Array oder ein assoziatives Array (Dictionary):
JSON_file := array
| dictionary
Ein gewöhnliches Array wird als Folge von einem oder mehreren Elementen geschrieben, die durch Komma getrennt und in eckigen Klammern eingeschlossen sind (Zeichen, die in der Grammatik in einfache Anführungszeichen eingeschlossen sind, müssen explizit im JSON-File stehen). Leere Arrays sind ebenfalls erlaubt:
array := '[' elements ']'
| '[' ']'
elements := value
| value ',' elements
Ein Dictionary wird in ähnlicher Weise als Folge von Schlüssel/Wert-Paaren geschrieben, die durch Komma getrennt und in geschweiften Klammern eingeschlossen sind. Leere Dictionaries sind erlaubt. Die Schlüssel müssen immer Strings sein, gefolgt von einem Doppelpunkt:
dictionary := '{' pairs '}'
| '{' '}'
pairs := string ':' value
| string ':' value ',' pairs
Strings sind Zeichenfolgen (inklusive einiger Sonderzeichen wie "\n" für einen Zeilenumbruch), die in doppelte Anführungszeichen eingeschlossen sind, oder der Leerstring:
string := '"' '"'
| '"'characters'"'
Werte können Zahlen (ganze oder reelle Zahlen, definiert wie in Python), Boolesche Werte ('true' oder 'false'), Strings oder 'null' sein. Außerdem können Arrays und Dictionaries wiederum als Werte verwendet werden, wodurch sich beliebig tief geschachtelte, hierarchische Datenstrukturen ergeben:
value := number | string | boolean | null | array | dictionary
Hier ist ein einfaches Beispiel für ein JSON-File, das Ausschnitte aus einer Studenten-Datenbank enthält:
{
"Müller, Friedrich" : {
"Mathematik" : 2.0,
"ALDA" : 1.3
},
"Weise, Anna" : {
"Mathematik" : 1.0,
"Philosophie": 1.3
}
}
Das JSON-Format ist syntaktisch der Sprache Python sehr nahe, und kann mit einigen verherigen Definitionen direkt durch die <tt>eval()</tt>-Funktion in ein Python-Dictionary oder -Array umgewandelt werden.
# don't do this - it is highly '''unsafe''' and dangerous
true, false, null = True, False, None # fehlende Konstanten defininieren
res = eval(file("test.json").read().decode("utf_8")) # File einlesen und nach Python konvertieren
Dies sollte man jedoch '''auf keinen Fall''' tun, weil ein Hacker dadurch beliebigen Code ausführen könnte, den er vorher in das File 'test.json' eingeschmuggelt hat. Da die Funktion <tt>eval()</tt> nur prüft, ob der Ausdruck gültiges Python ist, aber nicht, ob das File gültiges JSON (also nur Daten, aber keinen ausführbaren Code) enthält, kann man dies nicht erkennen oder verhindern. Deshalb sollte man zum Einlesen von JSON stets das Python-Modul [http://docs.python.org/library/json.html json] verwenden, das ein manipuliertes File einfach zurückweisen würde:
# sicheres Einlesen und Konvertieren
import json, codecs

with codecs.open("test.json", 'r', encoding='utf-8') as f: # File im UTF-8 Format öffnen
res = json.load(f) # und als json einlesen

==Implementation von assoziativen Array-Klassen==

Die dritte Kante des Datenstruktur-Dreiecks bezieht sich schließlich auf die Realisierung der Datenstruktur als Klasse, indem man auf geeignet organisiertem Speicher die geforderten Operationen implementiert. In Python ist mit der Klasse <tt>dict</tt> eine sehr leistungsfähige Implementation eines assoziativen Arrays integraler Bestandteil der Sprache. Diese Implementation beruht auf dem Konzept der Hashtabellen, das wir in der Vorlesung [[Hashing und Hashtabellen|später behandeln]]. Man benötigt dafür eine Funktion <tt>hash(key)</tt>, die in Python für alle Standarddatentypen bereits implementiert ist. In diesem Abschnitt wollen wir zwei alternative Implementationen auf der Basis von sequentieller Suche und auf der Basis von Suchbäumen betrachten.

=== Realisierung durch sequentielle Suche===

Wenn für die Schlüssel nur ein Identitätsvergleich
key1 == key2
definiert ist, hat man keine Möglichkeit, die Schlüsselsuche durch eine spezielle Datenstruktur zu beschleunigen. Man speichert die Schlüssel/Wert-Paare dann einfach in einem gewöhnlichen Array, das man sequentiell durchsucht. Dazu implementieren wir zunächst eine Hilfsklasse, die Schlüssel/Wert-Paare aufnimmt:
class KeyValuePair:
def __init__(self, key, value):
self.key = key
self.value = value
Die Arrayklasse speichert die Paare in einem Array <tt>self.data</tt>, dessen aktuelle Länge der Größe des assoziativen Arrays entspricht. Damit ist das Speicherlayout der Klasse festgelegt:
class SequentialSearchArray:
def __init__(self):
self.data = []
def __len__(self):
return len(self.data)
Um auf die Daten zugreifen zu können, müssen wir nach dem richtigen Schlüssel suchen. Dazu implementieren wir die Hilfsfunktion <tt>findKey</tt>, die den Index des Schlüssels zurückgibt, oder <tt>None</tt>, wenn der Schlüssel nicht existiert:
def findKey(self, key):
for k in xrange(len(self.data)):
if key == self.data[k].key:
return k
return None
Beim Einfügen eines Elements müssen wir zuerst prüfen, ob es den Schlüssel schon gibt, und dann entweder die daten überschreiben oder ein neues Element anfügen:
def __setitem__(self, key, value):
k = self.findKey(key)
if k is None:
self.data.append(KeyValuePair(key, value)) # neues Paar einfügen
else:
self.data[k].value = value # Daten ersetzen
Die Suche hingegen löst eine Exception aus, wenn der Schlüssel nicht gefunden wurde:
def __getitem__(self, key):
k = self.findKey(key)
if k is None:
raise KeyError(key) # Schlüssel nicht gefunden => Fehler
else:
return self.data[k].value # Schlüssel gefunden => Daten zurückgeben
Die übrigen geforderten Funktionen sind ebenso einfach zu implementieren:
def has_key(self, key):
return (self.findKey(key) is not None)

def __delitem__(self, key):
k = self.findKey(key)
if k is None:
raise KeyError(key) # Schlüssel nicht gefunden => Fehler
else:
del self.data[k] # Schlüssel gefunden => löschen
Wegen der sequentiellen Suche hat der Zugriff auf ein Element in dieser Datenstruktur die Komplexität O(len(a)).

=== Realisierung als Suchbaum ===

Wenn für den Schlüsseltyp des assoziativen Arrays eine Ordnung definiert ist (wenn also <tt>key1 < key2</tt> oder <tt>cmp(key1, key2)</tt> unterstützt werden), kann man das Indexierungsproblem auf das Suchproblem zurückführen. Dann kann das assoziative Array effizient als selbst-balancierender Suchbaum imlementiert werden, so dass die Zugriffsfunktionen nur noch eine Komplexität in O(log(len(a))) haben. Die Datenstruktur des Suchbaums muss dafür so erweitert werden, dass zu jedem Schlüssel auch die zugehörigen Daten gespeichert werden. Man erweitert die Node-Klasse deshalb um ein Feld "value":
class Node:
def __init__(self, key, value):
self.key = key
self.data = value
self.left = self.right = None
Dann kann man eine Klasse <tt>TreeSearchArray</tt> realisieren, deren Konstruktor einen leeren Suchbaum initialisiert:
class TreeSearchArray:
def __init__(self):
self.root = None
self.size = 0
def __len__(self):
return self.size
Die Funktion <tt>__setitem__</tt> schaut nach, ob ein Eintrag mit dem betreffenden Schlüssel bereits existiert. Wenn ja, werden seine Daten mit den neuen Daten überschrieben, andernfalls wird ein neuer Eintrag angelegt. Intern werden dazu die bereits bekannten Funktionen <tt>treeSearch</tt> und <tt>treeInsert</tt> verwendet (siehe Abschnitt [[Suchen#Suchbäume|Suchbäume]]):
def __setitem__(self, key, value):
node = treeSearch(self.root, key)
if node is None:
self.root = treeInsert(self.root, key)
self.size += 1
node = treeSearch(self.root, key)
node.value = value
(Eine geschicktere Implementation würde natürlich den zweiten Aufruf von <tt>treeSearch</tt> eliminieren und das Setzen der Daten gleich in <tt>treeInsert</tt> erledigen. Dies ändert aber nichts an der Komplexität der Funktion.) Die Funktion <tt>__getitem__</tt> sucht ebenfalls einen Eintrag mit dem gegebenen Schlüssel. Wenn er gefunden wird, gibt sie die zugehörigen Daten zurück, andernfalls eine Fehlermeldung:
def __getitem__(self, key):
node = treeSearch(self.root, key)
if node is None:
raise KeyError(key)
else:
return node.value
Die Indexoperationen haben bei der Realisierung mit Baumsuche eine Komplexität in O(log n).

Ein wichtiges Beispiel für ein assoziatives Array, das auf diese Weise realisiert wurde, ist die C++ Standardklasse <tt>[http://www.sgi.com/tech/stl/Map.html std::map]</tt>.

[[Hashing und Hashtabellen|Nächstes Thema]]

Sortieren in linearer Zeit

2020-07-02T16:24:23Z

Alda: /* Bucket Sort */

Wir kehren an dieser Stelle nochmals zum Sortierproblem zurück und stellen uns die Frage, ob wir noch schnellere Algorithmen finden können, die eventuell sogar in O(N) statt in O(N*log(N)) zum Ziel kommen. Mit Hilfe der gerade eingeführten Suchbäumen werden wir zeigen, dass dies nicht möglich ist, solange für die Sortierschlüssel nur eine paarweise Vergleichsfunktion definiert ist. Besitzen wir jedoch zusätzliche Informationen über die Schlüssel, die uns die Anwendung des ''Bucket-Prinzips'' erlauben, ist das Sortieren in linearer Zeit möglich.

== Sortieren und Permutationen ==

Bevor wir die Grenzen des Sortierens mit Paarvergleichen analysieren, wollen wir noch etwas näher beleuchten, was beim Sortieren eigentlich geschieht. Dazu gehen wir noch einen Schritt zurück und schauen uns an, was beim Mischen eines zunächst sortierten Arrays passiert. Wir betrachten das Array mit den drei Element A, B, C sowie ein korrespondierendes ''Indexarray'', das angibt, an welcher Position im sortierten Array die drei Elemente gehören. Solange das Hauptarray noch sortiert ist, enthält das Indexarray einfach die aufsteigende Folge 0, 1, 2:
L = A B C # Hauptarray sortiert (0. Permutation)
I = 0 1 2 # Indexarray
Es gibt jetzt 5 weitere Anordnungsmöglichkeiten (imsgesamt also 6 = 3! Permutationen) für die drei Elementa A, B und C. Immer, wenn wir diese drei Elemente umordnen, ordnen wir das Indexarray so, dass das Element <tt>I[k]</tt> in jedem Indexarray uns angibt, wo sich der Buchstabe jetzt befindet, der ursprünglich (also in der sortierten Anordnung) an Position <tt>k</tt> stand:
L = A C B # 1. Permutation
I = 0 2 1

L = B A C # 2. Permutation
I = 1 0 2

L = B C A # 3. Permutation
I = 2 0 1

L = C A B # 4. Permutation
I = 1 2 0

L = C B A # 5. Permutation
I = 2 1 0
In der 5. Permutation sagt beispielsweise <tt>I[0] = 2</tt>, dass der ursprünglich 0. Buchstabe (das A) jetzt an Position 2 ist. Daraus folgt, dass wir ein permutiertes Array in linearer Zeit sortieren können, wenn uns das Indexarray bekannt ist. Wir müssen einfach einmal durch das Indexarray gehen und jedes Element von Position <tt>I[k]</tt> wieder an Position <tt>k</tt> verschieben:
def sortByIndexArray(L, I):
R = [None]*len(L) # zunächst leeres Ergebnisarray
for k in xrange(len(L)):
R[k] = L[I[k]] # Elemente sortiert in R einfügen
return R
Da man nur einmal über den Bereich k = 0 ... len(L)-1 gehen muss, ist der Aufwand dieser Funktion O(len(L)), also linear. Dieser Algorithmus ist z.B. nützlich, wenn man mehrere Arrays in der gleichen Weise sortieren muss, z.B. die Liste der Studentennamen und die Liste der dazugehörigen Übungspunkte. Man kann dann einfach einmal die Permutation des Indexarrays bestimmen, und dann alle Listen entsprechend sortieren. Wie man das Indexarray mit dem Standard-Sortieralgorithmus <tt>array.sort()</tt> bestimmen kann, ist Aufgabe im Übungsblatt 9.

==Sortieren als Suchproblem==

Wir haben gesehen, dass wir in linearer Zeit sortieren können, wenn uns die Permutation bzw. das zugehörige Indexarray bekannt ist. Die nächste Frage lautet deshalb: Wie viele Schritte brauchen wir, um die Permutation zu finden? Dabei ist es nur erlaubt, Schlüssel paarweise zu vergleichen, und man erhält jeweils eine ja/nein Antwort. Ein solches Vorgehen kann als Entscheidungsbaum dargestellt werden. Jeder Knoten ist eine Frage, und wir gehen zum linken Kind weiter, wenn die Frage mit "ja" beantwortet wurde, ansonsten zum rechten Kind. An jeder Kante stehen die jetzt noch in Frage kommenden Permutationen, und der jeweilige Kindknoten gibt uns die nächste Frage vor. Die Blätter enthalten das Indexarray, das der Permutation entspricht:
(L[0] < L[1])
ja / \ nein
ABC / \ BAC
ACB / \ CAB
BCA / \ CBA
/ \
(L[0] < L[2]) (L[0] < L[2])
/ \ / \
ja / nein \ / ja \ nein
ABC / BCA | | BAC \ CAB
ACB / | | \ CBA
/ (2 0 1) (1 0 2) \
(L[1] < L[2]) (L[1] < L[2])
/ \ / \
ja / \ nein ja / \ nein
ABC / \ ACB CAB / \ CBA
/ \ / \
(0 1 2) (0 2 1) (1 2 0) (2 1 0)

Der Suchaufwand im schlechtesten Fall entspricht offensichtlich der Tiefe des Baumes. Bei Arrays mit drei Elementen ist die Tiefe gerade 3, wir benötigen maximal 3 Fragen bis zum Ziel. Für Arrays der Länge n gilt allgemein: Es gibt N = n! verschiedene Permutationen, der Baum muss also n! Blätter haben. Wir haben im Abschnitt [[Suchen#Balance_eines_Suchbaumes|Suchen]] gesehen, dass die Tiefe eines Baumes minimal wird, wenn der Baum ''perfekt balanciert'' ist, und dass der balancierte Baum mit den meisten Blättern der ''vollständige Baum ist''. Die Tiefe des vollständigen Baums mit n! Blättern gibt uns also eine untere Schranke für die minimale Anzahl der Vergleiche im schlechtesten Fall.

Ein vollständiger Baum der Tiefe d hat 2d+1-1 Knoten und 2d Blätter:
{| border="0" cellspacing="0" cellpadding="5"
|-valign="center"
|[[Image:vollbaum.png|left]]
| vollständiger Baum 2d+1-1 Knoten 2d Blätter
|}

Im Fall des Sortierens von n Elementen gilt, dass es N = n! mögliche Permutation gibt. Ein Baum mit n! Blättern hat mindestens die Tiefe log(n!). Im obigen Beispiel für n=3 gilt 3! = 1*2*3 = 6 und damit für die Tiefe d
:::<math>d = \lceil \log_2(6)\rceil \approx \lceil 2.6\rceil = 3</math>
Im ungünstigsten Fall braucht man bei dem Frage-Baum drei Schritte. Weil aber <math>\log(6)\approx 2.6 < 3</math> muss nicht jeder Pfad zu Ende durchlaufen werden, um die Lösung zu bekommen.

Allgemein gilt
::<math>d \ge \log_2(n!)</math>
Wir können die Tiefe am einfachsten durch die ''Stirlingsche Näherungsformel für die Fakultät'' abschätzen:
::<math>n! \approx \sqrt{2\pi n} \left(\frac{n}{e}\right)^n</math>,
die asymptitisch für große n gilt. Einsetzen liefert
::<math>d \ge \log_2(n!) \in \Omega\left(\log_2\left(\sqrt{2\pi n} \left(\frac{n}{e}\right)^n\right)\right)</math>
Der Logarithmus eines Produkts ist gleich der Summe der Logarithmen der einzelnen Faktoren:
::<math>\Omega\left(\log_2\left(\sqrt{2\pi n} \left(\frac{n}{e}\right)^n\right)\right) = \Omega(\log_2(\sqrt{2\pi})) + \Omega(\log_2(\sqrt{n})) + \Omega(\log_2(n^n)) - \Omega(\log_2(e^n))</math>
Wir vereinfachen die rechte Seite nach den Regeln der O-Notation: nur der am schnellsten wachsende Term bleibt übrig:
::<math>\Omega\left(\log_2\left(\sqrt{2\pi n} \left(\frac{n}{e}\right)^n\right)\right) = \Omega(\log_2(n^n))</math>.
Den Exponenten in nn kann man vor den Logarithmus ziehen, und die Basis des Logarithmus spielt keine Rolle. Wir erhalten somit:
::<math>d \in \Omega(n \log n)</math>.
Somit braucht man im schlechtesten Fall mindestens <math>\Omega(n \log n)</math> Vergleiche, und Merge Sort ist somit optimal und kann nicht weiter verbessert werden, solange man sich auf paarweise Vergleiche von Schlüsseln beschränkt.

Eine exakte Herleitung dieser Tatsache, ohne Verwendung der Stirlingschen Formel, ist möglich durch

===Abschätzung von Summen durch Integrale===

Schreibt man die Fakultät als Produkt aus, und transformiert den Logarithmus des Produkts in eine Summe von Logarithmen, erhalten wir:
::<math>d \ge \log_2(n!) = \log_2(1\cdot 2\cdot ... \cdot n) = \log_2(1) + \log_2(2) + ... + \log_2(n) = \sum_{k=1}^n \log_2(k) = \frac{1}{\ln(2)}\sum_{k=1}^n \ln(k) = \frac{1}{\ln(2)}\sum_{k=2}^n \ln(k)</math>
Die letzte Identität gilt, weil <math>\ln(1) = 0</math> in der Summe weggelassen werden kann. Eine untere Schranke für die Tiefe kann man explizit bestimmen durch die Methode der

Gegeben sei eine monoton wachsende Funktion f(x) (blaue Kurve). Das bestimmte Integral über die Funktion sei
:::<math>\int_{x_1}^{x_2} f(x)dx</math>.
Wenn wir das Funktionsargument x abrunden (schwarze Kurve), entsteht ein Integral, das einen kleineren Wert als das ursprüngliche Integral hat. Runden wir auf (rote Kurve), entsteht ein Integral mit einem größeren Wert:

{| border="0" cellspacing="0" cellpadding="5"
|-valign="center"
|[[Image:integralGraph.png|400px|left]]
| <math>\int_{x_1}^{x_2} f(\lfloor x \rfloor)dx \le \int_{x_1}^{x_2} f(x)dx \le \int_{x_1}^{x_2} f(\lceil x \rceil)dx</math>
|}
In unserem Zusammenhang sind x1 und x2 positive ganze Zahlen. Deshalb gilt
:::<math>f(\lfloor x \rfloor)_{x_1}^{x_1+1}= f(x_1),</math>
:::<math>f(\lfloor x \rfloor)_{x_1+1}^{x_1+2}= f(x_1+1)</math>
:::<math>...</math>
:::<math>f(\lfloor x \rfloor)_{x_2-1}^{x_2}= f(x_2-1)</math>
Wir können die obigen Integrale daher folgendermaßen vereinfachen:
:::<math>\begin{array}{lcl}
\int_{x_1}^{x_2} f(\lfloor x \rfloor) dx &=& \int_{x_1}^{x_1 + 1} f(\lfloor x \rfloor) dx + ...+ \int_{x_2-1}^{x_2} f(\lfloor x \rfloor) dx \\
& = & \int_{x_1}^{x_1 + 1} f(x_1) dx + ...+ \int_{x_2-1}^{x_2} f(x_2-1) dx \\
& = & f(x_1) \int_{x_1}^{x_1 + 1} dx + ...+ f(x_2-1) \int_{x_2-1}^{x_2} dx \\
& = & f(x_1) + ...+ f(x_2-1) \\
& = & \sum_{k=x_1}^{x_2-1} f(k)
\end{array}</math>
für die Fläche unter den schwarzen Rechtecken sowie
:::<math>\begin{array}{lcl}
\int_{x_1}^{x_2} f(\lceil x \rceil) dx &=& \int_{x_1}^{x_1 + 1} f(\lceil x \rceil) dx + ...+ \int_{x_2-1}^{x_2} f(\lceil x \rceil) dx \\
& = & \int_{x_1}^{x_1 + 1} f(x_1+1) dx + ...+ \int_{x_2-1}^{x_2} f(x_2) dx \\
& = & f(x_1+1) \int_{x_1}^{x_1 + 1} dx + ...+ f(x_2) \int_{x_2-1}^{x_2} dx \\
& = & f(x_1+1) + ...+ f(x_2) \\
& = & \sum_{k=x_1+1}^{x_2} f(k)
\end{array}</math>
für die Fläche unter den roten Rechtecken. Zusammenfassend gilt also
<math> \sum_{k=x_1}^{x_2-1} f(k) \le \int_{x_1}^{x_2} f(x)dx</math> und
<math> \sum_{k=x_1+1}^{x_2} f(k) \ge \int_{x_1}^{x_2} f(x)dx</math>
Für unser Problem setzen wir f(k) = ln(k), x1+1 = 2, und x2 = n. Also können wir abschätzen
:::<math>\sum_{k=x_1+1}^{x_2} f(k) = \frac{1}{\ln(2)}\sum_{k=2}^{n} \ln(k) \ge \frac{1}{\ln(2)}\int_1^n \ln(x) dx</math>
Das Integral ist leicht zu lösen, und wir erhalten
:::<math>\frac{1}{\ln(2)}\sum_{k=2}^{n} \ln(k) \ge \frac{1}{\ln(2)}\left[x\ln(x)-x\right]_{x=1}^{n} = \frac{1}{\ln(2)}(n\ln(n)-n+1)=n\log_2(n) - \frac{n-1}{\ln(2)} \in \Omega(n \log(n))</math>
Folglich gilt:
:::<math>d\ge\log_2(n!) = \frac{1}{\ln(2)}\sum_{k=2}^{n} \ln(k) \in \Omega(n \log(n))</math>
Mit anderen Worten: '''Kein Sortieralgorithmus auf Basis paarweise Vergleiche ist asymptotisch schneller als Mergesort, denn die Anzahl der Vergleiche (= Tiefe des Entscheidungsbaumes) ist <math>\Omega(n \log(n))</math>'''. Falls man einen schnelleren Sortieralgorithmus benötigt, muss man ein anderes algorithmisches Prinzip verwenden.

==Effizientere Sortieralgorithmen==

Wir haben gezeigt, dass mit paarweisen Größenvergleichen allein kein Sortieralgorithmus schneller als <math>\Omega(n \log n)</math> sein kann. Um einen besseren Algorithmus zu finden, dürfen wir nicht nur die relative Größe der Schlüssel (also die Ordnung) berücksichtigen, sondern müssen die Werte selbst verwenden. Der entscheidende Trick dabei ist das

=== Bucket-Prinzip ===

Man definiert eine Funktion <tt>quantize(key, M)</tt>, die jeden Schlüssel auf eine ganze Zahl im Bereich <tt>[0,...,M-1]</tt> abbildet. Mit Hilfe dieser Zahlen werden die Schlüssel auf M ''Buckets'' aufgeteilt, und das Sortieren kann dann in jedem Bucket getrennt erfolgen. Am Ende setzt man aus den Inhalten der Buckets das gesamte Array (sortiert) wieder zusammen. Wir zeigen unten, dass man damit lineare Zeit erreicht.

Um für das Sortieren brauchbar zu sein, muss die Funktion <tt>quantize()</tt> ''Ordnung erhaltend'' definiert sein:
wenn key1 <= key2, gilt auch quantize(key1, M) <= quantize(key2, M)
Eine solche Abbildung nennt man ''Quantisierung''. Allgemein bekannt ist der Prozess der Quantisierung z.B. bei Digitalkameras: Hier wird in jedem Pixel eine reell-wertige Lichtintensität gemessen, die im resultierenden Bild mit nur 256 Intensitätsabstufungen pro Farbe abgespeichert wird (bzw. mit bis zu 65536 Abstufungen bei Kameras mit sogenanntem "high dynamic range"). Bleibt die Ordnung bei der Abbildung von Schlüsseln auf natürliche Zahlen nicht erhalten, spricht man von ''Hashing''. Hashing wird zur Implementation von [[Hashing und Hashtabellen|Hashtabellen]] nutzbringend eingesetzt.

Der einfachste Fall liegt vor, wenn die Schlüssel bereits genze Zahlen im Bereich <tt>[0,...,M-1]</tt> sind. Dann ist die <tt>quantize()</tt> einfach die Identität. Wir nehmen an, dass die Daten als Schlüssel/Wert-Paare in einem Array <tt>a</tt> gespeichert sind, und wir können das Sortieren wie folgt implementieren:
def integerSort(a, M):
# erzeuge M leere Buckets
buckets = [[] for k in range(M)]

# verteile die Daten auf die Buckets
for k in range(len(a)):
buckets[a[k].key].append(a[k]) # a[k].key sind Integer-Schlüssel in [0,...,M-1]

# setze das Array a aus den Buckets sortiert wieder zusammen
start = 0 # Anfangsindex des ersten Buckets
for k in range(M):
end = start + len(buckets[k]) # Endindex des aktuellen Buckets
a[start:end] = buckets[k] # Daten an der richtigen Position in a einfügen
start = end # Anfangsindex für das nächste Bucket aktualisieren
Das Array <tt>a</tt> ist am Ende sortiert, weil wir den Inhalt der Buckets nach aufsteigendem Bucket-Index, und damit automatisch nach aufsteigenden Schlüsseln, in <tt>a</tt> einfügen. Das Sortieren ist außerdem ''stabil'', da Daten mit gleichem Schlüssel immer hinten an das jeweilige Bucket angefügt werden.

Die Komplexität des Algorithmus ist <math>O(N)</math> mit <tt>N = len(a)</tt>, solange
::<math>M \in O(N)</math>
gilt: Das Erzeugen der Buckets erfordert <math>O(M)</math> Schritte und das Verteilen der Daten auf die Buckets <math>O(N)</math> Schritte (weil <tt>bucket[k].append()</tt> amortisiert konstante Komplexität hat). Das Zusammensetzen des sortierten Arrays wird vom Kopieren der Daten dominiert, welches die Komplexität
::<math>\sum_{k=0}^{M-1} O(N_k)= O\left(\sum_{k=0}^{M-1} N_k\right)</math>
besitzt, wobei <tt>Nk=len(buckets[k])</tt> die Größe des k-ten Buckets ist. Die Gesamtanzahl der Daten in allen Buckets zusammen ist aber gerade wieder die Größe von <tt>a</tt>, also
::<math>O\left(\sum_{k=0}^{M-1} N_k\right) = O(N)</math>
Nach der Sequenzregel ist die Gesamtkomplexität somit <math>O(M + N)=O(N)</math>, falls <math>M \in O(N)</math> gilt.

===Bucket Sort===

Der Algorithmus wird nur wenig komplizierter, wenn die Schlüssel beliebig sein können, aber eine ordnung-erhaltende <tt>quantize()</tt>-Funktion vorhanden ist. Allerdings geht bei der Quantisierung, also der Abbildung von Schlüsseln auf Bucket-Indizes, ein Teil der Schlüsselinformation verloren. Die Elemente im selben Bucket haben im Allgemeinen nicht exakt den gleichen Schlüssel, so dass jeder Bucket noch explizit sortiert werden muss. Diese Tatsache führt zu einer zusätzlichen Einschränkung: einerseits muss für die Anzahl der Buckets nach wie vor
::<math>M \in O(N)</math>
gelten, aber andererseits sollte jeder Bucket nur wenige Daten enthalten, so dass das Sortieren innerhalb der Buckets effizient ist. Wir fordern deshalb, dass <math>N_k \in O(1)</math> sein soll. Unter der Voraussetzung, dass <tt>quantize()</tt> die Daten gleichmäßig auf alle Buckets verteilt (dazu unten mehr), gilt für die Bucketgrößen
::<math>N_k \in O\left(\frac{N}{M}\right)</math>
denn wir verteilen N Elemente auf M Buckets. Beide Bedingungen sind erfüllt, wenn
::<math>M = \frac{N}{d}</math>
gilt, wobei d eine Konstante unabhängig von N ist. In der Praxis erzielt man gute Resultate mit d ≈ 10 (die beste Wahl hängt im konkreten Fall von der Schlüsselverteilung und von der <tt>quantize()</tt>-Funktion ab). Wir übergeben die Konstante d und die <tt>quantize()</tt>-Funktion als Parameter an den Algorithmus:
def bucketSort(a, quant, d):
N = len(a)
M = int(N // d) + 1 # Anzahl der Buckets festlegen (+1, damit es mindestens ein Bucket gibt)

# M leere Buckets erzeugen
buckets = [[] for k in range(M)]

# Daten auf die Buckets verteilen
for k in range(len(a)):
index = quant(a[k].key, M) # Bucket-Index berechnen
buckets[index].append(a[k]) # a[k] im passenden Bucket einfügen

# Daten sortiert wieder in a einfügen
start = 0 # Anfangsindex des ersten Buckets
for k in range(M):
insertionSort(buckets[k]) # Daten innerhalb des aktuellen Buckets sortieren
end = start + len(buckets[k]) # Endindex des aktuellen Buckets
a[start:end] = buckets[k] # Daten an der richtigen Position in a einfügen
start += len(buckets[k]) # Anfangsindex für nächsten Bucket aktualisieren
Wir verwenden zum Sortieren der Daten in jedem Bucket <tt>insertionSort()</tt>. Dies ist aus zwei Gründen eine gute Wahl: Erstens haben wir die Buckets so konstruiert, dass jeder Bucket nur wenige Elemente enthält (<math>N_k \in O(1)</math>), und für kleine Arrays ist Insertion Sort der schnellste Algorithmus. Zweitens ist Insertion Sort ein ''stabiler'' Sortieralgorithmus, und demzufolge ist auch das gesamte <tt>bucketSort()</tt> stabil.

Unter der Voraussetzung, dass <tt>quantize()</tt> konstante Zeit für die Quantisierung eines Schlüssels benötigt, unterscheidet sich die Komplexitätsanalyse von <tt>bucketSort()</tt> nur in einem Punkt von <tt>integerSort()</tt>, nämlich durch das zusätzliche Sortieren in jedem Bucket. Bei Verwendung von Insertion Sort hat dies quadratische Komplexität in <math>N_k</math>, aber wenn <math>N_k \in O(1)</math> erfüllt ist, gilt <math>O(N_k^2) = O(1^2) = O(1)</math>. Das Sortieren hat also konstante Komplexität pro Bucket, und somit ist die Gesamtkomplexität von <tt>bucketSort()</tt> linear in N, wie am Anfang des Abschnitts gewünscht.

Allerdings steht und fällt diese Analyse damit, dass die <tt>quantize()</tt>-Funktion die Daten tatsächlich gleichmäßig auf die Buckets verteilt. Andernfalls könnten im schlechtesten Fall alle Daten in einem einzigen Bucket landen, und dann hätte <tt>bucketSort()</tt> quadratische Komplexität. Die <tt>quantize()</tt>-Funktion muss deshalb je nach der Wahrscheinlichkeitsverteilung der Schlüssel immer wieder anders festgelegt werden. Sehr einfach ist dies, wenn die Schlüssel in einem gewissen Intervall <tt>[U,...,V)</tt> gleichverteilt sind: dann kann man einfach das Intervall <tt>[U,...,V)</tt> durch eine lineare Gleichung auf das Intervall <tt>[0,...M-1]</tt> abbilden und dann abrunden. Für <tt>U = 0</tt> und <tt>V = 1</tt> erhalten wir beilspielsweise:
'''Beispiel:'''
# keys sind reelle Zahlen in [0, 1)

def quantize(key, M):
return int(key * M)
Die Definition einer geeigneten <tt>quantize()</tt>-Funktion für eine andere Schlüsselverteilung ist Bestandteil einer Übungsaufgabe. In der Praxis findet man allerdings, dass die Verteilung der Daten auf die Buckets nicht übermäßig kritisch ist -- <tt>bucketSort()</tt> bleibt auch dann ein sehr schneller Algorithmus, wenn die Verteilung nicht ganz gleichmäßig gelingt. Die obige Implementation ist somit ein guter Default für viele Anwendungen.

[[Prioritätswarteschlangen|Nächstes Thema]]

Sortieren in linearer Zeit

2020-07-02T16:20:15Z

Alda: /* Bucket Sort */

Wir kehren an dieser Stelle nochmals zum Sortierproblem zurück und stellen uns die Frage, ob wir noch schnellere Algorithmen finden können, die eventuell sogar in O(N) statt in O(N*log(N)) zum Ziel kommen. Mit Hilfe der gerade eingeführten Suchbäumen werden wir zeigen, dass dies nicht möglich ist, solange für die Sortierschlüssel nur eine paarweise Vergleichsfunktion definiert ist. Besitzen wir jedoch zusätzliche Informationen über die Schlüssel, die uns die Anwendung des ''Bucket-Prinzips'' erlauben, ist das Sortieren in linearer Zeit möglich.

== Sortieren und Permutationen ==

Bevor wir die Grenzen des Sortierens mit Paarvergleichen analysieren, wollen wir noch etwas näher beleuchten, was beim Sortieren eigentlich geschieht. Dazu gehen wir noch einen Schritt zurück und schauen uns an, was beim Mischen eines zunächst sortierten Arrays passiert. Wir betrachten das Array mit den drei Element A, B, C sowie ein korrespondierendes ''Indexarray'', das angibt, an welcher Position im sortierten Array die drei Elemente gehören. Solange das Hauptarray noch sortiert ist, enthält das Indexarray einfach die aufsteigende Folge 0, 1, 2:
L = A B C # Hauptarray sortiert (0. Permutation)
I = 0 1 2 # Indexarray
Es gibt jetzt 5 weitere Anordnungsmöglichkeiten (imsgesamt also 6 = 3! Permutationen) für die drei Elementa A, B und C. Immer, wenn wir diese drei Elemente umordnen, ordnen wir das Indexarray so, dass das Element <tt>I[k]</tt> in jedem Indexarray uns angibt, wo sich der Buchstabe jetzt befindet, der ursprünglich (also in der sortierten Anordnung) an Position <tt>k</tt> stand:
L = A C B # 1. Permutation
I = 0 2 1

L = B A C # 2. Permutation
I = 1 0 2

L = B C A # 3. Permutation
I = 2 0 1

L = C A B # 4. Permutation
I = 1 2 0

L = C B A # 5. Permutation
I = 2 1 0
In der 5. Permutation sagt beispielsweise <tt>I[0] = 2</tt>, dass der ursprünglich 0. Buchstabe (das A) jetzt an Position 2 ist. Daraus folgt, dass wir ein permutiertes Array in linearer Zeit sortieren können, wenn uns das Indexarray bekannt ist. Wir müssen einfach einmal durch das Indexarray gehen und jedes Element von Position <tt>I[k]</tt> wieder an Position <tt>k</tt> verschieben:
def sortByIndexArray(L, I):
R = [None]*len(L) # zunächst leeres Ergebnisarray
for k in xrange(len(L)):
R[k] = L[I[k]] # Elemente sortiert in R einfügen
return R
Da man nur einmal über den Bereich k = 0 ... len(L)-1 gehen muss, ist der Aufwand dieser Funktion O(len(L)), also linear. Dieser Algorithmus ist z.B. nützlich, wenn man mehrere Arrays in der gleichen Weise sortieren muss, z.B. die Liste der Studentennamen und die Liste der dazugehörigen Übungspunkte. Man kann dann einfach einmal die Permutation des Indexarrays bestimmen, und dann alle Listen entsprechend sortieren. Wie man das Indexarray mit dem Standard-Sortieralgorithmus <tt>array.sort()</tt> bestimmen kann, ist Aufgabe im Übungsblatt 9.

==Sortieren als Suchproblem==

Wir haben gesehen, dass wir in linearer Zeit sortieren können, wenn uns die Permutation bzw. das zugehörige Indexarray bekannt ist. Die nächste Frage lautet deshalb: Wie viele Schritte brauchen wir, um die Permutation zu finden? Dabei ist es nur erlaubt, Schlüssel paarweise zu vergleichen, und man erhält jeweils eine ja/nein Antwort. Ein solches Vorgehen kann als Entscheidungsbaum dargestellt werden. Jeder Knoten ist eine Frage, und wir gehen zum linken Kind weiter, wenn die Frage mit "ja" beantwortet wurde, ansonsten zum rechten Kind. An jeder Kante stehen die jetzt noch in Frage kommenden Permutationen, und der jeweilige Kindknoten gibt uns die nächste Frage vor. Die Blätter enthalten das Indexarray, das der Permutation entspricht:
(L[0] < L[1])
ja / \ nein
ABC / \ BAC
ACB / \ CAB
BCA / \ CBA
/ \
(L[0] < L[2]) (L[0] < L[2])
/ \ / \
ja / nein \ / ja \ nein
ABC / BCA | | BAC \ CAB
ACB / | | \ CBA
/ (2 0 1) (1 0 2) \
(L[1] < L[2]) (L[1] < L[2])
/ \ / \
ja / \ nein ja / \ nein
ABC / \ ACB CAB / \ CBA
/ \ / \
(0 1 2) (0 2 1) (1 2 0) (2 1 0)

Der Suchaufwand im schlechtesten Fall entspricht offensichtlich der Tiefe des Baumes. Bei Arrays mit drei Elementen ist die Tiefe gerade 3, wir benötigen maximal 3 Fragen bis zum Ziel. Für Arrays der Länge n gilt allgemein: Es gibt N = n! verschiedene Permutationen, der Baum muss also n! Blätter haben. Wir haben im Abschnitt [[Suchen#Balance_eines_Suchbaumes|Suchen]] gesehen, dass die Tiefe eines Baumes minimal wird, wenn der Baum ''perfekt balanciert'' ist, und dass der balancierte Baum mit den meisten Blättern der ''vollständige Baum ist''. Die Tiefe des vollständigen Baums mit n! Blättern gibt uns also eine untere Schranke für die minimale Anzahl der Vergleiche im schlechtesten Fall.

Ein vollständiger Baum der Tiefe d hat 2d+1-1 Knoten und 2d Blätter:
{| border="0" cellspacing="0" cellpadding="5"
|-valign="center"
|[[Image:vollbaum.png|left]]
| vollständiger Baum 2d+1-1 Knoten 2d Blätter
|}

Im Fall des Sortierens von n Elementen gilt, dass es N = n! mögliche Permutation gibt. Ein Baum mit n! Blättern hat mindestens die Tiefe log(n!). Im obigen Beispiel für n=3 gilt 3! = 1*2*3 = 6 und damit für die Tiefe d
:::<math>d = \lceil \log_2(6)\rceil \approx \lceil 2.6\rceil = 3</math>
Im ungünstigsten Fall braucht man bei dem Frage-Baum drei Schritte. Weil aber <math>\log(6)\approx 2.6 < 3</math> muss nicht jeder Pfad zu Ende durchlaufen werden, um die Lösung zu bekommen.

Allgemein gilt
::<math>d \ge \log_2(n!)</math>
Wir können die Tiefe am einfachsten durch die ''Stirlingsche Näherungsformel für die Fakultät'' abschätzen:
::<math>n! \approx \sqrt{2\pi n} \left(\frac{n}{e}\right)^n</math>,
die asymptitisch für große n gilt. Einsetzen liefert
::<math>d \ge \log_2(n!) \in \Omega\left(\log_2\left(\sqrt{2\pi n} \left(\frac{n}{e}\right)^n\right)\right)</math>
Der Logarithmus eines Produkts ist gleich der Summe der Logarithmen der einzelnen Faktoren:
::<math>\Omega\left(\log_2\left(\sqrt{2\pi n} \left(\frac{n}{e}\right)^n\right)\right) = \Omega(\log_2(\sqrt{2\pi})) + \Omega(\log_2(\sqrt{n})) + \Omega(\log_2(n^n)) - \Omega(\log_2(e^n))</math>
Wir vereinfachen die rechte Seite nach den Regeln der O-Notation: nur der am schnellsten wachsende Term bleibt übrig:
::<math>\Omega\left(\log_2\left(\sqrt{2\pi n} \left(\frac{n}{e}\right)^n\right)\right) = \Omega(\log_2(n^n))</math>.
Den Exponenten in nn kann man vor den Logarithmus ziehen, und die Basis des Logarithmus spielt keine Rolle. Wir erhalten somit:
::<math>d \in \Omega(n \log n)</math>.
Somit braucht man im schlechtesten Fall mindestens <math>\Omega(n \log n)</math> Vergleiche, und Merge Sort ist somit optimal und kann nicht weiter verbessert werden, solange man sich auf paarweise Vergleiche von Schlüsseln beschränkt.

Eine exakte Herleitung dieser Tatsache, ohne Verwendung der Stirlingschen Formel, ist möglich durch

===Abschätzung von Summen durch Integrale===

Schreibt man die Fakultät als Produkt aus, und transformiert den Logarithmus des Produkts in eine Summe von Logarithmen, erhalten wir:
::<math>d \ge \log_2(n!) = \log_2(1\cdot 2\cdot ... \cdot n) = \log_2(1) + \log_2(2) + ... + \log_2(n) = \sum_{k=1}^n \log_2(k) = \frac{1}{\ln(2)}\sum_{k=1}^n \ln(k) = \frac{1}{\ln(2)}\sum_{k=2}^n \ln(k)</math>
Die letzte Identität gilt, weil <math>\ln(1) = 0</math> in der Summe weggelassen werden kann. Eine untere Schranke für die Tiefe kann man explizit bestimmen durch die Methode der

Gegeben sei eine monoton wachsende Funktion f(x) (blaue Kurve). Das bestimmte Integral über die Funktion sei
:::<math>\int_{x_1}^{x_2} f(x)dx</math>.
Wenn wir das Funktionsargument x abrunden (schwarze Kurve), entsteht ein Integral, das einen kleineren Wert als das ursprüngliche Integral hat. Runden wir auf (rote Kurve), entsteht ein Integral mit einem größeren Wert:

{| border="0" cellspacing="0" cellpadding="5"
|-valign="center"
|[[Image:integralGraph.png|400px|left]]
| <math>\int_{x_1}^{x_2} f(\lfloor x \rfloor)dx \le \int_{x_1}^{x_2} f(x)dx \le \int_{x_1}^{x_2} f(\lceil x \rceil)dx</math>
|}
In unserem Zusammenhang sind x1 und x2 positive ganze Zahlen. Deshalb gilt
:::<math>f(\lfloor x \rfloor)_{x_1}^{x_1+1}= f(x_1),</math>
:::<math>f(\lfloor x \rfloor)_{x_1+1}^{x_1+2}= f(x_1+1)</math>
:::<math>...</math>
:::<math>f(\lfloor x \rfloor)_{x_2-1}^{x_2}= f(x_2-1)</math>
Wir können die obigen Integrale daher folgendermaßen vereinfachen:
:::<math>\begin{array}{lcl}
\int_{x_1}^{x_2} f(\lfloor x \rfloor) dx &=& \int_{x_1}^{x_1 + 1} f(\lfloor x \rfloor) dx + ...+ \int_{x_2-1}^{x_2} f(\lfloor x \rfloor) dx \\
& = & \int_{x_1}^{x_1 + 1} f(x_1) dx + ...+ \int_{x_2-1}^{x_2} f(x_2-1) dx \\
& = & f(x_1) \int_{x_1}^{x_1 + 1} dx + ...+ f(x_2-1) \int_{x_2-1}^{x_2} dx \\
& = & f(x_1) + ...+ f(x_2-1) \\
& = & \sum_{k=x_1}^{x_2-1} f(k)
\end{array}</math>
für die Fläche unter den schwarzen Rechtecken sowie
:::<math>\begin{array}{lcl}
\int_{x_1}^{x_2} f(\lceil x \rceil) dx &=& \int_{x_1}^{x_1 + 1} f(\lceil x \rceil) dx + ...+ \int_{x_2-1}^{x_2} f(\lceil x \rceil) dx \\
& = & \int_{x_1}^{x_1 + 1} f(x_1+1) dx + ...+ \int_{x_2-1}^{x_2} f(x_2) dx \\
& = & f(x_1+1) \int_{x_1}^{x_1 + 1} dx + ...+ f(x_2) \int_{x_2-1}^{x_2} dx \\
& = & f(x_1+1) + ...+ f(x_2) \\
& = & \sum_{k=x_1+1}^{x_2} f(k)
\end{array}</math>
für die Fläche unter den roten Rechtecken. Zusammenfassend gilt also
<math> \sum_{k=x_1}^{x_2-1} f(k) \le \int_{x_1}^{x_2} f(x)dx</math> und
<math> \sum_{k=x_1+1}^{x_2} f(k) \ge \int_{x_1}^{x_2} f(x)dx</math>
Für unser Problem setzen wir f(k) = ln(k), x1+1 = 2, und x2 = n. Also können wir abschätzen
:::<math>\sum_{k=x_1+1}^{x_2} f(k) = \frac{1}{\ln(2)}\sum_{k=2}^{n} \ln(k) \ge \frac{1}{\ln(2)}\int_1^n \ln(x) dx</math>
Das Integral ist leicht zu lösen, und wir erhalten
:::<math>\frac{1}{\ln(2)}\sum_{k=2}^{n} \ln(k) \ge \frac{1}{\ln(2)}\left[x\ln(x)-x\right]_{x=1}^{n} = \frac{1}{\ln(2)}(n\ln(n)-n+1)=n\log_2(n) - \frac{n-1}{\ln(2)} \in \Omega(n \log(n))</math>
Folglich gilt:
:::<math>d\ge\log_2(n!) = \frac{1}{\ln(2)}\sum_{k=2}^{n} \ln(k) \in \Omega(n \log(n))</math>
Mit anderen Worten: '''Kein Sortieralgorithmus auf Basis paarweise Vergleiche ist asymptotisch schneller als Mergesort, denn die Anzahl der Vergleiche (= Tiefe des Entscheidungsbaumes) ist <math>\Omega(n \log(n))</math>'''. Falls man einen schnelleren Sortieralgorithmus benötigt, muss man ein anderes algorithmisches Prinzip verwenden.

==Effizientere Sortieralgorithmen==

Wir haben gezeigt, dass mit paarweisen Größenvergleichen allein kein Sortieralgorithmus schneller als <math>\Omega(n \log n)</math> sein kann. Um einen besseren Algorithmus zu finden, dürfen wir nicht nur die relative Größe der Schlüssel (also die Ordnung) berücksichtigen, sondern müssen die Werte selbst verwenden. Der entscheidende Trick dabei ist das

=== Bucket-Prinzip ===

Man definiert eine Funktion <tt>quantize(key, M)</tt>, die jeden Schlüssel auf eine ganze Zahl im Bereich <tt>[0,...,M-1]</tt> abbildet. Mit Hilfe dieser Zahlen werden die Schlüssel auf M ''Buckets'' aufgeteilt, und das Sortieren kann dann in jedem Bucket getrennt erfolgen. Am Ende setzt man aus den Inhalten der Buckets das gesamte Array (sortiert) wieder zusammen. Wir zeigen unten, dass man damit lineare Zeit erreicht.

Um für das Sortieren brauchbar zu sein, muss die Funktion <tt>quantize()</tt> ''Ordnung erhaltend'' definiert sein:
wenn key1 <= key2, gilt auch quantize(key1, M) <= quantize(key2, M)
Eine solche Abbildung nennt man ''Quantisierung''. Allgemein bekannt ist der Prozess der Quantisierung z.B. bei Digitalkameras: Hier wird in jedem Pixel eine reell-wertige Lichtintensität gemessen, die im resultierenden Bild mit nur 256 Intensitätsabstufungen pro Farbe abgespeichert wird (bzw. mit bis zu 65536 Abstufungen bei Kameras mit sogenanntem "high dynamic range"). Bleibt die Ordnung bei der Abbildung von Schlüsseln auf natürliche Zahlen nicht erhalten, spricht man von ''Hashing''. Hashing wird zur Implementation von [[Hashing und Hashtabellen|Hashtabellen]] nutzbringend eingesetzt.

Der einfachste Fall liegt vor, wenn die Schlüssel bereits genze Zahlen im Bereich <tt>[0,...,M-1]</tt> sind. Dann ist die <tt>quantize()</tt> einfach die Identität. Wir nehmen an, dass die Daten als Schlüssel/Wert-Paare in einem Array <tt>a</tt> gespeichert sind, und wir können das Sortieren wie folgt implementieren:
def integerSort(a, M):
# erzeuge M leere Buckets
buckets = [[] for k in range(M)]

# verteile die Daten auf die Buckets
for k in range(len(a)):
buckets[a[k].key].append(a[k]) # a[k].key sind Integer-Schlüssel in [0,...,M-1]

# setze das Array a aus den Buckets sortiert wieder zusammen
start = 0 # Anfangsindex des ersten Buckets
for k in range(M):
end = start + len(buckets[k]) # Endindex des aktuellen Buckets
a[start:end] = buckets[k] # Daten an der richtigen Position in a einfügen
start = end # Anfangsindex für das nächste Bucket aktualisieren
Das Array <tt>a</tt> ist am Ende sortiert, weil wir den Inhalt der Buckets nach aufsteigendem Bucket-Index, und damit automatisch nach aufsteigenden Schlüsseln, in <tt>a</tt> einfügen. Das Sortieren ist außerdem ''stabil'', da Daten mit gleichem Schlüssel immer hinten an das jeweilige Bucket angefügt werden.

Die Komplexität des Algorithmus ist <math>O(N)</math> mit <tt>N = len(a)</tt>, solange
::<math>M \in O(N)</math>
gilt: Das Erzeugen der Buckets erfordert <math>O(M)</math> Schritte und das Verteilen der Daten auf die Buckets <math>O(N)</math> Schritte (weil <tt>bucket[k].append()</tt> amortisiert konstante Komplexität hat). Das Zusammensetzen des sortierten Arrays wird vom Kopieren der Daten dominiert, welches die Komplexität
::<math>\sum_{k=0}^{M-1} O(N_k)= O\left(\sum_{k=0}^{M-1} N_k\right)</math>
besitzt, wobei <tt>Nk=len(buckets[k])</tt> die Größe des k-ten Buckets ist. Die Gesamtanzahl der Daten in allen Buckets zusammen ist aber gerade wieder die Größe von <tt>a</tt>, also
::<math>O\left(\sum_{k=0}^{M-1} N_k\right) = O(N)</math>
Nach der Sequenzregel ist die Gesamtkomplexität somit <math>O(M + N)=O(N)</math>, falls <math>M \in O(N)</math> gilt.

===Bucket Sort===

Der Algorithmus wird nur wenig komplizierter, wenn die Schlüssel beliebig sein können, aber eine ordnung-erhaltende <tt>quantize()</tt>-Funktion vorhanden ist. Allerdings geht bei der Quantisierung, also der Abbildung von Schlüsseln auf Bucket-Indizes, ein Teil der Schlüsselinformation verloren. Die Elemente im selben Bucket haben im Allgemeinen nicht exakt den gleichen Schlüssel, so dass jeder Bucket noch explizit sortiert werden muss. Diese Tatsache führt zu einer zusätzlichen Einschränkung: einerseits muss für die Anzahl der Buckets nach wie vor
::<math>M \in O(N)</math>
gelten, aber andererseits sollte jeder Bucket nur wenige Daten enthalten, so dass das Sortieren innerhalb der Buckets effizient ist. Wir fordern deshalb, dass <math>N_k \in O(1)</math> sein soll. Unter der Voraussetzung, dass <tt>quantize()</tt> die Daten gleichmäßig auf alle Buckets verteilt (dazu unten mehr), gilt für die Bucketgrößen
::<math>N_k \in O\left(\frac{N}{M}\right)</math>
denn wir verteilen N Elemente auf M Buckets. Beide Bedingungen sind erfüllt, wenn
::<math>M = \frac{N}{c}</math>
gilt, wobei c eine Konstante unabhängig von N ist. In der Praxis erzielt man die besten Resultate mit <math>c \approx 10</math> (die beste Wahl hängt im konkreten Fall von der Schlüsselverteilung und von der <tt>quantize()</tt>-Funktion ab). Wir übergeben die Konstante c und die <tt>quantize()</tt>-Funktion als Parameter an den Algorithmus:
def bucketSort(a, quant, c):
N = len(a)
M = int(N // c) + 1 # Anzahl der Buckets festlegen (+1, damit es mindestens ein Bucket gibt)

# M leere Buckets erzeugen
buckets = [[] for k in range(M)]

# Daten auf die Buckets verteilen
for k in range(len(a)):
index = quant(a[k].key, M) # Bucket-Index berechnen
buckets[index].append(a[k]) # a[k] im passenden Bucket einfügen

# Daten sortiert wieder in a einfügen
start = 0 # Anfangsindex des ersten Buckets
for k in range(M):
insertionSort(buckets[k]) # Daten innerhalb des aktuellen Buckets sortieren
end = start + len(buckets[k]) # Endindex des aktuellen Buckets
a[start:end] = buckets[k] # Daten an der richtigen Position in a einfügen
start += len(buckets[k]) # Anfangsindex für nächsten Bucket aktualisieren
Wir verwenden zum Sortieren der Daten in jedem Bucket <tt>insertionSort()</tt>. Dies ist aus zwei Gründen eine gute Wahl: Erstens haben wir die Buckets so konstruiert, dass jeder Bucket nur wenige Elemente enthält (<math>N_k \in O(1)</math>), und für kleine Arrays ist Insertion Sort der schnellste Algorithmus. Zweitens ist Insertion Sort ein ''stabiler'' Sortieralgorithmus, und demzufolge ist auch das gesamte <tt>bucketSort()</tt> stabil.

Unter der Voraussetzung, dass <tt>quantize()</tt> konstante Zeit für die Quantisierung eines Schlüssels benötigt, unterscheidet sich die Komplexitätsanalyse von <tt>bucketSort()</tt> nur in einem Punkt von <tt>integerSort()</tt>, nämlich durch das zusätzliche Sortieren in jedem Bucket. Bei Verwendung von Insertion Sort hat dies quadratische Komplexität in <math>N_k</math>, aber wenn <math>N_k \in O(1)</math> erfüllt ist, gilt <math>O(N_k^2) = O(1^2) = O(1)</math>. Das Sortieren hat also konstante Komplexität pro Bucket, und somit ist die Gesamtkomplexität von <tt>bucketSort()</tt> linear in N, wie am Anfang des Abschnitts gewünscht.

Allerdings steht und fällt diese Analyse damit, dass die <tt>quantize()</tt>-Funktion die Daten tatsächlich gleichmäßig auf die Buckets verteilt. Andernfalls könnten im schlechtesten Fall alle Daten in einem einzigen Bucket landen, und dann hätte <tt>bucketSort()</tt> quadratische Komplexität. Die <tt>quantize()</tt>-Funktion muss deshalb je nach der Wahrscheinlichkeitsverteilung der Schlüssel immer wieder anders festgelegt werden. Sehr einfach ist dies, wenn die Schlüssel in einem gewissen Intervall <tt>[U,...,V)</tt> gleichverteilt sind: dann kann man einfach das Intervall <tt>[U,...,V)</tt> durch eine lineare Gleichung auf das Intervall <tt>[0,...M-1]</tt> abbilden und dann abrunden. Für <tt>U = 0</tt> und <tt>V = 1</tt> erhalten wir beilspielsweise:
'''Beispiel:'''
# keys sind reelle Zahlen in [0, 1)

def quantize(key, M):
return int(key * M)
Die Definition einer geeigneten <tt>quantize()</tt>-Funktion für eine andere Schlüsselverteilung ist Bestandteil einer Übungsaufgabe. In der Praxis findet man allerdings, dass die Verteilung der Daten auf die Buckets nicht übermäßig kritisch ist -- <tt>bucketSort()</tt> bleibt auch dann ein sehr schneller Algorithmus, wenn die Verteilung nicht ganz gleichmäßig gelingt. Die obige Implementation ist somit ein guter Default für viele Anwendungen.

[[Prioritätswarteschlangen|Nächstes Thema]]

Sortieren in linearer Zeit

2020-07-02T16:14:46Z

Alda: /* Bucket-Prinzip */

Wir kehren an dieser Stelle nochmals zum Sortierproblem zurück und stellen uns die Frage, ob wir noch schnellere Algorithmen finden können, die eventuell sogar in O(N) statt in O(N*log(N)) zum Ziel kommen. Mit Hilfe der gerade eingeführten Suchbäumen werden wir zeigen, dass dies nicht möglich ist, solange für die Sortierschlüssel nur eine paarweise Vergleichsfunktion definiert ist. Besitzen wir jedoch zusätzliche Informationen über die Schlüssel, die uns die Anwendung des ''Bucket-Prinzips'' erlauben, ist das Sortieren in linearer Zeit möglich.

== Sortieren und Permutationen ==

Bevor wir die Grenzen des Sortierens mit Paarvergleichen analysieren, wollen wir noch etwas näher beleuchten, was beim Sortieren eigentlich geschieht. Dazu gehen wir noch einen Schritt zurück und schauen uns an, was beim Mischen eines zunächst sortierten Arrays passiert. Wir betrachten das Array mit den drei Element A, B, C sowie ein korrespondierendes ''Indexarray'', das angibt, an welcher Position im sortierten Array die drei Elemente gehören. Solange das Hauptarray noch sortiert ist, enthält das Indexarray einfach die aufsteigende Folge 0, 1, 2:
L = A B C # Hauptarray sortiert (0. Permutation)
I = 0 1 2 # Indexarray
Es gibt jetzt 5 weitere Anordnungsmöglichkeiten (imsgesamt also 6 = 3! Permutationen) für die drei Elementa A, B und C. Immer, wenn wir diese drei Elemente umordnen, ordnen wir das Indexarray so, dass das Element <tt>I[k]</tt> in jedem Indexarray uns angibt, wo sich der Buchstabe jetzt befindet, der ursprünglich (also in der sortierten Anordnung) an Position <tt>k</tt> stand:
L = A C B # 1. Permutation
I = 0 2 1

L = B A C # 2. Permutation
I = 1 0 2

L = B C A # 3. Permutation
I = 2 0 1

L = C A B # 4. Permutation
I = 1 2 0

L = C B A # 5. Permutation
I = 2 1 0
In der 5. Permutation sagt beispielsweise <tt>I[0] = 2</tt>, dass der ursprünglich 0. Buchstabe (das A) jetzt an Position 2 ist. Daraus folgt, dass wir ein permutiertes Array in linearer Zeit sortieren können, wenn uns das Indexarray bekannt ist. Wir müssen einfach einmal durch das Indexarray gehen und jedes Element von Position <tt>I[k]</tt> wieder an Position <tt>k</tt> verschieben:
def sortByIndexArray(L, I):
R = [None]*len(L) # zunächst leeres Ergebnisarray
for k in xrange(len(L)):
R[k] = L[I[k]] # Elemente sortiert in R einfügen
return R
Da man nur einmal über den Bereich k = 0 ... len(L)-1 gehen muss, ist der Aufwand dieser Funktion O(len(L)), also linear. Dieser Algorithmus ist z.B. nützlich, wenn man mehrere Arrays in der gleichen Weise sortieren muss, z.B. die Liste der Studentennamen und die Liste der dazugehörigen Übungspunkte. Man kann dann einfach einmal die Permutation des Indexarrays bestimmen, und dann alle Listen entsprechend sortieren. Wie man das Indexarray mit dem Standard-Sortieralgorithmus <tt>array.sort()</tt> bestimmen kann, ist Aufgabe im Übungsblatt 9.

==Sortieren als Suchproblem==

Wir haben gesehen, dass wir in linearer Zeit sortieren können, wenn uns die Permutation bzw. das zugehörige Indexarray bekannt ist. Die nächste Frage lautet deshalb: Wie viele Schritte brauchen wir, um die Permutation zu finden? Dabei ist es nur erlaubt, Schlüssel paarweise zu vergleichen, und man erhält jeweils eine ja/nein Antwort. Ein solches Vorgehen kann als Entscheidungsbaum dargestellt werden. Jeder Knoten ist eine Frage, und wir gehen zum linken Kind weiter, wenn die Frage mit "ja" beantwortet wurde, ansonsten zum rechten Kind. An jeder Kante stehen die jetzt noch in Frage kommenden Permutationen, und der jeweilige Kindknoten gibt uns die nächste Frage vor. Die Blätter enthalten das Indexarray, das der Permutation entspricht:
(L[0] < L[1])
ja / \ nein
ABC / \ BAC
ACB / \ CAB
BCA / \ CBA
/ \
(L[0] < L[2]) (L[0] < L[2])
/ \ / \
ja / nein \ / ja \ nein
ABC / BCA | | BAC \ CAB
ACB / | | \ CBA
/ (2 0 1) (1 0 2) \
(L[1] < L[2]) (L[1] < L[2])
/ \ / \
ja / \ nein ja / \ nein
ABC / \ ACB CAB / \ CBA
/ \ / \
(0 1 2) (0 2 1) (1 2 0) (2 1 0)

Der Suchaufwand im schlechtesten Fall entspricht offensichtlich der Tiefe des Baumes. Bei Arrays mit drei Elementen ist die Tiefe gerade 3, wir benötigen maximal 3 Fragen bis zum Ziel. Für Arrays der Länge n gilt allgemein: Es gibt N = n! verschiedene Permutationen, der Baum muss also n! Blätter haben. Wir haben im Abschnitt [[Suchen#Balance_eines_Suchbaumes|Suchen]] gesehen, dass die Tiefe eines Baumes minimal wird, wenn der Baum ''perfekt balanciert'' ist, und dass der balancierte Baum mit den meisten Blättern der ''vollständige Baum ist''. Die Tiefe des vollständigen Baums mit n! Blättern gibt uns also eine untere Schranke für die minimale Anzahl der Vergleiche im schlechtesten Fall.

Ein vollständiger Baum der Tiefe d hat 2d+1-1 Knoten und 2d Blätter:
{| border="0" cellspacing="0" cellpadding="5"
|-valign="center"
|[[Image:vollbaum.png|left]]
| vollständiger Baum 2d+1-1 Knoten 2d Blätter
|}

Im Fall des Sortierens von n Elementen gilt, dass es N = n! mögliche Permutation gibt. Ein Baum mit n! Blättern hat mindestens die Tiefe log(n!). Im obigen Beispiel für n=3 gilt 3! = 1*2*3 = 6 und damit für die Tiefe d
:::<math>d = \lceil \log_2(6)\rceil \approx \lceil 2.6\rceil = 3</math>
Im ungünstigsten Fall braucht man bei dem Frage-Baum drei Schritte. Weil aber <math>\log(6)\approx 2.6 < 3</math> muss nicht jeder Pfad zu Ende durchlaufen werden, um die Lösung zu bekommen.

Allgemein gilt
::<math>d \ge \log_2(n!)</math>
Wir können die Tiefe am einfachsten durch die ''Stirlingsche Näherungsformel für die Fakultät'' abschätzen:
::<math>n! \approx \sqrt{2\pi n} \left(\frac{n}{e}\right)^n</math>,
die asymptitisch für große n gilt. Einsetzen liefert
::<math>d \ge \log_2(n!) \in \Omega\left(\log_2\left(\sqrt{2\pi n} \left(\frac{n}{e}\right)^n\right)\right)</math>
Der Logarithmus eines Produkts ist gleich der Summe der Logarithmen der einzelnen Faktoren:
::<math>\Omega\left(\log_2\left(\sqrt{2\pi n} \left(\frac{n}{e}\right)^n\right)\right) = \Omega(\log_2(\sqrt{2\pi})) + \Omega(\log_2(\sqrt{n})) + \Omega(\log_2(n^n)) - \Omega(\log_2(e^n))</math>
Wir vereinfachen die rechte Seite nach den Regeln der O-Notation: nur der am schnellsten wachsende Term bleibt übrig:
::<math>\Omega\left(\log_2\left(\sqrt{2\pi n} \left(\frac{n}{e}\right)^n\right)\right) = \Omega(\log_2(n^n))</math>.
Den Exponenten in nn kann man vor den Logarithmus ziehen, und die Basis des Logarithmus spielt keine Rolle. Wir erhalten somit:
::<math>d \in \Omega(n \log n)</math>.
Somit braucht man im schlechtesten Fall mindestens <math>\Omega(n \log n)</math> Vergleiche, und Merge Sort ist somit optimal und kann nicht weiter verbessert werden, solange man sich auf paarweise Vergleiche von Schlüsseln beschränkt.

Eine exakte Herleitung dieser Tatsache, ohne Verwendung der Stirlingschen Formel, ist möglich durch

===Abschätzung von Summen durch Integrale===

Schreibt man die Fakultät als Produkt aus, und transformiert den Logarithmus des Produkts in eine Summe von Logarithmen, erhalten wir:
::<math>d \ge \log_2(n!) = \log_2(1\cdot 2\cdot ... \cdot n) = \log_2(1) + \log_2(2) + ... + \log_2(n) = \sum_{k=1}^n \log_2(k) = \frac{1}{\ln(2)}\sum_{k=1}^n \ln(k) = \frac{1}{\ln(2)}\sum_{k=2}^n \ln(k)</math>
Die letzte Identität gilt, weil <math>\ln(1) = 0</math> in der Summe weggelassen werden kann. Eine untere Schranke für die Tiefe kann man explizit bestimmen durch die Methode der

Gegeben sei eine monoton wachsende Funktion f(x) (blaue Kurve). Das bestimmte Integral über die Funktion sei
:::<math>\int_{x_1}^{x_2} f(x)dx</math>.
Wenn wir das Funktionsargument x abrunden (schwarze Kurve), entsteht ein Integral, das einen kleineren Wert als das ursprüngliche Integral hat. Runden wir auf (rote Kurve), entsteht ein Integral mit einem größeren Wert:

{| border="0" cellspacing="0" cellpadding="5"
|-valign="center"
|[[Image:integralGraph.png|400px|left]]
| <math>\int_{x_1}^{x_2} f(\lfloor x \rfloor)dx \le \int_{x_1}^{x_2} f(x)dx \le \int_{x_1}^{x_2} f(\lceil x \rceil)dx</math>
|}
In unserem Zusammenhang sind x1 und x2 positive ganze Zahlen. Deshalb gilt
:::<math>f(\lfloor x \rfloor)_{x_1}^{x_1+1}= f(x_1),</math>
:::<math>f(\lfloor x \rfloor)_{x_1+1}^{x_1+2}= f(x_1+1)</math>
:::<math>...</math>
:::<math>f(\lfloor x \rfloor)_{x_2-1}^{x_2}= f(x_2-1)</math>
Wir können die obigen Integrale daher folgendermaßen vereinfachen:
:::<math>\begin{array}{lcl}
\int_{x_1}^{x_2} f(\lfloor x \rfloor) dx &=& \int_{x_1}^{x_1 + 1} f(\lfloor x \rfloor) dx + ...+ \int_{x_2-1}^{x_2} f(\lfloor x \rfloor) dx \\
& = & \int_{x_1}^{x_1 + 1} f(x_1) dx + ...+ \int_{x_2-1}^{x_2} f(x_2-1) dx \\
& = & f(x_1) \int_{x_1}^{x_1 + 1} dx + ...+ f(x_2-1) \int_{x_2-1}^{x_2} dx \\
& = & f(x_1) + ...+ f(x_2-1) \\
& = & \sum_{k=x_1}^{x_2-1} f(k)
\end{array}</math>
für die Fläche unter den schwarzen Rechtecken sowie
:::<math>\begin{array}{lcl}
\int_{x_1}^{x_2} f(\lceil x \rceil) dx &=& \int_{x_1}^{x_1 + 1} f(\lceil x \rceil) dx + ...+ \int_{x_2-1}^{x_2} f(\lceil x \rceil) dx \\
& = & \int_{x_1}^{x_1 + 1} f(x_1+1) dx + ...+ \int_{x_2-1}^{x_2} f(x_2) dx \\
& = & f(x_1+1) \int_{x_1}^{x_1 + 1} dx + ...+ f(x_2) \int_{x_2-1}^{x_2} dx \\
& = & f(x_1+1) + ...+ f(x_2) \\
& = & \sum_{k=x_1+1}^{x_2} f(k)
\end{array}</math>
für die Fläche unter den roten Rechtecken. Zusammenfassend gilt also
<math> \sum_{k=x_1}^{x_2-1} f(k) \le \int_{x_1}^{x_2} f(x)dx</math> und
<math> \sum_{k=x_1+1}^{x_2} f(k) \ge \int_{x_1}^{x_2} f(x)dx</math>
Für unser Problem setzen wir f(k) = ln(k), x1+1 = 2, und x2 = n. Also können wir abschätzen
:::<math>\sum_{k=x_1+1}^{x_2} f(k) = \frac{1}{\ln(2)}\sum_{k=2}^{n} \ln(k) \ge \frac{1}{\ln(2)}\int_1^n \ln(x) dx</math>
Das Integral ist leicht zu lösen, und wir erhalten
:::<math>\frac{1}{\ln(2)}\sum_{k=2}^{n} \ln(k) \ge \frac{1}{\ln(2)}\left[x\ln(x)-x\right]_{x=1}^{n} = \frac{1}{\ln(2)}(n\ln(n)-n+1)=n\log_2(n) - \frac{n-1}{\ln(2)} \in \Omega(n \log(n))</math>
Folglich gilt:
:::<math>d\ge\log_2(n!) = \frac{1}{\ln(2)}\sum_{k=2}^{n} \ln(k) \in \Omega(n \log(n))</math>
Mit anderen Worten: '''Kein Sortieralgorithmus auf Basis paarweise Vergleiche ist asymptotisch schneller als Mergesort, denn die Anzahl der Vergleiche (= Tiefe des Entscheidungsbaumes) ist <math>\Omega(n \log(n))</math>'''. Falls man einen schnelleren Sortieralgorithmus benötigt, muss man ein anderes algorithmisches Prinzip verwenden.

==Effizientere Sortieralgorithmen==

Wir haben gezeigt, dass mit paarweisen Größenvergleichen allein kein Sortieralgorithmus schneller als <math>\Omega(n \log n)</math> sein kann. Um einen besseren Algorithmus zu finden, dürfen wir nicht nur die relative Größe der Schlüssel (also die Ordnung) berücksichtigen, sondern müssen die Werte selbst verwenden. Der entscheidende Trick dabei ist das

=== Bucket-Prinzip ===

Man definiert eine Funktion <tt>quantize(key, M)</tt>, die jeden Schlüssel auf eine ganze Zahl im Bereich <tt>[0,...,M-1]</tt> abbildet. Mit Hilfe dieser Zahlen werden die Schlüssel auf M ''Buckets'' aufgeteilt, und das Sortieren kann dann in jedem Bucket getrennt erfolgen. Am Ende setzt man aus den Inhalten der Buckets das gesamte Array (sortiert) wieder zusammen. Wir zeigen unten, dass man damit lineare Zeit erreicht.

Um für das Sortieren brauchbar zu sein, muss die Funktion <tt>quantize()</tt> ''Ordnung erhaltend'' definiert sein:
wenn key1 <= key2, gilt auch quantize(key1, M) <= quantize(key2, M)
Eine solche Abbildung nennt man ''Quantisierung''. Allgemein bekannt ist der Prozess der Quantisierung z.B. bei Digitalkameras: Hier wird in jedem Pixel eine reell-wertige Lichtintensität gemessen, die im resultierenden Bild mit nur 256 Intensitätsabstufungen pro Farbe abgespeichert wird (bzw. mit bis zu 65536 Abstufungen bei Kameras mit sogenanntem "high dynamic range"). Bleibt die Ordnung bei der Abbildung von Schlüsseln auf natürliche Zahlen nicht erhalten, spricht man von ''Hashing''. Hashing wird zur Implementation von [[Hashing und Hashtabellen|Hashtabellen]] nutzbringend eingesetzt.

Der einfachste Fall liegt vor, wenn die Schlüssel bereits genze Zahlen im Bereich <tt>[0,...,M-1]</tt> sind. Dann ist die <tt>quantize()</tt> einfach die Identität. Wir nehmen an, dass die Daten als Schlüssel/Wert-Paare in einem Array <tt>a</tt> gespeichert sind, und wir können das Sortieren wie folgt implementieren:
def integerSort(a, M):
# erzeuge M leere Buckets
buckets = [[] for k in range(M)]

# verteile die Daten auf die Buckets
for k in range(len(a)):
buckets[a[k].key].append(a[k]) # a[k].key sind Integer-Schlüssel in [0,...,M-1]

# setze das Array a aus den Buckets sortiert wieder zusammen
start = 0 # Anfangsindex des ersten Buckets
for k in range(M):
end = start + len(buckets[k]) # Endindex des aktuellen Buckets
a[start:end] = buckets[k] # Daten an der richtigen Position in a einfügen
start = end # Anfangsindex für das nächste Bucket aktualisieren
Das Array <tt>a</tt> ist am Ende sortiert, weil wir den Inhalt der Buckets nach aufsteigendem Bucket-Index, und damit automatisch nach aufsteigenden Schlüsseln, in <tt>a</tt> einfügen. Das Sortieren ist außerdem ''stabil'', da Daten mit gleichem Schlüssel immer hinten an das jeweilige Bucket angefügt werden.

Die Komplexität des Algorithmus ist <math>O(N)</math> mit <tt>N = len(a)</tt>, solange
::<math>M \in O(N)</math>
gilt: Das Erzeugen der Buckets erfordert <math>O(M)</math> Schritte und das Verteilen der Daten auf die Buckets <math>O(N)</math> Schritte (weil <tt>bucket[k].append()</tt> amortisiert konstante Komplexität hat). Das Zusammensetzen des sortierten Arrays wird vom Kopieren der Daten dominiert, welches die Komplexität
::<math>\sum_{k=0}^{M-1} O(N_k)= O\left(\sum_{k=0}^{M-1} N_k\right)</math>
besitzt, wobei <tt>Nk=len(buckets[k])</tt> die Größe des k-ten Buckets ist. Die Gesamtanzahl der Daten in allen Buckets zusammen ist aber gerade wieder die Größe von <tt>a</tt>, also
::<math>O\left(\sum_{k=0}^{M-1} N_k\right) = O(N)</math>
Nach der Sequenzregel ist die Gesamtkomplexität somit <math>O(M + N)=O(N)</math>, falls <math>M \in O(N)</math> gilt.

===Bucket Sort===

Der Algorithmus wird nur wenig komplizierter, wenn die Schlüssel beliebig sein können, aber eine Ordnung-erhaltende <tt>bucketMap()</tt>-Funktion vorhanden ist. Allerdings geht bei der Abbildung von Schlüsseln auf Bucket-Indizes im allgemeinen ein Teil der Schlüsselinformation verloren. Die Elemente im selben Bucket haben nicht (wie oben) automatisch den gleichen Schlüssel, so dass jeder Bucket noch explizit sortiert werden muss. Diese Tatsache führt zu einer zusaätzlichen Einschränkung: einerseits muss für die Anzahl der Buckets nach wie vor
::<math>M \in O(N)</math>
gelten, aber andererseits sollte jeder Bucket nur wenige Daten enthalten, so dass das Sortieren innerhalb der Buckets effizient ist. Wir fordern deshalb, dass <math>N_k \in O(1)</math> sein soll. Unter der Voraussetzung, dass <tt>bucketMap()</tt> die daten gleichmäßig auf alle Buckets verteilt (dazu unten mehr), gilt für die Bucketgrößen
::<math>N_k \in O\left(\frac{N}{M}\right)</math>
denn wir verteilen N Elemente auf M Buckets. Beide Bedingungen sind erfüllt, wenn
::<math>M = \frac{N}{d}</math>
gilt, wobei d eine Konstante unabhängig von N ist. In der Praxis erzielt man die besten Resultate mit <math>1 \le d \le 10</math> (die beste Wahl hängt im konkreten Fall von der Schlüsselverteilung und von der <tt>bucketMap()</tt>-Funktion ab). Wir übergeben die Konstante d und die <tt>bucketMap()</tt>-Funktion als Parameter an den Algorithmus:
def bucketSort(a, bucketMap, d):
N = len(a)
M = int(N / float(d)) # Anzahl der Buckets festlegen

# M leere Buckets erzeugen
buckets = [[] for k in range(M)]

# Daten auf die Buckets verteilen
for k in range(len(a)):
index = bucketMap(a[k].key, M) # Bucket-Index berechnen
buckets[index].append(a[k]) # a[k] im passenden Bucket einfügen

# Daten sortiert wieder in a einfügen
start = 0 # Anfangsindex des ersten Buckets
for k in range(M):
insertionSort(buckets[k]) # Daten innerhalb des aktuellen Buckets sortieren
end = start + len(buckets[k]) # Endindex des aktuellen Buckets
a[start:end] = buckets[k] # Daten an der richtigen Position in a einfügen
start += len(buckets[k]) # Anfangsindex für nächsten Bucket aktualisieren
Wir verwenden zum Sortieren der Daten in jedem Bucket <tt>insertionSort()</tt>. Dies ist aus zwei Gründen eine gute Wahl: Erstens haben wir die Buckets so konstruiert, dass jeder Bucket nur wenige Elemente enthält (<math>N_k \in O(1)</math>), und für kleine Arrays ist Insertion Sort der schnellste Algorithmus. Zweitens ist Insertion Sort ein ''stabiler'' Sortieralgorithmus, und demzufolge ist auch das gesamte <tt>bucketSort()</tt> stabil.

Unter der Voraussetzung, dass <tt>bucketMap()</tt> konstante Zeit für die Quantisierung eines Schlüssels benötigt, unterscheidet sich die Komplexitätsanalyse von <tt>bucketSort()</tt> nur in einem Punkt von <tt>integerSort()</tt>, nämlich durch das zusätzliche Sortieren in jedem Bucket. Bei Verwendung von Insertion Sort hat dies quadratische Komplexität in <math>N_k</math>, aber wenn <math>N_k \in O(1)</math> erfüllt ist, gilt <math>O(N_k^2) = O(1^2) = O(1)</math>. Das Sortieren hat also konstante Komplexität pro Bucket, und somit ist die Gesamtkomplexität von <tt>bucketSort()</tt> linear in N, wie am Anfang des Abschnitts gewünscht.

Allerdings steht und fällt diese Analyse damit, dass die <tt>bucketMap()</tt>-Funktion die Daten tatsächlich gleichmäßig auf die Buckets verteilt. Andernfalls könnten im schlechtesten Fall alle Daten in einem einzigen Bucket landen, und dann hätte <tt>bucketSort()</tt> quadratische Komplexität. Die <tt>bucketMap()</tt>-Funktion muss deshalb je nach der Wahrscheinlichkeitsverteilung der Schlüssel immer wieder anders festgelegt werden. Sehr einfach ist dies, wenn die Schlüssel in einem gewissen Intervall <tt>[U,...,V)</tt> gleichverteilt sind: dann kann man einfach das Intervall <tt>[U,...,V)</tt> durch eine lineare Gleichung auf das Intervall <tt>[0,...M-1]</tt> abbilden und dann abrunden. Für <tt>U = 0</tt> und <tt>V = 1</tt> erhalten wir beilspielsweise:
'''Beispiel:'''
# keys sind reelle Zahlen in [0, 1)

def bucketMap(key, M):
return int(key * M)
Die Definition einer geeigneten <tt>bucketMap()</tt>-Funktion für eine andere Schlüsselverteilung ist Bestandteil einer Übungsaufgabe. In der Praxis findet man allerdings, dass die Verteilung der Daten auf die Buckets nicht übermäßig kritisch ist -- <tt>bucketSort()</tt> blaibt auch dann ein sehr schneller Algorithmus, wenn die Verteilung nicht ganz gleichmäßig gelingt.

[[Prioritätswarteschlangen|Nächstes Thema]]

Graphen und Graphenalgorithmen

2020-07-02T16:10:52Z

Alda: /* Breitensuche in Graphen (Breadth First Search, BFS) */

== 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 auf demselben Weg zurück (sogenanntes back tracking), bis man einen Knoten findet, der noch einen unbesuchten 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.

Die 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 property map genannt. (Die Verwendung von property maps hat sich gegenüber der alternativen Idee durchgesetzt, solche Eigenschaften in speziellen Knotenklassen zu speichern. Im letzteren Fall braucht man nämlich für jede Anwendung eine angepasste Knotenklasse mit den jeweils gewünschten Attributen und damit auch angepasste Implementationen der Graphenfunktionen, was sich als sehr aufwändig erwiesen hat.)

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 Nachbarpixeln 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, Informationen über den Verlauf der Suche zu sammeln und am Ende zurückzugeben, so dass andere Algorithmen diese Information nutzen können. Typische Beispiele dafür sind eine Reihenfolge der Knoten (in discovery oder finishing order) oder die Vorgänger jedes Knotens im Tiefensuchbaum (also von welchem Knoten aus man den jeweiligen Knoten zuerst erreicht hat). Wir führen dafür drei neue Arrays ein.

def dfs(graph, startnode):
visited = [False]*len(graph) # wurde ein Knoten bereits besucht?
parents = [None]*len(graph) # registriere für jeden Knoten den Vorgänger im Tiefensuchbaum
discovery_order = [] # enthält am Ende die pre-order Sortierung
finishing_order = [] # enthält am Ende die post-order Sortierung

def visit(node, parent): # rekursive Hilfsfunktion
if not visited[node]: # besuche 'node', wenn noch nicht besucht wurde
visited[node] = True # markiere 'node' als besucht
parents[node] = parent # speichere den Vorgänger von 'node'
discovery_order.append(node) # registriere, dass 'node' jetzt entdeckt wurde
for neighbor in graph[node]: # besuche rekursiv die Nachbarn ...
visit(neighbor, node) # ... wobei 'node' zu deren Vorgänger wird
finishing_order.append(node) # registriere, dass 'node' jetzt fertiggestellt wurde

visit(startnode, None) # beginne bei 'startnode', der keinen Vorgänger hat

return parents, discovery_order, finishing_order # gib die zusätzliche Informationen zurück

Beginnt man die Suche bei Knoten 1, entsprechen die Inhalte der Arrays <tt>discovery_order</tt> und <tt>finishing_order</tt> für den obigen Beispielgraphen gerade den vorher angeführten <tt>print</tt>-Ausgaben. Die Vorgänger im Array <tt>parents</tt> lauten:
Knotennummer | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
--------------+-----+-----+-----+-----+-----+-----+-----+-----
Vorgänger | None| None| 1 | 4 | 2 | 2 | 3 | 3

Die Knotennummern dienen hier als Array-Indizes, und die dazugehörigen Arrayeinträge verweisen auf die Vorgänger. Man kann mit diesen Informationen den Weg von jedem Knoten zur Wurzel zurückverfolgen und damit den Tiefensuchbaum von unten nach oben rekonstruieren. Man beachte, dass <tt>parents</tt> den Eintrag <tt>None</tt> für die Knoten 0 umd 1 enthält, weil Knoten 0 in diesem Graphen nicht existiert und Knoten 1 als Wurzel der Suche keinen Vorgänger hat.

Wird das Array <tt>parents</tt> verwendet, kann man den Code vereinfachen, indem man das Array <tt>visited</tt> einspart: Sobald ein Knoten erstmals besucht wurde, ist sein Vorgänger bekannt und damit ungleich <tt>None</tt>. Die Abfrage <tt>if parents[node] is None:</tt> liefert damit das gleiche Resultat wie die Abfrage <tt>if not visited[node]:</tt>. Einzige Ausnahme ist der Startknoten der Suche, dessen Vorgänger bisher <tt>None</tt> war. Dieses Problem löst man leicht mit der Konvention, dass man den Startknoten zu seinem eigenen Vorgänger erklärt. Man startet die Suche also mit <tt>visit(startnode, startnode)</tt> statt mit <tt>visit(startnode, None)</tt>.

=== Breitensuche in Graphen (Breadth First Search, BFS) ===

Im Gegensatz zur Tiefensuche werden bei der Breitensuche alle Nachbarknoten 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):
parents = [None]*len(graph) # speichere für jeden Knoten den Vorgänger im Breitensuchbaum
parents[startnode] = startnode # Konvention: der Startknoten hat sich selbst als Vorgänger

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # solange noch Knoten zu bearbeiten sind
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
 # Beachte: mit q.popright() bekommen wir DFS
print(node) # den Knoten bearbeiten (hier: Knotennummer drucken)
for neighbor in graph[node]: # die Nachbarn expandieren
if parents[neighbor] is None: # Nachbar wurde noch nicht besucht
parents[neighbor] = node # => Vorgänger merken, Knoten dadurch als "besucht" markieren
q.append(neighbor) # und in die Queue aufnehmen

[[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.

=== 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.

=== 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]]

=== 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 range(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 = list(range(len(graph))) # Initialisierung der property map: jeder Knoten ist sein eigener Anker

for node in range(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 range(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 zunächst eine wichtige Eigenschaft des Algorithmus: Die Priorität (=Pfadlänge) des Knotens an der Spitze des Heaps wächst im Laufe des Algorithmus monoton an (aber nicht notwendigerweise streng monoton). Mit anderen Worten: liefert <tt>heappop</tt> in der i-ten Iteration der <tt>while</tt>-Schleife den Knoten u mit der Pfadlänge lu, und in der (i+1)-ten Iteration den Knoten v mit der Pfadlänge lv, so gilt stets lv ≥ lu. Wir zeigen dies mit der Technik des indirekten Beweises, d.h. wir nehmen das Gegenteil an und führen diese Annahme zum Widerspruch. Wäre also lv < lu, gäbe es zwei Möglichkeiten:
<ol>
<li>Der Weg nach v mit der Länge lv war in der i-ten Iteration schon bekannt und somit bereits im Heap enthalten. Dann hätte <tt>heappop</tt> in dieser Iteration aber v zurückgegeben, im Widerspruch zur Annahme, dass u zurückgegeben wurde.</li>
<li>Der Weg wurde erst bei der Expansion von u in der i-ten Iteration gefunden. Dann muss v ein Nachbar von u sein, und seine Weglänge berechnet sich als lv = lu + wu,v. Da für die Kantengewichte aber wu,v ≥ 0 gefordert ist, kann lv < lu nicht gelten.</li>
</ol>
Diese Monotonieeigenschaft hat eine interessante Konsequenz: Beträgt der Abstand vom Start zum Zielknoten lz, so findet Dijsktra's Algorithmus als Nebenprodukt auch die kürzesten Wege zu allen näher gelegenen Knoten, also zu allen Knoten u, für deren Abstand lu < lz gilt. Dies trifft auch dann zu, wenn diese Wege für den Benutzer gar nicht von Interesse sind. Der A*-Algorithmus, der weiter unten erklärt wird, versucht dem abzuhelfen.

Wir können nun mittels vollständiger Induktion die folgende Schleifen-Invariante beweisen: 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 wieder 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 dem Momemnt in den Heap eingefügt werden, wo der kürzeste Weg für <tt>predecessor</tt> gefunden wurde. Man beachte auch, dass wegen der Monotonieeigenschaft alle Knoten, die noch nicht in <math>S</math> enthalten sind, weiter vom Start entfernt sind als die Knoten in <math>S</math>.
: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 im Heap 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>: Wegen der Monotonieeigenschaft muss jetzt <tt>Kosten(x → startnode) > Kosten(node → predecessor → startnode)</tt> gelten. Die Kosten des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> berechnen sich aber als <tt>Kosten(x → startnode) + weight[(x, node)]</tt>, und deshalb kann dieser Weg keinesfalls kürzer sein.
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 range(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 range(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 range(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: # neuer Knoten gefunden:
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
else:
return False # node war bereits 'finished' => kein Zyklus

for node in range(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 range(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]]

== 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

2020-07-02T16:10:31Z

Alda: /* Breitensuche in Graphen (Breadth First Search, BFS) */

== 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 auf demselben Weg zurück (sogenanntes back tracking), bis man einen Knoten findet, der noch einen unbesuchten 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.

Die 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 property map genannt. (Die Verwendung von property maps hat sich gegenüber der alternativen Idee durchgesetzt, solche Eigenschaften in speziellen Knotenklassen zu speichern. Im letzteren Fall braucht man nämlich für jede Anwendung eine angepasste Knotenklasse mit den jeweils gewünschten Attributen und damit auch angepasste Implementationen der Graphenfunktionen, was sich als sehr aufwändig erwiesen hat.)

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 Nachbarpixeln 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, Informationen über den Verlauf der Suche zu sammeln und am Ende zurückzugeben, so dass andere Algorithmen diese Information nutzen können. Typische Beispiele dafür sind eine Reihenfolge der Knoten (in discovery oder finishing order) oder die Vorgänger jedes Knotens im Tiefensuchbaum (also von welchem Knoten aus man den jeweiligen Knoten zuerst erreicht hat). Wir führen dafür drei neue Arrays ein.

def dfs(graph, startnode):
visited = [False]*len(graph) # wurde ein Knoten bereits besucht?
parents = [None]*len(graph) # registriere für jeden Knoten den Vorgänger im Tiefensuchbaum
discovery_order = [] # enthält am Ende die pre-order Sortierung
finishing_order = [] # enthält am Ende die post-order Sortierung

def visit(node, parent): # rekursive Hilfsfunktion
if not visited[node]: # besuche 'node', wenn noch nicht besucht wurde
visited[node] = True # markiere 'node' als besucht
parents[node] = parent # speichere den Vorgänger von 'node'
discovery_order.append(node) # registriere, dass 'node' jetzt entdeckt wurde
for neighbor in graph[node]: # besuche rekursiv die Nachbarn ...
visit(neighbor, node) # ... wobei 'node' zu deren Vorgänger wird
finishing_order.append(node) # registriere, dass 'node' jetzt fertiggestellt wurde

visit(startnode, None) # beginne bei 'startnode', der keinen Vorgänger hat

return parents, discovery_order, finishing_order # gib die zusätzliche Informationen zurück

Beginnt man die Suche bei Knoten 1, entsprechen die Inhalte der Arrays <tt>discovery_order</tt> und <tt>finishing_order</tt> für den obigen Beispielgraphen gerade den vorher angeführten <tt>print</tt>-Ausgaben. Die Vorgänger im Array <tt>parents</tt> lauten:
Knotennummer | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
--------------+-----+-----+-----+-----+-----+-----+-----+-----
Vorgänger | None| None| 1 | 4 | 2 | 2 | 3 | 3

Die Knotennummern dienen hier als Array-Indizes, und die dazugehörigen Arrayeinträge verweisen auf die Vorgänger. Man kann mit diesen Informationen den Weg von jedem Knoten zur Wurzel zurückverfolgen und damit den Tiefensuchbaum von unten nach oben rekonstruieren. Man beachte, dass <tt>parents</tt> den Eintrag <tt>None</tt> für die Knoten 0 umd 1 enthält, weil Knoten 0 in diesem Graphen nicht existiert und Knoten 1 als Wurzel der Suche keinen Vorgänger hat.

Wird das Array <tt>parents</tt> verwendet, kann man den Code vereinfachen, indem man das Array <tt>visited</tt> einspart: Sobald ein Knoten erstmals besucht wurde, ist sein Vorgänger bekannt und damit ungleich <tt>None</tt>. Die Abfrage <tt>if parents[node] is None:</tt> liefert damit das gleiche Resultat wie die Abfrage <tt>if not visited[node]:</tt>. Einzige Ausnahme ist der Startknoten der Suche, dessen Vorgänger bisher <tt>None</tt> war. Dieses Problem löst man leicht mit der Konvention, dass man den Startknoten zu seinem eigenen Vorgänger erklärt. Man startet die Suche also mit <tt>visit(startnode, startnode)</tt> statt mit <tt>visit(startnode, None)</tt>.

=== Breitensuche in Graphen (Breadth First Search, BFS) ===

Im Gegensatz zur Tiefensuche werden bei der Breitensuche alle Nachbarknoten 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):
parents = [None]*len(graph) # speichere für jeden Knoten den Vorgänger im Breitensuchbaum
parents[startnode] = startnode # Konvention: der Startknoten hat sich selbst als Vorgänger

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # solange noch Knoten zu bearbeiten sind
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
 # Beachte: mit q.popright() bekommen wir DFS
print(node) # den Knoten bearbeiten (hier: Knotennummer drucken)
for neighbor in graph[node]: # die Nachbarn expandieren
if parents[neighbor] is None: # Nachbar wurde noch nicht besucht
parents[neighbor] = node # => Vorgänger merken, Knoten dadurch als "besucht" markieren
q.append(neighbor) # und in die Queue aufnehmen

[[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.

=== 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.

=== 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]]

=== 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 range(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 = list(range(len(graph))) # Initialisierung der property map: jeder Knoten ist sein eigener Anker

for node in range(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 range(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 zunächst eine wichtige Eigenschaft des Algorithmus: Die Priorität (=Pfadlänge) des Knotens an der Spitze des Heaps wächst im Laufe des Algorithmus monoton an (aber nicht notwendigerweise streng monoton). Mit anderen Worten: liefert <tt>heappop</tt> in der i-ten Iteration der <tt>while</tt>-Schleife den Knoten u mit der Pfadlänge lu, und in der (i+1)-ten Iteration den Knoten v mit der Pfadlänge lv, so gilt stets lv ≥ lu. Wir zeigen dies mit der Technik des indirekten Beweises, d.h. wir nehmen das Gegenteil an und führen diese Annahme zum Widerspruch. Wäre also lv < lu, gäbe es zwei Möglichkeiten:
<ol>
<li>Der Weg nach v mit der Länge lv war in der i-ten Iteration schon bekannt und somit bereits im Heap enthalten. Dann hätte <tt>heappop</tt> in dieser Iteration aber v zurückgegeben, im Widerspruch zur Annahme, dass u zurückgegeben wurde.</li>
<li>Der Weg wurde erst bei der Expansion von u in der i-ten Iteration gefunden. Dann muss v ein Nachbar von u sein, und seine Weglänge berechnet sich als lv = lu + wu,v. Da für die Kantengewichte aber wu,v ≥ 0 gefordert ist, kann lv < lu nicht gelten.</li>
</ol>
Diese Monotonieeigenschaft hat eine interessante Konsequenz: Beträgt der Abstand vom Start zum Zielknoten lz, so findet Dijsktra's Algorithmus als Nebenprodukt auch die kürzesten Wege zu allen näher gelegenen Knoten, also zu allen Knoten u, für deren Abstand lu < lz gilt. Dies trifft auch dann zu, wenn diese Wege für den Benutzer gar nicht von Interesse sind. Der A*-Algorithmus, der weiter unten erklärt wird, versucht dem abzuhelfen.

Wir können nun mittels vollständiger Induktion die folgende Schleifen-Invariante beweisen: 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 wieder 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 dem Momemnt in den Heap eingefügt werden, wo der kürzeste Weg für <tt>predecessor</tt> gefunden wurde. Man beachte auch, dass wegen der Monotonieeigenschaft alle Knoten, die noch nicht in <math>S</math> enthalten sind, weiter vom Start entfernt sind als die Knoten in <math>S</math>.
: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 im Heap 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>: Wegen der Monotonieeigenschaft muss jetzt <tt>Kosten(x → startnode) > Kosten(node → predecessor → startnode)</tt> gelten. Die Kosten des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> berechnen sich aber als <tt>Kosten(x → startnode) + weight[(x, node)]</tt>, und deshalb kann dieser Weg keinesfalls kürzer sein.
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 range(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 range(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 range(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: # neuer Knoten gefunden:
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
else:
return False # node war bereits 'finished' => kein Zyklus

for node in range(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 range(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]]

== 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

2020-07-02T16:08:19Z

Alda: /* Tiefensuche in Graphen (Depth First Search, DFS) */

== 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 auf demselben Weg zurück (sogenanntes back tracking), bis man einen Knoten findet, der noch einen unbesuchten 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.

Die 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 property map genannt. (Die Verwendung von property maps hat sich gegenüber der alternativen Idee durchgesetzt, solche Eigenschaften in speziellen Knotenklassen zu speichern. Im letzteren Fall braucht man nämlich für jede Anwendung eine angepasste Knotenklasse mit den jeweils gewünschten Attributen und damit auch angepasste Implementationen der Graphenfunktionen, was sich als sehr aufwändig erwiesen hat.)

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 Nachbarpixeln 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, Informationen über den Verlauf der Suche zu sammeln und am Ende zurückzugeben, so dass andere Algorithmen diese Information nutzen können. Typische Beispiele dafür sind eine Reihenfolge der Knoten (in discovery oder finishing order) oder die Vorgänger jedes Knotens im Tiefensuchbaum (also von welchem Knoten aus man den jeweiligen Knoten zuerst erreicht hat). Wir führen dafür drei neue Arrays ein.

def dfs(graph, startnode):
visited = [False]*len(graph) # wurde ein Knoten bereits besucht?
parents = [None]*len(graph) # registriere für jeden Knoten den Vorgänger im Tiefensuchbaum
discovery_order = [] # enthält am Ende die pre-order Sortierung
finishing_order = [] # enthält am Ende die post-order Sortierung

def visit(node, parent): # rekursive Hilfsfunktion
if not visited[node]: # besuche 'node', wenn noch nicht besucht wurde
visited[node] = True # markiere 'node' als besucht
parents[node] = parent # speichere den Vorgänger von 'node'
discovery_order.append(node) # registriere, dass 'node' jetzt entdeckt wurde
for neighbor in graph[node]: # besuche rekursiv die Nachbarn ...
visit(neighbor, node) # ... wobei 'node' zu deren Vorgänger wird
finishing_order.append(node) # registriere, dass 'node' jetzt fertiggestellt wurde

visit(startnode, None) # beginne bei 'startnode', der keinen Vorgänger hat

return parents, discovery_order, finishing_order # gib die zusätzliche Informationen zurück

Beginnt man die Suche bei Knoten 1, entsprechen die Inhalte der Arrays <tt>discovery_order</tt> und <tt>finishing_order</tt> für den obigen Beispielgraphen gerade den vorher angeführten <tt>print</tt>-Ausgaben. Die Vorgänger im Array <tt>parents</tt> lauten:
Knotennummer | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
--------------+-----+-----+-----+-----+-----+-----+-----+-----
Vorgänger | None| None| 1 | 4 | 2 | 2 | 3 | 3

Die Knotennummern dienen hier als Array-Indizes, und die dazugehörigen Arrayeinträge verweisen auf die Vorgänger. Man kann mit diesen Informationen den Weg von jedem Knoten zur Wurzel zurückverfolgen und damit den Tiefensuchbaum von unten nach oben rekonstruieren. Man beachte, dass <tt>parents</tt> den Eintrag <tt>None</tt> für die Knoten 0 umd 1 enthält, weil Knoten 0 in diesem Graphen nicht existiert und Knoten 1 als Wurzel der Suche keinen Vorgänger hat.

Wird das Array <tt>parents</tt> verwendet, kann man den Code vereinfachen, indem man das Array <tt>visited</tt> einspart: Sobald ein Knoten erstmals besucht wurde, ist sein Vorgänger bekannt und damit ungleich <tt>None</tt>. Die Abfrage <tt>if parents[node] is None:</tt> liefert damit das gleiche Resultat wie die Abfrage <tt>if not visited[node]:</tt>. Einzige Ausnahme ist der Startknoten der Suche, dessen Vorgänger bisher <tt>None</tt> war. Dieses Problem löst man leicht mit der Konvention, dass man den Startknoten zu seinem eigenen Vorgänger erklärt. Man startet die Suche also mit <tt>visit(startnode, startnode)</tt> statt mit <tt>visit(startnode, None)</tt>.

=== Breitensuche in Graphen (Breadth First Search, BFS) ===

Im Gegensatz zur Tiefensuche werden bei der Breitensuche alle Nachbarknoten 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):
parents = [None]*len(graph) # speichere für jeden Knoten den Vorgänger im Breitensuchbaum
parents[startnode] = startnode # Konvention: der Startknoten hat sich selbst als Vorgänger

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # solange noch Knoten zu bearbeiten sind
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
print(node) # den Knoten bearbeiten (hier: Knotennummer drucken)
for neighbor in graph[node]: # die Nachbarn expandieren
if parents[neighbor] is None: # Nachbar wurde noch nicht besucht
parents[neighbor] = node # => Vorgänger merken, Knoten dadurch als "besucht" markieren
q.append(neighbor) # und in die Queue aufnehmen

[[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.

=== 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.

=== 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]]

=== 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 range(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 = list(range(len(graph))) # Initialisierung der property map: jeder Knoten ist sein eigener Anker

for node in range(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 range(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 zunächst eine wichtige Eigenschaft des Algorithmus: Die Priorität (=Pfadlänge) des Knotens an der Spitze des Heaps wächst im Laufe des Algorithmus monoton an (aber nicht notwendigerweise streng monoton). Mit anderen Worten: liefert <tt>heappop</tt> in der i-ten Iteration der <tt>while</tt>-Schleife den Knoten u mit der Pfadlänge lu, und in der (i+1)-ten Iteration den Knoten v mit der Pfadlänge lv, so gilt stets lv ≥ lu. Wir zeigen dies mit der Technik des indirekten Beweises, d.h. wir nehmen das Gegenteil an und führen diese Annahme zum Widerspruch. Wäre also lv < lu, gäbe es zwei Möglichkeiten:
<ol>
<li>Der Weg nach v mit der Länge lv war in der i-ten Iteration schon bekannt und somit bereits im Heap enthalten. Dann hätte <tt>heappop</tt> in dieser Iteration aber v zurückgegeben, im Widerspruch zur Annahme, dass u zurückgegeben wurde.</li>
<li>Der Weg wurde erst bei der Expansion von u in der i-ten Iteration gefunden. Dann muss v ein Nachbar von u sein, und seine Weglänge berechnet sich als lv = lu + wu,v. Da für die Kantengewichte aber wu,v ≥ 0 gefordert ist, kann lv < lu nicht gelten.</li>
</ol>
Diese Monotonieeigenschaft hat eine interessante Konsequenz: Beträgt der Abstand vom Start zum Zielknoten lz, so findet Dijsktra's Algorithmus als Nebenprodukt auch die kürzesten Wege zu allen näher gelegenen Knoten, also zu allen Knoten u, für deren Abstand lu < lz gilt. Dies trifft auch dann zu, wenn diese Wege für den Benutzer gar nicht von Interesse sind. Der A*-Algorithmus, der weiter unten erklärt wird, versucht dem abzuhelfen.

Wir können nun mittels vollständiger Induktion die folgende Schleifen-Invariante beweisen: 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 wieder 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 dem Momemnt in den Heap eingefügt werden, wo der kürzeste Weg für <tt>predecessor</tt> gefunden wurde. Man beachte auch, dass wegen der Monotonieeigenschaft alle Knoten, die noch nicht in <math>S</math> enthalten sind, weiter vom Start entfernt sind als die Knoten in <math>S</math>.
: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 im Heap 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>: Wegen der Monotonieeigenschaft muss jetzt <tt>Kosten(x → startnode) > Kosten(node → predecessor → startnode)</tt> gelten. Die Kosten des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> berechnen sich aber als <tt>Kosten(x → startnode) + weight[(x, node)]</tt>, und deshalb kann dieser Weg keinesfalls kürzer sein.
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 range(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 range(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 range(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: # neuer Knoten gefunden:
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
else:
return False # node war bereits 'finished' => kein Zyklus

for node in range(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 range(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]]

== 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

2020-07-02T16:07:31Z

Alda:

== 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 auf demselben Weg zurück (sogenanntes back tracking), bis man einen Knoten findet, der noch einen unbesuchten 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.

Die 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 property map genannt. (Die Verwendung von property maps hat sich gegenüber der alternativen Idee durchgesetzt, solche Eigenschaften in speziellen Knotenklassen zu speichern. Im letzteren Fall braucht man nämlich für jede Anwendung eine angepasste Knotenklasse mit den jeweils gewünschten Attributen und damit auch angepasste Implementationen der Graphenfunktionen, was sich als sehr aufwändig erwiesen hat.)

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 Nachbarpixeln 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, Informationen über den Verlauf der Suche zu sammeln und am Ende zurückzugeben, so dass andere Algorithmen diese Information nutzen können. Typische Beispiele dafür sind eine Reihenfolge der Knoten (in discovery oder finishing order) oder die Vorgänger jedes Knotens im Tiefensuchbaum (also von welchem Knoten aus man den jeweiligen Knoten zuerst erreicht hat). Wir führen dafür drei neue Arrays ein.

def dfs(graph, startnode):
visited = [False]*len(graph) # wurde ein Knoten bereits besucht?
parents = [None]*len(graph) # registriere für jeden Knoten den Vorgänger im Tiefensuchbaum
discovery_order = [] # enthält am Ende die pre-order Sortierung
finishing_order = [] # enthält am Ende die post-order Sortierung

def visit(node, parent): # rekursive Hilfsfunktion
if not visited[node]: # besuche 'node', wenn noch nicht besucht wurde
visited[node] = True # markiere 'node' als besucht
parents[node] = parent # speichere den Vorgänger von 'node'
discovery_order.append(node) # registriere, dass 'node' jetzt entdeckt wurde
for neighbor in graph[node]: # besuche rekursiv die Nachbarn ...
visit(neighbor, node) # ... wobei 'node' zu deren Vorgänger wird
finishing_order.append(node) # registriere, dass 'node' jetzt fertiggestellt wurde

visit(startnode, None) # beginne bei 'startnode', der keinen Vorgänger hat

return parents, discovery_order, finishing_order # gib die zusätzliche Informationen zurück

Beginnt man die Suche bei Knoten 1, entsprechen die Inhalte der Arrays <tt>discovery_order</tt> und <tt>finishing_order</tt> für den obigen Beispielgraphen gerade den vorher angeführten <tt>print</tt>-Ausgaben. Die Vorgänger im Array <tt>parents</tt> lauten:
Knotennummer | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
--------------+-----+-----+-----+-----+-----+-----+-----+-----
Vorgänger | None| None| 1 | 4 | 2 | 2 | 3 | 3

Die Knotennummern dienen hier als Array-Indizes, und die dazugehörigen Arrayeinträge verweisen auf die Vorgänger. Man kann mit diesen Informationen den Weg von jedem Knoten zur Wurzel zurückverfolgen und damit den Tiefensuchbaum von unten nach oben rekonstruieren. Man beachte, dass <tt>parents</tt> den Eintrag <tt>None</tt> für die Knoten 0 umd 1 enthält, weil Knoten 0 in diesem Graphen nicht existiert und Knoten 1 als Wurzel der Suche keinen Vorgänger hat.

Wird das Array <tt>parents</tt> verwendet, kann man den Code vereinfachen, indem man das Array <tt>visited</tt> einspart: Sobald ein Knoten erstmals besucht wurde, ist sein Vorgänger bekannt und damit ungleich <tt>None</tt>. Die Abfrage <tt>if parents[node] is None:</tt> liefert damit das gleiche Resultat wie die Abfrage <tt>if not visited[node]:</tt>. Einzige Ausnahme ist der Startknoten der Suche, dessen Vorgänger bisher <tt>None</tt> war. Dieses Problem löst man leicht mit der Konvention, dass man den Startknoten zu seinem eigenen Vorgänger erklärt. Man startet die Suche also mit <tt>visit(startnode, startnode)</tt> statt mit <tt>visit(startnode, None)</tt>.

=== Breitensuche in Graphen (Breadth First Search, BFS) ===

Im Gegensatz zur Tiefensuche werden bei der Breitensuche alle Nachbarknoten 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):
parents = [None]*len(graph) # speichere für jeden Knoten den Vorgänger im Breitensuchbaum
parents[startnode] = startnode # Konvention: der Startknoten hat sich selbst als Vorgänger

q = deque() # Queue für die zu besuchenden Knoten
q.append(startnode) # Startknoten in die Queue einfügen

while len(q) > 0: # solange noch Knoten zu bearbeiten sind
node = q.popleft() # Knoten aus der Queue nehmen (first in - first out)
print(node) # den Knoten bearbeiten (hier: Knotennummer drucken)
for neighbor in graph[node]: # die Nachbarn expandieren
if parents[neighbor] is None: # Nachbar wurde noch nicht besucht
parents[neighbor] = node # => Vorgänger merken, Knoten dadurch als "besucht" markieren
q.append(neighbor) # und in die Queue aufnehmen

[[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.

=== 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.

=== 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]]

=== 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 range(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 = list(range(len(graph))) # Initialisierung der property map: jeder Knoten ist sein eigener Anker

for node in range(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 range(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 zunächst eine wichtige Eigenschaft des Algorithmus: Die Priorität (=Pfadlänge) des Knotens an der Spitze des Heaps wächst im Laufe des Algorithmus monoton an (aber nicht notwendigerweise streng monoton). Mit anderen Worten: liefert <tt>heappop</tt> in der i-ten Iteration der <tt>while</tt>-Schleife den Knoten u mit der Pfadlänge lu, und in der (i+1)-ten Iteration den Knoten v mit der Pfadlänge lv, so gilt stets lv ≥ lu. Wir zeigen dies mit der Technik des indirekten Beweises, d.h. wir nehmen das Gegenteil an und führen diese Annahme zum Widerspruch. Wäre also lv < lu, gäbe es zwei Möglichkeiten:
<ol>
<li>Der Weg nach v mit der Länge lv war in der i-ten Iteration schon bekannt und somit bereits im Heap enthalten. Dann hätte <tt>heappop</tt> in dieser Iteration aber v zurückgegeben, im Widerspruch zur Annahme, dass u zurückgegeben wurde.</li>
<li>Der Weg wurde erst bei der Expansion von u in der i-ten Iteration gefunden. Dann muss v ein Nachbar von u sein, und seine Weglänge berechnet sich als lv = lu + wu,v. Da für die Kantengewichte aber wu,v ≥ 0 gefordert ist, kann lv < lu nicht gelten.</li>
</ol>
Diese Monotonieeigenschaft hat eine interessante Konsequenz: Beträgt der Abstand vom Start zum Zielknoten lz, so findet Dijsktra's Algorithmus als Nebenprodukt auch die kürzesten Wege zu allen näher gelegenen Knoten, also zu allen Knoten u, für deren Abstand lu < lz gilt. Dies trifft auch dann zu, wenn diese Wege für den Benutzer gar nicht von Interesse sind. Der A*-Algorithmus, der weiter unten erklärt wird, versucht dem abzuhelfen.

Wir können nun mittels vollständiger Induktion die folgende Schleifen-Invariante beweisen: 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 wieder 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 dem Momemnt in den Heap eingefügt werden, wo der kürzeste Weg für <tt>predecessor</tt> gefunden wurde. Man beachte auch, dass wegen der Monotonieeigenschaft alle Knoten, die noch nicht in <math>S</math> enthalten sind, weiter vom Start entfernt sind als die Knoten in <math>S</math>.
: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 im Heap 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>: Wegen der Monotonieeigenschaft muss jetzt <tt>Kosten(x → startnode) > Kosten(node → predecessor → startnode)</tt> gelten. Die Kosten des Weges <tt>node</tt> → <tt>x</tt> → <tt>startnode</tt> berechnen sich aber als <tt>Kosten(x → startnode) + weight[(x, node)]</tt>, und deshalb kann dieser Weg keinesfalls kürzer sein.
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 range(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 range(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 range(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: # neuer Knoten gefunden:
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
else:
return False # node war bereits 'finished' => kein Zyklus

for node in range(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 range(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]]

== 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]]

Hashing und Hashtabellen

2020-06-23T14:11:22Z

Alda: /* Doppeltes Hashing */

Die Mitschrift gibts auch als [http://hci.iwr.uni-heidelberg.de/alda/images/AlDa.pdf PDF].
== Hashing ==

Wir haben im Abschnitt [[Assoziative Arrays]] gezeigt, dass man assoziative Arrays effizient mit Hilfe von Suchbäumen realisieren kann, so dass die Zugriffszeit auf ein Element in O(log(len(a))) ist. Genau wie beim Sortierproblem stellt sich jetzt die Frage, ob die Zugriffszeit noch verbessert werden kann, idealerseise auf O(1) wie beim gewöhnlichen Array. Die Antwort lautet: Ja, wenn für die Schlüssel eine Hashfunktion definiert ist.

===Hashfunktionen===

Hashfunktionen sind eine weitere Anwendung des [[Sortieren in linearer Zeit#Bucket-Prinzip|Bucket-Prinzips]], das wir im Zusammenhang mit dem Sortieren in linearer Zeit eingeführt haben. man bildet die Schlüssel wiederum auf Bucket-Indizes ab, um die Suche zu beschleunigen (von O(log N) nach O(1)). Im Unterschied zum Sortieren verzichtet man hier allerdings darauf, dass die Abbildung auf Bucket-Indizes die Ordnung der Schlüssel erhalten muss (es muss nicht einmal eine Ordnung definiert sein), weil diese Forderung es erschwert, die Schlüssel gleichmäßig auf die Buckets zu verteilen. Letzteres ist aber bei Hashtabellen extrem wichtig.

Gegeben sei ein Universum U, dass die Menge aller legalen Schlüssel darstellt. Die Mächtigkeit |U| der Menge U ist im allgemeinen sehr groß. Beispielsweise kann man mit Strings der Länge 9 bis zu 279≈1013≈243 verschiedene Schlüssel generieren, wenn 27 Zeichen erlaubt sind (Kleinbuchstaben und Leerzeichen). Die Grundannahme von Hashing ist jetzt, dass in jeder gegebenen Anwendung nur ein (kleiner) Teil der erlaubten Schlüssel tatsächlich verwendet wird. Man definiert eine Hashfunktion, die jeden Schlüssel auf eine natürliche Zahl im Bereich 0...(M-1) abbildet, wobei M viel kleiner als |U| ist.
;Definition einer Hashfunktion:
:::<math> f: U \rightarrow [0, 1, \ldots, M-1] \subset \mathbb{N} </math>
:::<math> f(u \in U) = h \in [0, 1, \ldots, M-1]</math>
h wird als ''Hashwert'' von u bezeichnet. Da M < |U|, werden notwendigerweise einige Schlüssel auf dieselbe Zahl abgebildet. Man bezeichnet den Fall <math> f(u_1 \in U) = f(u_2 \in U) </math> als ''Kollision'' zwischen den Schlüsseln u1 und u2.

Die '''Aufgabe''' besteht jetzt darin, ein Hash-Funktion zu entwerfen, die möglichst wenige Kollisionen hat. Hashfunktionen ähneln damit einem Zufallszahlengenerator, weil jede Zahl <math> h \in 0 \ldots (M-1) </math> nach Möglichkeit mit gleicher Wahrscheinlichkeit herauskommen soll. Wird dieses Ziel erreicht, spricht man vom ''uniformen Hashing''.

In der Regel ist aber nicht vorher bekannt, welche Schlüssel in einer Anwendung verwendet werden. Es kann deshalb immer vorkommen, dass die verwendete Schlüsselmenge sehr viele Kollisionen verursacht. Man sieht in der Tat leicht ein, dass für jede gegebene Hashfunktion ungünstige Schlüsselmengen <math> U_f \subset U</math> existieren, bei denen es sehr viele Kollisionen gibt. Im ungünstigsten Fall könnte Uf so gewählt sein, dass f(Uf) = k = const. gilt. Ein Hacker, der die verwendete Hashfunktion kennt, kann z.B. Uf absichtlich so wählen, um eine denial-of-service-Attacke gegen einen hash-basierten Webservice zu starten. Ein anderes anschauliches Beispiel wäre eine Party, zu der nur Leute eingeladen werden, die an einem 8ten im Monat Geburtstag haben. Auf dieser Party ist es viel wahrscheinlicher, Leute zu finden, die am selben (oder gleichen) Tag Geburtstag haben, als wenn man alle einlädt.

D.h. die Wahl einer guten Hashfunktion ist eine Kunst, und man muss (wenn möglich) die Daten analysieren um ein gutes f zu finden.

====Perfektes Hashing====

Kennt man die Untermenge der tatsächlich vorkommenden Schlüssel <math>U_f \subset U</math> schon im voraus, hat man die Möglichkeit, eine ''perfekte Hashfunktion'' ohne Kollisionen zu entwerfen.

;Beispiel anhand der Monatsnamen

U ist in diesem Fall eine Menge von Strings der Länge 9 (weil der September als längster Monatsname 9 Zeichen hat). Es ergeben sich also <math>60^{9}</math>>≈1016≈254 mögliche Strings, da mit Groß- und Kleinbuchstaben, Umlauten, ß und Leerzeichen 60 Zeichen im deutschen Alphabet vorhanden sind. Von all diesen Möglichkeiten werden genau 12 benutzt:
:::<math>U_f</math> = {"Januar"; "Februar"; ... ; "Dezember"}
* Benutzt man nun als Hashfunktion die Anfangsbuchstaben der Monatsnamen, benötigt man dafür 6 bit. M ist somit 64.
:::{"Januar"; "Februar"; ... ; "Dezember"} → {"J"; "F"; "M"; "A"; "M"; "J"; "J"; "A"; "S"; "O"; "N"; "D"}
:Dabei enstehen viele Kollisionen (J wird 3x verwendet, M 2x, A 2x), die gewählte ist also keine gute Hashfunktion
* Benutzt man als Hashfunktion die ersten 3 Buchstaben benötigt man 18 bit, M = <math>2^{18}</math>
:::{"Januar"; "Februar"; ... ; "Dezember"} → {"Jan", "Feb", "März", "Apr", "Mai", "Jun", "Jul", "Aug", "Sep", "Okt", "Nov", "Dez"}
:Nun entstehen keine Kollision mehr. Diese Hashfunktion ist deshalb beim Ausfüllen von Formularen und dergleichen sehr beliebt. Dafür ist M aber recht groß.

Die Aufgabe wird also präzisiert: man sucht für <math>U_f</math> eine '''minimale, perfekte Hashfunktion''', für die <math>|U_f| = M</math> gilt. Ein Verfahren hierfür ist Gegenstand von Übungsblatt 9.

====Universelles Hashing====

Hier wählt man für eine gegebene Hashtabelle die Hashfunktion per Zufallszahl aus einer (großen) Menge erlaubter Hashfunktion → Die Wahrscheinlichkeit, dass die Hashfunktion für die Schlüssel ungünstig ist, wird dadruch minimiert. Die oben erwähnte denial-of-service-Attacke ist jetzt nicht mehr möglich, weil kein Hacker die Hashfunktion im voraus kennen kann. Näheres zum universellen Hashing finden Sie in der [http://en.wikipedia.org/wiki/Universal_hashing Wikpedia].

====Kryptographische Hashfunktionen====

In kryptographischen Anwendungen treten neben dem Hauptziel, die Größe des Universums auf eine überschaubare Zahl von Integer-Werten zu reduzieren, zwei weitere Anforderungen, die für Verschlüsselung bzw. verschlüsselte Kommunikation wichtig sind: erstens will man Kollisionen unbedingt vermeiden (damit zwei verschiedene Dokumente oder Passwörter nicht auf den gleichen Hashwert abgebildet werden), und zweitens darf es nicht möglich sein, aus dem Hashwert die urpsrüngliche Nachricht (also das Dokument oder Passwort) zu rekonstruieren. Man wählt deshalb relative große M (128 bit und mehr) sowie spezielle, für diesen Zweck optimierte Hashfunktionen, wie z.B. [http://de.wikipedia.org/wiki/Message-Digest_Algorithm_5 md5] und [http://de.wikipedia.org/wiki/SHA1 sha1]. Weitere Einzelheiten finden Sie in der [http://en.wikipedia.org/wiki/Cryptographic_hash_function Wikipedia].

====Beliebte Standard-Hashfunktionen====

In der Praxis definiert man Hashfunktionen gewöhnlich zweistufig: Zunächst bildet man den Schlüssel auf einen 32 bit Integerwert ab, M' ist damit 232. Dieser "rohe" Hashwert wird dann mittels der Modulo-Operation auf die eigentliche Größe M des assoziativen Arrays abgebildet:
:::<math> f(u \in U) = f'(u \in U)\,\%\,M\,=\,h \in [0, 1, \ldots, M-1] </math>
mit
:::<math> f'(u \in U) = h' \in [0, 1, \ldots, 2^{32}-1] </math>
Der große Wert von M' sichert, dass man bei der Wahl von M großen Spielraum hat, so dass die Größe des assoziativen Arrays sehr gut an die Menge der zu speichernden Daten angepaßt werden kann. Die Funktion f'(u) definiert man wie folgt:
* Falls U = <tt>unsigned int</tt> (32bit int Datentyp) ⇒ f'(u) = u
* Falls U = <tt>signed int</tt> ⇒ Typkonvertierung nach <tt>unsigned int</tt> ⇒ f'(u) = (unsigned int)u
* Andere Schlüsseltypen (also insbesondere Strings) interpretiert man als Array of byte ⇒ f'(u) konvertiert Array of Byte nach <tt>unsigned int</tt>. Beispiele für solche Funktionen:
:: '''Bernsteinfunktion:'''
def bHash(u): # u: Array of Byte
h=0
for k in u:
h = 33 * h + k
return h
:: '''modifizierte Bernsteinfunktion:'''
def mbHash(u): # u: Array of Byte
h=0
for k in u:
h = (33 * h) ^ k # ^ ist bitweises Xor
return h
:: '''Shift-Add-Xor-Funktion:'''
def saxhash(u): # u: Array of Byte
h=0
for k in u:
h ^= (h << 5) + (h >> 2) + k # << und >> sind Links- bzw. Rechtsshift der Bits, ^= ist bitweise Xor-Zuweisung
return h
:: '''Fowler/Noll/Vo-Funktion:'''
def FNVhash(u): # u: Array of Byte
h = 2166136261
for k in u:
h = (16777619 * h) ^ k # ähnlich der modifizierten Bernsteinfunktion, aber mit anderen Konstanten
return h
:: Die verwendeten Konstanten sind experimentell so gewählt worden, dass die Hashfunktionen in typischen Praxisanwendungen relativ wenige Kollisionen verursachen. Der tiefere Grund, warum z.B. 33 in der Bernsteinfunktion eine gute Wahl darstellt, ist unbekannt. Es empfielt sich, in einer gegebenen Anwendung mit mehreren Hashfunktionen zu experimentieren. Weitere solche Funktionen und andere nützliche Informationen findet man auf der Seite [http://www.eternallyconfuzzled.com/tuts/algorithms/jsw_tut_hashing.aspx eternallyconfuzzled.com].

== Hashtabellen ==

Eine Hashtabelle ist eine Datenstruktur, die die Funktionalität des assoziativen Arrays mit Hilfe von Hashing realisiert. Das Grundprinzip besteht darin, dass die Hashtabelle intern ein (dynamisches) Array der Größe <tt>capacity</tt> verwaltet, so dass die Hashwerte als Indizes in diesem Array verwendet werden können (<tt>capacity</tt> entspricht der Zahl M aus der mathematischen Definition oben). Eine naive Implementation der Einfügeoperation sieht also so aus
def __setitem__(self, key, value): # naive Implementation, funktioniert so nicht
index = self.hash(key) % self.capacity
self.array[index] = value
Diese Implementation ist allerdings zu einfach. Wenn nämlich die Schlüssel aus dem Universum U beliebig gewählt werden dürfen, sind Kollisionen unvermeidlich. Tritt aber eine Kollision auf, werden die Daten eines Schlüssels mit den Daten eines anderen Schlüssels überschrieben. Um Kollisionen geschickt zu behandeln gibt es zwei Ansätze:
* lineare Verkettung
* offene Adressierung

=== Hashtabelle mit linearer Verkettung (offenes Hashing/geschlossene Adressierung) ===

Man kann dies als die pessimistische Lösung bezeichnen: Man nimmt an, dass Kollisionen häufig auftreten. Deshalb wird unter jedem
Hashindex gleich eine Liste angelegt, in der Einträge mit gleichem Hashindex aufgenommen werden können. Die Hashtabelle verwaltet ein Array von Listen, und jedes Arrayfeld kann beliebig viele Elemente speichern: Wird ein Element auf den Index <tt>i</tt> abgebildet, werden die Daten einfach an die betreffende Liste angehängt. Bei Zugriff auf ein Element wird zunächst die passende Liste gesucht (mit Hilfe des Hashwerts), danach erfolgt in dieser Liste eine sequentielle Suche nach dem richtigen Schlüssel.

Um diese Idee implementieren zu können, benötigen wir zunächst eine Hilfsklasse <tt>HashNode</tt>, die (Schlüssel, Wert)-Paare speichert und mit Hilfe von <tt>next</tt> eine verkettete Liste realisiert:
class HashNode:
def __init__(self,key,data,next):
self.key = key
self.data = data
self.next = next # Verkettung!
Die eigentliche Hashtabelle wird in der Klasse ''HashTable'' implementiert:
class HashTable:
def __init__(self):
self.capacity = ... # Geeignete Werte siehe unten
self.size = 0 # Anzahl der Werte, die zur Zeit tatsächlich gespeichert sind
self.array = [None]*self.capacity
Wie oben bereits erwähnt, werden die Zugriffsoperatoren ''[ ]'' für eine Datenstruktur in Python durch die Funktionen <tt>__setitem__</tt> bzw. <tt>__getitem__</tt> implementiert.
Die <tt>__setitem__</tt>-Funktion speichert die gegebenen Daten unter dem Schlüssel <tt>key</tt> in der <tt>HashTable</tt>-Klasse:
def __setitem__(self, key, value):
index = hash(key) % self.capacity # hash(...) ist in Python eine vordefinierte Funktion
node = self.array[index] # finde die zu 'key' gehörende Liste
while node is not None: # sequentielle Suche nach 'key' in dieser Liste
if node.key == key:
# Element 'key' ist schon in der Tabelle
# => überschreibe die Daten mit dem neuen Wert
node.data = value
return
# andernfalls: Kollision des Hashwerts, probiere nächsten 'key' aus
node = node.next
# kein Element hatte den richtigen Schlüssel.
# => es gibt diesen Schlüssel noch nicht
# füge also ein neues Element in die Hashtabelle ein
self.array[index] = HashNode(key, value, self.array[index]) # der alte Anfang der Liste wird zum
# Nachfolger des neu eingefügten ersten Elements
self.size += 1
... # eventuell muss jetzt noch die Kapazität optimiert werden
Die Funktion <tt>__getitem__</tt> gibt die unter dem Schlüssel <tt>key</tt> abgelegten Daten zurück, oder eine Fehlermeldung, falls dieser Schlüssel nicht existiert:
def __getitem__(self, key):
index = hash(key) % self.capacity
node = self.array[index] # finde die zu 'key' gehörende Liste
while node is not None: # sequentielle Suche nach 'key' in dieser Liste
if node.key == key: # gefunden!
return node.data # => Daten zurückgeben
node = node.next # nächsten Schlüssel probieren
raise KeyError(key) # Schlüssel nicht gefunden => Fehler

==== Komplexität der linearen Verkettung und Wahl der Kapazität ====

Die Komplexität wird durch zwei Operationen bestimmt: erstens das Auffinden der zu einem Schlüssel gehörenden Liste (die in O(1) erfolgt), zweitens das sequentielle Durchsuchen der Liste, die Zeit in O(L) erfordert, wobei L die mittlere Länge der Listen ist. Die Hashtabelle ist also nur schnell, wenn die Länge der Listen möglichst klein ist. Unter der Annahme des ''uniformen Hashings'', wenn also alle Indizes gleich häufig verwendet werden, ist L gleich dem '''Füllstand''' der Hashtabelle:
:::<math>\alpha = \frac{N}{M} = \frac{\text{size}}{\text{capacity}}</math> wobei N die Größe <tt>size</tt> der Hashtabelle und M die Größe <tt>capacity</tt> des Arrays ist.
Wenn die Hashwerte uniform sind, entfallen auf jede Liste im Mittel N/M Einträge (N Einträge, verteilt auf M Listen). Die Gesamtkomplexität berechnet sich nach der Sequenzregel zu
:::<math>O(1+\alpha)</math>
Für eine effiziente Suche muss demnach <math>\alpha \in O(1)</math> gewählt werden. Dies erreicht man, indem man, wie beim dynamischen Array, <tt>capacity</tt> immer wieder anpasst, falls <tt>size</tt> zu groß wird. Üblicherweise verdoppelt man <tt>capacity</tt>, sobald <tt>size == capacity</tt> erreicht wird. Analog zum dynamischen Array werden die Daten dann aus dem alten Array (<tt>self.array</tt>) in ein entsprechend vergrößertes neues Array kopiert.

In der C++ Standardbibliothek (Klasse <tt> [http://www.cplusplus.com/reference/stl/unordered_map/ std::unordered_map]</tt>, siehe auch [http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/src/shared/hashtable-aux.cc?view=markup GCC hashtable_aux.cc (Primzahlen)] und [http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/hashtable_policy.h?view=markup GCC Hash Implementation]) wird die Hashtabelle häufig so
implementiert. Dabei wird <tt>capacity</tt> immer als ''Primzahl'' gewählt, wobei sich aufeinanderfolgende Kapazitäten immer ungefähr verdoppeln. Dazu wählt man aus einer vorberechneten Liste von Primzahlen die kleinste Zahl, so dass <tT>new_capacity >= 2*capacity</tt> gilt, und beginnt z.B. mit einer Default-Kapazität von 11:
11, 23, 47, 97, 199, 409, 823, ...
Die Wahl von Primzahlen hat zur Folge, dass <tt>hash(key) % self.capacity</tt> ''alle'' Bits von h benutzt (Eigenschaft aus der Zahlentheorie). Die Kapazität wird vergrößert, wenn <tt>size == capacity</tt> erreicht wird, und die ungefähre Verdoppelung sichert, dass die amortisierte Komplexität der Einfügeoperation in O(1) ist (wie beim dynamischen Array).

=== Hashtabelle mit offener Adressierung (geschlossenes Hashing) ===
[[Image:HASHTB12.svg.png|frame|Prinzip ([http://en.wikipedia.org/wiki/Hash_table Quelle])]]

Dies kann als die optimistische Variante betrachtet werden: man nimmt an, dass Kollisionen nicht so häufig auftreten, um eine komplexe Datenstruktur wie das "Array von Listen" zu rechtfertigen. Stattdessen behandelt man Kollisionen mit einer einfachen '''Idee''': Wenn <tt>array[index]</tt> durch Kollision bereits vergeben ist, probiere einen
anderen Index aus (siehe auch [http://de.wikipedia.org/wiki/Hashtabelle#Hashing_mit_offener_Adressierung Wikipedia (de)] und
[http://en.wikipedia.org/wiki/Open_addressing Wikipedia (en)]). Dabei muss man folgendes beachten:

* Das Array enthält pro Element höchstens ein (key,value)-Paar
* Das Array muss stets mindestens ''einen'' freien Platz haben (sonst gäbe es beim Ausprobieren anderer Indizes eine Endlosschleife). Es gilt immer <tt>self.size < self.capacity</tt>. Dies war bei der vorigen Hash-Implementation mit linearer Verkettung nicht notwendig (aber im Sinne schneller Zugriffszeiten trotzdem wünschenswert).

==== Vorgehen bei Kollisionen ====

=====Sequentielles Sondieren=====

Probiere den nächsten Index: <tt>index = (index+1) % capacity</tt>

* Vorteil: einfach
* Nachteil: Clusterbildung

Clusterbildung heißt, dass sich größere zusammenhängende Bereiche bilden die belegt sind, unterbrochen von Bereichen die komplett frei sind. Beim Versuch des Einfügens eines Elements an einen Platz, der schon belegt ist, muss jetzt das ganze Cluster sequentiell durchlaufen werden, bis ein freier Platz gefunden wird. Damit entspricht die Komplexität der Suche der mittleren Länge der belegten Bereiche, was sich entsprechend in einer langsamen Suche widerspiegelt.

=====Doppeltes Hashing=====

[http://de.wikipedia.org/wiki/Doppel-Hashing Wikipedia (de)] [http://en.wikipedia.org/wiki/Double_hashing Wikipedia (en)]

Bestimme einen neuen Index (bei Kollisionen) durch eine ''2. Hashfunktion''.

Das doppelte Hashing wird typischerweise in der Praxis angewendet und liegt auch der Python Implementierung des Datentyps [http://docs.python.org/tut/node7.html#SECTION007500000000000000000 Dictionary] (Syntax <tt>{'a':1, 'b':2, 'c':3}</tt> zugrunde.

Eine effiziente Implementierung dieses Datentyps ist für die Performance der Skriptsprache Python extrem wichtig, da z.B. beim Aufruf einer Funktion der auszuführunde Code in einem Dictionary unter dem Schlüssel ''Funktionsname'' nachgeschlagen wird oder die Werte lokaler Variablen innerhalb einer Funktion ebenfalls in einem Dictionary zu finden sind.

Für die Implementierung in Python werden wieder die obigen Klassen <tt>HashNode</tt> (das Attribut <tt>next</tt> kann allerdings jetzt entfernt werden) und <tt>HashTable</tt> benötigt, es folgen die angepassten Implementationen von <tt>__setitem__</tt> und <tt>__getitem__</tt>:

def __setitem__(self, key, value):
h = hash(key)
index = h % self.capacity
# erste Schleife: teste, ob key schon vorhanden ist
while True:
if self.array[index] is None: # freies Feld gefunden => key nicht vorhanden
break
if self.array[index].key == key: # key gefunden => Daten aktualisieren
self.array[index].data = value
return
# self.array[index].key ist anderer Schlüssel oder als gelöscht markiert
# => neuen Index durch 2. Hashfunktion berechnen
index = (5*index+1+h) % self.capacity
h = h // 32
# wenn wir hier landen, wurde key nicht gefunden
h = hash(key)
index = h % self.capacity
# zweite Schleife: neues Element einfügen
while True:
if self.array[index] is None or self.array[index].key is None:
# index ist frei (1. Bedingung) oder als gelöscht markiert (2. Bedingung)
# => hier gehört key hin
self.array[index] = HashNode(key, value)
self.size +=1
... # eventuell muss hier die Kapazität optimiert werden
return
# index ist schon belegt => neuen Index durch 2. Hashfunktion berechnen
index = (5*index+1+h) % self.capacity
h = h // 32

Wir nehmen bei dieser Implementation an, dass gelöschte Elemente dadurch markiert werden, dass <tt>self.array[index].key</tt> auf einen Schlüssel gesetzt wird, der sonst nicht vorkommen kann (z.B. <tt>None</tt>). Dann wird die if-Abfrage <tt>self.array[index].key == key</tt> niemals wahr, und es wird weitergesucht. Würde man hingegen das Element vollständig löschen, könnte die Bedingung <tt>self.array[index] is None</tt> zu früh wahr werden, so dass die Schleife vorzeitig abgebrochen und das vorhandene Element für <tt>key</tt> nicht erreicht würde.

def __getitem__(self, key):
h = hash(key)
index = h % self.capacity
while True:
if self.array[index] is None: # die Suchkette bricht ab => key existiert nicht
raise KeyError(key)
if self.array[index].key == key: # key gefunden => zugehörige Daten zurückgeben
return self.array[index].data
# index enthält nicht den passenden kay => neuen Index durch 2. Hashfunktion berechnen
index = (5*index+1+h) % self.capacity
h = h // 32

Die vorgestellte Implementierung orientiert sich an Pythons interner Dictionary Implementierung, der zugehörige Quellcode (mit ausführlichem Kommentar) findet sich im File [https://github.com/python/cpython/blob/master/Objects/dictobject.c dictobject.c] der Python Implementation.

===== Beispiel für doppeltes Hashing =====

Der Übersichtlichkeit wegen wählen wir M'=25 (statt 232) und eine Kapazität von M=8.

Roher Hashwert (für das Beispiel willkürlich gewählt):
h=25
Erster Index:
i0 = h % capacity = 25 % 8 = 1
Es finde eine Kollision statt. Es wird ein zweiter Index berechnet:
i1 = (5*i0 + 1 + h) % 8 = (5*1 + 1 + 25) % 8 = 31 % 8 = 7
Der Hashwert wird aktualisiert um die höherwertigen Bits von <tt>h</tt> ins Spiel zu bringen (hier durch <tt>h >> 2</tt> anstelle von <tt>h >> 5</tt> im originalen Pythoncode). Wir stellen <tt>h</tt> als Binärzahl dar, damit der Rechtsshift besser sichtbar wird:
h = h >> 2
==> h = (11001 >> 2) = 00110 = 6
Es finde wieder eine Kollision statt, so dass ein dritter Index berechnet werden muss.
i2 = (5*i1 + 1 + h) % 8 = (5*7 + 1 + 6) % 8 = 42 % 8 = 2
Der Hashwert wird wiederum aktualisiert:
h = h >> 2
==> h = (00110 >> 2) = 00001 = 1
Es finde eine Kollision statt, und wir berechnen den vierten Index:
i3 = (5*i2 + 1 + h) % 8 = (5*2 + 1 + 1) % 8 = 12 % 8 = 4
Der Hashwert wird nochmals aktualisiert und erreicht jetzt den Wert 0 (der sich dann nicht mehr ändert):
h = h >> 2
==> h = (00110 >> 2) = 0
Es finde eine Kollision statt. Da jetzt <tt>h = 0</tt> gilt, und die Zahlen 5 (Multiplikator) und 8 (capacity) teilerfremd sind, werden ab jetzt systematisch alle Indizes von 0 bis 7 durchprobiert (in der durch die Modulo-Operation bestimmten Reihenfolge):
i4 = (5*i3 + 1 + h) % 8 = (5*4 + 1 + 0) % 8 = 21 % 8 = 5
i5 = (5*i4 + 1 + h) % 8 = (5*5 + 1 + 0) % 8 = 26 % 8 = 2
i6 = (5*i5 + 1 + h) % 8 = (5*2 + 1 + 0) % 8 = 11 & 8 = 3
i7 = (5*i6 + 1 + h) % 8 = (5*3 + 1 + 0) % 8 = 16 & 8 = 0
i8 = (5*i7 + 1 + h) % 8 = (5*0 + 1 + 0) % 8 = 1 & 8 = 1
i9 = (5*i8 + 1 + h) % 8 = (5*1 + 1 + 0) % 8 = 6 & 8 = 6
i10 = (5*i9 + 1 + h) % 8 = (5*6 + 1 + 0) % 8 = 31 & 8 = 7
i11 = (5*i10 + 1 + h) % 8 = (5*7 + 1 + 0) % 8 = 36 & 8 = 4
Allen Indizes werden also erreicht, bevor sich die Folge wiederholt. Da man <tt>capacity</tt> immer so wählt, dass mindestens ein Arrayfeld noch frei ist, wird dadurch immer ein geeigneter Platz für das einzufügende Element gefunden.

==== Komplexität der offenen Adressierung ====

* Annahme: uniformes Hashing, das heißt alle Indizes haben gleiche Wahrscheinlichkeit
* Füllstand <math>\alpha =\frac{N}{M} = \frac{\text{size}}{\text{capacity}}</math>

* '''Erfolglose Suche''' (d.h. es wird entweder ein neues Element eingefügt oder ein <tt>KeyError</tt> geworfen): Untere Schranke für die Komplexität ist <math>\Omega\left(\frac{1}{1-\alpha}\right)</math> Schritte (= Anzahl der notwendigen index-Berechnungen).
* '''Erfolgreiche Suche''' <math>\Omega\left(\frac{1}{\alpha}\ln\left(\frac{1} {1-\alpha}\right)\right)</math> Schritte.

{| border="1" cellspacing="0" cellpadding="5" align="center"
! <math>\alpha</math>
! 0.5
! 0.9
|-
| erfolglos
| 2.0
| 10
|-
| erfolgreich
| 1.4
| 2.6
|}

==== Wahl der Kapazität ====
Man sieht an der obigen Tabelle, dass die erfolglose Suche (und damit das Einfügen) sehr langsam wird, wenn der Füllstand hoch ist. In Python wird <tt>capacity</tt> deshalb so gewählt, dass <math>\alpha \leq 2/3</math>. Falls <math>\alpha</math> größer werden sollte, verdopple die Kapazität und kopiere das alte array in das neue Array (analog zum dynamischen Array)

In Python werden die Kapazitätsgrößen als Zweierpotenzen gewählt, also 4,8,16,32,...,
so dass <tt>h % self.capacity</tt> nur die unteren Bits von <tt>h</tt> benutzt. Die oberen Bits von <tt>h</tt> kommen erst ins Spiel, wenn bei der Berechnung der 2. Hashfunktion die Aktualisierung <tt>h = h >> 5</tt> erfolgt. Dies hat sich bei umfangreichen Experimenten als sehr gute Lösung erwiesen.

== Anwendungen von Hashing ==

* Hashtabelle, assoziatives Aray
* Sortieren in linearer Zeit (Übungsaufgabe 6.2)
* Suchen von Strings in Texten: Rabin-Karp-Algorithmus
* ...

=== Rabin Karp Algorithmus ===
[http://de.wikipedia.org/wiki/Rabin-Karp-Algorithmus Wikipedia (de)] [http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm Wikipedia (en)]

In Textverarbeitungsanwendungen ist eine häufig benutzte Funktion die ''Search & Replace'' Funktionalität. Die Suche sollte in O(len(text)) möglich sein, aber ein naiver Algorithmus braucht O(len(text)*len(searchstring))

==== Naive Implementierung der Textsuche ====
def search(text, s):
M, N = len(text), len(s)
for k in range(M-N):
if s==text[k:k+N]: # O(N), da N Zeichen verglichen werden müssen
return k
return -1 #nicht gefunden

==== Idee des Rabin Karp Algorithmus ====
Statt Vergleichen <tt>s==text[k:k+N]</tt>, die O(N) benötigen, weil N Vergleiche der Buchstaben durchgeführt werden müssen, vergleichen wir die Hashs von Suchstring und dem zu untersuchenden Textabschnitt: <tt>hash(s) == hash(text[k:k+N])</tt>. Dabei muss natürlich <tt>hash(s)</tt> nur einmal berechnet werden, wohingegen <tt>hash(text[k:k+N])</tt> immer wieder neu berechnet werden muss. Damit der Vergleich O(1) sein kann, ist es deswegen erforderlich, eine solche Hashfunktion zu haben, die nicht alle Zeichen (das wäre O(N) ) einlesen muss, sondern die den vorhergehenden Hashwert mit einbezieht.

Eine solche Hashfunktion heißt ''Running Hash'' und funktioniert analog zum ''Sliding Mean''.

Die Running Hash Funktion berechnet in O(1) den hash von <tt>text[k+1:k+1+N]</tt> ausgehend vom hash für <tt>text[k:k+N]</tt>.

Idee: Interpretiere den Text als Ziffern in einer base d Darstellung:

<math>h_k = \text{text}[k]\cdot d^{N-1} + \text{text}[k+1]\cdot d^{N-2} + \cdots + \text{text}[k+N-1]</math>

Für die Basis 10 (Dezimalsystem) ergibt sich also

<math>h_k = \text{text}[k]\cdot {10}^{N-1} + \text{text}[k+1]\cdot {10}^{N-2} + \cdots + \text{text}[k+N-1]</math>

Daraus folgt

<math>h_{k+1} = 10 \cdot h_k - \text {text}[k]\cdot {10}^{N} + \text {text}[k+N]</math>

Die Komplexität dieses Updates ist O(1), falls man <math>{10}^{N}</math> vorberechnet hat.

In der Realität wählt man dann d=32 und benutzt noch an einigen Stellen modulo Operationen, um die Zahlen nicht zu groß werden zu lassen (siehe die Zahl <tt>q</tt> in der folgenden Implementation).

==== Implementation ====
def searchRabinKarp(text, s):
M, N = len(text), len(s)
d = 32
q = 33554393 # q ist eine große Primzahl, aber so,
# dass d*q < 2**32 (um Überlauf bei 32-bit Integerarithmetik zu vermeiden)
dN = d**N % q # Vorberechnung des Vorfaktors für das Entfernen aus dem Hash

# Initialisierung
hs, ht = 0, 0
for k in range(N):
# ord() gibt die Zeichen-Nummer (z.B. ASCII- oder UTF-8-Code) des
# übergebenen Zeichens zurück
hs = (hs*d + ord( s[k] )) % q
ht = (ht*d + ord(text[k])) % q
# Die Variablen sind jetzt wie folgt initialisiert:
# hs = hash(s)
# ht = hash(text[0:N])

# Hauptschleife
k = 0
while k < M-N:
if hs == ht: # übereinstimmende Hashs => prüfe, dass es nicht nur
# eine Kollision ist
if s == text[k:k+N]: # O(N)-Vergleich nur nötig, wenn Hashs übereinstimmen
return k # search string an Position k gefunden
# nicht gefunden => aktualisiere Hash für den nächsten Teilabschnitt von text:
ht = (d*ht + ord(text[k+N])) % q # neues Zeichen text[k+N] in Hash einfügen
ht = (ht - dN*ord(text[k])) % q # Zeichen text[k] aus Hash entfernen.
k +=1
return -1 # search string nicht gefunden

[[Iteration versus Rekursion|Nächstes Thema]]

Hashing und Hashtabellen

2020-06-23T14:08:35Z

Alda: /* Doppeltes Hashing */

Die Mitschrift gibts auch als [http://hci.iwr.uni-heidelberg.de/alda/images/AlDa.pdf PDF].
== Hashing ==

Wir haben im Abschnitt [[Assoziative Arrays]] gezeigt, dass man assoziative Arrays effizient mit Hilfe von Suchbäumen realisieren kann, so dass die Zugriffszeit auf ein Element in O(log(len(a))) ist. Genau wie beim Sortierproblem stellt sich jetzt die Frage, ob die Zugriffszeit noch verbessert werden kann, idealerseise auf O(1) wie beim gewöhnlichen Array. Die Antwort lautet: Ja, wenn für die Schlüssel eine Hashfunktion definiert ist.

===Hashfunktionen===

Hashfunktionen sind eine weitere Anwendung des [[Sortieren in linearer Zeit#Bucket-Prinzip|Bucket-Prinzips]], das wir im Zusammenhang mit dem Sortieren in linearer Zeit eingeführt haben. man bildet die Schlüssel wiederum auf Bucket-Indizes ab, um die Suche zu beschleunigen (von O(log N) nach O(1)). Im Unterschied zum Sortieren verzichtet man hier allerdings darauf, dass die Abbildung auf Bucket-Indizes die Ordnung der Schlüssel erhalten muss (es muss nicht einmal eine Ordnung definiert sein), weil diese Forderung es erschwert, die Schlüssel gleichmäßig auf die Buckets zu verteilen. Letzteres ist aber bei Hashtabellen extrem wichtig.

Gegeben sei ein Universum U, dass die Menge aller legalen Schlüssel darstellt. Die Mächtigkeit |U| der Menge U ist im allgemeinen sehr groß. Beispielsweise kann man mit Strings der Länge 9 bis zu 279≈1013≈243 verschiedene Schlüssel generieren, wenn 27 Zeichen erlaubt sind (Kleinbuchstaben und Leerzeichen). Die Grundannahme von Hashing ist jetzt, dass in jeder gegebenen Anwendung nur ein (kleiner) Teil der erlaubten Schlüssel tatsächlich verwendet wird. Man definiert eine Hashfunktion, die jeden Schlüssel auf eine natürliche Zahl im Bereich 0...(M-1) abbildet, wobei M viel kleiner als |U| ist.
;Definition einer Hashfunktion:
:::<math> f: U \rightarrow [0, 1, \ldots, M-1] \subset \mathbb{N} </math>
:::<math> f(u \in U) = h \in [0, 1, \ldots, M-1]</math>
h wird als ''Hashwert'' von u bezeichnet. Da M < |U|, werden notwendigerweise einige Schlüssel auf dieselbe Zahl abgebildet. Man bezeichnet den Fall <math> f(u_1 \in U) = f(u_2 \in U) </math> als ''Kollision'' zwischen den Schlüsseln u1 und u2.

Die '''Aufgabe''' besteht jetzt darin, ein Hash-Funktion zu entwerfen, die möglichst wenige Kollisionen hat. Hashfunktionen ähneln damit einem Zufallszahlengenerator, weil jede Zahl <math> h \in 0 \ldots (M-1) </math> nach Möglichkeit mit gleicher Wahrscheinlichkeit herauskommen soll. Wird dieses Ziel erreicht, spricht man vom ''uniformen Hashing''.

In der Regel ist aber nicht vorher bekannt, welche Schlüssel in einer Anwendung verwendet werden. Es kann deshalb immer vorkommen, dass die verwendete Schlüsselmenge sehr viele Kollisionen verursacht. Man sieht in der Tat leicht ein, dass für jede gegebene Hashfunktion ungünstige Schlüsselmengen <math> U_f \subset U</math> existieren, bei denen es sehr viele Kollisionen gibt. Im ungünstigsten Fall könnte Uf so gewählt sein, dass f(Uf) = k = const. gilt. Ein Hacker, der die verwendete Hashfunktion kennt, kann z.B. Uf absichtlich so wählen, um eine denial-of-service-Attacke gegen einen hash-basierten Webservice zu starten. Ein anderes anschauliches Beispiel wäre eine Party, zu der nur Leute eingeladen werden, die an einem 8ten im Monat Geburtstag haben. Auf dieser Party ist es viel wahrscheinlicher, Leute zu finden, die am selben (oder gleichen) Tag Geburtstag haben, als wenn man alle einlädt.

D.h. die Wahl einer guten Hashfunktion ist eine Kunst, und man muss (wenn möglich) die Daten analysieren um ein gutes f zu finden.

====Perfektes Hashing====

Kennt man die Untermenge der tatsächlich vorkommenden Schlüssel <math>U_f \subset U</math> schon im voraus, hat man die Möglichkeit, eine ''perfekte Hashfunktion'' ohne Kollisionen zu entwerfen.

;Beispiel anhand der Monatsnamen

U ist in diesem Fall eine Menge von Strings der Länge 9 (weil der September als längster Monatsname 9 Zeichen hat). Es ergeben sich also <math>60^{9}</math>>≈1016≈254 mögliche Strings, da mit Groß- und Kleinbuchstaben, Umlauten, ß und Leerzeichen 60 Zeichen im deutschen Alphabet vorhanden sind. Von all diesen Möglichkeiten werden genau 12 benutzt:
:::<math>U_f</math> = {"Januar"; "Februar"; ... ; "Dezember"}
* Benutzt man nun als Hashfunktion die Anfangsbuchstaben der Monatsnamen, benötigt man dafür 6 bit. M ist somit 64.
:::{"Januar"; "Februar"; ... ; "Dezember"} → {"J"; "F"; "M"; "A"; "M"; "J"; "J"; "A"; "S"; "O"; "N"; "D"}
:Dabei enstehen viele Kollisionen (J wird 3x verwendet, M 2x, A 2x), die gewählte ist also keine gute Hashfunktion
* Benutzt man als Hashfunktion die ersten 3 Buchstaben benötigt man 18 bit, M = <math>2^{18}</math>
:::{"Januar"; "Februar"; ... ; "Dezember"} → {"Jan", "Feb", "März", "Apr", "Mai", "Jun", "Jul", "Aug", "Sep", "Okt", "Nov", "Dez"}
:Nun entstehen keine Kollision mehr. Diese Hashfunktion ist deshalb beim Ausfüllen von Formularen und dergleichen sehr beliebt. Dafür ist M aber recht groß.

Die Aufgabe wird also präzisiert: man sucht für <math>U_f</math> eine '''minimale, perfekte Hashfunktion''', für die <math>|U_f| = M</math> gilt. Ein Verfahren hierfür ist Gegenstand von Übungsblatt 9.

====Universelles Hashing====

Hier wählt man für eine gegebene Hashtabelle die Hashfunktion per Zufallszahl aus einer (großen) Menge erlaubter Hashfunktion → Die Wahrscheinlichkeit, dass die Hashfunktion für die Schlüssel ungünstig ist, wird dadruch minimiert. Die oben erwähnte denial-of-service-Attacke ist jetzt nicht mehr möglich, weil kein Hacker die Hashfunktion im voraus kennen kann. Näheres zum universellen Hashing finden Sie in der [http://en.wikipedia.org/wiki/Universal_hashing Wikpedia].

====Kryptographische Hashfunktionen====

In kryptographischen Anwendungen treten neben dem Hauptziel, die Größe des Universums auf eine überschaubare Zahl von Integer-Werten zu reduzieren, zwei weitere Anforderungen, die für Verschlüsselung bzw. verschlüsselte Kommunikation wichtig sind: erstens will man Kollisionen unbedingt vermeiden (damit zwei verschiedene Dokumente oder Passwörter nicht auf den gleichen Hashwert abgebildet werden), und zweitens darf es nicht möglich sein, aus dem Hashwert die urpsrüngliche Nachricht (also das Dokument oder Passwort) zu rekonstruieren. Man wählt deshalb relative große M (128 bit und mehr) sowie spezielle, für diesen Zweck optimierte Hashfunktionen, wie z.B. [http://de.wikipedia.org/wiki/Message-Digest_Algorithm_5 md5] und [http://de.wikipedia.org/wiki/SHA1 sha1]. Weitere Einzelheiten finden Sie in der [http://en.wikipedia.org/wiki/Cryptographic_hash_function Wikipedia].

====Beliebte Standard-Hashfunktionen====

In der Praxis definiert man Hashfunktionen gewöhnlich zweistufig: Zunächst bildet man den Schlüssel auf einen 32 bit Integerwert ab, M' ist damit 232. Dieser "rohe" Hashwert wird dann mittels der Modulo-Operation auf die eigentliche Größe M des assoziativen Arrays abgebildet:
:::<math> f(u \in U) = f'(u \in U)\,\%\,M\,=\,h \in [0, 1, \ldots, M-1] </math>
mit
:::<math> f'(u \in U) = h' \in [0, 1, \ldots, 2^{32}-1] </math>
Der große Wert von M' sichert, dass man bei der Wahl von M großen Spielraum hat, so dass die Größe des assoziativen Arrays sehr gut an die Menge der zu speichernden Daten angepaßt werden kann. Die Funktion f'(u) definiert man wie folgt:
* Falls U = <tt>unsigned int</tt> (32bit int Datentyp) ⇒ f'(u) = u
* Falls U = <tt>signed int</tt> ⇒ Typkonvertierung nach <tt>unsigned int</tt> ⇒ f'(u) = (unsigned int)u
* Andere Schlüsseltypen (also insbesondere Strings) interpretiert man als Array of byte ⇒ f'(u) konvertiert Array of Byte nach <tt>unsigned int</tt>. Beispiele für solche Funktionen:
:: '''Bernsteinfunktion:'''
def bHash(u): # u: Array of Byte
h=0
for k in u:
h = 33 * h + k
return h
:: '''modifizierte Bernsteinfunktion:'''
def mbHash(u): # u: Array of Byte
h=0
for k in u:
h = (33 * h) ^ k # ^ ist bitweises Xor
return h
:: '''Shift-Add-Xor-Funktion:'''
def saxhash(u): # u: Array of Byte
h=0
for k in u:
h ^= (h << 5) + (h >> 2) + k # << und >> sind Links- bzw. Rechtsshift der Bits, ^= ist bitweise Xor-Zuweisung
return h
:: '''Fowler/Noll/Vo-Funktion:'''
def FNVhash(u): # u: Array of Byte
h = 2166136261
for k in u:
h = (16777619 * h) ^ k # ähnlich der modifizierten Bernsteinfunktion, aber mit anderen Konstanten
return h
:: Die verwendeten Konstanten sind experimentell so gewählt worden, dass die Hashfunktionen in typischen Praxisanwendungen relativ wenige Kollisionen verursachen. Der tiefere Grund, warum z.B. 33 in der Bernsteinfunktion eine gute Wahl darstellt, ist unbekannt. Es empfielt sich, in einer gegebenen Anwendung mit mehreren Hashfunktionen zu experimentieren. Weitere solche Funktionen und andere nützliche Informationen findet man auf der Seite [http://www.eternallyconfuzzled.com/tuts/algorithms/jsw_tut_hashing.aspx eternallyconfuzzled.com].

== Hashtabellen ==

Eine Hashtabelle ist eine Datenstruktur, die die Funktionalität des assoziativen Arrays mit Hilfe von Hashing realisiert. Das Grundprinzip besteht darin, dass die Hashtabelle intern ein (dynamisches) Array der Größe <tt>capacity</tt> verwaltet, so dass die Hashwerte als Indizes in diesem Array verwendet werden können (<tt>capacity</tt> entspricht der Zahl M aus der mathematischen Definition oben). Eine naive Implementation der Einfügeoperation sieht also so aus
def __setitem__(self, key, value): # naive Implementation, funktioniert so nicht
index = self.hash(key) % self.capacity
self.array[index] = value
Diese Implementation ist allerdings zu einfach. Wenn nämlich die Schlüssel aus dem Universum U beliebig gewählt werden dürfen, sind Kollisionen unvermeidlich. Tritt aber eine Kollision auf, werden die Daten eines Schlüssels mit den Daten eines anderen Schlüssels überschrieben. Um Kollisionen geschickt zu behandeln gibt es zwei Ansätze:
* lineare Verkettung
* offene Adressierung

=== Hashtabelle mit linearer Verkettung (offenes Hashing/geschlossene Adressierung) ===

Man kann dies als die pessimistische Lösung bezeichnen: Man nimmt an, dass Kollisionen häufig auftreten. Deshalb wird unter jedem
Hashindex gleich eine Liste angelegt, in der Einträge mit gleichem Hashindex aufgenommen werden können. Die Hashtabelle verwaltet ein Array von Listen, und jedes Arrayfeld kann beliebig viele Elemente speichern: Wird ein Element auf den Index <tt>i</tt> abgebildet, werden die Daten einfach an die betreffende Liste angehängt. Bei Zugriff auf ein Element wird zunächst die passende Liste gesucht (mit Hilfe des Hashwerts), danach erfolgt in dieser Liste eine sequentielle Suche nach dem richtigen Schlüssel.

Um diese Idee implementieren zu können, benötigen wir zunächst eine Hilfsklasse <tt>HashNode</tt>, die (Schlüssel, Wert)-Paare speichert und mit Hilfe von <tt>next</tt> eine verkettete Liste realisiert:
class HashNode:
def __init__(self,key,data,next):
self.key = key
self.data = data
self.next = next # Verkettung!
Die eigentliche Hashtabelle wird in der Klasse ''HashTable'' implementiert:
class HashTable:
def __init__(self):
self.capacity = ... # Geeignete Werte siehe unten
self.size = 0 # Anzahl der Werte, die zur Zeit tatsächlich gespeichert sind
self.array = [None]*self.capacity
Wie oben bereits erwähnt, werden die Zugriffsoperatoren ''[ ]'' für eine Datenstruktur in Python durch die Funktionen <tt>__setitem__</tt> bzw. <tt>__getitem__</tt> implementiert.
Die <tt>__setitem__</tt>-Funktion speichert die gegebenen Daten unter dem Schlüssel <tt>key</tt> in der <tt>HashTable</tt>-Klasse:
def __setitem__(self, key, value):
index = hash(key) % self.capacity # hash(...) ist in Python eine vordefinierte Funktion
node = self.array[index] # finde die zu 'key' gehörende Liste
while node is not None: # sequentielle Suche nach 'key' in dieser Liste
if node.key == key:
# Element 'key' ist schon in der Tabelle
# => überschreibe die Daten mit dem neuen Wert
node.data = value
return
# andernfalls: Kollision des Hashwerts, probiere nächsten 'key' aus
node = node.next
# kein Element hatte den richtigen Schlüssel.
# => es gibt diesen Schlüssel noch nicht
# füge also ein neues Element in die Hashtabelle ein
self.array[index] = HashNode(key, value, self.array[index]) # der alte Anfang der Liste wird zum
# Nachfolger des neu eingefügten ersten Elements
self.size += 1
... # eventuell muss jetzt noch die Kapazität optimiert werden
Die Funktion <tt>__getitem__</tt> gibt die unter dem Schlüssel <tt>key</tt> abgelegten Daten zurück, oder eine Fehlermeldung, falls dieser Schlüssel nicht existiert:
def __getitem__(self, key):
index = hash(key) % self.capacity
node = self.array[index] # finde die zu 'key' gehörende Liste
while node is not None: # sequentielle Suche nach 'key' in dieser Liste
if node.key == key: # gefunden!
return node.data # => Daten zurückgeben
node = node.next # nächsten Schlüssel probieren
raise KeyError(key) # Schlüssel nicht gefunden => Fehler

==== Komplexität der linearen Verkettung und Wahl der Kapazität ====

Die Komplexität wird durch zwei Operationen bestimmt: erstens das Auffinden der zu einem Schlüssel gehörenden Liste (die in O(1) erfolgt), zweitens das sequentielle Durchsuchen der Liste, die Zeit in O(L) erfordert, wobei L die mittlere Länge der Listen ist. Die Hashtabelle ist also nur schnell, wenn die Länge der Listen möglichst klein ist. Unter der Annahme des ''uniformen Hashings'', wenn also alle Indizes gleich häufig verwendet werden, ist L gleich dem '''Füllstand''' der Hashtabelle:
:::<math>\alpha = \frac{N}{M} = \frac{\text{size}}{\text{capacity}}</math> wobei N die Größe <tt>size</tt> der Hashtabelle und M die Größe <tt>capacity</tt> des Arrays ist.
Wenn die Hashwerte uniform sind, entfallen auf jede Liste im Mittel N/M Einträge (N Einträge, verteilt auf M Listen). Die Gesamtkomplexität berechnet sich nach der Sequenzregel zu
:::<math>O(1+\alpha)</math>
Für eine effiziente Suche muss demnach <math>\alpha \in O(1)</math> gewählt werden. Dies erreicht man, indem man, wie beim dynamischen Array, <tt>capacity</tt> immer wieder anpasst, falls <tt>size</tt> zu groß wird. Üblicherweise verdoppelt man <tt>capacity</tt>, sobald <tt>size == capacity</tt> erreicht wird. Analog zum dynamischen Array werden die Daten dann aus dem alten Array (<tt>self.array</tt>) in ein entsprechend vergrößertes neues Array kopiert.

In der C++ Standardbibliothek (Klasse <tt> [http://www.cplusplus.com/reference/stl/unordered_map/ std::unordered_map]</tt>, siehe auch [http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/src/shared/hashtable-aux.cc?view=markup GCC hashtable_aux.cc (Primzahlen)] und [http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/hashtable_policy.h?view=markup GCC Hash Implementation]) wird die Hashtabelle häufig so
implementiert. Dabei wird <tt>capacity</tt> immer als ''Primzahl'' gewählt, wobei sich aufeinanderfolgende Kapazitäten immer ungefähr verdoppeln. Dazu wählt man aus einer vorberechneten Liste von Primzahlen die kleinste Zahl, so dass <tT>new_capacity >= 2*capacity</tt> gilt, und beginnt z.B. mit einer Default-Kapazität von 11:
11, 23, 47, 97, 199, 409, 823, ...
Die Wahl von Primzahlen hat zur Folge, dass <tt>hash(key) % self.capacity</tt> ''alle'' Bits von h benutzt (Eigenschaft aus der Zahlentheorie). Die Kapazität wird vergrößert, wenn <tt>size == capacity</tt> erreicht wird, und die ungefähre Verdoppelung sichert, dass die amortisierte Komplexität der Einfügeoperation in O(1) ist (wie beim dynamischen Array).

=== Hashtabelle mit offener Adressierung (geschlossenes Hashing) ===
[[Image:HASHTB12.svg.png|frame|Prinzip ([http://en.wikipedia.org/wiki/Hash_table Quelle])]]

Dies kann als die optimistische Variante betrachtet werden: man nimmt an, dass Kollisionen nicht so häufig auftreten, um eine komplexe Datenstruktur wie das "Array von Listen" zu rechtfertigen. Stattdessen behandelt man Kollisionen mit einer einfachen '''Idee''': Wenn <tt>array[index]</tt> durch Kollision bereits vergeben ist, probiere einen
anderen Index aus (siehe auch [http://de.wikipedia.org/wiki/Hashtabelle#Hashing_mit_offener_Adressierung Wikipedia (de)] und
[http://en.wikipedia.org/wiki/Open_addressing Wikipedia (en)]). Dabei muss man folgendes beachten:

* Das Array enthält pro Element höchstens ein (key,value)-Paar
* Das Array muss stets mindestens ''einen'' freien Platz haben (sonst gäbe es beim Ausprobieren anderer Indizes eine Endlosschleife). Es gilt immer <tt>self.size < self.capacity</tt>. Dies war bei der vorigen Hash-Implementation mit linearer Verkettung nicht notwendig (aber im Sinne schneller Zugriffszeiten trotzdem wünschenswert).

==== Vorgehen bei Kollisionen ====

=====Sequentielles Sondieren=====

Probiere den nächsten Index: <tt>index = (index+1) % capacity</tt>

* Vorteil: einfach
* Nachteil: Clusterbildung

Clusterbildung heißt, dass sich größere zusammenhängende Bereiche bilden die belegt sind, unterbrochen von Bereichen die komplett frei sind. Beim Versuch des Einfügens eines Elements an einen Platz, der schon belegt ist, muss jetzt das ganze Cluster sequentiell durchlaufen werden, bis ein freier Platz gefunden wird. Damit entspricht die Komplexität der Suche der mittleren Länge der belegten Bereiche, was sich entsprechend in einer langsamen Suche widerspiegelt.

=====Doppeltes Hashing=====

[http://de.wikipedia.org/wiki/Doppel-Hashing Wikipedia (de)] [http://en.wikipedia.org/wiki/Double_hashing Wikipedia (en)]

Bestimme einen neuen Index (bei Kollisionen) durch eine ''2. Hashfunktion''.

Das doppelte Hashing wird typischerweise in der Praxis angewendet und liegt auch der Python Implementierung des Datentyps [http://docs.python.org/tut/node7.html#SECTION007500000000000000000 Dictionary] (Syntax <tt>{'a':1, 'b':2, 'c':3}</tt> zugrunde.

Eine effiziente Implementierung dieses Datentyps ist für die Performance der Skriptsprache Python extrem wichtig, da z.B. beim Aufruf einer Funktion der auszuführunde Code in einem Dictionary unter dem Schlüssel ''Funktionsname'' nachgeschlagen wird oder die Werte lokaler Variablen innerhalb einer Funktion ebenfalls in einem Dictionary zu finden sind.

Für die Implementierung in Python werden wieder die obigen Klassen <tt>HashNode</tt> (das Attribut <tt>next</tt> kann allerdings jetzt entfernt werden) und <tt>HashTable</tt> benötigt, es folgen die angepassten Implementationen von <tt>__setitem__</tt> und <tt>__getitem__</tt>:

def __setitem__(self, key, value):
h = hash(key)
index = h % self.capacity
# erste Schleife: teste, ob key schon vorhanden ist
while True:
if self.array[index] is None: # freies Feld gefunden => key nicht vorhanden
break
if self.array[index].key == key: # key gefunden => Daten aktualisieren
self.array[index].data = value
return
# self.array[index].key ist anderer Schlüssel oder als gelöscht markiert
# => neuen Index durch 2. Hashfunktion berechnen
index = (5*index+1+h) % self.capacity
h = h // 32
# wenn wir hier landen, wurde key nicht gefunden
h = hash(key)
index = h % self.capacity
# zweite Schleife: neues Element einfügen
while True:
if self.array[index] is None or self.array[index].key is None:
# index ist frei (1. Bedingung) oder als gelöscht markiert (2. Bedingung)
# => hier gehört key hin
self.array[index] = HashNode(key, value)
self.size +=1
... # eventuell muss hier die Kapazität optimiert werden
return
# index ist schon belegt => neuen Index durch 2. Hashfunktion berechnen
index = (5*index+1+h) % self.capacity
h = h // 32

Wir nehmen bei dieser Implementation an, dass gelöschte Elemente dadurch markiert werden, dass <tt>self.array[index].key</tt> auf einen Schlüssel gesetzt wird, der sonst nicht vorkommen kann (z.B. <tt>None</tt>). Dann wird die if-Abfrage <tt>self.array[index].key == key</tt> niemals wahr, und es wird weitergesucht. Würde man hingegen das Element vollständig löschen, könnte die Bedingung <tt>self.array[index] is None</tt> zu früh wahr werden, so dass die Schleife vorzeitig abgebrochen und das vorhandene Element <tt>key</tt> nicht erreicht würde.

def __getitem__(self, key):
h = hash(key)
index = h % self.capacity
while True:
if self.array[index] is None: # die Suchkette bricht ab => key existiert nicht
raise KeyError(key)
if self.array[index].key == key: # key gefunden => zugehörige Daten zurückgeben
return self.array[index].data
# index enthält nicht den passenden kay => neuen Index durch 2. Hashfunktion berechnen
index = (5*index+1+h) % self.capacity
h = h // 32

Die vorgestellte Implementierung orientiert sich an Pythons interner Dictionary Implementierung, der zugehörige Quellcode (mit ausführlichem Kommentar) findet sich im File [https://github.com/python/cpython/blob/master/Objects/dictobject.c dictobject.c] der Python Implementation.

===== Beispiel für doppeltes Hashing =====

Der Übersichtlichkeit wegen wählen wir M'=25 (statt 232) und eine Kapazität von M=8.

Roher Hashwert (für das Beispiel willkürlich gewählt):
h=25
Erster Index:
i0 = h % capacity = 25 % 8 = 1
Es finde eine Kollision statt. Es wird ein zweiter Index berechnet:
i1 = (5*i0 + 1 + h) % 8 = (5*1 + 1 + 25) % 8 = 31 % 8 = 7
Der Hashwert wird aktualisiert um die höherwertigen Bits von <tt>h</tt> ins Spiel zu bringen (hier durch <tt>h >> 2</tt> anstelle von <tt>h >> 5</tt> im originalen Pythoncode). Wir stellen <tt>h</tt> als Binärzahl dar, damit der Rechtsshift besser sichtbar wird:
h = h >> 2
==> h = (11001 >> 2) = 00110 = 6
Es finde wieder eine Kollision statt, so dass ein dritter Index berechnet werden muss.
i2 = (5*i1 + 1 + h) % 8 = (5*7 + 1 + 6) % 8 = 42 % 8 = 2
Der Hashwert wird wiederum aktualisiert:
h = h >> 2
==> h = (00110 >> 2) = 00001 = 1
Es finde eine Kollision statt, und wir berechnen den vierten Index:
i3 = (5*i2 + 1 + h) % 8 = (5*2 + 1 + 1) % 8 = 12 % 8 = 4
Der Hashwert wird nochmals aktualisiert und erreicht jetzt den Wert 0 (der sich dann nicht mehr ändert):
h = h >> 2
==> h = (00110 >> 2) = 0
Es finde eine Kollision statt. Da jetzt <tt>h = 0</tt> gilt, und die Zahlen 5 (Multiplikator) und 8 (capacity) teilerfremd sind, werden ab jetzt systematisch alle Indizes von 0 bis 7 durchprobiert (in der durch die Modulo-Operation bestimmten Reihenfolge):
i4 = (5*i3 + 1 + h) % 8 = (5*4 + 1 + 0) % 8 = 21 % 8 = 5
i5 = (5*i4 + 1 + h) % 8 = (5*5 + 1 + 0) % 8 = 26 % 8 = 2
i6 = (5*i5 + 1 + h) % 8 = (5*2 + 1 + 0) % 8 = 11 & 8 = 3
i7 = (5*i6 + 1 + h) % 8 = (5*3 + 1 + 0) % 8 = 16 & 8 = 0
i8 = (5*i7 + 1 + h) % 8 = (5*0 + 1 + 0) % 8 = 1 & 8 = 1
i9 = (5*i8 + 1 + h) % 8 = (5*1 + 1 + 0) % 8 = 6 & 8 = 6
i10 = (5*i9 + 1 + h) % 8 = (5*6 + 1 + 0) % 8 = 31 & 8 = 7
i11 = (5*i10 + 1 + h) % 8 = (5*7 + 1 + 0) % 8 = 36 & 8 = 4
Allen Indizes werden also erreicht, bevor sich die Folge wiederholt. Da man <tt>capacity</tt> immer so wählt, dass mindestens ein Arrayfeld noch frei ist, wird dadurch immer ein geeigneter Platz für das einzufügende Element gefunden.

==== Komplexität der offenen Adressierung ====

* Annahme: uniformes Hashing, das heißt alle Indizes haben gleiche Wahrscheinlichkeit
* Füllstand <math>\alpha =\frac{N}{M} = \frac{\text{size}}{\text{capacity}}</math>

* '''Erfolglose Suche''' (d.h. es wird entweder ein neues Element eingefügt oder ein <tt>KeyError</tt> geworfen): Untere Schranke für die Komplexität ist <math>\Omega\left(\frac{1}{1-\alpha}\right)</math> Schritte (= Anzahl der notwendigen index-Berechnungen).
* '''Erfolgreiche Suche''' <math>\Omega\left(\frac{1}{\alpha}\ln\left(\frac{1} {1-\alpha}\right)\right)</math> Schritte.

{| border="1" cellspacing="0" cellpadding="5" align="center"
! <math>\alpha</math>
! 0.5
! 0.9
|-
| erfolglos
| 2.0
| 10
|-
| erfolgreich
| 1.4
| 2.6
|}

==== Wahl der Kapazität ====
Man sieht an der obigen Tabelle, dass die erfolglose Suche (und damit das Einfügen) sehr langsam wird, wenn der Füllstand hoch ist. In Python wird <tt>capacity</tt> deshalb so gewählt, dass <math>\alpha \leq 2/3</math>. Falls <math>\alpha</math> größer werden sollte, verdopple die Kapazität und kopiere das alte array in das neue Array (analog zum dynamischen Array)

In Python werden die Kapazitätsgrößen als Zweierpotenzen gewählt, also 4,8,16,32,...,
so dass <tt>h % self.capacity</tt> nur die unteren Bits von <tt>h</tt> benutzt. Die oberen Bits von <tt>h</tt> kommen erst ins Spiel, wenn bei der Berechnung der 2. Hashfunktion die Aktualisierung <tt>h = h >> 5</tt> erfolgt. Dies hat sich bei umfangreichen Experimenten als sehr gute Lösung erwiesen.

== Anwendungen von Hashing ==

* Hashtabelle, assoziatives Aray
* Sortieren in linearer Zeit (Übungsaufgabe 6.2)
* Suchen von Strings in Texten: Rabin-Karp-Algorithmus
* ...

=== Rabin Karp Algorithmus ===
[http://de.wikipedia.org/wiki/Rabin-Karp-Algorithmus Wikipedia (de)] [http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm Wikipedia (en)]

In Textverarbeitungsanwendungen ist eine häufig benutzte Funktion die ''Search & Replace'' Funktionalität. Die Suche sollte in O(len(text)) möglich sein, aber ein naiver Algorithmus braucht O(len(text)*len(searchstring))

==== Naive Implementierung der Textsuche ====
def search(text, s):
M, N = len(text), len(s)
for k in range(M-N):
if s==text[k:k+N]: # O(N), da N Zeichen verglichen werden müssen
return k
return -1 #nicht gefunden

==== Idee des Rabin Karp Algorithmus ====
Statt Vergleichen <tt>s==text[k:k+N]</tt>, die O(N) benötigen, weil N Vergleiche der Buchstaben durchgeführt werden müssen, vergleichen wir die Hashs von Suchstring und dem zu untersuchenden Textabschnitt: <tt>hash(s) == hash(text[k:k+N])</tt>. Dabei muss natürlich <tt>hash(s)</tt> nur einmal berechnet werden, wohingegen <tt>hash(text[k:k+N])</tt> immer wieder neu berechnet werden muss. Damit der Vergleich O(1) sein kann, ist es deswegen erforderlich, eine solche Hashfunktion zu haben, die nicht alle Zeichen (das wäre O(N) ) einlesen muss, sondern die den vorhergehenden Hashwert mit einbezieht.

Eine solche Hashfunktion heißt ''Running Hash'' und funktioniert analog zum ''Sliding Mean''.

Die Running Hash Funktion berechnet in O(1) den hash von <tt>text[k+1:k+1+N]</tt> ausgehend vom hash für <tt>text[k:k+N]</tt>.

Idee: Interpretiere den Text als Ziffern in einer base d Darstellung:

<math>h_k = \text{text}[k]\cdot d^{N-1} + \text{text}[k+1]\cdot d^{N-2} + \cdots + \text{text}[k+N-1]</math>

Für die Basis 10 (Dezimalsystem) ergibt sich also

<math>h_k = \text{text}[k]\cdot {10}^{N-1} + \text{text}[k+1]\cdot {10}^{N-2} + \cdots + \text{text}[k+N-1]</math>

Daraus folgt

<math>h_{k+1} = 10 \cdot h_k - \text {text}[k]\cdot {10}^{N} + \text {text}[k+N]</math>

Die Komplexität dieses Updates ist O(1), falls man <math>{10}^{N}</math> vorberechnet hat.

In der Realität wählt man dann d=32 und benutzt noch an einigen Stellen modulo Operationen, um die Zahlen nicht zu groß werden zu lassen (siehe die Zahl <tt>q</tt> in der folgenden Implementation).

==== Implementation ====
def searchRabinKarp(text, s):
M, N = len(text), len(s)
d = 32
q = 33554393 # q ist eine große Primzahl, aber so,
# dass d*q < 2**32 (um Überlauf bei 32-bit Integerarithmetik zu vermeiden)
dN = d**N % q # Vorberechnung des Vorfaktors für das Entfernen aus dem Hash

# Initialisierung
hs, ht = 0, 0
for k in range(N):
# ord() gibt die Zeichen-Nummer (z.B. ASCII- oder UTF-8-Code) des
# übergebenen Zeichens zurück
hs = (hs*d + ord( s[k] )) % q
ht = (ht*d + ord(text[k])) % q
# Die Variablen sind jetzt wie folgt initialisiert:
# hs = hash(s)
# ht = hash(text[0:N])

# Hauptschleife
k = 0
while k < M-N:
if hs == ht: # übereinstimmende Hashs => prüfe, dass es nicht nur
# eine Kollision ist
if s == text[k:k+N]: # O(N)-Vergleich nur nötig, wenn Hashs übereinstimmen
return k # search string an Position k gefunden
# nicht gefunden => aktualisiere Hash für den nächsten Teilabschnitt von text:
ht = (d*ht + ord(text[k+N])) % q # neues Zeichen text[k+N] in Hash einfügen
ht = (ht - dN*ord(text[k])) % q # Zeichen text[k] aus Hash entfernen.
k +=1
return -1 # search string nicht gefunden

[[Iteration versus Rekursion|Nächstes Thema]]

Hashing und Hashtabellen

2020-06-23T14:05:58Z

Alda: /* Doppeltes Hashing */

Die Mitschrift gibts auch als [http://hci.iwr.uni-heidelberg.de/alda/images/AlDa.pdf PDF].
== Hashing ==

Wir haben im Abschnitt [[Assoziative Arrays]] gezeigt, dass man assoziative Arrays effizient mit Hilfe von Suchbäumen realisieren kann, so dass die Zugriffszeit auf ein Element in O(log(len(a))) ist. Genau wie beim Sortierproblem stellt sich jetzt die Frage, ob die Zugriffszeit noch verbessert werden kann, idealerseise auf O(1) wie beim gewöhnlichen Array. Die Antwort lautet: Ja, wenn für die Schlüssel eine Hashfunktion definiert ist.

===Hashfunktionen===

Hashfunktionen sind eine weitere Anwendung des [[Sortieren in linearer Zeit#Bucket-Prinzip|Bucket-Prinzips]], das wir im Zusammenhang mit dem Sortieren in linearer Zeit eingeführt haben. man bildet die Schlüssel wiederum auf Bucket-Indizes ab, um die Suche zu beschleunigen (von O(log N) nach O(1)). Im Unterschied zum Sortieren verzichtet man hier allerdings darauf, dass die Abbildung auf Bucket-Indizes die Ordnung der Schlüssel erhalten muss (es muss nicht einmal eine Ordnung definiert sein), weil diese Forderung es erschwert, die Schlüssel gleichmäßig auf die Buckets zu verteilen. Letzteres ist aber bei Hashtabellen extrem wichtig.

Gegeben sei ein Universum U, dass die Menge aller legalen Schlüssel darstellt. Die Mächtigkeit |U| der Menge U ist im allgemeinen sehr groß. Beispielsweise kann man mit Strings der Länge 9 bis zu 279≈1013≈243 verschiedene Schlüssel generieren, wenn 27 Zeichen erlaubt sind (Kleinbuchstaben und Leerzeichen). Die Grundannahme von Hashing ist jetzt, dass in jeder gegebenen Anwendung nur ein (kleiner) Teil der erlaubten Schlüssel tatsächlich verwendet wird. Man definiert eine Hashfunktion, die jeden Schlüssel auf eine natürliche Zahl im Bereich 0...(M-1) abbildet, wobei M viel kleiner als |U| ist.
;Definition einer Hashfunktion:
:::<math> f: U \rightarrow [0, 1, \ldots, M-1] \subset \mathbb{N} </math>
:::<math> f(u \in U) = h \in [0, 1, \ldots, M-1]</math>
h wird als ''Hashwert'' von u bezeichnet. Da M < |U|, werden notwendigerweise einige Schlüssel auf dieselbe Zahl abgebildet. Man bezeichnet den Fall <math> f(u_1 \in U) = f(u_2 \in U) </math> als ''Kollision'' zwischen den Schlüsseln u1 und u2.

Die '''Aufgabe''' besteht jetzt darin, ein Hash-Funktion zu entwerfen, die möglichst wenige Kollisionen hat. Hashfunktionen ähneln damit einem Zufallszahlengenerator, weil jede Zahl <math> h \in 0 \ldots (M-1) </math> nach Möglichkeit mit gleicher Wahrscheinlichkeit herauskommen soll. Wird dieses Ziel erreicht, spricht man vom ''uniformen Hashing''.

In der Regel ist aber nicht vorher bekannt, welche Schlüssel in einer Anwendung verwendet werden. Es kann deshalb immer vorkommen, dass die verwendete Schlüsselmenge sehr viele Kollisionen verursacht. Man sieht in der Tat leicht ein, dass für jede gegebene Hashfunktion ungünstige Schlüsselmengen <math> U_f \subset U</math> existieren, bei denen es sehr viele Kollisionen gibt. Im ungünstigsten Fall könnte Uf so gewählt sein, dass f(Uf) = k = const. gilt. Ein Hacker, der die verwendete Hashfunktion kennt, kann z.B. Uf absichtlich so wählen, um eine denial-of-service-Attacke gegen einen hash-basierten Webservice zu starten. Ein anderes anschauliches Beispiel wäre eine Party, zu der nur Leute eingeladen werden, die an einem 8ten im Monat Geburtstag haben. Auf dieser Party ist es viel wahrscheinlicher, Leute zu finden, die am selben (oder gleichen) Tag Geburtstag haben, als wenn man alle einlädt.

D.h. die Wahl einer guten Hashfunktion ist eine Kunst, und man muss (wenn möglich) die Daten analysieren um ein gutes f zu finden.

====Perfektes Hashing====

Kennt man die Untermenge der tatsächlich vorkommenden Schlüssel <math>U_f \subset U</math> schon im voraus, hat man die Möglichkeit, eine ''perfekte Hashfunktion'' ohne Kollisionen zu entwerfen.

;Beispiel anhand der Monatsnamen

U ist in diesem Fall eine Menge von Strings der Länge 9 (weil der September als längster Monatsname 9 Zeichen hat). Es ergeben sich also <math>60^{9}</math>>≈1016≈254 mögliche Strings, da mit Groß- und Kleinbuchstaben, Umlauten, ß und Leerzeichen 60 Zeichen im deutschen Alphabet vorhanden sind. Von all diesen Möglichkeiten werden genau 12 benutzt:
:::<math>U_f</math> = {"Januar"; "Februar"; ... ; "Dezember"}
* Benutzt man nun als Hashfunktion die Anfangsbuchstaben der Monatsnamen, benötigt man dafür 6 bit. M ist somit 64.
:::{"Januar"; "Februar"; ... ; "Dezember"} → {"J"; "F"; "M"; "A"; "M"; "J"; "J"; "A"; "S"; "O"; "N"; "D"}
:Dabei enstehen viele Kollisionen (J wird 3x verwendet, M 2x, A 2x), die gewählte ist also keine gute Hashfunktion
* Benutzt man als Hashfunktion die ersten 3 Buchstaben benötigt man 18 bit, M = <math>2^{18}</math>
:::{"Januar"; "Februar"; ... ; "Dezember"} → {"Jan", "Feb", "März", "Apr", "Mai", "Jun", "Jul", "Aug", "Sep", "Okt", "Nov", "Dez"}
:Nun entstehen keine Kollision mehr. Diese Hashfunktion ist deshalb beim Ausfüllen von Formularen und dergleichen sehr beliebt. Dafür ist M aber recht groß.

Die Aufgabe wird also präzisiert: man sucht für <math>U_f</math> eine '''minimale, perfekte Hashfunktion''', für die <math>|U_f| = M</math> gilt. Ein Verfahren hierfür ist Gegenstand von Übungsblatt 9.

====Universelles Hashing====

Hier wählt man für eine gegebene Hashtabelle die Hashfunktion per Zufallszahl aus einer (großen) Menge erlaubter Hashfunktion → Die Wahrscheinlichkeit, dass die Hashfunktion für die Schlüssel ungünstig ist, wird dadruch minimiert. Die oben erwähnte denial-of-service-Attacke ist jetzt nicht mehr möglich, weil kein Hacker die Hashfunktion im voraus kennen kann. Näheres zum universellen Hashing finden Sie in der [http://en.wikipedia.org/wiki/Universal_hashing Wikpedia].

====Kryptographische Hashfunktionen====

In kryptographischen Anwendungen treten neben dem Hauptziel, die Größe des Universums auf eine überschaubare Zahl von Integer-Werten zu reduzieren, zwei weitere Anforderungen, die für Verschlüsselung bzw. verschlüsselte Kommunikation wichtig sind: erstens will man Kollisionen unbedingt vermeiden (damit zwei verschiedene Dokumente oder Passwörter nicht auf den gleichen Hashwert abgebildet werden), und zweitens darf es nicht möglich sein, aus dem Hashwert die urpsrüngliche Nachricht (also das Dokument oder Passwort) zu rekonstruieren. Man wählt deshalb relative große M (128 bit und mehr) sowie spezielle, für diesen Zweck optimierte Hashfunktionen, wie z.B. [http://de.wikipedia.org/wiki/Message-Digest_Algorithm_5 md5] und [http://de.wikipedia.org/wiki/SHA1 sha1]. Weitere Einzelheiten finden Sie in der [http://en.wikipedia.org/wiki/Cryptographic_hash_function Wikipedia].

====Beliebte Standard-Hashfunktionen====

In der Praxis definiert man Hashfunktionen gewöhnlich zweistufig: Zunächst bildet man den Schlüssel auf einen 32 bit Integerwert ab, M' ist damit 232. Dieser "rohe" Hashwert wird dann mittels der Modulo-Operation auf die eigentliche Größe M des assoziativen Arrays abgebildet:
:::<math> f(u \in U) = f'(u \in U)\,\%\,M\,=\,h \in [0, 1, \ldots, M-1] </math>
mit
:::<math> f'(u \in U) = h' \in [0, 1, \ldots, 2^{32}-1] </math>
Der große Wert von M' sichert, dass man bei der Wahl von M großen Spielraum hat, so dass die Größe des assoziativen Arrays sehr gut an die Menge der zu speichernden Daten angepaßt werden kann. Die Funktion f'(u) definiert man wie folgt:
* Falls U = <tt>unsigned int</tt> (32bit int Datentyp) ⇒ f'(u) = u
* Falls U = <tt>signed int</tt> ⇒ Typkonvertierung nach <tt>unsigned int</tt> ⇒ f'(u) = (unsigned int)u
* Andere Schlüsseltypen (also insbesondere Strings) interpretiert man als Array of byte ⇒ f'(u) konvertiert Array of Byte nach <tt>unsigned int</tt>. Beispiele für solche Funktionen:
:: '''Bernsteinfunktion:'''
def bHash(u): # u: Array of Byte
h=0
for k in u:
h = 33 * h + k
return h
:: '''modifizierte Bernsteinfunktion:'''
def mbHash(u): # u: Array of Byte
h=0
for k in u:
h = (33 * h) ^ k # ^ ist bitweises Xor
return h
:: '''Shift-Add-Xor-Funktion:'''
def saxhash(u): # u: Array of Byte
h=0
for k in u:
h ^= (h << 5) + (h >> 2) + k # << und >> sind Links- bzw. Rechtsshift der Bits, ^= ist bitweise Xor-Zuweisung
return h
:: '''Fowler/Noll/Vo-Funktion:'''
def FNVhash(u): # u: Array of Byte
h = 2166136261
for k in u:
h = (16777619 * h) ^ k # ähnlich der modifizierten Bernsteinfunktion, aber mit anderen Konstanten
return h
:: Die verwendeten Konstanten sind experimentell so gewählt worden, dass die Hashfunktionen in typischen Praxisanwendungen relativ wenige Kollisionen verursachen. Der tiefere Grund, warum z.B. 33 in der Bernsteinfunktion eine gute Wahl darstellt, ist unbekannt. Es empfielt sich, in einer gegebenen Anwendung mit mehreren Hashfunktionen zu experimentieren. Weitere solche Funktionen und andere nützliche Informationen findet man auf der Seite [http://www.eternallyconfuzzled.com/tuts/algorithms/jsw_tut_hashing.aspx eternallyconfuzzled.com].

== Hashtabellen ==

Eine Hashtabelle ist eine Datenstruktur, die die Funktionalität des assoziativen Arrays mit Hilfe von Hashing realisiert. Das Grundprinzip besteht darin, dass die Hashtabelle intern ein (dynamisches) Array der Größe <tt>capacity</tt> verwaltet, so dass die Hashwerte als Indizes in diesem Array verwendet werden können (<tt>capacity</tt> entspricht der Zahl M aus der mathematischen Definition oben). Eine naive Implementation der Einfügeoperation sieht also so aus
def __setitem__(self, key, value): # naive Implementation, funktioniert so nicht
index = self.hash(key) % self.capacity
self.array[index] = value
Diese Implementation ist allerdings zu einfach. Wenn nämlich die Schlüssel aus dem Universum U beliebig gewählt werden dürfen, sind Kollisionen unvermeidlich. Tritt aber eine Kollision auf, werden die Daten eines Schlüssels mit den Daten eines anderen Schlüssels überschrieben. Um Kollisionen geschickt zu behandeln gibt es zwei Ansätze:
* lineare Verkettung
* offene Adressierung

=== Hashtabelle mit linearer Verkettung (offenes Hashing/geschlossene Adressierung) ===

Man kann dies als die pessimistische Lösung bezeichnen: Man nimmt an, dass Kollisionen häufig auftreten. Deshalb wird unter jedem
Hashindex gleich eine Liste angelegt, in der Einträge mit gleichem Hashindex aufgenommen werden können. Die Hashtabelle verwaltet ein Array von Listen, und jedes Arrayfeld kann beliebig viele Elemente speichern: Wird ein Element auf den Index <tt>i</tt> abgebildet, werden die Daten einfach an die betreffende Liste angehängt. Bei Zugriff auf ein Element wird zunächst die passende Liste gesucht (mit Hilfe des Hashwerts), danach erfolgt in dieser Liste eine sequentielle Suche nach dem richtigen Schlüssel.

Um diese Idee implementieren zu können, benötigen wir zunächst eine Hilfsklasse <tt>HashNode</tt>, die (Schlüssel, Wert)-Paare speichert und mit Hilfe von <tt>next</tt> eine verkettete Liste realisiert:
class HashNode:
def __init__(self,key,data,next):
self.key = key
self.data = data
self.next = next # Verkettung!
Die eigentliche Hashtabelle wird in der Klasse ''HashTable'' implementiert:
class HashTable:
def __init__(self):
self.capacity = ... # Geeignete Werte siehe unten
self.size = 0 # Anzahl der Werte, die zur Zeit tatsächlich gespeichert sind
self.array = [None]*self.capacity
Wie oben bereits erwähnt, werden die Zugriffsoperatoren ''[ ]'' für eine Datenstruktur in Python durch die Funktionen <tt>__setitem__</tt> bzw. <tt>__getitem__</tt> implementiert.
Die <tt>__setitem__</tt>-Funktion speichert die gegebenen Daten unter dem Schlüssel <tt>key</tt> in der <tt>HashTable</tt>-Klasse:
def __setitem__(self, key, value):
index = hash(key) % self.capacity # hash(...) ist in Python eine vordefinierte Funktion
node = self.array[index] # finde die zu 'key' gehörende Liste
while node is not None: # sequentielle Suche nach 'key' in dieser Liste
if node.key == key:
# Element 'key' ist schon in der Tabelle
# => überschreibe die Daten mit dem neuen Wert
node.data = value
return
# andernfalls: Kollision des Hashwerts, probiere nächsten 'key' aus
node = node.next
# kein Element hatte den richtigen Schlüssel.
# => es gibt diesen Schlüssel noch nicht
# füge also ein neues Element in die Hashtabelle ein
self.array[index] = HashNode(key, value, self.array[index]) # der alte Anfang der Liste wird zum
# Nachfolger des neu eingefügten ersten Elements
self.size += 1
... # eventuell muss jetzt noch die Kapazität optimiert werden
Die Funktion <tt>__getitem__</tt> gibt die unter dem Schlüssel <tt>key</tt> abgelegten Daten zurück, oder eine Fehlermeldung, falls dieser Schlüssel nicht existiert:
def __getitem__(self, key):
index = hash(key) % self.capacity
node = self.array[index] # finde die zu 'key' gehörende Liste
while node is not None: # sequentielle Suche nach 'key' in dieser Liste
if node.key == key: # gefunden!
return node.data # => Daten zurückgeben
node = node.next # nächsten Schlüssel probieren
raise KeyError(key) # Schlüssel nicht gefunden => Fehler

==== Komplexität der linearen Verkettung und Wahl der Kapazität ====

Die Komplexität wird durch zwei Operationen bestimmt: erstens das Auffinden der zu einem Schlüssel gehörenden Liste (die in O(1) erfolgt), zweitens das sequentielle Durchsuchen der Liste, die Zeit in O(L) erfordert, wobei L die mittlere Länge der Listen ist. Die Hashtabelle ist also nur schnell, wenn die Länge der Listen möglichst klein ist. Unter der Annahme des ''uniformen Hashings'', wenn also alle Indizes gleich häufig verwendet werden, ist L gleich dem '''Füllstand''' der Hashtabelle:
:::<math>\alpha = \frac{N}{M} = \frac{\text{size}}{\text{capacity}}</math> wobei N die Größe <tt>size</tt> der Hashtabelle und M die Größe <tt>capacity</tt> des Arrays ist.
Wenn die Hashwerte uniform sind, entfallen auf jede Liste im Mittel N/M Einträge (N Einträge, verteilt auf M Listen). Die Gesamtkomplexität berechnet sich nach der Sequenzregel zu
:::<math>O(1+\alpha)</math>
Für eine effiziente Suche muss demnach <math>\alpha \in O(1)</math> gewählt werden. Dies erreicht man, indem man, wie beim dynamischen Array, <tt>capacity</tt> immer wieder anpasst, falls <tt>size</tt> zu groß wird. Üblicherweise verdoppelt man <tt>capacity</tt>, sobald <tt>size == capacity</tt> erreicht wird. Analog zum dynamischen Array werden die Daten dann aus dem alten Array (<tt>self.array</tt>) in ein entsprechend vergrößertes neues Array kopiert.

In der C++ Standardbibliothek (Klasse <tt> [http://www.cplusplus.com/reference/stl/unordered_map/ std::unordered_map]</tt>, siehe auch [http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/src/shared/hashtable-aux.cc?view=markup GCC hashtable_aux.cc (Primzahlen)] und [http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/hashtable_policy.h?view=markup GCC Hash Implementation]) wird die Hashtabelle häufig so
implementiert. Dabei wird <tt>capacity</tt> immer als ''Primzahl'' gewählt, wobei sich aufeinanderfolgende Kapazitäten immer ungefähr verdoppeln. Dazu wählt man aus einer vorberechneten Liste von Primzahlen die kleinste Zahl, so dass <tT>new_capacity >= 2*capacity</tt> gilt, und beginnt z.B. mit einer Default-Kapazität von 11:
11, 23, 47, 97, 199, 409, 823, ...
Die Wahl von Primzahlen hat zur Folge, dass <tt>hash(key) % self.capacity</tt> ''alle'' Bits von h benutzt (Eigenschaft aus der Zahlentheorie). Die Kapazität wird vergrößert, wenn <tt>size == capacity</tt> erreicht wird, und die ungefähre Verdoppelung sichert, dass die amortisierte Komplexität der Einfügeoperation in O(1) ist (wie beim dynamischen Array).

=== Hashtabelle mit offener Adressierung (geschlossenes Hashing) ===
[[Image:HASHTB12.svg.png|frame|Prinzip ([http://en.wikipedia.org/wiki/Hash_table Quelle])]]

Dies kann als die optimistische Variante betrachtet werden: man nimmt an, dass Kollisionen nicht so häufig auftreten, um eine komplexe Datenstruktur wie das "Array von Listen" zu rechtfertigen. Stattdessen behandelt man Kollisionen mit einer einfachen '''Idee''': Wenn <tt>array[index]</tt> durch Kollision bereits vergeben ist, probiere einen
anderen Index aus (siehe auch [http://de.wikipedia.org/wiki/Hashtabelle#Hashing_mit_offener_Adressierung Wikipedia (de)] und
[http://en.wikipedia.org/wiki/Open_addressing Wikipedia (en)]). Dabei muss man folgendes beachten:

* Das Array enthält pro Element höchstens ein (key,value)-Paar
* Das Array muss stets mindestens ''einen'' freien Platz haben (sonst gäbe es beim Ausprobieren anderer Indizes eine Endlosschleife). Es gilt immer <tt>self.size < self.capacity</tt>. Dies war bei der vorigen Hash-Implementation mit linearer Verkettung nicht notwendig (aber im Sinne schneller Zugriffszeiten trotzdem wünschenswert).

==== Vorgehen bei Kollisionen ====

=====Sequentielles Sondieren=====

Probiere den nächsten Index: <tt>index = (index+1) % capacity</tt>

* Vorteil: einfach
* Nachteil: Clusterbildung

Clusterbildung heißt, dass sich größere zusammenhängende Bereiche bilden die belegt sind, unterbrochen von Bereichen die komplett frei sind. Beim Versuch des Einfügens eines Elements an einen Platz, der schon belegt ist, muss jetzt das ganze Cluster sequentiell durchlaufen werden, bis ein freier Platz gefunden wird. Damit entspricht die Komplexität der Suche der mittleren Länge der belegten Bereiche, was sich entsprechend in einer langsamen Suche widerspiegelt.

=====Doppeltes Hashing=====

[http://de.wikipedia.org/wiki/Doppel-Hashing Wikipedia (de)] [http://en.wikipedia.org/wiki/Double_hashing Wikipedia (en)]

Bestimme einen neuen Index (bei Kollisionen) durch eine ''2. Hashfunktion''.

Das doppelte Hashing wird typischerweise in der Praxis angewendet und liegt auch der Python Implementierung des Datentyps [http://docs.python.org/tut/node7.html#SECTION007500000000000000000 Dictionary] (Syntax <tt>{'a':1, 'b':2, 'c':3}</tt> zugrunde.

Eine effiziente Implementierung dieses Datentyps ist für die Performance der Skriptsprache Python extrem wichtig, da z.B. beim Aufruf einer Funktion der auszuführunde Code in einem Dictionary unter dem Schlüssel ''Funktionsname'' nachgeschlagen wird oder die Werte lokaler Variablen innerhalb einer Funktion ebenfalls in einem Dictionary zu finden sind.

Für die Implementierung in Python werden wieder die obigen Klassen <tt>HashNode</tt> (das Attribut <tt>next</tt> kann allerdings jetzt entfernt werden) und <tt>HashTable</tt> benötigt, es folgen die angepassten Implementationen von <tt>__setitem__</tt> und <tt>__getitem__</tt>:

def __setitem__(self, key, value):
h = hash(key)
index = h % self.capacity
# erste Schleife: teste, ob key schon vorhanden ist
while True:
if self.array[index] is None: # freies Feld gefunden => key nicht vorhanden
break
if self.array[index].key == key: # key gefunden => Daten aktualisieren
self.array[index].data = value
return
# self.array[index].key ist anderer Schlüssel oder als gelöscht markiert
# => neuen Index durch 2. Hashfunktion berechnen
index = (5*index+1+h) % self.capacity
h = h >> 5
# wenn wir hier landen, wurde key nicht gefunden
h = hash(key)
index = h % self.capacity
# zweite Schleife: neues Element einfügen
while True:
if self.array[index] is None or self.array[index].key is None:
# index ist frei (1. Bedingung) oder als gelöscht markiert (2. Bedingung)
# => hier gehört key hin
self.array[index] = HashNode(key, value)
self.size +=1
... # eventuell muss hier die Kapazität optimiert werden
return
# index ist schon belegt => neuen Index durch 2. Hashfunktion berechnen
index = (5*index+1+h) % self.capacity
h = h // 5

Wir nehmen bei dieser Implementation an, dass gelöschte Elemente dadurch markiert werden, dass <tt>self.array[index].key</tt> auf einen Schlüssel gesetzt wird, der sonst nicht vorkommen kann (z.B. <tt>None</tt>). Dann wird die if-Abfrage <tt>self.array[index].key == key</tt> niemals wahr, und es wird weitergesucht. Würde man hingegen das Element vollständig löschen, könnte die Bedingung <tt>self.array[index] is None</tt> zu früh wahr werden, so dass die Schleife vorzeitig abgebrochen und das vorhandene Element <tt>key</tt> nicht erreicht würde.

def __getitem__(self, key):
h = hash(key)
index = h % self.capacity
while True:
if self.array[index] is None: # die Suchkette bricht ab => key existiert nicht
raise KeyError(key)
if self.array[index].key == key: # key gefunden => zugehörige Daten zurückgeben
return self.array[index].data
# index enthält nicht den passenden kay => neuen Index durch 2. Hashfunktion berechnen
index = (5*index+1+h) % self.capacity
h = h // 5

Die vorgestellte Implementierung orientiert sich an Pythons interner Dictionary Implementierung, der zugehörige Quellcode (mit ausführlichem Kommentar) findet sich im File [https://github.com/python/cpython/blob/master/Objects/dictobject.c dictobject.c] der Python Implementation.

===== Beispiel für doppeltes Hashing =====

Der Übersichtlichkeit wegen wählen wir M'=25 (statt 232) und eine Kapazität von M=8.

Roher Hashwert (für das Beispiel willkürlich gewählt):
h=25
Erster Index:
i0 = h % capacity = 25 % 8 = 1
Es finde eine Kollision statt. Es wird ein zweiter Index berechnet:
i1 = (5*i0 + 1 + h) % 8 = (5*1 + 1 + 25) % 8 = 31 % 8 = 7
Der Hashwert wird aktualisiert um die höherwertigen Bits von <tt>h</tt> ins Spiel zu bringen (hier durch <tt>h >> 2</tt> anstelle von <tt>h >> 5</tt> im originalen Pythoncode). Wir stellen <tt>h</tt> als Binärzahl dar, damit der Rechtsshift besser sichtbar wird:
h = h >> 2
==> h = (11001 >> 2) = 00110 = 6
Es finde wieder eine Kollision statt, so dass ein dritter Index berechnet werden muss.
i2 = (5*i1 + 1 + h) % 8 = (5*7 + 1 + 6) % 8 = 42 % 8 = 2
Der Hashwert wird wiederum aktualisiert:
h = h >> 2
==> h = (00110 >> 2) = 00001 = 1
Es finde eine Kollision statt, und wir berechnen den vierten Index:
i3 = (5*i2 + 1 + h) % 8 = (5*2 + 1 + 1) % 8 = 12 % 8 = 4
Der Hashwert wird nochmals aktualisiert und erreicht jetzt den Wert 0 (der sich dann nicht mehr ändert):
h = h >> 2
==> h = (00110 >> 2) = 0
Es finde eine Kollision statt. Da jetzt <tt>h = 0</tt> gilt, und die Zahlen 5 (Multiplikator) und 8 (capacity) teilerfremd sind, werden ab jetzt systematisch alle Indizes von 0 bis 7 durchprobiert (in der durch die Modulo-Operation bestimmten Reihenfolge):
i4 = (5*i3 + 1 + h) % 8 = (5*4 + 1 + 0) % 8 = 21 % 8 = 5
i5 = (5*i4 + 1 + h) % 8 = (5*5 + 1 + 0) % 8 = 26 % 8 = 2
i6 = (5*i5 + 1 + h) % 8 = (5*2 + 1 + 0) % 8 = 11 & 8 = 3
i7 = (5*i6 + 1 + h) % 8 = (5*3 + 1 + 0) % 8 = 16 & 8 = 0
i8 = (5*i7 + 1 + h) % 8 = (5*0 + 1 + 0) % 8 = 1 & 8 = 1
i9 = (5*i8 + 1 + h) % 8 = (5*1 + 1 + 0) % 8 = 6 & 8 = 6
i10 = (5*i9 + 1 + h) % 8 = (5*6 + 1 + 0) % 8 = 31 & 8 = 7
i11 = (5*i10 + 1 + h) % 8 = (5*7 + 1 + 0) % 8 = 36 & 8 = 4
Allen Indizes werden also erreicht, bevor sich die Folge wiederholt. Da man <tt>capacity</tt> immer so wählt, dass mindestens ein Arrayfeld noch frei ist, wird dadurch immer ein geeigneter Platz für das einzufügende Element gefunden.

==== Komplexität der offenen Adressierung ====

* Annahme: uniformes Hashing, das heißt alle Indizes haben gleiche Wahrscheinlichkeit
* Füllstand <math>\alpha =\frac{N}{M} = \frac{\text{size}}{\text{capacity}}</math>

* '''Erfolglose Suche''' (d.h. es wird entweder ein neues Element eingefügt oder ein <tt>KeyError</tt> geworfen): Untere Schranke für die Komplexität ist <math>\Omega\left(\frac{1}{1-\alpha}\right)</math> Schritte (= Anzahl der notwendigen index-Berechnungen).
* '''Erfolgreiche Suche''' <math>\Omega\left(\frac{1}{\alpha}\ln\left(\frac{1} {1-\alpha}\right)\right)</math> Schritte.

{| border="1" cellspacing="0" cellpadding="5" align="center"
! <math>\alpha</math>
! 0.5
! 0.9
|-
| erfolglos
| 2.0
| 10
|-
| erfolgreich
| 1.4
| 2.6
|}

==== Wahl der Kapazität ====
Man sieht an der obigen Tabelle, dass die erfolglose Suche (und damit das Einfügen) sehr langsam wird, wenn der Füllstand hoch ist. In Python wird <tt>capacity</tt> deshalb so gewählt, dass <math>\alpha \leq 2/3</math>. Falls <math>\alpha</math> größer werden sollte, verdopple die Kapazität und kopiere das alte array in das neue Array (analog zum dynamischen Array)

In Python werden die Kapazitätsgrößen als Zweierpotenzen gewählt, also 4,8,16,32,...,
so dass <tt>h % self.capacity</tt> nur die unteren Bits von <tt>h</tt> benutzt. Die oberen Bits von <tt>h</tt> kommen erst ins Spiel, wenn bei der Berechnung der 2. Hashfunktion die Aktualisierung <tt>h = h >> 5</tt> erfolgt. Dies hat sich bei umfangreichen Experimenten als sehr gute Lösung erwiesen.

== Anwendungen von Hashing ==

* Hashtabelle, assoziatives Aray
* Sortieren in linearer Zeit (Übungsaufgabe 6.2)
* Suchen von Strings in Texten: Rabin-Karp-Algorithmus
* ...

=== Rabin Karp Algorithmus ===
[http://de.wikipedia.org/wiki/Rabin-Karp-Algorithmus Wikipedia (de)] [http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm Wikipedia (en)]

In Textverarbeitungsanwendungen ist eine häufig benutzte Funktion die ''Search & Replace'' Funktionalität. Die Suche sollte in O(len(text)) möglich sein, aber ein naiver Algorithmus braucht O(len(text)*len(searchstring))

==== Naive Implementierung der Textsuche ====
def search(text, s):
M, N = len(text), len(s)
for k in range(M-N):
if s==text[k:k+N]: # O(N), da N Zeichen verglichen werden müssen
return k
return -1 #nicht gefunden

==== Idee des Rabin Karp Algorithmus ====
Statt Vergleichen <tt>s==text[k:k+N]</tt>, die O(N) benötigen, weil N Vergleiche der Buchstaben durchgeführt werden müssen, vergleichen wir die Hashs von Suchstring und dem zu untersuchenden Textabschnitt: <tt>hash(s) == hash(text[k:k+N])</tt>. Dabei muss natürlich <tt>hash(s)</tt> nur einmal berechnet werden, wohingegen <tt>hash(text[k:k+N])</tt> immer wieder neu berechnet werden muss. Damit der Vergleich O(1) sein kann, ist es deswegen erforderlich, eine solche Hashfunktion zu haben, die nicht alle Zeichen (das wäre O(N) ) einlesen muss, sondern die den vorhergehenden Hashwert mit einbezieht.

Eine solche Hashfunktion heißt ''Running Hash'' und funktioniert analog zum ''Sliding Mean''.

Die Running Hash Funktion berechnet in O(1) den hash von <tt>text[k+1:k+1+N]</tt> ausgehend vom hash für <tt>text[k:k+N]</tt>.

Idee: Interpretiere den Text als Ziffern in einer base d Darstellung:

<math>h_k = \text{text}[k]\cdot d^{N-1} + \text{text}[k+1]\cdot d^{N-2} + \cdots + \text{text}[k+N-1]</math>

Für die Basis 10 (Dezimalsystem) ergibt sich also

<math>h_k = \text{text}[k]\cdot {10}^{N-1} + \text{text}[k+1]\cdot {10}^{N-2} + \cdots + \text{text}[k+N-1]</math>

Daraus folgt

<math>h_{k+1} = 10 \cdot h_k - \text {text}[k]\cdot {10}^{N} + \text {text}[k+N]</math>

Die Komplexität dieses Updates ist O(1), falls man <math>{10}^{N}</math> vorberechnet hat.

In der Realität wählt man dann d=32 und benutzt noch an einigen Stellen modulo Operationen, um die Zahlen nicht zu groß werden zu lassen (siehe die Zahl <tt>q</tt> in der folgenden Implementation).

==== Implementation ====
def searchRabinKarp(text, s):
M, N = len(text), len(s)
d = 32
q = 33554393 # q ist eine große Primzahl, aber so,
# dass d*q < 2**32 (um Überlauf bei 32-bit Integerarithmetik zu vermeiden)
dN = d**N % q # Vorberechnung des Vorfaktors für das Entfernen aus dem Hash

# Initialisierung
hs, ht = 0, 0
for k in range(N):
# ord() gibt die Zeichen-Nummer (z.B. ASCII- oder UTF-8-Code) des
# übergebenen Zeichens zurück
hs = (hs*d + ord( s[k] )) % q
ht = (ht*d + ord(text[k])) % q
# Die Variablen sind jetzt wie folgt initialisiert:
# hs = hash(s)
# ht = hash(text[0:N])

# Hauptschleife
k = 0
while k < M-N:
if hs == ht: # übereinstimmende Hashs => prüfe, dass es nicht nur
# eine Kollision ist
if s == text[k:k+N]: # O(N)-Vergleich nur nötig, wenn Hashs übereinstimmen
return k # search string an Position k gefunden
# nicht gefunden => aktualisiere Hash für den nächsten Teilabschnitt von text:
ht = (d*ht + ord(text[k+N])) % q # neues Zeichen text[k+N] in Hash einfügen
ht = (ht - dN*ord(text[k])) % q # Zeichen text[k] aus Hash entfernen.
k +=1
return -1 # search string nicht gefunden

[[Iteration versus Rekursion|Nächstes Thema]]

Effizienz

2020-05-26T11:14:16Z

Alda: /* O-Kalkül */

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 [https://en.wikipedia.org/wiki/Profiling_(computer_programming) 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 [https://www.cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.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 [https://docs.python.org/3/library/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 Integer- 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 [https://en.wikipedia.org/wiki/Cache_(computing) 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.)

Code aus kompilierten Sprachen wie C/C++ 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):
min = i
for j in range(i+1, len(a)):
if a[j] < a[min]:
min = j
a[min], a[i] = a[i], a[min] # 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) \in \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) \in \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 verwenden 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.next
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 man sehr einfach exakt beweisen: Betrachtet man jede Stelle der Binärzahlen einzeln, erkennt man, dass sich die letzte Stelle (20) in jedem Schritt ändert und man jedesmal eine Einheit dafür bezahlen muss. Die vorletzte Stelle (21) ändert sich in jedem zweiten Schritt. Man zahlt also in jedem Schritt durchschnittlich nur 1/2 Einheit. Die drittletzte Stelle (22) ändert sich in jedem vierten Schritt und verursacht somit durchschnittliche Kosten von 1/4 Einheit usw. Die durchschnittlichen Gesamtkosten pro Schritt kann man durch die unendliche Summe

<math>c = 1 + \frac{1}{2} + \frac{1}{4} + \frac{1}{8} + ...</math>

berechnen. Dies ist die bekannte Summe der geometrischen Reihe mit <math>q=\frac{1}{2}</math>

<math>c = \sum_{k=0}^{\infty} q^k = \frac{1}{1-q} = 2</math>

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 der Accounting Methode====

Um den formalen Beweis zu führen, legen wir fast, dass Kosten mit positiven Zahlen ausgedrückt werden, während Guthaben als negative Werte geschrieben werden. Wir definieren also das Guthaben nach Schritt i als Differenz zwischen Größe und Kapazität des Arrays:

<math>\Phi_i = \mathrm{size}_i - \mathrm{capacity}_i</math>

Dies kann niemals positiv sein, weil die Anzahl der Elemente des Arrays niemals die Kapazität überschreitet, und entspricht der negierten Anzahl der freien Speicherzellen. Wir zahlen also Guthaben ein, wenn wir mehr Speicher allokieren als zur Zeit benötigt wird, und verbrauchen es, wenn wir neue Elemente in die freien Speicherzellen einfügen.

Bei jeder Einfügung erhöht sich die Arraygröße um ein Element:

<math>\mathrm{size}_i = \mathrm{size}_{i-1}+1</math>

Die amortisierten Kosten der Einfügeoperation <math>\hat c_i</math> setzen sich zusammen aus den tatsächlichen Kosten <math>c_i</math> der Operation (der Einfügung des neuen Elements und eventuell dem Umkopieren der vorhandenen Elemente) sowie der Änderung des Guthabens:

<math>\hat c_i = c_i + \Phi_i - \Phi_{i-1}</math>

Durch Änderung des Guthabens können die Kosten der Einfügeoperation kompensiert werden. Wir unterscheiden zwei Fälle:

Fall 1: Array ist nicht voll 
Es ist kein Umkopieren nötig, da noch Kapazität frei ist. Daher gilt

<math>\mathrm{capacity}_i = \mathrm{capacity}_{i-1}</math>

Die Einfügung kostet nur eine Einheit für das Kopieren des neuen Elements

<math>c_i=1</math>

Einsetzen in die Formel für die amortisierten Kosten liefert:

<math>\hat c_i = 1 + (\mathrm{size}_{i-1} + 1 - \mathrm{capacity}_{i-1}) - (\mathrm{size}_{i-1} - \mathrm{capacity}_{i-1}) = 2</math>

Die amortisierten Kosten betragen somit zwei Einheiten.

Fall 2: Array ist voll 
Das heißt, vor dem Einfügen gilt

<math>\mathrm{size}_{i-1} = \mathrm{capacity}_{i-1}</math>

Jetzt muss der Speicher zunächst verdoppelt und die vorhandenen Elemente umkopiert werden. Die Kapazität ändert sich somit nach

<math>\mathrm{capacity}_i = 2\cdot\mathrm{capacity}_{i-1}</math>

Zu den Kosten für das Kopieren des neuen Elements kommen jetzt die Kosten für das Umkopieren der vorhandenen Elemente (wir nehmen an, dass das Kopieren jedes einzelnen Elements stets eine Einheit kostet):

<math>c_i=1 + \mathrm{size}_{i-1}</math>

Einsetzen in die Formel für die amortisierten Kosten liefert jetzt:

<math>\hat c_i = (1 + \mathrm{size}_{i-1}) + (\mathrm{size}_{i-1} + 1 - 2\cdot\mathrm{capacity}_{i-1}) - (\mathrm{size}_{i-1} - \mathrm{capacity}_{i-1}) = 2 + \mathrm{size}_{i-1} - \mathrm{capacity}_{i-1}</math>

Wegen <math>\mathrm{size}_{i-1} = \mathrm{capacity}_{i-1}</math> (das Array war vor der Einfügung voll) vereinfacht sich dies aber zu

<math>\hat c_i = 2</math>

Auch in diesem Fall betragen die amortisierten Kosten zwei Einheiten.

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine konstante amortisierte Komplexität 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 = 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>0</center>
| <center>1</center>
| <center>2</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>0</center>
| <center>0</center>
| <center>2</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>-1</center>
| <center>-1</center>
| <center>2</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>0</center>
| <center>1</center>
| <center>2</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>-3</center>
| <center>-3</center>
| <center>2</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>-2</center>
| <center>1</center>
| <center>2</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>-1</center>
| <center>1</center>
| <center>2</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>0</center>
| <center>1</center>
| <center>2</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>-7</center>
| <center>-7</center>
| <center>2</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 amortisierten Kosten, die mit Hilfe des Guthabens berechnet werden, sind hingegen konstant 2, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

[[Suchen|Nächstes Thema]]

Container

2020-04-28T10:56:16Z

Alda: /* Required Interfaces */

==Abstrakte Datentypen==

Bei einem abstrakten Datentyp wird die Datenstruktur definiert, indem man die Menge der erlaubten Operationen und deren Bedeutung in abstrakter Form (d.h. unabhängig von einer bestimmten Implementation) angibt. Dazu verwendet man im allgemeinen die ''algebraische Spezifikation'', die zunächst die Operationen auflistet und danach deren Eigenschaften in Form von ''Axiomen'' beschreibt, die nach der Ausführung einer Operation jeweils gelten müssen.

Wir unterscheiden folgende Arten von Operationen:
# Observer: geben Informationen über den Zustand eines Objekts
# Modifier: beim funktionalen Programmierstil: erzeugen ein neues, verändertes Objekt beim prozeduralen und objekt-orientierten Programmierstil: verändern ein vorhandenes Objekt
# Konstruktoren: erzeugen ein neues Objekt (bei funktionaler Programmierung sind Konstruktoren nur ein Spezialfall der Modifier).
Wird ein Objekt '''a''' modifiziert, ist sein alter Wert in der Spezifikation unter dem formalen Namen '''aold''' zugreifbar. Dies ermöglicht es, in den Axiomen den alten mit dem neuen Zustand zu vergleichen.

Im folgenden beschreiben wir die algebraische Spezifikation am Beispiel der ''Container-Datenstrukturen''. Container dienen, wie in der Schifffahrt, zum Aufbewahren anderer Datenobjekte und sind damit grundlegend für die Programmierung, siehe auch [http://de.wikipedia.org/wiki/Datenstruktur Datenstrukturen] in der Wikipedia.

==Array==

In einem Array erhalten alle Elemente einen ''Index'', d.h. eine nicht-negative laufende Nummer, die bei Null ("zero-based indexing", z.B. C++, Python) oder bei Eins ("one-based indexing", z.B. Fortran, Matlab) startet. Auf die Elemente des Arrays wird zugegriffen, indem man den jeweiligen Index angibt. Wir definieren das Array hier mit zero-based indexing.

Seien a ∈ Array, i ∈ <math>\mathbb{N}_0</math> (ein nicht-negativer Index) und v ∈ Object (ein beliebiges Objekt).

====Operationen:====

{| border="1" cellspacing="0" cellpadding="7"
|-valign="top"
| erzeuge ein neues Array:
| <tt>new_array(size ∈ <math>\mathbb{N}_0</math>, initial ∈ Object) → Array</tt>
|-
|erfrage die Anzahl der Arrayelemente:
|<tt>len(a) → <math>\mathbb{N}_0</math></tt>
|-
|erfrage das Element beim Index i:
|<tt>get(a, i) → Object</tt>
|-
|setze das Objekt beim Index i:
|<tt>set(a, i, v) → Array</tt>
|}
 

====Axiome:====
{| border="1" cellspacing="0" cellpadding="7"
|-valign="top"
| Ein neues Array enthält so viele Elemente, wie in <tt>size</tt> angegeben waren. Alle Elemente haben den gegebenen Initialwert <tt>initial</tt>.
| <tt>a = new_array(size, initial) assert(len(a) == size)</tt> für alle <tt>i ∈ 0, ..., size-1</tt> gilt:    <tt>assert(get(a, i) == initial)</tt>
|-valign="top"
|Nach der Zuweisung von v beim Index i gilt: (i) die Größe bleibt unverändert, (ii) Index i enthält das Element v, (iii) die übrigen Elemente haben sich nicht verändert.
|<tt>a = set(a, i, v) assert(len(a) == len(aold)) assert(get(a, i) == v)</tt> für alle <tt>k ≠ i</tt> gilt:    <tt>assert(get(a, k) == get(aold, k))</tt>
|}
 

====in Python:====
Der Array-Typ heißt <tt>list</tt> (aus historischen Gründen, das hat nichts mit verketteten Listen zu tun):
* <tt>get</tt> und <tt>set</tt> heißen <tt>__getitem__</tt> bzw. <tt>__setitem__</tt>
* rufe Funktionen mit Punktsyntax auf: statt <tt>get(a, i)</tt> schreibe <tt>a.__getitem__(i)</tt>
* Indexschreibweise: <tt>v = a[i]</tt> ist äquivalent zu <tt>v = a.__getitem__(i)</tt> <tt>a[i] = v</tt> ist äquivalent zu <tt>a.__setitem__(i, v)</tt>
* Konstruktoren: <tt>a = list()</tt> ist äquivalent zu <tt>a = []</tt> und entspricht <tt>a = new_array(0, 0)</tt> (erzeugt ein leeres Array) <tt>a = [initial]*size</tt> entspricht <tt>a = new_array(size, initial)</tt> (erzeugt ein Array der gewünschten Größe mit Initialwert) 
<tt>a = [1, 3, 2, 0, 5]</tt> initialisiert ein Array mit den gegebenen Elementen.
 

==Stack==

Ein Stack verhält sich wie ein Stapel (z.B. von Büchern oder Bierkästen) in der realen Welt: nur das jeweils oberste Element ist einfach zugänglich (Funktion <tt>top</tt>), die darunterliegenden sind blockiert. Ein neues Element wird immer oben auf den Stapel gelegt (Funktion <tt>push</tt>), und das ''zuletzt'' eingefügte Element wird als ''erstes'' wieder entfernt (Funktion <tt>pop</tt>). Dies bezeichnet man als "last in - first out"-Verhalten (LIFO).

Seien s ∈ Stack und v ∈ Object (ein beliebiges Objekt).

====Operationen:====

{| border="1" cellspacing="0" cellpadding="7"
|-valign="top"
| erzeuge einen leeren Stack:
| <tt>new_stack() → Stack</tt>
|-
|erfrage die Anzahl der Stackelemente:
|<tt>len(s) → <math>\mathbb{N}_0</math></tt>
|-
|hänge ein neues Element am Ende an:
|<tt>push(s, v) → Stack</tt>
|-
|erfrage das letzte Element:
|<tt>top(s) → Object</tt>
|-
|entferne das letzte Element:
|<tt>pop(s) → Stack</tt>
|}
 

====Axiome:====
{| border="1" cellspacing="0" cellpadding="7"
|-valign="top"
| Ein neuer Stack ist leer.
| <tt>s = new_stack() assert(len(s) == 0)</tt>
|-valign="top"
| Nach einem <tt>push</tt> gilt: (i) die Größe hat sich um eins erhöht, (ii) das gerade eingefügte Element ist jetzt das letzte.
|<tt>s = push(s, v) assert(len(s) == len(sold)+1) assert(top(s) == v)</tt>
|-valign="top"
| <tt>push</tt> gefolgt von <tt>pop</tt> reproduziert den Stack vor dem <tt>push</tt>.
|<tt>s = pop(push(s, v)) assert(s == sold)</tt>
|}
 

====in Python:====
Der Typ <tt>list</tt> ist gleichzeitig ein Stack:
* <tt>push(s, v)</tt> heißt <tt>s.append(v)</tt>
* <tt>pop(s)</tt> heißt <tt>s.pop()</tt>
* <tt>top(s)</tt> heißt <tt>s[-1]</tt> (Python unterstützt negative Indizes <tt>i</tt> und interpretiert sie als <tt>s[len(s)-abs(i)]</tt>, hier also <tt>s[len(s)-1]</tt>)
 

==Queue==

Ein Queue realisiert das Verhalten einer Warteschlange (wie z.B. im Supermarkt): das aktuell vorderste Element ist einfach zugänglich (Funktion <tt>first</tt>), die dahinterliegenden sind blockiert. Ein neues Element wird immer am Ende der Queue angefügt (Funktion <tt>push</tt>), und das ''zuerst'' eingefügte Element wird als ''erstes'' wieder entfernt (Funktion <tt>popFirst</tt>). Dies bezeichnet man als "first in - first out"-Verhalten (FIFO).

Seien q ∈ Queue und v ∈ Object (ein beliebiges Objekt).

====Operationen:====

{| border="1" cellspacing="0" cellpadding="7"
|-valign="top"
| erzeuge eine leere Queue:
| <tt>new_queue() → Queue</tt>
|-
|erfrage die Anzahl der Queueelemente:
|<tt>len(q) → <math>\mathbb{N}_0</math></tt>
|-
|hänge ein neues Element am Ende an:
|<tt>push(q, v) → Queue</tt>
|-
|erfrage das erste Element:
|<tt>first(q) → Object</tt>
|-
|entferne das erste Element:
|<tt>pop(q) → Queue</tt>
|}
 

====Axiome:====
Um die Axiome der Queue zu formulieren, brauchen wir zusätzlich die Zugriffsfunktion <tt>get</tt> des Arrays. Die Queue muss diese Funktion aber nur zum Testen und Debuggen unterstützen, beim Normalbetrieb ist sie nicht notwendig.

{| border="1" cellspacing="0" cellpadding="7"
|-valign="top"
| Eine neue Queue ist leer.
| <tt>q = new_queue() assert(len(q) == 0)</tt>
|-valign="top"
| Nach einem <tt>push</tt> gilt: (i) die Größe hat sich um eins erhöht, (ii) das gerade eingefügte Element ist jetzt das letzte, (iii) die übrigen Elemente haben sich nicht verändert.
|<tt>q = push(q, v) assert(len(q) == len(qold)+1) assert(get(q, len(q)-1) == v)</tt> für alle <tt>k ∈ 0, ..., len(q)-2</tt> gilt:    <tt>assert(get(q, k) == get(qold, k))</tt>
|-valign="top"
| Wenn die Queue nicht leer ist, hat das erste Element den Index 0.
| <tt>assert(len(q) > 0) assert(first(q) == get(q, 0))</tt>
|-valign="top"
| Nach einem <tt>popFirst</tt> gilt: (i) die Größe hat sich um eins verringert, (ii) alle Elemente ab dem zweiten rücken einen Index nach vorn.
|<tt>q = popFirst(q) assert(len(q) == len(qold)-1)</tt> für alle <tt>k ∈ 0, ..., len(q)-1</tt> gilt:    <tt>assert(get(q, k) == get(qold, k+1))</tt>
|}
 

====in Python:====
Der Typ <tt>list</tt> ist gleichzeitig eine Queue:
* <tt>push(q, v)</tt> heißt <tt>q.append(v)</tt>
* <tt>popFirst(q)</tt> heißt <tt>q.pop(0)</tt> oder <tt>del q[0]</tt> (Mit beiden Funktionen kann man allgemein das Element bei einem beliebigen Index entfernen.)
* <tt>first(q)</tt> heißt <tt>q[0]</tt>
Allerdings ist es nicht sehr effizient, das erste Element aus einem <tt>list</tt>-Objekt zu entfernen. Eine effizientere Implementation der Queue-Funktionalität bietet der Type <tt>deque</tt> aus dem Modul <tt>collections</tt>, der sowohl für das Queue-Verhalten (FIFO) als auch das Stack-Verhalten (LIFO) effizient ist (deque ist die Abkürzung für "double-ended queue").
 

==Assoziatives Array==

Ein assoziatives Array erweitert die Array-Funktionalität, indem es statt der Indizes beliebige Schlüssel unterstützt, unter denen die Elemente abgerufen werden. Typische Schlüssel sind z.B. Zahlen, die keine laufende Nummer bilden (z.B. Matrikelnummern), Strings (z.B. Namen). Auf die Elemente des assoziativen Arrays wird zugegriffen, indem man den jeweiligen Schlüsselwert angibt. Assoziative Array werden häufig auch als ''dictionaries'' bezeichnet.

Seien d ∈ Dictionary, i ∈ Object (ein Schlüsselobjekt), v ∈ Object (ein beliebiges Objekt) und error ∈ Error (ein Objekt, das einen Fehler signalisiert).

====Operationen:====

{| border="1" cellspacing="0" cellpadding="7"
|-valign="top"
| erzeuge ein neues Dictionary:
| <tt>new_dictionary() → Dictionary</tt>
|-
|erfrage die Anzahl der Elemente:
|<tt>len(d) → <math>\mathbb{N}_0</math></tt>
|-
|erfrage die zur Zeit gültigen Schlüssel:
|<tt>keys(d) → Array</tt>
|-
|teste, ob der angegebene Schlüssel gültig ist:
|<tt>has_key(d, i) → Boolean</tt>
|-
|erfrage das Element zum Schlüssel i:
|<tt>get(d, i) → Object</tt>
|-
|setze das Objekt zum Schlüssel i:
|<tt>set(d, i, v) → Dictionary</tt>
|-
|lösche den Schlüssel i und das zugehörige Objekt:
|<tt>del_key(d, i) → Dictionary</tt>
|}
 

====Axiome:====
{| border="1" cellspacing="0" cellpadding="7"
|-valign="top"
| Ein neues Dictionary ist leer, ebenso die Liste seiner Schlüssel.
| <tt>d = new_dictionary() assert(len(d) == 0) assert(len(keys(d)) == 0)</tt>
|-valign="top"
| Es gilt stets: alle Elemente im Array <tt>keys</tt> sind tatsächlich Schlüssel.
| <tt>k = keys(d)</tt> für alle <tt>j ∈ k</tt> gilt:    <tt>assert(has_key(d, j))</tt>
|-valign="top"
|Wenn i kein Schlüssel ist, gilt: (i) <tt>has_key</tt> liefert <tt>false</tt>, (ii) Zugriffe mit <tt>get</tt> und <tt>del_key</tt> signalisieren einen Fehler.
|<tt>assert(not has_key(d, i)) assert(get(d, i) == error) assert(del_key(d, i) == error)</tt>
|-valign="top"
|Wenn i kein Schlüssel ist, gilt nach der Zuweisung von v an den Schlüssel i: (i) die Größe erhöht sich um eins, (ii) i ist jetzt Schlüssel und enthält das Element v, (iii) die übrigen Schlüssel und Elemente haben sich nicht verändert.
|<tt>assert(not has_key(d, i)) d = set(d, i, v) assert(len(d) == len(dold)+1) assert(has_key(d, i)) assert(get(d, i) == v)</tt> für alle <tt>j ∈ keys(dold)</tt> gilt:    <tt>assert(get(d, j) == get(dold, j))</tt>
|-valign="top"
|Wenn i bereits Schlüssel ist, gilt nach der Zuweisung von v an den Schlüssel i: (i) die Größe bleibt unverändert, (ii) Schlüssel i enthält das Element v, (iii) die übrigen Schlüssel und Elemente haben sich nicht verändert.
|<tt>assert(has_key(d, i)) d = set(d, i, v) assert(len(d) == len(dold)) assert(get(d, i) == v) assert(keys(d) == keys(dold))</tt> für alle <tt>j ∈ keys(d), j ≠ i</tt> gilt:    <tt>assert(get(d, j) == get(dold, j))</tt>
|-valign="top"
|Wenn i ein Schlüssel ist, gilt nach dem Löschen von i: (i) die Größe verringert sich um eins, (ii) der Schlüssel ist nicht mehr vorhanden, (iii) die übrigen Schlüssel und Elemente bleiben unverändert.
|<tt>assert(has_key(d, i) d = del_key(d, i) assert(len(d) == len(dold)-1) assert(not has_key(d, i))</tt> für alle <tt>j ∈ keys(d)</tt> gilt:    <tt>assert(get(d, j) == get(dold, j))</tt>
|}
 

====in Python:====
Der Dictionary-Typ heißt <tt>dict</tt>:
* rufe Funktionen mit Punktsyntax auf: statt <tt>has_key(d, i)</tt> schreibe <tt>d.has_key(i)</tt> etc.
* <tt>get</tt> und <tt>set</tt> heißen <tt>__getitem__</tt> bzw. <tt>__setitem__</tt>
* <tt>get</tt> ist ebenfalls implementiert, aber es signalisiert keinen Fehler, wenn der Schlüssel unbekannt ist, sondern gibt ein Defaultobjekt zurück (siehe Dokumentation für Einzelheiten)
* <tt>del_key(d, i)</tt> heißt <tt>d.pop(i)</tt> oder <tt>del d[i]</tt>
* <tt>d.keys()</tt> liefert ab Python 3 kein Array, sondern ein ''iterable'', siehe Dokumentation
* Indexschreibweise: <tt>v = d[i]</tt> ist äquivalent zu <tt>v = d.__getitem__(i)</tt> <tt>d[i] = v</tt> ist äquivalent zu <tt>d.__setitem__(i, v)</tt>
* Konstruktoren: <tt>d = dict()</tt> ist äquivalent zu <tt>d = {}</tt> und entspricht <tt>d = new_dictionary()</tt>: erzeugt ein leeres Dictionary <tt>d = {'eins': 1, 'zwei': 2, 'drei': 3}</tt> initialisiert ein Dictionary mit den angegebenen Schlüssel/Wert-Paaren (die Schlüssel sind hier Strings, die Werte Zahlen).
 

==Required Interfaces==

Eine andere Möglichkeit, die Anforderungen an Container-Datenstrukturen zu definieren, ist das ''required interface''. Dabei nimmt man den Standpunkt eines Algorithmus ein, der diese Datenstrukturen benutzen will, und fragt: Welche Operationen hätte man denn gerne bei einem Container? Wie sollten die Daten organisiert sein, damit der Algorithmus effizient damit arbeiten können?

Eine solche Anforderungsanalyse ist sehr aufwändig und kann sich über Jahre erstrecken, weil Erfahrungen gesammelt werden müssen, welche Anforderungen in vielen Algorithmen immer wieder auftreten. Wir listen im folgenden nur das Resultat, also die wichtigsten Operationen von Container-Datenstrukturen auf. Wenig überraschend kommen am Ende gerade die Datenstrukturen heraus, die wir oben bereits behandelt haben.

Sei <tt>c</tt> eine Container-Datenstruktur und <tt>v</tt> ein darin gespeicherter Wert:

 
===Lesender Zugriff===

{| border="1" cellspacing="0" cellpadding="7"
|-valign="top"
|'''0.'''
| <tt>c.size()</tt>
|gibt die Anzahl der Elemente im Container an
|-
|'''1a.'''
|<tt>v = c.get(i)</tt>
|das i-te Element im Container lesen
|-
|'''1b.'''
|<tt>v = c.get(pos)</tt>
|das Element an Position <tt>pos</tt> lesen (<tt>pos</tt> ist ein geeignetes Hilfsobjekt, das in Abhängigkeit von der Art der Datenstruktur eine Position im Container referenziert. Im Falle 1a. <tt>v = c.get(i)</tt> ist <tt>pos</tt> eine natürliche Zahl, aber es gibt auch andere Möglichkeiten, die Position zu kodieren.)
|-
|'''1c.'''
|<tt>v = c.get(key)</tt>
|das Element mit dem Schlüssel <tt>key</tt> lesen (Beachte den Unterschied zu 1b: In 1b markiert <tt>pos</tt> eine Position im Container, hier in 1c bezieht sich <tt>key</tt> auf eine Eigenschaft der Datenelemente, die von der Position im Container unabhängig ist.)
|-
|'''2a.'''
|<tt>v = c.first()</tt>
|erstes Element lesen (äquivalent zu <tt>v = c.get(0)</tt>)
|-
|'''2b.'''
|<tt>v = c.last()</tt>
|letztes Element lesen (äquivalent zu <tt>v = c.get(c.size()-1)</tt>)
|-
|'''3a.'''
|<tt>v = c.smallest()</tt>
|das kleinste Element lesen (dies bezieht sich auf eine Eigenschaft der Datenelemente bzw. Schlüssel, im Unterschied zu 2a, wo es um die Position im Container geht.)
|-
|'''3b.'''
|<tt>v = c.largest()</tt>
|das größte Element lesen (dies bezieht sich auf eine Eigenschaft der Datenelemente bzw. Schlüssel, im Unterschied zu 2b, wo es um die Position im Container geht.)
|}

 
===Schreibender Zugriff===

{| border="1" cellspacing="0" cellpadding="7"
|-valign="top"
|'''4a.'''
|<tt>v.set(i, v)</tt>
|i-tes Element überschreiben (<tt>c.size()</tt> bleibt unverändert)
|-
|'''4b.'''
|<tt>v.set(pos, v)</tt>
|Element an der Stelle <tt>pos</tt> überschreiben (<tt>c.size()</tt> bleibt unverändert. Zur Bedeutung von <tt>pos</tt> siehe 1b.)
|-
|'''4c.'''
|<tt>v.set(key, v)</tt>
|Element mit dem Schlüssel <tt>key</tt> überschreiben (<tt>c.size()</tt> bleibt unverändert)
|-
|'''5a.'''
|<tt>c.insert(i, v)</tt>
|Objekt als i-tes in den Container einfügen (Werte ab <tt>i</tt> werden eine Position nach hinten verschoben, <tt>c.size()</tt> erhöht sich um 1)
|-
|'''5b.'''
|<tt>c.insert(pos, v)</tt>
|Objekt an Position <tt>pos</tt> in den Container einfügen (Werte ab <tt>pos</tt> werden eine Position nach hinten verschoben, <tt>c.size()</tt> erhöht sich um 1)
|-
|'''5c.'''
|<tt>c.insert(key, v)</tt>
|Objekt unter dem Schlüssel <tt>key</tt> in den Container einfügen (Wenn der Schlüssel schon vergeben war, wird ein Fehler signalisiert. <tt>c.size()</tt> erhöht sich um 1).
|-
|'''5d.'''
|<tt>c.insert(v)</tt>
|Objekt an beliebiger Stelle in den Container einfügen (Der Container bestimmt die optimale Position selbst. <tt>c.size()</tt> erhöht sich um 1).
|-
|'''6a.'''
|<tt>c.prepend(v)</tt>
|Objekt am Anfang einfügen (äquivalent zu <tt>c.insert(0, v)</tt>, <tt>c.size()</tt> erhöht sich um 1)
|-
|'''6b.'''
|<tt>c.append(v)</tt>
|Objekt am Ende anhängen (äquivalent zu <tt>c.insert(c.size(), v)</tt>, <tt>c.size()</tt> erhöht sich um 1)
|-
|'''7a.'''
|<tt>c.remove(i)</tt>
|i-tes Element aus dem Container löschen (Werte ab <tt>i</tt> werden eine Position nach vorn verschoben, <tt>c.size()</tt> verringert sich um 1)
|-
|'''7b.'''
|<tt>c.remove(pos)</tt>
|Objekt an Position <tt>pos</tt> aus dem Container löschen (Werte ab <tt>pos</tt> werden eine Position nach vorn verschoben, <tt>c.size()</tt> verringert sich um 1)
|-
|'''7c.'''
|<tt>c.remove(key)</tt>
|Objekt unter dem Schlüssel <tt>key</tt> aus dem Container löschen (Wenn der Schlüssel nicht vergeben war, wird ein Fehler signalisiert. <tt>c.size()</tt> verringert sich um 1, wenn es kein Fehler signalisiert hat.)
|-
|'''8a.'''
|<tt>c.removeFirst()</tt>
|das erste Element aus dem Container entfernen (äquivalent zu <tt>c.remove(0)</tt>, <tt>c.size()</tt> verringert sich um 1)
|-
|'''8b.'''
|<tt>c.removeLast()</tt>
|das letzte Element aus dem Container entfernen (äquivalent zu <tt>c.remove(c.size()-1)</tt>, <tt>c.size()</tt> verringert sich um 1)
|-
|'''9a.'''
|<tt>c.removeSmallest()</tt>
|das kleinste Element aus dem Container entfernen (dies bezieht sich auf eine Eigenschaft der Datenelemente bzw. Schlüssel, im Unterschied zu 8a, wo es um die Position im Container geht. <tt>c.size()</tt> verringert sich um 1)
|-
|'''9b.'''
|<tt>c.removeLargest()</tt>
|das größte Element aus dem Container entfernen (dies bezieht sich auf eine Eigenschaft der Datenelemente bzw. Schlüssel, im Unterschied zu 8b, wo es um die Position im Container geht. <tt>c.size()</tt> verringert sich um 1)
|}
 

==Facts==

*Jede dieser Operationen kann sehr effizient implementiert werden.
*Keine Datenstruktur ist bekannt, die '''alle''' diese Operationen effizient implementiert.

==Beispiele==

Je nachdem welche Operation effizient sein soll, wird eine andere Container Datenstruktur ausgewählt. Die Operation <tt>c.size()</tt> wird von allen Containern effizient unterstützt.

===Arrays===
;'''(statisches) Array''' [http://en.wikipedia.org/wiki/Array]: Das Array ist die einfachste Datenstruktur, es kann einfach als aufeinanderfolgender Bereich von Speicherzellen implementiert werden. Jede dieser Speicherzellen nimmt ein Objekt als Datenelement auf. Die Größe ist nicht veränderbar (daher der Name ''statisch''). Das statische Array unterstützt die Operationen
1a. c.get(i)
4a. c.set(i, value)
;'''Dynamisches Array''' [http://en.wikipedia.org/wiki/Dynamic_array]: Die Größe ist veränderbar, aber nur durch Anfügen oder Entfernen eines Elements am ''Ende'' des Arrays. Die unterstützen Operationen sind dieselben wie die des statischen Arrays, zusätzlich unterstützt das dynamische Array die Operationen
6b. c.append(v)
8b. c.removeLast()
Wir beschreiben im Abschnitt [[Effizienz#dynamisches_Array|Amortisierte Komplexität]], wie man dies effizient implementieren kann. Das Anfügen neuer Elemente am Ende ist eine sehr häufige Operation, so dass das dynamische Array eine der beliebtesten Datenstrukturen ist. In Python hat das dynamische Array den Typ <tt>list</tt>, was in diesem Fall nichts mit verketten Listen zu tun hat, sondern eher auf Listen im Sinne von Tabellen hinweist (die Namenswahl ist dennoch etwas unglücklich und kann zu Verwechslungen führen).
;'''assoziatives Array (Dictionary)''' [http://en.wikipedia.org/wiki/Associative_array]: Ein Dictionary verallgemeinert das dynamische Array: Während Arrays auf ihre Elemente über Indizes (= natürliche Zahlen) zugreifen, können die Schlüssel (Keys) bei einem Dictionary einen beliebigen Typ haben. Jedes Element des Dictionary besteht aus einem Schlüssel-Wert-Paar, jeder Schlüssel bekommt somit einen Wert zugewiesen. Das Dictionary unterstützt die Operationen
1c. c.get(key)
4c. c.set(key, value)
5c. c.insert(key, value)
7c. c.remove(key)
Wenn als Schlüssel natürliche Zahlen 0, 1, ..., N gewählt werden, sind dies im wesentlichen dieselben Operationen wie beim Array. Man wird das Dictionary also vor allem dann einsetzen, wenn die Schlüssel einen anderen Typ haben, oder wenn die Zahlen nicht aus dem zusammenhängenden Intervall 0, ..., N kommen. Das Python-Dictionary hat den Typ <tt>dict</tt>. Wir behandeln diese Datenstruktur in den Kapiteln [[Assoziative Arrays]] und [[Hashing und Hashtabellen]].

===verkettete Listen===
;'''(einfach) verkettete Liste''' [http://en.wikipedia.org/wiki/Linked_list#Singly-linked_list]: Im Gegensatz zum Array müssen die Speicherzellen nicht nacheinenander im Speicher abgelegt sein. Statt dessen enthält jedes Element der Liste ein Feld <tt>next</tt>, das auf das nächste Element der Liste verweist. Um das i-te Element zu finden, muss man die Liste von vorn nach hinten durchlaufen. Deshalb ist die Operation <tt>c.get(i)</tt> für verkettete Listen nicht effizient. Wenn man allerdings auf ein Element zugegriffen hat, kann man ein <tt>pos</tt>-Objekt (in diesem Fall eine Referenz auf das Element) speichern, so dass ein erneuter Zugriff auf das selbe Element schnell geht. Das gleiche gilt für das folgende Element, weil man nur einmal <tt>pos = pos.next</tt> aufrufen muss. Nur wenig komplizierter (und dadurch ebenfalls effizient) ist das Einfügen eines neuen Elements an der Position <tt>pos</tt>. Die verkette Liste unterstützt somit die Operationen:
1b. c.get(pos)
2a. c.first()
4b. c.set(pos, value)
5b. c.insert(pos, value)
6a. c.prepend(value)
7b. c.remove(pos)
8a. c.removeFirst(pos)
Es scheint, dass die Liste eine sehr flexible Datenstruktur ist. Allerdings ist es ein gravierender Nachteil, dass <tt>pos</tt> nur auf das jeweils nächste Element weitergesetzt werden kann. Im Gegensatz dazu können Indizes in einem Array effizient auf beliebige Positionen gesetzt werden. Man bevorzugt deshalb heute dynamische Arrays.
;'''Doppelt verkettete Liste''' [http://en.wikipedia.org/wiki/Linked_list#Doubly-linked_list]: Im Gegensatz zur einfach verketteten Liste enthält jedes Element nicht nur einen Zeiger auf das darauffolgende, sondern auch auf das vorherige Element in der Liste. Dadurch kann ein <tt>pos</tt>-Objekt auch effizient um ein Element zurückgesetzt werden: <tt>pos = pos.previous</tt>. Die doppelt verkette Liste unterstützt deshalb die selben Operationen wie die einfach verkettete, und zusätzlich
2b. c.last()
6b. c.append(value)
8b. c.removeLast()

===Queues===
;'''Stack (Stapelspeicher)''' [http://en.wikipedia.org/wiki/Stack_(data_structure)]: Speichert/Stapelt die Objekte mit push in einen Speicher. Wiederrum mit pop kann das oberste (=zuletzt eingefügte) Element herausgeholt werden: LIFO (Last In First Out) Die Python-Datenstruktur <tt>List</tt> eignet sich beispielsweise als Stack. Operationen:
2b. c.last() # auf das oberste Element zugreifen, ohne es zu entfernen
6b. c.append(value) # Element auf den Stapel legen (beim Stack meist c.push(value) genannt)
8b. c.removeLast() # oberstes Element entfernen (beim Stack meist c.pop() genannt)
;'''Queue (Schlange)''' [http://en.wikipedia.org/wiki/Queue_(data_structure)]: Eine Queue ist wie eine Warteschlange an der Kasse im Supermarkt, bedient wird derjenige der als erster an die Kasse kommt: FIFO (First In First Out) Operationen:
2a. c.first()
6b. c.append(value)
8a. c.removeFirst()
;'''Deque (Double Ended Queue)''' [http://en.wikipedia.org/wiki/Deque]: wie Stack + Queue, d.h. Objekte können am Ende eingefügt, aber sowohl vorn als auch hinten gelesen und entfernt werden. Operationen
2a. c.first()
2b. c.last()
6b. c.append(value)
8a. c.removeFirst()
8b. c.removeLast()
Die Deque ist Thema in [[Media:Übung-3.pdf|Übungsblatt 3]].

===Prioritätswarteschlangen===
;'''MinPriorityQueue''' [http://en.wikipedia.org/wiki/Priority_queue]: Warteschlange, die das Element mit der kleinsten Priorität zuerst zurückgibt (z.B. an der Kasse im Supermarkt diejenige/derjenige, die/der die wenigsten Produkte kaufen möchte) Mögliche Operationen:
3a. c.smallest()
5d. c.insert(value)
9a. c.removeSmallest()
;'''MaxPriorityQueue''' [http://en.wikipedia.org/wiki/Priority_queue]: Warteschlange, die das Element mit der größten Priorität zuerst zurückgibt Unterstützte Operationen sind:
3b. c.largest()
5d. c.insert(value)
9b. c.removeLargest()
;'''MinMaxPriorityQueue''' [http://en.wikipedia.org/wiki/Priority_queue]: kombiniert MinPriorityQueue + MaxPriorityQueue

Die drei letzten Datenstrukturen behandeln wir im Kapitel [[Prioritätswarteschlangen]].

==Container in Python==

Wir hatten die Python-Datenstrukturen <tt>list</tt>, <tt>dict</tt> und <tt>collections.deque</tt> bereits weiter oben diskutiert. Es fehlen noch die Prioritätswarteschlangen, für die Python das Modul <tt>heapq</tt> anbietet. Es implementiert allerdings keine eigene Datenstruktur, sondern stellt Funktionen zur Verfügung, die die notwendigen Operationen auf der Basis eines normalen Arrays von Typ <tt>list</tt> realisieren, siehe Dokumentation für Einzelheiten.

[[Sortieren|Nächstes Thema]]

Einführung

2020-04-28T10:49:05Z

Alda: /* Beispiele für Datenformate */

== Definition von Algorithmen ==

Es gibt viele Definitionen von Algorithmen. Hier sind die Ergebnisse einer Google-Suche auf [http://www.google.de/search?hl=de&defl=en&q=define:Algorithm&sa=X&oi=glossary_definition&ct=title englisch] und auf
[http://www.google.de/search?hl=de&defl=de&q=define:Algorithmus&sa=X&oi=glossary_definition&ct=title deutsch]. Die Grundidee ist aber immer gleich:

Ein '''Algorithmus''' ist eine Problemlösung durch endlich viele elementare Schritte. Die Teile der Definition bedürfen näherer Erläuterung:

;Problemlösung: Damit ein Algorithmus ein Problem (genauer: eine Menge von gleichartigen Problemen) lösen kann, muss das Problem zunächst definiert (''spezifiziert'') werden. Die '''Spezifikation''' legt fest, ''was'' der Algorithmus erreichen soll, sagt aber nichts über das ''wie''. Die Spezifikation beschreibt somit relevante Eigenschaften des Systemzustands ''vor'' und ''nach'' der Ausführung des Algorithmus (sogenannte '''Vor-''' und '''Nachbedingungen'''), während der Algorithmus einen bestimmten ''Lösungsweg'' repräsentiert. Mit Hilfe der Spezifikation kann getestet werden, ob der Algorithmus tatsächlich eine Lösung des gestellten Problems liefert. Diese Frage untersuchen wir im Kapitel [[Korrektheit]].
;Endlich viele Schritte: Die Forderung nach endlich vielen Schritten unterstellt, dass jeder einzelne Schritt eine gewisse Zeit benötigt, also nicht unendlich schnell ausgeführt werden kann. Damit ist diese Forderung äquivalent zu der Forderung, dass der Algorithmus in endlicher Zeit zum Ergebnis kommen muss. Der Sinn einer solchen Forderung leuchtet aus praktischer Sicht unmittelbar ein. Interessant ist darüber hinaus die Frage, wie man mit möglichst wenigen Schritten, also möglichst schnell, zur Lösung kommt. Diese Frage untersuchen wir im Kapitel [[Effizienz]].
;Elementare Schritte: Im weiteren Sinne verstehen wir unter einem elementaren Schritt ein Teilproblem, für das bereits ein Algorithmus bekannt ist. Im engeren Sinne ist die Menge der elementaren Schritte durch die Hilfsmittel vorgegeben, mit denen der Algorithmus ausgeführt werden soll, also z.B. durch die Hardware oder die Programmiersprache. Wir gehen darauf im nächsten Abschnitt näher ein.

=== Zur Frage der elementaren Schritte ===

Welche Schritte als elementar angesehen werden können, hängt sehr stark vom Kontext der Aufgabe und den Hilfsmitteln zu ihrer Lösung ab. Ein interessantes Beispiel ist die Geometrie der alten Griechen, wo geometrische Probleme in der Ebene allein mit Zirkel und Lineal gelöst werden. In diesem Fall sind folgende elementare Operationen erlaubt:
* das Markieren eines Punktes (beliebig in der Ebene oder als Schnittpunkt zwischen bereits gezeichneten Linien),
* das Zeichnen einer Geraden durch zwei Punkte,
* das Zeichnen eines Kreises um einen Punkt,
* das Abgreifen des Abstands zwischen zwei Punkten mit dem Zirkel.
Auf der Basis dieser Operationen kann zum Beispiel kein Algorithmus für die Dreiteilung eines beliebigen Winkels definiert werden, während der Algorithmus für die Zweiteilung sehr einfach ist.

Eine völlig andere Menge von elementaren Operationen ergibt sich für arithmetische Berechnungen mit Hilfe des Abacus (Rechenbrett), der seit der Römerzeit in Europa weit verbreitet war. Hier werden Zahlen durch die Positionen von Perlen auf Rillen oder Drähten dargestellt und Berechnungen durch deren Verschiebung. Eine ausführliche Beschreibung der wichtigsten Abacus-Algorithmen findet sich unter [http://abacus.etherwork.net/ The Bead Unbuffled] von Totton Heffelfinger und Gary Flom.

Die moderne Auffassung von elementaren Operationen wird durch die Berechenbarkeitstheorie (ein Teilgebiet der theoretischen Informatik) bestimmt. Verschiedene Mathematiker (darunter die Pioniere Alan Turing, Alonso Church, Kurt Gödel, Stephen Kleene und Emil Post) haben seit den 1930er Jahren versucht, den intuitiven Begriff der Berechenbarkeit einer Funktion zu formalisieren und sind dabei zu völlig verschiedenen Lösungen gelangt (z.B. Turingmaschine, Lambda-Kalkül, μ-Rekursion und WHILE-Programm). Interessanterweise stellte sich heraus, dass diese Lösungen alle die gleiche Mächtigkeit haben: Obwohl die elementaren Operationen jeweils ganz anders definiert sind, ist die Menge der damit berechenbaren Funktionen immer gleich. Die [http://en.wikipedia.org/wiki/Church_thesis Church-Turing-These] besagt, dass es prinzipiell unmöglich ist, eine mächtigere Definition von elementaren Operationen zu finden, aber dies ist unbewiesen. Am bequemsten für die Praxis sind die [http://de.wikipedia.org/wiki/WHILE-Programm WHILE-Programme], da sie sich direkt auf die heute gebräuchliche Hardware-Architektur abbilden lassen. Die elementaren Operationen eines WHILE-Programms lauten in erweiterter Backus-Naur Notation:
P ::= x[i] = x[j] + c # Addition einer Konstanten zur Variable x[i]
| x[i] = x[j] - c # Subtraktion einer Konstanten von x[i]
| P; P # Nacheinanderausführung von zwei Anweisungen
| WHILE x[i] != 0 DO P DONE # Wiederholte Ausführung der Anweisung(en) P
# (x[i] muss sich innerhalb von P ändern, um eine Endlosschleife zu vermeiden)
wobei <tt>c</tt> eine beliebige ganzahlige Konstante (eine ausgeschriebene ganze Zahl) und <tt>x[i]</tt> die Speicherzelle <tt>i</tt> bezeichnen. Alle Speicherzellen können ganze Zahlen aufnehmen und sind anfangs mit Null belegt. Darüber hinaus wird vorausgesetzt, dass mindestens soviele Speicherzellen vorhanden sind, wie der gegebene Algorithmus benötigt, und jede Speicherzelle groß genug ist, um die größte auftretende Zahl aufzunehmen. Beide Annahmen sind in der Praxis nicht immer erfüllt.

In einem WHILE-Programm gibt es keine elementare Funktion, um die Summe von zwei Variablen zu berechnen. Diese Operation muss man bereits als Algorithmus implementieren. Der folgende Code berechnet die Summe unter der Voraussetzung, dass <tt>x[j]</tt> nicht negativ ist, indem <tt>x[j]</tt> solange dekrementiert (um 1 erniedrigt) wird, bis es den Wert 0 annimmt, und <tt>x[i]</tt> entsprechend bei jedem Schritt inkrementiert (um 1 erhöht) wird. Die alten Werte der Variablen gehen bei der Berechnung verloren:
Algorithmus: x[i] = x[i] + x[j] als WHILE-Programm (Vorbedingung: x[j] >= 0)
WHILE x[j] != 0 DO
x[i] = x[i] + 1;
x[j] = x[j] - 1
DONE
Man erkennt, dass tatsächlich nur die vier elementaren Operationen (Addition/Subtraktion einer Konstanten, Nacheinanderausführung von Anweisungen, WHILE-Schleife) vorkommen. Allerdings ist dieser Algorithmus sehr langsam. Außerdem ist die Zerlegung in Form eines WHILE-Programms (oder eines äquivalenten Formalismus der Berechenbarkeitstheorie) für unsere Zwecke zu feinkörnig: Sie würde bedeuten, dass alle Algorithmen auf einem extrem einfachen Prozessor in Assembler programmiert werden müssten. Bereits eine so einfache Operation wie die Summe von zwei Variablen erfordert vier Codezeilen!

Deshalb definiert man ''höhere Programmiersprachen'', die wichtige Algorithmen wie z.B. die arithmetischen Operationen mit ganzen Zahlen und Gleitkomma-Zahlen bereits als elementare Operationen enthalten. Weitere nicht ganz so wichtige Funktionen wie die Wurzel oder der Logarithmus werden in Programmbibliotheken angeboten, die standardmäßig mitgeliefert werden. In der Praxis betrachtet man eine Operation deshalb als elementar, wenn sie von einer typischen Programmiersprache oder einer typischen Standardbibliothek unterstützt wird. In dieser Vorlesung wählen wir die Operationen und Bibliotheken der Programmiersprache [http://www.python.org Python]. Wenn ein Algorithmus Anforderungen stellt, die nicht selbstverständlich sind, müssen sie als ''Requirements'' explizit angegeben werden. Wir werden darauf im Kapitel [[Generizität]] zurückkommen.

=== Zur Geschichte ===

{| border="0" cellspacing="0" cellpadding="5"
|-valign="top"
| Algorithmen wurden bereits im Altertum verwendet. Besonders die alten Griechen haben Pionierarbeit geleistet, z.B. auf dem Gebiet der Arithmetik (Euklidischer Algorithmus für den größten gemeinsamen Teiler von zwei Zahlen, Sieb des Eratosthenes zur Bestimmung von Primzahlen) und der Geometrie (Teilung einer Strecke oder eines Winkels nur mit Zirkel und Lineal). Der Begriff ''Algorithmus'' ist vom Namen des arabischen Gelehrten Muhammed Al Chwarizmi (ca. 783-850) abgeleitet, der in seinem Werk „Über das Rechnen mit indischen Ziffern“ (um 825) grundlegende Verfahren für das Rechnen im dekadischen Positionssystem beschrieben hat. Im 12. Jahrhundert wurde dieses Buch ins Lateinische übersetzt, und die Einleitung begann mit den Worten „Dixit Algorismi“ (Al Chwarizmi hat gesagt). Ab etwa 1200 wurden die neuen Rechenmethoden als „Algorismus de integris“ bzw. „Algorismus vulgaris“ (Rechnen mit ganzen Zahlen, d.h. Grundrechenarten und Wurzelziehen) sowie „Algorismus de minutiis“ (Bruchrechnung) zum festen Bestandteil der mathematischen Ausbildung im Rahmen der sieben freien Künste. Dabei diente der Begriff Algorithmus ursprünglich vor allem zur Abgrenzung des schriftlichen Rechnens mit indischen/arabischen Zahlen (wie wir es noch heute in der Schule lernen) vom traditionellen mechanischen Rechnen mit Abacus und römischen Zahlen, das noch bis ca. 1500 in Europa vorherrschend blieb.

Die allgemeinere Bedeutung des Wortes Algorithmus als systematische Rechenvorschrift war jedoch ebenfalls schon früh gebräuchlich. Dies zeigt zum Beispiel der Titel des Buches „Algorismus proportionum“ (Rechenkunst mit Proportionen, ca. 1350) von Nicole Oresme, wo erstmals die Rechenregeln für Potenzen mit rationalen Exponenten beschrieben werden. Durch die steigenden Anforderungen des kaufmännischen Rechnens und der Navigation verbreitete sich die algorithmische Denkweise ab etwa 1500 rasch. Der Buchdruck machte mit Werken wie Adam Ries' „Rechenung auff der linihen und federn“ (d.h. mit Abacus und mit indischen/arabischen Zahlen, zuerst 1522) die grundlegenden Rechenalgorithmen einem breiten Bevölkerungskreis bekannt. Umfangreiche gedruckte Tafelwerke, z.B. der „Canon“ von G.J. Rhaeticus (1551) mit bis zu siebenstelligen Tabellen der trigonometrischen Funktionen, erlaubten es, komplizierte Berechnungen auf einfache Schritte (Addition, Subtraktion sowie Nachschlagen in der Tabelle) zurückzuführen. Unsere heutige Verwendung des Begriffs geht wohl auf Alonso Church's Aufsatz „An Unsolvable Problem of Elementary Number Theory“ (1936) zurück, wo die Berechenbarkeit einer Funktion mit der Existenz eines terminierenden Berechnungsalgorithmus gleichgesetzt wird.
| [[Image:Al-Khwarizmi.jpg]] Al Chwarizmi-Denkmal in Teheran
|}

== Definition von Datenstrukturen ==

=== Beispiele für Datenformate ===

Der Speicher eines Computers enthält eine Folge von Zeichen aus einem gegebenen Alphabet. Bei fast allen heutigen Computern ist dies eine Folge von Bits aus dem Alphabet {0,1}. Ein '''Datenformat''' ordnet eine Bitfolge in Gruppen und gibt jeder Gruppe eine Bedeutung. Der Gruppierungsprozess kann dann hierarchisch fortgesetzt werden.

Die selben Bits können somit völlig verschiedene Bedeutungen annehmen, ja nachdem in welchem Datenformat sie sich befinden. Man betrachte z.B. die Folge von 16 Bits:
1101011001101100
Wenn wir diese Folge als eine zusammengehörende Gruppe betrachten und als positive ganze Zahl in Binärdarstellung interpretieren (unsigned integer, <tt>uint16</tt>), ergibt sich die Dezimalzahl
54892 = 1*215 + ... + 1*23 + 1*22 + 0*21 + 0*20
Interpretieren wir dieselbe Gruppe als vorzeichenbehaftete ganze Zahl in [http://de.wikipedia.org/wiki/Zweierkomplement Zweierkomplement]-Darstellung (signed integer, <tt>int16</tt>), ergibt sich eine andere Dezimalzahl: Da das linke (höchstwertige) Bit Eins ist, handelt es sich um eine negative Zahl. Das Zweierkomplement erhält man durch Negieren aller Bits und nachfolgende Addition von 1:
Zweierkomplement von 1101011001101100:
0010100110010011 + 1 = 0010100110010100
Die resultierende Dezimalzahl ist somit
-10644 = -(0*215 + ... + 0*23 + 1*22 + 0*21 + 0*20)
Alternativ können wir die Folge in zwei Gruppen zu 8 Bit gruppieren, und die Gruppen als Zeichencodes im Windows-Zeichensatz interpretieren. Wir erhalten die Zeichenkette "Öl":
11010110 01101100 = char[214] char[108] => Öl
Eine weitere Interpretation ist diejenige als 16-Bit Gleitkommazahl (<tt>float16</tt>) gemäß [http://en.wikipedia.org/wiki/IEEE_floating-point_standard IEEE Standard 754]. Dabei wird die Folge in Gruppen zu 1 Bit, 5 Bit und 10 Bit eingeteilt:
1 10101 1001101100
Die Gruppen werden als nicht-negative Binärzahlen gelesen, wobei die erste Gruppe das Vorzeichen <tt>s</tt> der Gleitkommazahl ist (0 bedeutet "+", 1 bedeutet "-"), die zweite ist ihr Exponent <tt>exp</tt> und die dritte die Mantisse <tt>m</tt>. In unserem Beispiel gilt <tt>s = 1</tt>, <tt>exp = 21</tt> und <tt>m = 620</tt>). Die Umrechnung in eine Gleitkommazahl erfolgt, gemäß IEEE Standard, nach folgender Formel: 
<tt>z = (1 - 2*s) * 2exp-15 * (1 + m * 2-10)</tt>. 
In Dezimaldarstellung ist dies <tt>-102.75</tt>.

Das analoge Beispiel für eine Folge von 32 Bits ist vielleicht realistischer, weil 32-bit Zahlen (integer und float) in der Praxis häufiger vorkommen. Wir betrachten die Bitfolge:
11111100011000100110010101101110
Als positive ganze Zahl in Binärdarstellung (unsigned integer, <tt>uint32</tt>) ergibt sich die Dezimalzahl 4234306926. Dieselben Bits als vorzeichenbehaftete ganze Zahl in Zweierkomplement-Darstellung (signed integer, <tt>int32</tt>) ergiben die Dezimalzahl -60660370. Als Zeichenfolge (vier Gruppen zu 8 Bit) bekommen wir die Zeichenkette "üben". Eine weitere mögliche Interpretation ist diejenige als Farbe im RGBA System (8 Bit pro Farbkanal, 8 Bit Transparenzwert), und wir erhalten ein halbtransparentes Rosa (Rot: 252, Grün: 98, Blau: 101, Alpha: 110). 
Eine 32-Bit Gleitkommazahl (<tt>float32</tt>) ist gemäß IEEE Standard 754 definiert durch Gruppen zu 1 Bit für das Vorzeichen, 8 Bit für den Exponenten und 23 Bit für die Mantisse, d.h:
1 11111000 11000100110010101101110
Hier gilt also <tt>s = 1</tt>, <tt>exp = 248</tt> und <tt>m = 6448494</tt>). Die Umrechnung in eine Gleitkommazahl erfolgt jetzt nach der Formel: 
<tt>z = (1 - 2*s) * 2exp-127 * (1 + m * 2-23)</tt>. 
In Dezimaldarstellung ist dies rund <tt>-4.7020653*1036</tt>.

Im Sinne einer hierarchischen Gruppierung können wir jetzt z.B. eine Datenstruktur "Farbbild" definieren, indem wir viele RGBA-Werte zu einem 2-dimensionalen Array zusammenfassen. Eine Datenstruktur "komplexe Zahl" wird durch ein geordnetes Paar von Gleitkommazahlen gebildet, eine "Meßreihe" als Liste von ganzen Zahlen oder Gleitkommawerten (je nach Art der Messung), usw.

=== Varianten der Datenstrukturdefinition ===

{| border="0" cellspacing="0" cellpadding="5"
|-valign="bottom"
| Bei den Beispielen im vorigen Abschnitt habe wir das Speicherlayout und die Bedeutung der einzelnen Bits bzw. Bit-Gruppen festgelegt. Wir bezeichnen eine auf diese Weise definierte Datenstruktur als Datenformat. Datenformate werden vor allem verwendet, um Datenstrukturen auf Festplatte oder in einer Datenbank zu speichern und Daten über ein Netzwerk auszutauschen (vgl. den Eintrag [http://de.wikipedia.org/wiki/Dateitypen Dateityp] in der WikiPedia). Aus Sicht des Betriebssystems ist ein File einfach eine Folge von Bits, deren Bedeutung aus anderen Informationen geschlossen werden muss, z.B. aus der Endung des Filenames (.jpg, .png, .xml usw.) oder aus dem mit dem File assoziierten [http://de.wikipedia.org/wiki/Internet_Media_Type MIME-Type]. Viele Fileformate beginnen zudem mit bestimmten Bitfolgen ("[http://de.wikipedia.org/wiki/Magische_Zahl_%28Informatik%29 magischen Zahlen]"), die für das betreffende Fileformat charakteristisch sind. Jedes JPEG-File beginnt z.B. mit dem Bytemuster <tt>255 216 255</tt>, jedes PNG-File mit der Folge <tt>137 80 78 71</tt>, jedes XML-File mit dem String <tt>"<?xml version="1.0" encoding="utf-8" ?></tt> (wobei Versionsnummer und Zeichensatzdefinition natürlich verschieden sein können, je nach Fileinhalt). Wann immer möglich sollte man bei der Verwendung von Datenformaten auf vorhandene Standards (wie z.B. IEEE 754 für Gleitkommazahlen oder XML für hierarchisch strukturierte Dokumente) zurückgreifen, weil sonst beim Einlesen und Interpretieren der gespeicherten Bitfolgen sehr leicht Fehler passieren.

Innerhalb einer Programmiersprache werden Datenstrukturen typischerweise nicht als Datenformate definiert, sondern durch die Verknüpfung eines Speicherlayouts mit einer Menge erlaubter Operationen auf diesen Daten. Die Interpretation ergibt sich implizit aus der Definition dieser Operationen. Verwendet man beispielsweise eine Folge von 32 Bits zusammen mit den arithmetischen Operationen für natürliche Zahlen (inklusive der zugehörigen Vor- und Nachbedingungen), ist die Interpretation als <tt>uint32</tt> dadurch gegeben. Eine Folge von Bytes mit den Operationen <tt>print</tt>, <tt>append</tt>, <tt>toLowerCase</tt>, <tt>toUpperCase</tt> usw. weist auf die Interpretation "Zeichenkette" (<tt>string</tt>). Eine solche Verknüpfung von Datenrepräsentation mit Operationen bezeichnen wir als '''(Daten-)Typ''' oder '''Klasse'''. Klassen sind für den Programmierer das wichtigste Mittel, um eigene Datenstrukturen zu definieren, und wir werden in der Vorlesung ausführlich darauf eingehen.

Die dritte Möglichkeit ist schließlich die Kombination einer Interpretation mit einer Menge erlaubter Operationen, ohne ein bestimmtes Speicherlayout oder eine konkrete Implementation der Operationen festzulegen. In diesem Fall sprechen wir von '''Abstrakten Datentypen''' (ADTs). Diese spielen beim Entwurf von anwendungsübergreifenden Programmierschnittstellen und bei der theoretischen Analyse von Algorithmen und Datenstrukturen eine wichtige Rolle. Da von den Besonderheiten einer bestimmten Implementation und eines bestimmten Computers abstrahiert wird, sind die gewonnen Erkenntnisse auf viele Anwendungen übertragbar. Konzepte, die als abstrakte Datentypen definiert sind, können je nach Kontext immer wieder anders implementiert werden, ohne dass die übergreifenden (abstrakten) Eigenschaften verloren gehen. Viele der konkreten Datenstrukturen, die wir behandeln werden, kann man zu abstrakten Datenstrukturen verallgemeinern. Dies ist eine Schlüsselaufgabe beim Entwurf wiederverwendbarer Programmbibliotheken. Wir kommen im Kapitel [[Generizität]] auf ADTs zurück.

Man kann sich die drei Möglichkeiten "Speicherlayout", "Bedeutung" und "Menge der darauf ausführbaren Operatoren" als Ecken eines Dreiecks wie in der nebenstehenden Skizze vorstellen. Definiert man zwei Ecken des Dreiecks, ist auch die dritte weitgehend (oder zumindest zu einem gewissen Grade, wie bei ADTs) festgelegt. Die drei Kanten entsprechen den drei Arten der Datenstrukturen: Legt man "Speicherlayout" und "Bedeutung" fest, erhalten wir ein Datenformat, bei "Speicherlayout" plus "Operatoren" einen Klasse bzw. einen Typ, und aus "Operatoren" plus "Bedeutung" folgt ein abstrakter Datentyp.
| [[Image:Dt dreieck.png|400px]] <center>Datenstruktur-Dreieck</center>
|}

=== Wichtige Begriffe ===

Programmiersprachen, die ausgereifte Mechanismen zur Definition von Klassen bieten, werden als ''objekt-orientiert'' bezeichnet. Sprachen heißen ''streng typisiert'', wenn der Compiler bzw. Interpreter der Sprache sicherstellt, dass auf jeder Datenstruktur nur die jeweils explizit erlaubten Operationen ausgeführt werden (jeder Versuch, eine illegale Operation auszuführen, wird hier als Fehler signalisiert). Erfolgt diese Prüfung während der Compilierung (also während der Übersetzung des Quellcodes in eine Maschinensprache), spricht man von einer ''statisch typisierten Sprache''. Wird die Prüfung hingegen während der Ausführung des Programms durchgeführt, handelt es sich um eine ''dynamisch typisierte Sprache''. Python ist eine dynamisch-typisierte, objekt-orientierte Sprache. Streng typisiert ist sie allerdings nur für die vordefinierten Klassen. Bei benutzerdefinierten Klassen gibt es (wie bei den meisten anderen Programmiersprachen auch) Möglichkeiten, die erlaubten Operationen zu umgehen. Dies sollte man allerdings nur dann tun, wenn es einen wichtigen Grund gibt. Solange man sich nämlich auf die erlaubten Operationen beschränkt, ist eine große Menge von Fehlerquellen von vornherein ausgeschlossen.

Ein bestimmter Speicherbereich, der den Anforderungen an eine Klasse genügt (wo also die Bits in entsprechender Weise gruppiert und interpretiert werden), wird als '''Objekt''' dieser Klasse oder als '''Instanz''' bezeichnet. Jede Instanz hat eine eindeutige Identität, einen ''Schlüssel''. Innerhalb eines Programms wird dafür gewöhnlich die Speicheradresse des ersten Bytes der Instanz (also der Index der ersten Speicherzelle) verwendet. Dies ist besonders effizient, weil die Speicheradresse für jedes Objekt eindeutig und leicht feststellbar ist. Ist das Objekt hingegen als Datei gespeichert, benötigt man einen expliziten Schlüssel, z.B. den Dateinamen oder die URL.

Das Bitmuster selbst bzw. die daraus folgende Interpretation wird als '''Zustand''' oder '''Wert''' der Instanz bezeichnet. Daraus folgt, dass verschiedene Instanzen einer Klasse dennoch gleiche Werte haben können. Die Menge aller legalen Werte bilden den ''Wertebereich'' der Klasse. Werden Instanzen ausschließlich mit den explizit erlaubten Operationen ihrer Klasse manipuliert, können niemals illegale Werte entstehen. Es liegt auf der Hand, dass illegale Werte schwerwiegende Programmfehler darstellen, die man auf diese Weise vermeidet. [Computerviren tun genau das Gegenteil: Sie verwenden absichtlich verbotene Operationen, um das Programm in einen illegalen, vom Angreifer gewünschten Zustand zu bringen. Dies ist möglich, weil nicht alle verbotenen Operationen automatisch als Fehler erkannt werden, siehe oben.]

Die meisten Programmiersprachen haben einen oder mehrere spezielle Typen für das Speichern von Objektschlüsseln. Die gebräuchlichsten Namen für diese Typen sind ''Zeiger'' (pointer), ''Referenz'' (reference) und ''Handle''. Wir verwenden das Wort '''Referenz'''. Ein Objekt der Klasse Referenz enthält also den Schlüssel eines anderen Objekts. Man sagt, dass die Referenz ''auf das andere Objekt verweist''. Diese Art der Indirektion ist uns heutzutage durch das Internet bestens vertraut: Jede WWW-Seite ist ein Objekt, und seine URL ist der dazugehörige Schlüssel. Hyperlinks und Lesezeichen (bookmarks) hingegen sind Referenzen, die mittels der URL auf andere Seiten verweisen.

Aus der Unterscheidung von Werten und Referenzen ergibt sich die wichtige Unterscheidung von ''Wertsemantik'' und ''Referenzsemantik''. Wird nämlich ein Objekt an eine Variable zugewiesen
x = anObject
so hängt die korrekte Verwendung der Variablen <tt>x</tt> davon ab, ob sie das Objekt in Form eines Wertes oder einer Referenz speichert. Im ersten Fall wird das Objekt selbst kopiert, und es entsteht ein neues Objekt mit neuer Identität, aber gleichem Zustand. Im anderen Fall wird nur der Schlüssel kopiert, und die Referenz verweist nach wie vor auf das ursprüngliche Objekt. Ist <tt>x</tt> ein Wert, so verändert eine Manipulation von <tt>x</tt> nur das neue Objekt (das ursprüngliche bleibt erhalten). Ist <tt>x</tt> hingegen eine Referenz, wird immer das ürsprüngliche Objekt manipuliert (denn es gibt ja keine Kopie). Ob eine Variable einen Wert oder eine Referenz enthält, wird in jeder Programmiersprache anderes festgelegt. In Python gilt
* Zahlen (Typen <tt>bool</tt>, <tt>int</tt>, und <tt>float</tt>) werden immer als Werte gespeichert und kopiert.
* Alle anderen Typen werden als Referenzen gespeichert und kopiert.
* Für alle Typen kann Wertsemantik mit Hilfe des Python-Moduls [http://docs.python.org/lib/module-copy.html copy] erzwungen werden.
Das Verständnis von Werten und Referenzen wird in der 1. Übung vertieft.

Der Entwurf von Datentypen bzw. Klassen wird uns im Laufe der Vorlesung immer wieder beschäftigen.

== Fundamentale Algorithmen ==

Einige Algorithmen werden praktisch bei jeder Klasse benötigt, unabhängig vom eigentlichem Verwendungszweck der Klasse. Es ist wichtig, diese fundamentalen Algorithmen zu kennen. Außerdem eignen sie sich gut zur Einführung der Grundprinzipien der Algorithmen-Spezifikation mittels Vor- und Nachbedingungen. Diese Bedingungen beschreiben Eigenschaften, die die Variablen des Systems ''vor'' bzw. ''nach'' der Ausführung des Algorithmus haben sollen. Damit man außerdem die Veränderungen durch den Algorithmus beschreiben kann, führt man zu jeder Variablen (z.B. <tt>x</tt>) eine Hilfsvariable (z.B. <tt>xo</tt>, sprich "x-old") ein. In den Hilfsvariablen wird der Zustand ''vor'' der Ausführung des Algorithmus gespeichert, so dass man diesen noch abfragen kann, wenn Variablen durch den Algorithmus verändert werden. Wenn der Algorithmus beispielsweise die Variable <tt>x</tt> inkrementiert (um eins erhöht), gilt die Nachbedingung <tt>x == xo + 1</tt> (darin ist <tt>x</tt> der neue, und <tt>xo</tt> der alte Wert der Variablen). Falls <tt>x</tt> hingegen nicht verändert wird, gilt <tt>x == xo</tt>. (Man beachte, dass dies in der Literatur nicht einheitlich gehandhabt wird -- einige Autoren verwenden z.B. <tt>x</tt> für den Zustand vor Ausführung des Algorithmus, und <tt>x'</tt> für denjenigen danach. Diese Syntax ist jedoch mit den meisten Programmiersprachen inkompatibel.)

Die wichtigste Gruppe von fundamentalen Funktionen sind die '''Konstruktoren''', die einen vorher unbenutzten Speicherbereich in eine Datenstruktur mit einem wohldefinierten Anfangswert transformieren. In Python haben die Konstruktoren im allgemeinen den gleichen Namen wie die dazugehörige Klasse, also z.B.
i = int() # erzeuge eine ganze Zahl mit Anfangswert 0
f = float() # erzeuge eine Gleitkommazahl mit Anfangswert 0
a = list() # erzeuge ein leeres Array
usw. (Man beachte, dass das Python-Array den Klassennamen <tt>list</tt> hat. Dies hat nichts mit verketteten Listen zu tun.) Konstruktoren ohne Argumente bezeichnet man als ''Standard-Konstruktoren'' (default constructors). Ja nach Typ gibt es meist noch weitere Konstruktoren, die Objekte mit anderen Anfangswerten erzeugen, z.B.
i = int(2) # erzeuge eine ganze Zahl mit Anfangswert 2
i = 2 # ebenso (abgekürzte Schreibweise)
f = float(1.5) # erzeuge eine Gleitkommazahl mit Anfangswert 1.5
f = 1.5 # ebenso (abgekürzte Schreibweise)
a = [i, f] # erzeuge ein Array mit Kopien der Werte von i und f
(Das Array <tt>a</tt> enthält Kopien der Werte, weil Zahlen immer mit Wertsemantik zugewiesen werden.) Die allgemeine Spezifikation eines Standard-Konstruktors lautet

<math>\begin{array}{ll}
\mathrm{Precondition: } & T \in \mathrm{Types}\\
\mathrm{Constructor: } & t = T() \\
\mathrm{Postcondition: } & t \in T
\end{array}</math>

Der Ausdruck <math>t \in T</math> besagt, dass t nach Ausführung des Konstruktors eine legale Instanz des Typs T (oder eine Referenz auf einen solche Instanz) sein muss. In Pythonsyntax kann dies folgendermassen geschrieben werden
import inspect # wir brauchen das inspect-Modul

if inspect.isclass(T): # prüfe, dass T ein Type ist
t = T()
assert isinstance(t, T)
Natürlich funktioniert der Code nur, wenn die Klasse <tt>T</tt> tatsächlich existiert und dafür ein Standardkonstruktor definiert wurde. Das Gegenstück zu Konstruktoren sind die '''Destruktoren''', die den Speicher der Datenstruktur wieder frei geben. Da Python automatisches Speichermanagment unterstützt, werden die Destruktoren automatisch aufgerufen. Wir können sie deshalb hier übergehen.

Sehr wichtig sind auch die '''Vergleichsoperatoren'''. Wir müssen dabei unterscheiden, ob auf Gleichheit der Referenzen (''identity'') oder auf Gleichkeit der Werte (''equality'') geprüft werden soll. In Python werden dazu die Operatoren <tt>is</tt> bzw. <tt>==</tt> verwendet. Die Negation erhält man durch <tt>is not</tt> bzw.
<tt>!=</tt>
a = [1, 2]
b = [1, 2]

a == b # True weil gleiche Werte
a != b # False weil Negation
a is b # False weil unterschiedliche Identität
a is not b # True weil Negation

(Beachte: beim Vergleich von Zahlen des gleichen Typs liefern <tt>is</tt> und <tt>==</tt> immer dasselbe Ergebnis.) Natürlich impliziert die Gleichheit der Schlüssel (Identität der Objekte) die Gleichheit der Werte.

Ebenso wichtig sind die '''Zuweisungen'''. Hier zeigt sich besonders der Unterschied zwischen Wert- und Referenzsemantik. Im Falle von Wertsemantik gilt

<math>\begin{array}{ll}
\mathrm{Preconditions: } & s,t \in T \\
& s \mathrm{\ is\ not\ } t \\
\mathrm{Assign\ by\ value: } & s = t \\
\mathrm{Postconditions: } & t \mathrm{\ is\ } t_o \\
& s \mathrm{\ is\ not\ } t \\
& s == t
\end{array}</math>

Das heisst, t darf sich nicht verändern, und s hat nach der Zuweisung den gleichen Wert wie t. Bei Referenzsemantik gilt sogar

<math>\begin{array}{ll}
\mathrm{Precondition: } & t \in T \\
\mathrm{Assign\ by\ reference: } & s = t \\
\mathrm{Postconditions: } & t \mathrm{\ is\ } t_o \\
& s \mathrm{\ is\ } t
\end{array}</math>

Dies entspricht dem Pythoncode
x = y
assert x is y
Die Wertsemantik muss man in Python explizit erzwingen
import copy # wir brauchen das copy-Modul

x = copy.deepcopy(y)
assert x == y
assert x is not y

Mit der Zuweisung eng verwandt ist die Funktion <tt>swap</tt>, die den Inhalt von zwei Variablen vertauscht:

<math>\begin{array}{ll}
\mathrm{Precondition: } & t \in T, s \in S \\
\mathrm{Algorithm\ swap: } & \mathrm{swap}(s, t) \\
\mathrm{Postconditions: } & t \mathrm{\ is\ } s_o \\
& s \mathrm{\ is\ } t_o
\end{array}</math>

Diese Funktion wird sich beim Sortieren als sehr nützlich erweisen, weil dort das Vertauschen von zwei Datenelementen eine Grundoperation ist. In Python kann man dies so implementieren:
t, s = s, t # swap
Dabei macht man sich zunutze, dass Python mehrere Variablen in einem einzigen Statement zuweisen kann.

[[Container|Nächstes Thema]]

Main Page

2020-04-23T19:20:51Z

Alda: /* Vorlesung Algorithmen und Datenstrukturen */

== Vorlesung Algorithmen und Datenstrukturen ==

apl. Prof. Dr. Ullrich Köthe, Universität Heidelberg, Sommersemester 2020

Die Vorlesung findet '''dienstags''' um 14:15 Uhr und '''donnerstags''' um 16:15 Uhr online auf Discord und Twitch statt. Die Links haben in Müsli angemeldete Teilnehmer per Email erhalten.

=== Klausur und Nachprüfung ===

Der Termin der '''Abschlussklausur''' steht noch nicht fest.




=== Übungsbetrieb ===

* Die Übungsgruppen werden über [https://muesli.mathi.uni-heidelberg.de/lecture/view/1171 MÜSLI] verwaltet.
* Übungsblätter werden auf [https://moodle.uni-heidelberg.de/course/view.php?id=2239 Moodle] veröffentlicht.

=== 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 ===
(Termine werden nach und nach aktualisiert)

# [[Einführung]] (21. und 23.4.2020)
#* Definition von Algorithmen und Datenstrukturen, Geschichte
#* Fundamentale Algorithmen: Konstruktoren, Kopierfunktionen, swap.
#* Fundamentale Datenstrukturen: Zahlen, Container, Handles
#* Python-Grundlagen

# [[Container]] (28.4.2020)
#* Abstrakte Datentypen und algebraische Spezifikation
#* Grundlegende Container: Array, Stack, Queue, assoziatives Array

# [[Sortieren]] (27. bis 4.5.2017)
#* Spezifikation des Sortierproblems
#* Selection Sort und Insertion Sort
#* Merge Sort
#* Quick Sort und seine Varianten
#* Anzahl der benötigten Vergleiche

# [[Korrektheit]] (29.4. und 6.5.2014 -- ab hier altes Datum)
#* 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]] (8. und 13.5.2014)
#* 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]] (15. und 20.5.2014)
#* 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]] (22.5.2014)
#* Permutationen
#* Sortieren als Suchproblem
#* Bucket Prinzip, Bucket Sort

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

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

# [[Hashing und Hashtabellen]] (5. und 10.6.2014)
#* 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]] (12.6.2014)
#* Typen der Rekursion und ihre Umwandlung in Iteration
#* Auflösung rekursiver Formeln mittels Master-Methode und Substitutionsmethode

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

# [[Graphen und Graphenalgorithmen]] (24.6. bis 10.7.2014)
#* 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 15.7.2014)
#* 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.2014)
#* 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]] (22.7.2014)
#* die Klassen P und NP
#* NP-Vollständigkeit und Problemreduktion

# Wiederholung (24.7.2014)

== Übungsaufgaben ==

(im PDF Format). Die Abgabe erfolgt am angegebenen Tag bis 14:00 Uhr per Email an den jeweiligen Übungsgruppenleiter. Bei verspäteter Abgabe bis zu drei Tagen werden noch 50% der erreichten Punkte angerechnet. Danach wird die Musterlösung freigeschaltet.

Die Übungsaufgaben sind zur Zeit nicht freigeschaltet.



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

Korrektheit

2019-05-02T10:04:18Z

Alda:

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://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.54.3892 Practical Strategy for Testing Pair-wise Coverage of Network Interfaces], [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]]

NP-Vollständigkeit

2017-08-03T15:29:56Z

Alda: /* Alg. 2 (det. Alg. für k=2 mittels SZK in gerichtetem Graphen) */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden.
: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

=== k-SAT, k=2 in pol. Zeit lösbar ===

==== Alg. 1 ====
(f. bei k) (nur für k=2 effizient) '''Randomisiert'''
* (0) initialisiere <math>x_i</math> beliebig
* (1) wiederhole <math>T_{max}</math> - mal
** (a) wenn das aktuelle x den Ausdruck erfüllt: return x (x=[<math> x_1</math>, ... , <math>x_N</math>])
** (b) wähle zufällig eine Klausel, die nicht erfüllt ist
** (c) wähle in dieser Klausel zufällig eine der k Variablen und invertiere sie => Klausel ist jetzt erfüllt
::: (andere können jetzt false geworden sein)
::: (<math>x_1 \or x_2 ) \and ( x_1 \or \lnot x_2 )</math>      <math> x_1 = 0, x_2 = 0,</math>      <math> x_2</math> auf 1 => 1. Klausel wahr, 2. falsch
* (2) return "keine Lösung gefunden"

Nach wie vielen Iterationen wird im Mittel eine Lösung gefunden?
* Ausdruck unerfüllbar => Endlosschleife, Timeout nach <math>T_{max}</math> Iterationen
* Ausrduck erfüllbar:
** falls k<math>\geq</math>3: nach <math>O((\frac{2(k-1)}{k})^N)</math> Iterationen wird Lösung gefunden
** k=3: <math>O((\frac{4}{3})^N)</math> exponentielle Zeit, wie zu erwarten für NP-vollständiges Problem
** k=2: <math>O(N^2)</math> Iterationen bis Lösung

Beweis: Algorithmus entspricht im Wesentlichen dem '''Random Walk'''
: Sei <math>x^*</math> die korrekte Lösung und x die aktuelle Belegung
: RW: Stuhl i <math>\mathrel{\hat=}</math> i Variablen zwischen <math>x^*</math> und x stimmen überein => Ziel: erreiche Stuhl N
* (c):
** Fall 1: beide Variablen falsch => egal welche wir invertieren, bewegen wir uns von Stuhl i zu i+1
** Fall 2: eine Variable ist falsch:
*** mit Wahrscheinlichkeit 1/2 wählen wir diese und gehen von i nach i+1
*** mit Wahrscheinlichkeit 1/2 wählen wir die andere und gehen von i nach i-1

schlechtester Fall: Es existiert keine Lösung <math>x^*</math> und wir haben immer Fall 2
: =>RW braucht <math>O(N^2 - i^2)</math> Schritte zum Stuhl N <math>\mathrel{\hat=} O(N^2)</math> falls i anfangs zufällig ist

==== Alg. 2 (det. Alg. für k=2 mittels SZK in gerichtetem Graphen) ====
: geg.: Ausdruck 2-CNF
* (1) wandle nach INF: ersetze jede Klausel <math>(x_i \or x_j)</math> durch <math>(\lnot x_i \Rightarrow x_j) \and (\lnot x_j \Rightarrow x_i)</math>
: (entsprechend, wenn in Originalklausel <math>\lnot</math> vorkommen)
* (2) repräsentiere den Ausdruck als Graph:
** (a) 2 Knoten pro Var:<math>v_i \mathrel{\hat=} x_i , v_{i+N} \mathrel{\hat=} \lnot x_i </math>
** (b) Verbindung für jede Implikation durch korrespondierenden Knoten durch gerichtete Kante

Bsp.:
<math>C_1 \and C_2 \Leftrightarrow (\lnot x_1 \Rightarrow x_2 ) \and (\lnot x_2 \Rightarrow x_1) \and (x_2 \Rightarrow x_3) \and (\lnot x_3 \Rightarrow \lnot x_2)</math>

* (3) Prüfe ob der Ausdruck erfüllbar ist. Bilde SZK des Graphen
: '''Satz''': Ausdruck erfüllbar <math>\Leftrightarrow \forall</math>i: <math> v_i</math> und <math>v_{i+N}</math> sind in verschiedenen Komponenten

Beweis: in jeder SZK gilt: <math>u,v \in SZK: \exists u \rightsquigarrow v und v \rightsquigarrow u</math>
: Kanten <math>\to</math> Implikationen, Implikationen sind transitiv
: <math>\Rightarrow u \rightsquigarrow v \mathrel{\hat=} u \to v </math>           <math>\to u \leftrightarrow v</math>   bzw.   u == v
:: <math> v \rightsquigarrow u \mathrel{\hat=} v \to u </math>
: <math>\Rightarrow</math> alle Knoten in einer SZK haben den gleichen Wahrheitswert true oder false
: aber <math>v_i</math> und <math>v_{i+N} \mathrel{\hat=} x_i</math> und <math>\lnot x_i</math> haben immer verschiedene Werte
: <math>\Rightarrow v_i</math> und <math>v_{i+N}</math> dürfen nicht in selber SZK sein, andernfalls fordert der Graph <math>x_i == \lnot x_i</math>, was unmöglich ist.

* (4) Bilde den Komponentengraphen <math>\to</math> azyklisch (zu jedem Knoten existiert Komplementärknoten mit negierter Variable)[jede SZK in je 1 Knoten kontrahieren]
** (b) bestehende topologische Sortierung
** (c) gehe in topologischer Sortierung von hinten nach vorne
*** (I) wenn aktueller Knoten noch keinen Wert hat: setze ihn auf true und Komplementoren false
*** (II) sonst: überspringe Knoten

Beweis, dass ein Problem aus NP auch NP-vollständig ist
* Möglichkeit 1: z.B. 3-SAT (Satz von Cook): mühsam, aber mindestens für ein Problem unbermeidbar (für erstes)
* Möglichkeit 2: zeige dass jedes Problem vom Typ A in eines von Typ B umwandelbar (in pol. Zeit)
** <math>\Rightarrow</math> Problem Type B nicht einfacher als Typ A
** falls Typ A NP-vollständig <math>\Rightarrow</math> Typ B auch

==== Anwendung auf TSP ====
3-SAT <math>\le</math> Hamiltonzyklus im gerichteten Graph <math>\le</math> Hamiltonzyklus im ungerichteten Graph <math>\le</math> TSP im gerwichteten ungerichteten Graph

NP-Vollständigkeit

2017-08-03T15:05:17Z

Alda: /* Alg. 2 (det. Alg. für k=2 mittels SZK in gerichtetem Graphen) */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden.
: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

=== k-SAT, k=2 in pol. Zeit lösbar ===

==== Alg. 1 ====
(f. bei k) (nur für k=2 effizient) '''Randomisiert'''
* (0) initialisiere <math>x_i</math> beliebig
* (1) wiederhole <math>T_{max}</math> - mal
** (a) wenn das aktuelle x den Ausdruck erfüllt: return x (x=[<math> x_1</math>, ... , <math>x_N</math>])
** (b) wähle zufällig eine Klausel, die nicht erfüllt ist
** (c) wähle in dieser Klausel zufällig eine der k Variablen und invertiere sie => Klausel ist jetzt erfüllt
::: (andere können jetzt false geworden sein)
::: (<math>x_1 \or x_2 ) \and ( x_1 \or \lnot x_2 )</math>      <math> x_1 = 0, x_2 = 0,</math>      <math> x_2</math> auf 1 => 1. Klausel wahr, 2. falsch
* (2) return "keine Lösung gefunden"

Nach wie vielen Iterationen wird im Mittel eine Lösung gefunden?
* Ausdruck unerfüllbar => Endlosschleife, Timeout nach <math>T_{max}</math> Iterationen
* Ausrduck erfüllbar:
** falls k<math>\geq</math>3: nach <math>O((\frac{2(k-1)}{k})^N)</math> Iterationen wird Lösung gefunden
** k=3: <math>O((\frac{4}{3})^N)</math> exponentielle Zeit, wie zu erwarten für NP-vollständiges Problem
** k=2: <math>O(N^2)</math> Iterationen bis Lösung

Beweis: Algorithmus entspricht im Wesentlichen dem '''Random Walk'''
: Sei <math>x^*</math> die korrekte Lösung und x die aktuelle Belegung
: RW: Stuhl i <math>\mathrel{\hat=}</math> i Variablen zwischen <math>x^*</math> und x stimmen überein => Ziel: erreiche Stuhl N
* (c):
** Fall 1: beide Variablen falsch => egal welche wir invertieren, bewegen wir uns von Stuhl i zu i+1
** Fall 2: eine Variable ist falsch:
*** mit Wahrscheinlichkeit 1/2 wählen wir diese und gehen von i nach i+1
*** mit Wahrscheinlichkeit 1/2 wählen wir die andere und gehen von i nach i-1

schlechtester Fall: Es existiert keine Lösung <math>x^*</math> und wir haben immer Fall 2
: =>RW braucht <math>O(N^2 - i^2)</math> Schritte zum Stuhl N <math>\mathrel{\hat=} O(N^2)</math> falls i anfangs zufällig ist

==== Alg. 2 (det. Alg. für k=2 mittels SZK in gerichtetem Graphen) ====
: geg.: Ausdruck 2-CNF
* (1) wandle nach INF: ersetze jede Klausel <math>(x_i \or x_j)</math> durch <math>(\lnot x_i \Rightarrow x_j) \and (\lnot x_j \Rightarrow x_i)</math>
: (entsprechend, wenn in Originalklausel <math>\lnot</math> vorkommen)
* (2) repräsentiere den Ausdruck als Graph:
** (a) 2 Knoten pro Var:<math>v_i \mathrel{\hat=} x_i , v_{i+N} \mathrel{\hat=} \lnot x_i </math>
** (b) Verbindung für jede Implikation durch korrespondierenden Knoten durch gerichtete Kante

Bsp.:
<math>C_1 \and C_2 \Leftrightarrow (\lnot x_1 \Rightarrow x_2 ) \and (\lnot x_2 \Rightarrow x_1) \and (x_2 \Rightarrow x_3) \and (\lnot x_3 \Rightarrow \lnot x_2)</math>

* (3) Prüfe ob der Ausdruck erfüllbar ist. Bilde SZK des Graphen
: '''Satz''': Ausdruck erfüllbar <math>\Leftrightarrow \forall</math>i: <math> v_i</math> und <math>v_{i+N}</math> sind in verschiedenen Komponenten

Beweis: in jeder SZK gilt: <math>u,v \in SZK: \exists u \rightsquigarrow v und v \rightsquigarrow u</math>
: Kanten <math>\to</math> Implikationen, Implikationen sind transitiv
: <math>\Rightarrow u \rightsquigarrow v \mathrel{\hat=} u \to v </math>           <math>\to u \leftrightarrow v</math>   bzw.   u == v
:: <math> v \rightsquigarrow u \mathrel{\hat=} v \to u </math>
: <math>\Rightarrow</math> alle Knoten in einer SZK haben den gleichen Wahrheitswert true oder false
: aber <math>v_i</math> und <math>v_{i+N} \mathrel{\hat=} x_i</math> und <math>\lnot x_i</math> haben immer verschiedene Werte
: <math>\Rightarrow v_i</math> und <math>v_{i+N}</math> dürfen nicht in selber SZK sein, andernfalls fordert der Graph <math>x_i == \lnot x_i</math>, was unmöglich ist.

NP-Vollständigkeit

2017-08-03T14:30:33Z

Alda: /* Alg. 2 det. Alg. für k=2 mittels SZK in gerichtetem Graphen */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden.
: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

=== k-SAT, k=2 in pol. Zeit lösbar ===

==== Alg. 1 ====
(f. bei k) (nur für k=2 effizient) '''Randomisiert'''
* (0) initialisiere <math>x_i</math> beliebig
* (1) wiederhole <math>T_{max}</math> - mal
** (a) wenn das aktuelle x den Ausdruck erfüllt: return x (x=[<math> x_1</math>, ... , <math>x_N</math>])
** (b) wähle zufällig eine Klausel, die nicht erfüllt ist
** (c) wähle in dieser Klausel zufällig eine der k Variablen und invertiere sie => Klausel ist jetzt erfüllt
::: (andere können jetzt false geworden sein)
::: (<math>x_1 \or x_2 ) \and ( x_1 \or \lnot x_2 )</math>      <math> x_1 = 0, x_2 = 0,</math>      <math> x_2</math> auf 1 => 1. Klausel wahr, 2. falsch
* (2) return "keine Lösung gefunden"

Nach wie vielen Iterationen wird im Mittel eine Lösung gefunden?
* Ausdruck unerfüllbar => Endlosschleife, Timeout nach <math>T_{max}</math> Iterationen
* Ausrduck erfüllbar:
** falls k<math>\geq</math>3: nach <math>O((\frac{2(k-1)}{k})^N)</math> Iterationen wird Lösung gefunden
** k=3: <math>O((\frac{4}{3})^N)</math> exponentielle Zeit, wie zu erwarten für NP-vollständiges Problem
** k=2: <math>O(N^2)</math> Iterationen bis Lösung

Beweis: Algorithmus entspricht im Wesentlichen dem '''Random Walk'''
: Sei <math>x^*</math> die korrekte Lösung und x die aktuelle Belegung
: RW: Stuhl i <math>\mathrel{\hat=}</math> i Variablen zwischen <math>x^*</math> und x stimmen überein => Ziel: erreiche Stuhl N
* (c):
** Fall 1: beide Variablen falsch => egal welche wir invertieren, bewegen wir uns von Stuhl i zu i+1
** Fall 2: eine Variable ist falsch:
*** mit Wahrscheinlichkeit 1/2 wählen wir diese und gehen von i nach i+1
*** mit Wahrscheinlichkeit 1/2 wählen wir die andere und gehen von i nach i-1

schlechtester Fall: Es existiert keine Lösung <math>x^*</math> und wir haben immer Fall 2
: =>RW braucht <math>O(N^2 - i^2)</math> Schritte zum Stuhl N <math>\mathrel{\hat=} O(N^2)</math> falls i anfangs zufällig ist

==== Alg. 2 (det. Alg. für k=2 mittels SZK in gerichtetem Graphen) ====
: geg.: Ausdruck 2-CNF
* (1) wandle nach INF: ersetze jede Klausel <math>(x_i \or x_j)</math> durch <math>(\lnot x_i \Rightarrow x_j) \and (\lnot x_j \Rightarrow x_i)</math>
: (entsprechend, wenn in Originalklausel <math>\lnot</math> vorkommen)
* (2) repräsentiere den Ausdruck als Graph:
** (a) 2 Knoten pro Var:<math>v_i \mathrel{\hat=} x_i , v_{i+N} \mathrel{\hat=} \lnot x_i </math>
** (b) Verbindung für jede Implikation durch korrespondierenden Knoten durch gerichtete Kante

Bsp.:
<math>C_1 \and C_2 \Leftrightarrow (\lnot x_1 \Rightarrow x_2 ) \and (\lnot x_2 \Rightarrow x_1) \and (x_2 \Rightarrow x_3) \and (\lnot x_3 \Rightarrow \lnot x_2)</math>

* (3) Prüfe ob der Ausdruck erfüllbar ist. Bilde SZK des Graphen
: '''Satz''': Ausdruck erfüllbar <math>\Leftrightarrow \forall</math>i: <math> v_i</math> und <math>v_{i+N}</math> sind in verschiedenen Komponenten

Beweis: in jeder SZK gilt:

NP-Vollständigkeit

2017-08-01T14:22:21Z

Alda: /* k-SAT, k=2 in pol. Zeit lösbar */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden.
: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

=== k-SAT, k=2 in pol. Zeit lösbar ===

==== Alg. 1 ====
(f. bei k) (nur für k=2 effizient) '''Randomisiert'''
* (0) initialisiere <math>x_i</math> beliebig
* (1) wiederhole <math>T_{max}</math> - mal
** (a) wenn das aktuelle x den Ausdruck erfüllt: return x (x=[<math> x_1</math>, ... , <math>x_N</math>])
** (b) wähle zufällig eine Klausel, die nicht erfüllt ist
** (c) wähle in dieser Klausel zufällig eine der k Variablen und invertiere sie => Klausel ist jetzt erfüllt
::: (andere können jetzt false geworden sein)
::: (<math>x_1 \or x_2 ) \and ( x_1 \or \lnot x_2 )</math>      <math> x_1 = 0, x_2 = 0,</math>      <math> x_2</math> auf 1 => 1. Klausel wahr, 2. falsch
* (2) return "keine Lösung gefunden"

Nach wie vielen Iterationen wird im Mittel eine Lösung gefunden?
* Ausdruck unerfüllbar => Endlosschleife, Timeout nach <math>T_{max}</math> Iterationen
* Ausrduck erfüllbar:
** falls k<math>\geq</math>3: nach <math>O((\frac{2(k-1)}{k})^N)</math> Iterationen wird Lösung gefunden
** k=3: <math>O((\frac{4}{3})^N)</math> exponentielle Zeit, wie zu erwarten für NP-vollständiges Problem
** k=2: <math>O(N^2)</math> Iterationen bis Lösung

Beweis: Algorithmus entspricht im Wesentlichen dem '''Random Walk'''
: Sei <math>x^*</math> die korrekte Lösung und x die aktuelle Belegung
: RW: Stuhl i <math>\mathrel{\hat=}</math> i Variablen zwischen <math>x^*</math> und x stimmen überein => Ziel: erreiche Stuhl N
* (c):
** Fall 1: beide Variablen falsch => egal welche wir invertieren, bewegen wir uns von Stuhl i zu i+1
** Fall 2: eine Variable ist falsch:
*** mit Wahrscheinlichkeit 1/2 wählen wir diese und gehen von i nach i+1
*** mit Wahrscheinlichkeit 1/2 wählen wir die andere und gehen von i nach i-1

schlechtester Fall: Es existiert keine Lösung <math>x^*</math> und wir haben immer Fall 2
: =>RW braucht <math>O(N^2 - i^2)</math> Schritte zum Stuhl N <math>\mathrel{\hat=} O(N^2)</math> falls i anfangs zufällig ist

==== Alg. 2 det. Alg. für k=2 mittels SZK in gerichtetem Graphen ====
: geg.: Ausdruck 2-CNF
* (1) wandle nach INF: ersetze jede Klausel <math>(x_i \or x_j)</math> durch <math>(\lnot x_i \Rightarrow x_j) \and (\lnot x_j \Rightarrow x_i)</math>
: (entsprechend, wenn in Originalklausel <math>\lnot</math> vorkommen)
* (2) repräsentiere den Ausdruck als Graph:
** (a) 2 Knoten pro Var:

NP-Vollständigkeit

2017-08-01T13:48:19Z

Alda: /* Alg. 1 */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden.
: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

=== k-SAT, k=2 in pol. Zeit lösbar ===

==== Alg. 1 ====
(f. bei k) (nur für k=2 effizient) '''Randomisiert'''
* (0) initialisiere <math>x_i</math> beliebig
* (1) wiederhole <math>T_{max}</math> - mal
** (a) wenn das aktuelle x den Ausdruck erfüllt: return x (x=[<math> x_1</math>, ... , <math>x_N</math>])
** (b) wähle zufällig eine Klausel, die nicht erfüllt ist
** (c) wähle in dieser Klausel zufällig eine der k Variablen und invertiere sie => Klausel ist jetzt erfüllt
::: (andere können jetzt false geworden sein)
::: (<math>x_1 \or x_2 ) \and ( x_1 \or \lnot x_2 )</math>      <math> x_1 = 0, x_2 = 0,</math>      <math> x_2</math> auf 1 => 1. Klausel wahr, 2. falsch
* (2) return "keine Lösung gefunden"

NP-Vollständigkeit

2017-08-01T13:47:22Z

Alda: /* Die Problemklassen P und NP */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden.
: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

=== k-SAT, k=2 in pol. Zeit lösbar ===

== Alg. 1 ==
(f. bei k) (nur für k=2 effizient) '''Randomisiert'''
* (0) initialisiere <math>x_i</math> beliebig
* (1) wiederhole <math>T_{max}</math> - mal
** (a) wenn das aktuelle x den Ausdruck erfüllt: return x (x=[<math> x_1</math>, ... , <math>x_N</math>])
** (b) wähle zufällig eine Klausel, die nicht erfüllt ist
** (c) wähle in dieser Klausel zufällig eine der k Variablen und invertiere sie => Klausel ist jetzt erfüllt
::: (andere können jetzt false geworden sein)
::: (<math>x_1 \or x_2 ) \and ( x_1 \or \lnot x_2 )</math>      <math> x_1 = 0, x_2 = 0,</math>      <math> x_2</math> auf 1 => 1. Klausel wahr, 2. falsch
* (2) return "keine Lösung gefunden"

NP-Vollständigkeit

2017-07-25T19:07:21Z

Alda: /* 3-SAT ist NP vollständig */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden.
: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T19:07:02Z

Alda: /* Die Problemklassen P und NP */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:
: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T11:21:04Z

Alda: /* Erfüllbarkeitsproblem */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.

{| cellspacing="0" border="1"
|- style="text-align:center;background-color:#ffffcc;width:50px"
|width="70px"| <math>x_1</math>
|width="70px"| <math>x_2</math>
|width="70px"| <math>x_1 \or x_2</math>
|width="70px"| <math>x_1 \implies x_2</math>
|width="70px"| <math>\lnot x_1 \implies x_2 (A)</math>
|width="70px"| <math>\lnot x_2 \implies x_1 (B)</math>
|width="70px"| <math>A \and B</math>
|- align="center"
| 0 || 0 || 0 || 1 || 0 || 0 || 0
|- align="center"
| 0 || 1 || 1 || 1 || 1 || 1 || 1
|- align="center"
| 1 || 0 || 1 || 0 || 1 || 1 || 1
|- align="center"
| 1 || 1 || 1 || 1 || 1 || 1 || 1
|}



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:

: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T11:13:45Z

Alda: /* Erfüllbarkeitsproblem */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren

2-CNF: wie 3-CNF, nur 2 Variablen pro Klausel
<math>\implies</math> effiziente Alg existieren, aber nicht jeder logische Ausdruck in 2-CNF transformierbar.
: z.B. Heim-Auswärtsproblem

INF (Implikationen-NF):
* 2 Variablen pro Klausel, Operatoren <math> \implies und \lnot </math>
* Klauseln mit <math> \and </math> verknüpft.

Satz: jede 2-CNF effizient in INF umwandelbat.
: <math> ( x_i \or x_j ) \rightsquigarrow ( \lnot x_i \implies x_j ) \and ( \lnot x_j \implies x_i )
</math>
<math>\implies</math> INF als gerichteter Graph schreibbar und mittels starker Zusammenhangskomponenten lösbar.



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:

: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T10:40:21Z

Alda: /* Einleitung */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage Y und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei Y impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:

: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T10:39:00Z

Alda: /* Erfüllbarkeitsproblem */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage > und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei > impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>
: Frage: Kann man X so belegen, dass Y wahr ist?
: <math>\rightarrow</math> Nein, nur möglich wenn es nur 2 Mannschaften gibt und diese abwechselnd gegeneinander antreten.

Normalformen für logische Ausdrücke zur Vereinfachung und Systematisierung
* 3-CNF (Konjunktionen-NF)
** jede Klausel enthält max 3 Variablen (genau 3 mit dummy Variablen)
** jede Klausel enthält nur <math> \or </math> und <math> /lnot </math>
** alle Klauseln sind durch <math> \and </math> verknüpft.
z.B. <math> ( x_1 \or x_2 \or \lnot x_4 ) \and ( \lnot x_2 \or x_3 \or x_4) \and (...) \and </math>

<math> \Rightarrow </math> Ausdruck ist wahr, wenn jede Klausel wahr ist.
: In jeder Klausel hat man 3 Chancen die Klausel wahr zu machen.
: Aber: Klauseln können sich widersprechen und nicht erfüllbar sein!

Satz: Jeder logische Ausdruck effizient (in pol. Zeit) in 3-CNF umwandelbar.

Satz v. Cook: 3-SAT (Erfüllbarkeitsproblem für Ausdrücke in 3-CNF) ist NP-vollständig

zur Zeit ist kein effizienterer Algorithmus bekannt, als im schlechtesten Fall alle <math>2^N</math> Belegungen von {<math>x_i</math>} auszuprobieren



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:

: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T09:44:53Z

Alda: /* Erfüllbarkeitsproblem */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage > und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei > impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>
: Alle Bedingungen sollen gleichzeitig Erfüllt sein:
:: <math>y = \begin{cases} (x_{11} \neq x_{21}) \and (x_{31} \neq x_{41}) \and ... \\
( x_{12} \neq x_{32} ) \and ... \\
( x_{11} \neq x_{12} ) \and ( x_{12} \neq x_{13} ) \and ...
\end{cases}</math>



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:

: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T09:26:14Z

Alda: /* Erfüllbarkeitsproblem */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage > und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei > impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\lnot</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\lnot</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern: [[Image:Bild 11.jpg]]
: Jede logische Schaltung kann als SAT-Ausdruck geschrieben werden.
* Bsp.: Zuordnung von Heim und Auswärtsspielen beim Fußball
: <math>x_{it} = \begin{cases}
true, & \mbox{Mannschaft i hat am Spieltag t Heimspiel} \\
false, & \mbox{Mannschaft i hat am Spieltag t Auswärtsspiel}
\end{cases}
</math>
: 1. Nebenbedingung: spielt Mannschaft i am Spieltag t gegen Mannschaft j, muss gelten <math> x_{it} = \lnot x_{jt}</math>
: 2. Nebenbedingung: Jede Mannschaft spielt gegen jede
: 3. Nebenbedingung: Jede Mannschaft spielt abwechselnd Heim und auswärts <math> x_{it} \neq x_{i(t+1)} </math>



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:

: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T08:46:35Z

Alda: /* Die Problemklassen P und NP */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage > und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei > impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\in</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\not</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\not</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern
[[Image:Bild 11.jpg]]



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:

: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T08:44:35Z

Alda: /* Einleitung */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage > und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei > impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.

=== Erfüllbarkeitsproblem ===
(SAT-satisfyability) ist das kanonische NP-Vollständige Problem (Satz von Cook 1971)
*boolsche Variable x1 <math>\element</math>{true, false}, i=1,...,N (Problemgröße N-Bits)
*logische Ausdrücke Y über X mit Operatoren <math>\not</math>, <math>\and</math>, <math>\or</math>, <math>\implies</math>, <math>\leftrightarrow</math>, <math>\neq</math>, ()
: z.B. N= 3, Y=(x1<math>\or</math>x2)<math>\and</math>(<math>\not</math>x1<math>\or</math>x2) <math>\implies</math> Z=(true[x1], true[x2], true[x3])

* Entscheidungsfrage: Gibt es eine Belegung con X sodass Y wahr ist?
* Bei komplizierten Problemen ist kein besserer Algorithmus bekannt als alle <math>\2^N</math> Möglichkeiten zu probieren.
*Jede CPU kann als logische Schaltung geschrieben werden (damit auch jedes while-Programm)
: Mit Gattern



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:

[[Image:Bild 11.jpg]]

: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T08:31:22Z

Alda: /* Einleitung */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage > und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei > impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"

: <math>\uparrow</math> ineffizient, da es meist exponentiell viele Kandidaten Z gibt.



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:

[[Image:Bild 11.jpg]]

: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T08:28:45Z

Alda: /* Einleitung */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?
: Orakel: "Rundreise Z ist <math>\le</math>200kM" <math>\implies</math>leicht & effizient zu testen

Klassische Definition von NP: Probleme die von einer nicht-deterministischen Turingmaschine gelöst werden können (N = Nicht deterministisch, P = Polynomiell).
: nicht deterministische Turingmaschine: formale Definition kompliziert <math>\rightarrow</math> Theoretische Informatik
:: anschaulich: TM kann in kritischen Situationen das Orakel fragen und sich vorsagen lassen

moderne Definition: "polynomiell Verifizierbar": es gibt effizienten Algorithmus, der für Probleme X und Entscheidungsfrage > und Kandidatenlösung Z entscheidet, ob Z eine "ja-Antwort" bei > impliziert.
: Fall 1: korrekte Antwort auf Y ist "ja" (wissen wir aber nicht): <math>\exist</math>z: V(X, Y, Z) <math>\implies</math> OK
:: Z ist Beweis (proof/witness/certificate) dafür, dass Y die Antwort "ja" hat
:: liefert V(X, Y, Z) <math>\implies</math> falsch, ist Z kein Beweis und wir wissen noch nicht, ib Y mit "ja" oder "nein" zu beantworten ist.
: Fall 2: korrekte Antwort auf Y ist "nein": <math>\forall</math>Z V(X, Y, Z) <math>\implies</math> falsch
: <math>\implies</math> hat man einen Überprüfungsalgorithmus V, kann man X mit Y stets duch erschöpfende Suche ("brute-force") lösen

: für jede mögliche Kandidatenlösung Z:
:: falls V(X, Y, Z) <math>\implies</math> ok:
:::return "ja"
:: return "nein"



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:

[[Image:Bild 11.jpg]]

: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.

NP-Vollständigkeit

2017-07-25T08:06:05Z

Alda: /* Einleitung */

== Das Problem des Handlungsreisenden ==
'''(engl.: Traveling Salesman Problem; abgekürzt: TSP)'''<br\>
[http://de.wikipedia.org/wiki/Problem_des_Handlungsreisenden Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]
[[Image:TSP_Deutschland_3.PNG|thumb|200px|right|Optimaler Reiseweg eines Handlungsreisenden([http://de.wikipedia.org/w/index.php?title=Bild:TSP_Deutschland_3.PNG&filetimestamp=20070110124506 Quelle])]]

*Eine der wohl bekanntesten Aufgabenstellungen im Bereich der Graphentheorie ist das Problem des Handlungsreisenden.
*Hierbei soll ein Handlungsreisender nacheinander ''n'' Städte besuchen und am Ende wieder an seinem Ausgangspunkt ankommen. Dabei soll jede Stadt nur einmal besucht werden und der Weg mit den minimalen Kosten gewählt werden.
*Alternativ kann auch ein Weg ermittelt werden, dessen Kosten unter einer vorgegebenen Schranke liegen.

:''gegeben'': zusammenhängender, gewichteter Graph (oft vollständiger Graph)
:''gesucht'': kürzester Weg, der alle Knoten genau einmal (falls ein solcher Pfad vorhanden) besucht (und zum Ausgangsknoten zurückkehrt)<br\>

:auch genannt: kürzester Hamiltonkreis
::- durch psychologische Experimente wurde herausgefunden, dass Menschen (in 2D) ungefähr proportionale Zeit zur Anzahl der Knoten brauchen, um einen guten Pfad zu finden, der typischerweise nur <math>\lesssim 5%</math> länger als der optimale Pfad ist<br\>
:''vorgegeben'': Startknoten (kann willkürlich gewählt werden), vollständiger Graph

::::: => v-1 Möglichkeiten für den ersten Nachfolgerknoten => je v-2 Möglichkeiten für dessen Nachfolger...
:::::also <math>\frac{(v-1)!}{2}</math> mögliche Wege in einem vollständigen Graphen

*Ein naiver Ansatz zur Lösung des TSP Problems ist das erschöpfende Durchsuchen des Graphen, auch "brute force" Algorithmus ("mit roher Gewalt"), indem alle möglichen Rundreisen betrachtet werden und schließlich die mit den geringsten Kosten ausgewählt wird.
*Dieses Verfahren versagt allerdings bei größeren Graphen, aufgrund der hohen Komplexität.

=== Approximationsalgorithmus ===

Für viele Probleme in der Praxis sind keine effizienten Algorithmen bekannt
(NP-schwer). Diese (z.B. TSP) werden mit Approximationsalgorithmen berechnet,
die effizient berechenbar sind, aber nicht unbedingt die optimale
Lösung liefern. Beispielsweise ist es relativ einfach, eine Tour zu finden, die höchstens um den Faktor zwei länger ist als die optimale Tour. Die Methode beruht darauf, dass einfach der minimale Spannbaum ermittelt wird.

'''Approximationsalgorithmus für TSP'''<br\>
* TSP für ''n'' Knoten sei durch Abstandsmatrix D = <math>(d_{ij}) 1 \le i, j \le n</math>
:gegeben (vollständiger Graph mit ''n'' Knoten, <math>d_{ij}</math> = Kosten der Kante (i,j)) <br\>
:''gesucht:'' Rundreise mit minimalen Kosten. Dies ist NP-schwer!<br\>
* D erfüllt die Dreiecksungleichung <math> \Leftrightarrow d_{ij} + d_{jk} \geq d_{ik} \text{ fuer } \forall{i, j, k} \in \lbrace 1, ..., n \rbrace</math> <br\>
* Dies ist insbesondere dann erfüllt, wenn D die Abstände bezüglich einer Metrik darstellt oder D Abschluss einer beliebigen Abstandsmatrix C ist, d.h. :<math>d_{ij}</math> = Länge des kürzesten Weges (bzgl. C) von i nach j.

*Die ”Qualität”der Lösung mit einem Approximationsalgorithmus ist höchstens um einen konstanten Faktor schlechter ist als die des Optimums.

=== Systematisches Erzeugen aller Permutationen ===
*Allgemeines Verfahren, wie man von einer gegebenen Menge verschiedene Schlüssel - in diesem Fall: Knotennummern - sämtliche Permutationen systematisch erzeugen kann. <br\>
*'''Trick''': interpretiere jede Permutation als Wort und betrachte dann deren lexikographische ("wie im Lexikon") Ordnung.<br\>
*Der erste unterschiedliche Buchstabe unterscheidet. Wenn die Buchstaben gleich sind, dann kommt das kürzere Wort zuerst.

''gegeben'': zwei Wörter a, b der Länge n=len(a) bzw. m=len(b). Sei k = min(n,m) (im Spezialfall des Vergleichs von Permutationen gilt k = n = m)<br\>
Mathematische Definition, wie die Wörter im Wörterbuch sortiert sind: <br\>
:::<math>a<b \Leftrightarrow
\begin{cases}
n < m & \text{ falls fuer } 0 \le i \le k-1 \text{ gilt: } a[i] = b[i] \\
a[j] < b[j] & \text{ falls fuer } 0 \le i \le j-1 \text{ gilt: } a[i] = b[i], \text{ aber fuer ein } j<k: a[j] \ne b[j]
\end{cases}</math><br\>

Algorithmus zur Erzeuguung aller Permutationen:
# beginne mit dem kleinsten Wort bezüglich der lexikographischen Ordnung => das ist das Wort, wo a aufsteigend sortiert ist
# definiere Funktion "next_permutation", die den Nachfolger in lexikographischer Ordnung erzeugt

Beispiel: Die folgenden Permutationen der Zahlen 1,2,3 sind lexikographisch geordnet

1 2 3 6 Permutationen, da 3! = 6
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
-----
0 1 2 Position

Die lexikographische Ordnung wird deutlicher, wenn wir statt dessen die Buchstaben a,b,c verwenden:

abc
acb
bac
bca
cab
cba

Eine Funktion, die aus einer gegebenen Permutation die in lexikographischer Ordnung nächst folgende erzeugt, kann wie folgt implementiert werden:

def next_permutation(a):
i = len(a) -1 #letztes Element; man arbeitet sich von hinten nach vorne durch
while True: # keine Endlosschleife, da i dekrementiert wird und damit irgendwann 0 wird
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexikogr. Nachfolger hat größeres a[i]
j = len(a)
while True:
j -= 1
if a[i] < a[j]: break
a[i], a[j] = a[j], a[i] #swap a[i], a[j]
#sortiere aufsteigend zwischen a[i] und Ende
#zur Zeit absteigend sortiert => invertieren
i += 1
j = len(a) -1
while i < j:
a[i], a[j] = a[j], a[i]
i += 1
j-= 1
return True # eine weitere Permutation gefunden

def naiveTSP(graph):
start = 0
result = range(len(graph))+[start]
rest = range(1,len(graph))
c = pathCost(result, graph)
while next_permutation(rest):
r = [start]+rest+[start]
cc = pathCost(r, graph)
if cc < c:
c = cc
result = r
return c, result

'''Komplexität''': <math>(v-1)!</math> Schleifendurchläufe (=Anzahl der Permutationen, da die Schleife abgebrochen wird, sobald es keine weiteren Permutationen mehr gibt), also
<math>O(v!) = O(v^v)</math>

;Beispiel:
{|
|-
| | i = 0 || | ||| ||| j = 3 ||

|-
|| ↓ || || || ↓ ||

|-

| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 2 || #input für next_permutation
|-
|-

|| || i = 2 || || j = 3 ||

|-
|| || ↓|| || ↓ ||
|-

|-
| style="background:silver; color:white" | 2 ||style="background:silver; color:white" | 4 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 1|| # vertauschen der beiden Elemente
|-
|-

|| || ||i = 2 || ||
|-
|| || ||j = 2 || ||

|-
|| || || ↓|| ||

|-
| style="background:silver; color:white" | 1 ||style="background:silver; color:white" | 2 ||style="background:silver; color:white"| 3 ||style="background:silver; color:white" | 4|| #absteigend sortiert
|}

=== Stirling'sche Formel ===
[http://de.wikipedia.org/wiki/Stirling-Formel Wikipedia (de)]
[http://en.wikipedia.org/wiki/Stirling%27s_approximation (en)]

Die Stirling-Formel ist eine mathematische Formel, mit der man für große Fakultäten Näherungswerte berechnen kann. Die Stirling-Formel findet überall dort Verwendung, wo die exakten Werte einer Fakultät nicht von Bedeutung sind. Damit lassen sich durch die Stirling'sche Formel z.T. starke Vereinfachungen erzielen.
<math>v! \approx \sqrt{2 \pi v} \left(\frac{v}{e}\right)^v</math>
: <math>O(v!) = O\left(\sqrt{v}\left(\frac{v}{e}\right)^v\right) \approx O(v^v)</math>

=== 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.

== Die Problemklassen P und NP ==

*für viele Probleme kein effizienter Algorithmus bekannt (effizient = polynomielle Komplexität
: O(<math>n^p</math>), für ein beliebig großes festes D; nicht effizient: langsamer als polynomiell,
: z.b. O(<math>2^N</math>))

Bsp:
*Problem des Handlungsreisenden
*Steine Bäume verallg. MST: man darf zusätzliche Punkte hinzufügen
*Clique - Problem: Clique in Graph G: maximaler vollständiger Teilgraph, trivial: 2 Kinder (gibt es eine Clique mit k Mitgliedern?)
*Integer Linear Programming <math>\hat{x}</math> = arg max <math>c^T</math>x [c,x Spaltenvektoren der Länge N]
: (s.t. A*x <math>\leq</math> b [A, Matrix MxN, b Spaltenvektor von M]
: x<math>\in \mathbb{N}^N, \mathbb{Z}^N</math>, {0, 1}<math>^N</math> <math>\implies</math> nicht effizient
: x<math>\in \mathbb{R}^N \implies</math> effizient)

=== Einleitung ===
*Komplexitätsklasse P: Effiziente Lösung bekannt (sortieren, MST, Dijkstra)

*Komplexitätsklasse NP: Existiert ein effizienter Algorithmus um einen '''geratenen''' Lösungsvorschlag zu überprüfen.
: geraten durch "Orakel" -> Black Box, nicht bekannt wie!
: offensichtlich gilt P<math>\subset</math>NP (bekannter Lösungsalgorithmus kann immer als Orakel dienen). Offen ob:
:: -P<math>\subset</math>NP (es gibt Probleme ohne effizienten Alg)
:: -oder P=NP (effizienter Algorithmus nur noch nicht entdeckt)

*Komplexitätsklasse NP-Vollständig (NP-C [complete]): Schwierigste Probleme in NP, wenn Q<math>\in</math>NP-C kann man mit Algorithmus für Q indirekt auch jedes andere Problem in NP lösen
: R<math>\in</math>NP <math>\rightsquigarrow</math>Q(R)<math>\in</math>NP-C (Reduktion)
:: <math>\downarrow</math>
: Lösung (R) <math>\rightsquigarrow</math> Lösung Q(R)
: Reduktion muss effizient funktionieren, d.h. O(<math>\N^D</math>)

*Komplexitätsklasse NP-Schwer (NP-hard): mindestens so schwer wie NP-C, aber nicht unbedingt <math>\in</math>NP
[[Image:DiagramNP.jpg]] Vereinfachung: NP enthält nur Entscheigungsprobleme: Fragen mit Ja/Nein-Antwort.
::::: z.B.
::::: TSP-Optimierungsproblem (NP-Schwer):
:::::: gegeben: gewichteter Graph
:::::: gesucht: kürzeste Rundreise
::::: TSP-Entscheidungsproblem (NP-Vollständig):
:::::: gegeben: gewichteter Graph
:::::: <math>\exist</math>Rundreise <math>\le</math> 200kM, ist das wahr oder falsch?



=== 3-SAT ist NP vollständig ===
Skizze des Beweises:
# Unsere Algorithmen können auf einer Turingmaschine ausgeführt werden (äquivalent zur Turingmaschine: λ-Kalkül, while-Programm usw.)
# Die Turingmaschine und ein gegebenes (festes) Programm können als logische Schaltung (Schaltnetz) implementiert werden, „Algorithmus in Hardware gegossen“
# Jedes Schaltnetzwerk kann als logische Formel geschrieben werden, z.B.:

[[Image:Bild 11.jpg]]

: 4. Jede logische Formel kann in 3-CNF umgewandelt werden

:=> Jedes algorithmische Entscheidungsproblem kann als 3-SAT-Problem geschrieben werden.