Alda - User contributions [en]

Sortieren

2010-08-18T15:24:17Z

Jschleic: /* Datenspeicherung */ typo

----
== Laufzeitmessung in Python ==

Verwendung der '''timeit-Bibliothek''' für die Hausaufgabe.

* Importiere das timeit-Modul: <tt>import timeit</tt>
* Teile den Algorithmus in die Initialisierungen und den Teil, dessen Geschwindigkeit gemessen werden soll. Beide Teile werden in jeweils einen (mehrzeiligen) String eingeschlossen:

+--------+ +----+ setup = """ prog = """
| algo | --> |init| +----+ +----+
| | +----+ |init| |prog|
| | +----+ +----+
| | +----+ """ """
| | --> |prog|
+--------+ +----+

* aus den beiden Strings wird ein Timeit-Objekt erzeugt: <tt>t = timeit.Timer(prog, setup)</tt>
* Frage: Wie oft soll die Algorithmik wiederholt werden
:z.B. N = 1000
* Zeit in Sekunden für N Durchläufe: <tt>K = t.timeit(N)</tt>
:Zeit für 1 Durchlauf: K/N

----
3.Stunde am 16.04.2008

==Sortierverfahren==

=== Motivation ===
'''Def:'''
Ein Sortierverfahren ist ein Algorithmus, der dazu dient, eine Liste von Elementen zu sortieren.
* Literatur, siehe Sortierverfahren; Bubblesort 1956, Quicksort 1962. Librarysort 2004

'''Anwendungen'''
* Sortierte Daten sind häufig Vorbedingungen für Suchverfahren (Speziell für effiziente Suchalgorithmen mit Komplexität <math>\mathcal{O}(log(N))</math>)
* Darstellung von Daten gemäß menschlicher Wahrnehmung
* Aus programmiertechnischer Anwendungssicht hat das Sortierproblem allerdings heute an Relevanz verloren da
** gängige Programmiersprachen heute typunabhängige Algorithmen zur Verfügung stellen. Der Programmierer braucht sich deshalb in den meisten Fällen nicht mehr um die Implementierung von Sortieralgorithmen zu kümmern. In C/C++ sorgen dafür beispielsweise Methoden aus der [http://de.wikipedia.org/wiki/Standard_Template_Library STL].
** Festplatten / Hauptspeicher heute weniger limitierenden Charakter haben, so dass Standardsortierverfahren meist ausreichen, während komplizierte, speicher-sparende Sortieralgorithmen nur noch selten benötigt werden.
* Die Kenntnis grundlegender Sortieralgorithmen ist trotzdem immer noch nötig: Einerseits kann man vorgefertigte Bausteine nur dann optimal einsetzen, wenn man weiß, was hinter den Kulissen passiert und andererseits verdeutlicht gerade das Sortierproblem wichtige Prinzipien der Algorithmenentwicklung und -analyse in sehr anschaulicher Form.

=== Vorraussetzungen/ Spielregeln ===

==== Mengentheoretische Anforderungen====
Definition Totale Ordnung/ Total gordnete Menge:
Eine Totale Ordnung / Total geordnete Menge ist eine binäre Relation
<math>R \subseteq M \times M</math> über einer Menge <math>M</math>, die transitiv, antisymmetrisch und total ist. 

<math>R</math> sei dargestellt als infix Notation <math>\le </math> dann, falls M total geordnet, gilt
<math> \forall a,b,c \ \epsilon M </math> 
(1) <math>a \le b \wedge b \le a \Rightarrow a=b </math> (antisymmetrisch) 
(2) <math>a \le b \wedge b \le c \Rightarrow a \le c </math> (transitiv) 
(3) <math>a \le b \vee b \le a </math> (total) 
Bemerkung: aus (3) folgt <math> a \le a </math> (reflexiv) 

''Hab in der Wiki eine gute Seite dazu gefunden [http://de.wikipedia.org/wiki/Ordnungsrelation'' Ordnungsrelation]

==== Datenspeicherung ====

Die Daten liegen typischerweise in Form von Arrays oder verketteten Listen vor. Je nach Datenstruktur sind andere Sortieralgorithmen am besten geeignet.
;Array:
+---+---+---+---+---+---+---+---+---+
|///| | | | | | | |///|
+---+---+---+---+---+---+---+---+---+
\________________ ____________________/
\/
N
Datenelemente können über Indexoperation a[i] gelesen, überschrieben und miteinander vertauscht werden. Vorteil: Die Zugriffsreihenfolge auf die Datenelemente ist beliebig. Nachteil: Einfügen oder Löschen von Elementen aus dem Array ist relativ aufwändig.

;Vekettete Liste:
+---+ +---+ +---+
| | --> | | --> | | --> Ende
+---+ +---+ +---+

Jeder Knoten der Liste enthält ein Datenelement und einen Zeiger auf den nächsten Knoten. Vorteil: Einfügen und Löschen von Elementen ist effizient möglich. Nachteil: effizienter Zugriff nur auf den Nachfolger eines gegebenen Elements, d.h. Zugriffsreihenfolge ist nicht beliebig.

==== Stabilität ====

Ein Sortierverfahren heißt ''stabil'' falls die relative Reihenfolge gleicher Schlüssel durch die Sortierung nicht verändert wird.

Beispiel: Sortiere eine Liste von Paaren <tt>[(3,7), (4,2), (4,1), (2,2), (2,8)]</tt>, wobei die Reihenfolge nur durch das erste Element (Schlüsselelement) jeden Paares festgelegt wird.
Dann erzeugt ein stabiles Sortierverfahren die Ausgabe
[(2,2), (2,8), (3,7), (4,2), (4,1)]
während die Ausgabe
[(2,2), (2,8), (3,7), (4,1), (4,2)]
nicht stabil ist (die Paare <tt>(4,1), (4,2)</tt> sind vertauscht).

==== Charakterisierung der Effizienz von Algorithmen ====

:(a) Komplexität O(1), O(n), etc. wird in Kapitel [[Effizienz]] erklärt.
:(b) Zählen der notwendigen Vergleiche
:(c) Messen der Laufzeit mit 'timeit' (auf identischen Daten)

'''Rekursive Beziehungen'''
zerlegt die ursprünglichen Probleme in kleinere Probleme und wendet den Algorithmus auf die kleineren Probleme an; daraufhin werden die Teilprobleme zur Lösung des Gesamtproblems verwendet.
d.h. Laufzeit (operativer Vergleich) für N Eingaben hängt von der Laufzeit der Eingaben für die Teilprobleme

'''Aufwand'''

(i) rekursives/ lineares Durchlaufen der Eingabedaten, Bearbeitung einzelner Elemente

C(N)= C(N-1)+ N ; N>1, C(1)= 1 +---+---+---+---+---+---+---+---+---+
= C(N-2) +(N-1)+ N | 7 | 3 | 2 | 5 | 6 | 8 | 1 | 4 | 2 |
= C(N-3) + (N-2) + (N-1) + N +---+---+---+---+---+---+---+---+---+
= ... ________________________/
= C(1) + 2+...+(N-1) +N /
+---+---+---+---+---+---+---+---+---+
N(N+1) N² | 1 | 3 | 2 | 5 | 6 | 8 | 7 | 4 | 2 |
= ----- ~ -- +---+---+---+---+---+---+---+---+---+
2 2

(ii) rekursives halbieren der Menge der Eingabedaten

C(N)= C(N/2)+1 ; N>1, C(1)=0
Aus Gründen der Einfachheit sei N = 2^n

C(N)= C(2^n)= C(<math>2^{n-1}</math>) + 1

= C(<math>2^{n-1}</math>) + 1 + 1
= ...

= C(<math>2^0</math>) + n
= n
= <math>log_2 N</math>
+---+---+---+---+-|-+---+---+---+---+
| | | | | | | | | |
+---+---+---+---+-|-+---+---+---+---+
+---+---+---+---+
| | | | |
+---+---+---+---+
+---+---+ +---+
| | | -> | |
+---+---+ +---+

(iii) rekursives halbieren, lineare Bearbeitung, jedes Elements

C(N)= 2C(N/2)+ N; N>1, C(1)= 0
Sei N= <math>2^n</math>
C(N)= C(<math>2^n</math>)= 2C (<math>2^{n-1}</math>)+ <math>2^n</math>
<=> <math> \cfrac{C(2^n)}{2^n}</math> = <math> \cfrac{2C(2^{n-1})}{2^{n-1}}</math>

= <math> \cfrac{2C(2^{n-2})+2^{n-1}}{2^{n-1}}+1</math>
= <math> \cfrac{2C(2^{n-2})}{2^{n-2}}+1 +1</math>
=...
= n
<=> C(<math>2^n</math>)= <math>2^n</math> * n
<=> C= N log<math>_2</math>N

==Selection Sort==

===Algorithmus===

array = [...] # zu sortierendes Array

for i in range(len(array)-1):
min = i
for j in range(i+1, len(array)):
if a[j]< a[min]:
min = j
a[i], a[min] = a[min], a[i] # Vertausche a[i] mit dem kleinsten rechts befindlichen Element
# Elemente links von a[i] und a[i] selbst befinden sich nun in ihrer endgültigen Position

Beispiel: Sortieren der Liste <tt>[S,O,R,T,I,N,G]</tt>.

erste Iteration der äußeren Schleife, Zustand ''vor'' dem Vertauschen:
i=0 min
+---+---+---+---+---+---+---+
| S | O | R | T | I | N | G |
+---+---+---+---+---+---+---+

erste Iteration der äußeren Schleife, Zustand ''nach'' dem Vertauschen:
+---|---+---+---+---+---+---+
| G | O | R | T | I | N | S |
+---|---+---+---+---+---+---+

zweite Iteration der äußeren Schleife:
i=1 min
+---|---+---+---+---+---+---+
| G | O | R | T | I | N | S |
+---|---+---+---+---+---+---+

weitere Iterationen:
i=2 min
+---+---|---+---+---+---+---+
| G | I | R | T | O | N | S |
+---+---|---+---+---+---+---+

i=3 min
+---+---+---|---+---+---+---+
| G | I | N | T | O | R | S |
+---+---+---|---+---+---+---+

i=4 min
+---+---+---+---+---+---+---+
| G | I | N | O | T | R | S |
+---+---+---+---+---+---+---+
...

===Laufzeit===

Da in jeder Iteration der ''inneren'' Schleife ein Vergleich <tt>a[j]< a[min]</tt> durchgeführt wird, ist die Anzahl der Vergleiche ein gutes Maß für den Aufwand des Algorithmus und damit für die Laufzeit. Sei C(N) die Anzahl der notwendigen Vergleiche, um ein Array der Größe N zu sortieren. Die Arbeitsweise des Algorithmus kann dann so beschrieben werden: Führe N-1 Vergleiche aus, bringe das kleinste Element an die erste Stelle, und fahre mit dem Sortieren des Rest-Arrays (Größe N-1) rechts des ersten Elements fort. Dafür sind nach Definition noch C(N-1) Vergleiche nötig. Es gilt also:
:::<math>C(N) = C(N-1) + (N-1)</math>
C(N-1) können wir nach der gleichen Formel einsetzen, und erhalten:
:::<math>C(N) = C(N-2) + (N-2) + (N-1)</math>
Wir können in dieser Weise weiter fortfahren. Bei C(1) wird das Einsetzen beendet, denn für ein Array der Länge 1 sind keine Vergleiche mehr nötig, also C(1) = 0. Wir erhalten somit
:::<math>C(N) = C(N-3) + (N-3) + (N-2) + (N-1)</math>
:::<math>...</math>
:::<math>C(N) = C(1) + 1 + 2 + ...+ (N-2)+ (N-1)</math>
:::<math>C(N) = 0 + 1 + 2 + ...+ (N-2)+ (N-1)</math>
Nach der Gaußschen Summenformel ist dies
:::<math>C(N) = \frac {(N-1)N}{2}\approx \cfrac {(N^2)}{2}</math> (für große N).

In jedem Durchlauf der äußeren Schleife werden außerdem zwei Elemente ausgetauscht. Es gilt für die Anzahl der Austauschoperationen
:::<math>A(N)= N-1</math>

===Stabilität===

Selection Sort ist stabil, wenn die Vergleiche durch <tt>a[j] < a[min]</tt> erfolgen, weil dann immer das erste Element mit einem gegebenen Schlüssel als erster nach vorn gebracht wird. Bei Vergleichen <tt>a[j] <= a[min]</tt> wird hingegen das letzte Element zuerst nach vorn gebracht, somit ist Selection Sort dann nicht stabil.

==Insertion Sort==

* wird in der Übungsgruppe behandelt, siehe auch in der [http://de.wikipedia.org/wiki/Insertionsort WikiPedia]
* Erweiterung: [http://en.wikipedia.org/wiki/Shell_sort Shell sort]

== Mergesort ==

===Algorithmus ===

Zugrunde liegende Idee:
* Zerlege das Problem in zwei möglichst gleich große Teilprobleme ("Teile und herrsche"-Prinzip -- divide and conquer)
* Löse die Teilprobleme rekursiv
* Führe die Teillösungen über Mischen (merging) in richtig sortierter Weise zusammen.
Der Algorithmus besteht somit aus zwei Teilen

====Zusammenführen -- merge====

a und b sind zwei sortierte Listen, die in eine sortierte Ergebnisliste kombiniert werden.

def merge(a,b):
c = [] # zunächst leere Ergebnisliste
i, j = 0, 0
while i < len(a) and j < len(b):
# wähle des kleinste der noch nicht angefügten Elemente
if a[i] <= b[j]:
c.append(a[i])
i += 1
else:
c.append(b[j])
j += 1
# eine Liste ist jetzt aufgebraucht => der Rest der anderen wird einfach an c angehängt
if i < len(a):
c += a[i:]
else:
c += b[j:]
return c

====rekursives Sortieren====

def mergeSort(a): # a ist das zu sortierende Array
if len(a) <= 1:
return a # Rekursionsabschluß: leere Arrays und Arrays mit einem Element müssen nicht sortiert werden
else:
left = a[:len(a)/2] # linkes Teilarray
right = a[len(a)/2:] # rechtes Teilarray
leftSorted = mergeSort(left) # rekursives Sortieren der Teilarrays
rightSorted = mergeSort(right) # ...
return merge(leftSorted, rightSorted) # Zusammenführen der Teilarrays

Bei der Sortierung mit Mergesort wird das Array immer in zwei Teile geteilt. → Es entsteht ein Binärbaum der Tiefe <math>\log_2 N</math>.

Beispiel: Sortieren der Liste <tt>[S,O,R,T,I,N,G]</tt>.

Der Algorithmus läuft in der folgenden Skizze zunächst rekursiv von unten nach oben (Zerlegen in Teillisten), danach werden die sortierten Teillisten von oben nach unten zusammengeführt (diese sortierten Teillisten sind in der Skizze dargestellt).

Schritt 0:
S 0 R T I N G S O R T I N G #Arraylänge: N/8 Vergleiche: 0
Schritt 1: \ / \ / \ / /
OS RT IN G OS RT IN / #Arraylänge: N/4 Vergleiche: 3 * 2 = 6
Schritt 2: \ / \ /
ORST GIN ORST GIN #Arraylänge: N/2 Vergleiche: 4 + 3 = 7
\ /
Schritt3: \ /
GINORST GINORST #Arraylänge: N Vergleiche: N = 7

===Laufzeit ===

Man erkennt an der Skizze, dass der Rekursionsbaum für ein Array der Länge N die Tiefe log N hat. Auf jeder Ebene werden weniger als N Vergleiche ausgeführt, so dass insgesamt weniger als N*log N Vergleiche benötigt werden. Dies ist natürlich wesentlich effizienter als die (N-1)*N/2 Vergleiche von Selection Sort. Mathematisch exakt kann man die Anzahl der Vergleiche durch die folgende Rekursionsformel berechnen:
:::<math>C(N) = C(\lfloor N/2\rfloor) + C(\lceil N/2\rceil) + N</math>
Der Aufwand ergibt sich aus dem Aufwand für die beiden Teilprobleme plus dem Aufwand für N Vergleiche beim Zusammenführen der sortierten Teillisten. Dabei stehen die Zeichen <math>\lfloor \rfloor</math> und <math>\lceil \rceil</math> für abrunden bzw. aufrunden, weil ein Problem mit ungeradem N nicht in zwei exakt gkeiche Teile geteilt werden kann. Um diese Komplikation zu vermeiden, beschränken wir uns im folgenden auf den Fall <math>N = 2^n</math> (mit etwas höherem Aufwand kann man zeigen, dass diese Einschränkung nicht notwendig ist und die Resultate für alle N gelten). Die vereinfachte Aufwandsformel lautet:
:::<math>C(N) = 2 C(N/2) + N</math>
Durch Einsetzen der Formel für N/2 erhalten wir:
:::<math>C(N) = 2 (2 C(N/4) + N/2) + N = 4 C(N/4) + N + N</math>
:::<math>C(N) = 4 (2 C(N/8) + N/4) + N + N = 8 C(N/8) + N + N + N</math>
:::<math>...</math>
Die Rekursion endet, weil für ein Array der Größe <math>N=1</math> keine Vergleiche mehr benötigt werden, also <math>C(1) = 0</math> gilt. Mit <math>N=2^n</math> ist dies aber gerade nach <math>n = \log_2 N</math> Zerlegungen der Fall. Merge Sort benötigt also
:::<math>C(N) = N + ... + N = n \cdot N = N\cdot \log_2 N</math>
Vergleiche.

===Weitere Eigenschaften von MergeSort ===

* Mergesort ist '''stabil''': wegen des Vergleichs <tt>a[i] <= b[j]</tt> wird die Position gleicher Schlüssel im Algorithmus <tt>merge(a,b)</tt> nicht verändert -- bei gleichem Schlüssel hat, wie gefordert, das linke Element Vorrang.
* Mergesort ist '''unempfindlich gegenüber der ursprünglichen Reihenfolge der Eingabedaten'''. Grund dafür ist
** die vollständige Aufteilung des Ausgangsarrays in Arrays der Länge 1 und
** dass <tt>merge(a,b)</tt> die Vorsortierung nicht ausnutzt, d.h. die Komplexität von <tt>merge(a,b)</tt> ist sortierungsunabhängig.
* Diese Eigenschaft kann unerwünscht sein, wenn ein Teil des Arrays oder gar das ganze Array schon sortiert ist. Es wird nämlich in jedem Fall das ganze Array neu sortiert.
* Merge Sort eignet sich für das Sortieren von '''verketteten Listen''', weil die Listenelemente stets von vorn nach hinten durchlaufen werden. In diesem Fall muss <tt>merge(a, b)</tt> keine neue Liste <tt>c</tt> für das Ergebnis anlegen, sondern kann einfach die Verkettung der Listenelemente von <tt>a</tt> und <tt>b</tt> entsprechend anpassen. In diesem Sinne arbeitet Merge Sort auf verketten Listen "in place", d.h. es wird kein zusätzlicher Speicher benötigt.
* Im Gegensatz dazu benötigt <tt>merge(a,b)</tt> zusätzlichen Speicher für das Ergebnis <tt>c</tt>, wenn die Daten in einem Array gegeben sind.

== Quicksort ==

* Quicksort wurde in den 60er Jahren von Charles Antony Richard Hoare [http://de.wikipedia.org/wiki/C._A._R._Hoare] entwickelt. Es gibt viele Implementierungen von Quicksort, vgl. [http://de.wikipedia.org/wiki/Quicksort].
* Dieser Algorithmus gehört zu den "Teile und herrsche"-Algorithmen (divide-and-conquer) und ist der Standardalgorithmus für Sortieren.
* Im Gegensatz zu Merge Sort wird das Problem aber nicht immer in zwei fast gleich große Teilprobleme zerlegt. Dadurch vermeidet man, dass zusätzlicher Speicher benötigt wird (Quick Sort arbeitet auch für Arrays "in place"). Allerdings erkauft man sich dies dadurch, dass Quick Sort bei ungünstigen Eingaben (die Bedeutung von "ungünstig" ist je nach Implementation verschieden) nicht effizient arbeitet. Da solche Eingaben jedoch in der Praxis fast nie vorkommen, tut dies der Beliebtheit von Quicksort keinen Abbruch.

=== Algorithmus===

Wie Merge Sort arbeitet Quick Sort rekursiv. Hier werden die Daten allerdings zuerst vorbereitet (in der Funktion <tt>partition</tt>), und danach erfolgt der rekursive Aufruf:

def quicksort(a, l, r):
"""a ist das zu sortierende Array,
l und r sind die linke und rechte Grenze des zu sortierenden Bereichs"""

if r > l: # Rekursionsabschluss: wenn r <= l, ist der Bereich leer und muss nicht mehr sortiert werden
i = partition(a, l, r) # i ist der Index des sog. Pivot-Elements (s. u.)
quicksort(a, l, i-1) # rekursives Sortieren der beiden Teilarrays
quicksort(a, i+1, r) # ...

Der Schlüssel des Algorithmus ist offensichtlich die Funktion <tt>partition</tt>. Diese wählt ein Element des Arrays aus (das Pivot-Element) und bringt es an die richtige Stelle (also an den Index <tt>i</tt>, der von <tt>partition</tt> zurückgegeben wird). Ausserdem stellt sie sicher, dass alle Elemente in der linken Teilliste (Index < <tt>i</tt>) kleiner als <tt>a[i]</tt>, und alle Elemente in der rechten Teilliste größer also <tt>a[i]</tt> sind:
# <math>a[i]</math> ist sortiert, d.h. dieses Element ist am endgültigen Platz.
# <math>\forall x \in \left\{ a \left[ l \right] , ... a \left[ i-1 \right] \right\} : x \leq a \left[ i \right]</math>
# <math>\forall x \in \left\{ a \left[ i+1 \right], ... a \left[ r \right] \right\} : x \geq a \left[ i \right]</math>

l r
+---+---+---+---+---+---+---+---+---+
Array: | | | | |\\\| | | | |
+---+---+---+---+---+---+---+---+---+
\______ _____/ i \______ _____/
\/ \/
<=a[i] >=a[i] (a[i] ist das Pivot-Element)

Die Position von <tt>i</tt> richtet sich also offensichtlich danach, wie viele Elemente im Bereich <tt>l</tt> bis <tt>r</tt> kleiner bzw. größer als das gewählte Pivot-Element sind. Der Wahl eines guten Pivot-Elements kommt demnach eine große Bedeutung zu (s.u.).

In der einfachsten Version wird <tt>partition</tt> wie folgt definiert:

def partition(a, l, r):
pivot = a[r] # Pivot-Element. Hier wird willkürlich das letzte Element verwendet.
i = l # i und j sind Laufvariablen
j = r - 1

while True:
while a[i] <= pivot and i < r:
i += 1 # finde von links das erste Element > pivot
while a[j] >= pivot and j > l:
j -= 1 # finde von rechts den ersten Eintrag <= pivot
if i >= j: break # keine weiteren Elemente zum Tauschen => Schleife beenden
a[i], a[j] = a[j], a[i] # a[i] und a[j] sind beide auf der falschen Seite des Pivot => vertausche sie
if a[i] > pivot:
a[i], a[r] = a[r], a[i]
return i

Die folgende Skizze verdeutlicht das Austauschen

p
+---+---+---+---+---+---+---+---+---+
Array: | | | | | | | | |\\\|
+---+---+---+---+---+---+---+---+---+
------> a[i]>p a[j]<p <-----
| |
+---------------+
Diese zwei Elemente werden ausgetauscht.

Dies wird wiederholt, bis sich die Zeiger treffen oder einander überholt haben. Am Schluss wird das Pivot-Element an die richtige Stelle verschoben:

p
+---+---+---+---+---+---+---+---+---+
Array: | | | | |\\\| | | | |
+---+---+---+---+---+---+---+---+---+
i
-----------------> <-----------------

Beispiel: Partitionieren des Arrays <tt>[A,S,O,R,T,I,N,G,E,X,A,M,P,L,E]</tt> mit Pivot 'E'.

l,i --> <-- j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | S | O | R | T | I | N | G | E | X | A | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i <--------- Vertauschen ---------> j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | S | O | R | T | I | N | G | E | X | A | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i <-------------------> j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | O | R | T | I | N | G | E | X | S | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

j i r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | R | T | I | N | G | O | X | S | M | P | L | E | --> Hier wird die
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Schleife verlassen.

j i <---------------------------------------> r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | R | T | I | N | G | O | X | S | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | E | T | I | N | G | O | X | S | M | P | L | R | --> Hier wird partition() beendet.
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Weitere ausführliche Erklärungen der Implementation findet man bei Sedgewick.

=== Laufzeit===

Wir müssen hier den schlechtesten und den typischen Fall unterscheiden. Der schlechteste Fall tritt ein, wenn das Array bereits sortiert ist. Dann ist das Pivot-Element immer bereits am richtigen Platz, so dass <tt>partition(a, l, r)</tt> stets den Index <tt>i = r</tt> zurück. Daher wird das Array niemals in zwei etwa gleichgroße Teile zerlegt. Die Anzahl der Vergleiche ergibt sich als

:::<math>C(N) = (N+1) + C(N-1) + C(0)</math>
:::<math>C(0) = 0</math>

mit (N+1) Vergleichen in <tt>partition()</tt>. Durch sukzessives Einsetzen erhalten wir:

:::<math>C(N) = (N+1) + (N) + (N-1) + ... + 1 = (N+1) N / 2</math>

In diesem Fall ist Quick Sort also nicht schneller als Selection Sort. Wir beschreiben mögliche Verbesserungen unten. Im typischen Fall (wenn nämlich das Array zufällig sortiert ist) sieht die Situation wesentlich besser aus. Bei zufälliger Sortierung wird jeder Index mit gleicher Wahrscheinlichkeit zur Pivot-Position. Wir mitteln deshalb über alle möglichen Positionen:

:::<math>C(N) = (N+1) + \frac{1}{N} \sum_{k=1}^{N} \left[ C(k-1) + C(N-k) \right]</math> für <math> N>0</math>

wobei <math>k</math> über alle möglichen Teilungspunkte läuft. Die Summe (der mittlere Aufwand über alle möglichen Zerlegungen) kann vereinfacht werden zu
:::<math>\frac{1}{N} \sum_{k=1}^{N} \left[ C(k-1) + C(N-k) \right] = 2 \frac{1}{N} \sum_{k=1}^{N} C(k-1) </math>
Die Auflösung der Formel ist etwas trickreich. Wir multiplizieren zunächst beide Seiten mit N:

:::<math>
N \cdot C(N) = N \left[ (N+1) + \frac{2}{N} \sum_{k=1}^{N} C(k-1) \right] = N (N+1) + 2\; \sum_{k=1}^{N} C(k-1)</math>

Durch die Substitution <math>N \rightarrow N-1</math> erhalten wir die entsprechende Formel für N-1:

:::<math>
(N-1) \cdot C(N-1) = (N-1) N + 2\; \sum_{k=1}^{N-1} C(k-1)</math>

Wir subtrahieren die Formel für N-1 von der Formel für N und eliminieren dadurch die Summe (nur der letzte Summend der ersten Summe bleibt übrig):
:::<math>
\begin{array}{rcl}
N \cdot C(N) - (N-1) \cdot C(N-1) &=& N(N+1) + 2\;\sum_{k=1}^{N} C(k-1) - (N-1) N - 2\;\sum_{k=1}^{N-1} C(k-1)\\
&&\\
N \cdot C(N) - (N-1) \cdot C(N-1) &=& N(N+1) - (N-1) N + 2 C(N-1)
\end{array}
</math>
Durch Vereinfachen erhalten wir die rekurrente Beziehung
:::<math>
N \cdot C(N) = (N+1)\cdot C(N-1) + 2 N</math>
Wir teilen jetzt beide Seiten durch <math>(N+1)N</math>
:::<math>
\frac{C(N)}{N+1} = \frac{C(N-1)}{N} + \frac{2}{N+1} </math>
Sukzessives Einsetzen der Formel für <math> C(N-1), C(N-2) </math> etc. bis <math>C(1)=0</math> liefert
:::<math>
\frac{C(N)}{N+1} = \frac{C(N-2)}{N-1} + \frac{2}{N} + \frac{2}{N+1} = \frac{C(2)}{3} + \sum_{k=3}^N\frac{2}{k+1} </math>
Für hinreichend große N kann die Summe sehr genau durch ein Integral approximiert werden. Der konstanten Term kann vernachlässigt werden:
:::<math>
\frac{C(N)}{N+1} \approx 2 \sum_{k=3}^{N} \frac{1}{k+1} \approx 2 \int_1^N \frac{1}{k} dk = 2 \cdot \ln(N)</math>
Somit benötigt Quick Sort im typischen Fall
:::<math>C(N)\approx 2 N\cdot\ln(N) \approx 1.38 N\cdot\log_2(N)</math>
Vergleiche. Quick Sort ist demnach etwa genauso schnell wie Merge Sort (in der Praxis sogar etwas schneller, da die innere Schleife von Quick Sort etwas einfacher ist).

=== Verbesserungen des Quicksort-Algorithmus ===

==== Beseitigung der Rekursion ====
Eine Verbesserung beseitigt die Rekursion durch Verwendung eines Stacks. Nach jeder Partitionierung wird das größere Teilintervall auf dem Stack abgelegt und das kleinere Teilintervall direkt weiterverarbeitet (hierdurch wird sichergestellt, dass die maximale Größe des Stacks minimiert wird).

def quicksortNonRecursive(a, l, r):
stack = [(l,r)] # initialisiere den Stack
while len(stack) > 0:
if r > l:
i = partition(a, l, r)
if (i-l) > (r-i):
stack.append((l,i-1))
l = i+1
else:
stack.append((i+1, r))
r = i-1
else:
l, r = stack.pop()

Die ist die Methode der ''Endrekursionsbeseitigung'', die wir im Kapitel [[Iteration versus Rekursion]] ausführlich behandeln. Die folgende Skizze verdeutlicht die Verwendung des Stacks.

+---+---+---+---+---+---+---+
| Q | U | I | C | K | S | O |
+---+---+---+---+---+---+---+

+---+---+---+===+---+---+---+
| K | C | I |=O=| Q | S | U |
+---+---+---+===+---+---+---+
\_________/
push

+---+===+---+
| C |=I=| K |
+---+===+---+
\_/
push

+===+
|=C=|
+===+

+===+
|=K=|
+===+

+---+---+===+
| Q | S |=U=|
+---+---+===+

+---+===+
| Q |=S=|
+---+===+

+===+
|=Q=|
+===+

+---+---+---+---+---+---+---+
| C | I | K | O | Q | S | U |
+---+---+---+---+---+---+---+

==== Alternatives Sortieren kleiner Intervalle ====

Für kleine Arrays (bis zu einer gegebenen Größe K) ist das "Teile und herrsche"-Prinzip nicht die effizienteste Herangehensweise. Insbesondere kann man ein Array mit maximal 3 Elementen direkt sortieren:
def sortThree(a, l, r):
if r > l and a[l+1] < a[l]: # Stelle sicher, dass a[l] und a[l+1] relativ zueinander sortiert sind.
a[l], a[l+1] = a[l+1], a[l]
if r == l + 2:
if a[r] < a[l]: # Stelle sicher, dass a[l] und a[r] relativ zueinander sortiert sind.
a[l], a[r] = a[r], a[l] # Danach ist a[l] auf jeden Fall das kleinste Element.
if a[r] < a[r-1]: # Stelle sicher, dass a[r-1] und a[r] relativ zueinander sortiert sind.
a[r], a[r-1] = a[r-1], a[r] # Jetzt ist a[r] auf jeden Fall das größte Element und das Array damit sortiert.

In die Funktion <tt>quicksort()</tt> wird jetzt ein Aufruf dieser Funktion eingefügt:
if r > l + 2:
# wie bisher
elif r > l:
sortThree(a, l, r)

==== Günstige Selektion des Pivot-Elements ====
Durch geschickte Wahl des Pivot-Elements kann man erreichen, dass der ungünstigste Fall (quadratische Laufzeit) nur mit sehr kleiner Wahrscheinlichkeit eintritt. Zwei Möglichkeiten haben sich bewährt:
# Anstatt des letzten Elements des Teilarrays wählt man ein zufälliges Element (mit Hilfe eines Zufallszahlengenerators). Dadurch wird Quick Sort unempfindlich gegenüber bereits sortierten Arrays, weil die Teilung im Mittel wie bei einem zufällig sortierten Array erfolgt (typischer Fall in obiger Laufzeitberechnung).
# Median (mittlerer Wert) von drei Elementen: Verwende den Median des ersten, mittleren und letzten Elements jedes Teilarrays als Pivot-Element.
In beiden Fällen ist es praktisch ausgeschlossen, dass ein Eingabearray so angeordnet ist, dass in jedem Teilarray gerade das kleinste oder größte Element als Pivot gewählt wird. Nur dann könnte der ungünstigste Fall jedoch eintreten, was somit effektiv verhindert wird.

[[Korrektheit|Nächstes Thema]]

Randomisierte Algorithmen

2010-08-14T07:22:33Z

Jschleic: /* 1. Randomisierte Algorithmen */ Formet

== 1. Randomisierte Algorithmen ==

'''Def.:''' Algorithmen, die bei Entscheidung oder bei der Wahl der Parameter Zufallszahlen benutzen

'''Bsp.:''' Lösen des K-SAT-Problems durch RA
geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Variablen} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>

for i in range (trials): #Anzahl der Versuche
#Bestimme eine Zufallsbelegung des <math>\{ x_i \}</math>:
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln: return <math>\{ x_i \}</math>
#wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
(die Klausel ist jetzt erfüllt)
return None

Eigenschaft: falls <math>k>2</math> : steps *trials <math>\in O\left(\Alpha^n \right) \Alpha >1</math>

z.B. <math>k=3</math> steps=3*n, trials=<math>\left(\frac{4}3\right)^n</math>

aber: bei <math>k=2</math> sind im Mittel nur steps=<math>O\left(n^2\right)</math> nötig, trials=<math>O\left(1\right)</math>

----

'''-Zufallsbelegung hat <math>t\leq n</math> richtige Variablen (im Mittel <math>t\approx \frac {n} 2</math>)'''

Negieren einer Variable ändert t um 1,
u.Z. <math>t\rightarrow t+1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac 1 k</math>)
::::::::::<math>t\rightarrow t-1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac {k-1} k</math>)

'''-Wieviele Schritte braucht man im Mittel, um zu einer Lösung mit t Richtigen zu kommen?'''

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

<math>S\left(n\right)=0</math> #Abbruchbedingung der Schleife

<math>S\left(0\right) = S\left( 1\right) + 1 \Rightarrow S\left(t\right) = n^2-t^2</math>

'''Probe:'''

<math>
\begin{align}
S\left(n\right) & = n^2-n^2=0 \\

S\left(0\right) &= n^2-0^2 \\

&= S\left(1\right)+1 \\

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

&= n^2 \\

S\left(t\right) &= \frac 1 2 \left(n^2-\left(t-1\right)^2\right) + \frac 1 2 \left(n^2-\left(t+1\right)^2\right)+1 \\

&= \frac 1 2 n^2-\frac 1 2 \left( t^2-2t+1\right) + \frac 1 2 n^2-\frac 1 2 \left(t^2+2t+1\right) + 1 \\

&= n^2-t^2
\end{align}</math>

'''Das ist das Random Walk Problem'''

Im ungünstigsten Fall (t=0) werden im Mittel <math>n^2</math> Schritte benötigt, um durch random walk nach t=n zu gelangen.

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

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

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

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

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

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

'''Lineares Gleichungssystem'''

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

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

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

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

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

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

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

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

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

----

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

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

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

RANSAC-Algorithmus

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

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

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

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

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

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

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

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

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

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

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

:::*Lösung:

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

:::*speziell:

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

----

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

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

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

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

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

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

== ''' Zufallszahlen ''' ==

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

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

\end{array}</math>

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

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

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

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

\end{array}</math>

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

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

\end{array}</math>

::stark geclustert ist.

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

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

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

\end{array}</math>

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

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

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

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

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

* schnell

class Random:
def __init__(self, seed):
self.N = 624
self.state = [0]*624
self.state = zufällig mit Hilfe des ''seeds'' initialisieren (einfacher ZZG)
self.i = 0 # zählt mit in welchem Zustand wir gerade aufhalten

def __call__(self):
N,M = 624, 397
i = self.i
r = (self.state[i] & 0x80000000)|(self.state[(i+1)%N] & 0x7FFFFFFF) # aktualisieren
if self.state[(i+1)%N]&1: # des Zustands
r^= 0x9908B0DF
self.state[i] = self.state[(i+1)%N]*^r

y = self.state[i]
self.i = (self.i + 1)%N
# bits verwürfeln
y ^= (y>>11)
y ^= ((y>>7) & 0x9D2C5680)
y ^= ((y>>15) & 0xEFC60000)
y ^= (y>>18)
return y

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

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

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

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

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

|}

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

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

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

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

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

Graphen und Graphenalgorithmen

2010-08-12T16:29:39Z

Jschleic: /* Stirling'sche Formel */ typo

== 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 Abbildung) einen Spaziergang zu unternehmen, bei dem jede der 7 Brücken genau einmal überquert wird?

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

Inzwischen haben Graphen ein 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.

;Transponierter Graph: 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 dann 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 transpose(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 ==

=== Tiefensuche in Graphen ===

Sei der Graph gegeben als Liste von Listen = g

def dfs (g,node,v=0):
if v == 0:
v = [0]*len(g) #visited-Liste
v[node] = 1 #besuche node
for t in g[node]: #gehe zu allen Nachbarn
if v[t] == 0: #falls diese noch nicht besucht
dfs(g,t,v) #Rekursion

[[Image:Tiefens.jpg]]

Aufruf dfs(g,1)

=>Folge 1,2,4,3,6,7,5

=== Breitensuche ===

from Queue import *
def bfs(g,startnode)
v = [0]*len(g)
q = Queue()
v[startnode] = 1 #besuche
q.put(startnode) #in Schlange
while not q.empty():
node = q.get()
for t in g[node]:
if v[t] == 0:
v[t] = 1
q.put(t)

Aufgrund von Problemen mit der Implementation von Queue eine neue Version:

def bfs(g,startnode)
v = [0]*len(g)
q = []
v[startnode] = 1 #besuche
q.append(startnode) #in Schlange
while not len(q):
node = q.pop(0)
for t in g[node]:
if v[t] == 0:
v[t] = 1
q.append(t)

[[Image:Breitens.jpg]]

=>Folge 1,2,3,4,5,6,7

== Damenproblem ==

---------------
| | X | | |
|---|---|---|---|
| | | | X |
|---|---|---|---|
| X | | | |
|---|---|---|---|
| | | | X |
---------------

4 Damen auf einem vereinfachten Schachbrett so Positionieren, dass sich keine bedroht.

erster Durchlauf:

[[Image:Suche1.jpg]]

zweiter Durchlauf:

[[Image:Suche2.jpg]]

== Weitere Anwendungen (18.06.08) ==

def dfs(graph):
'''
Diese Tiefensuche tut so noch nichts weiter als zu traversieren
+ graph ist Array,
i-ter Eintrag enthaelt Adjazenzliste (auch Array) des i-ten Knotens,
wobei Knoten nummeriert von 0 ... v-i
'''
def visit(graph, node, visited):
'''
visited ist Array mit Flags fuer besuchte Knoten
'''
if visited[node]: return
visited[node] = True
for neighbor in graph[node]:
visit(graph, neighbor, visited)
visited = [False]*len(graph)
for node in range(len(graph)):
visit(graph, node, visited)

=== Finden von Zusammenhangskomponenten ===

Ein möglicher Einsatz des Verfahrens ist das Finden von Zusammenhangskomponenten (connected components).

* Beispiel: ...

* Definition: CC_i = {u_k, u_l e V: es gibt einen Pfad von u_k nach u_l ("u_l ist von u_k aus erreichbar")
* für gerichtete Graphen gilt zusätzlich: es gibt einen Pfad von u_l nach u_k}

Die Relation CC_i, also die Zusammenhangskomponenten (ZK) bilden eine Aequivalenzrelation,
also kann fuer jede ZK ein Repraesentant bestimmt werden (der sog. "Anker"). Kennt jeder
Knoten seinen Anker, so ist das ZK-Problem geloest.

==== Tiefensuchen-Algorithmus ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden, wobei statt
Knotenbesuche Knotennummern fuer die schon gefundenen Anker gesetzt werden. Ein moeglicher
Algorithmus lautet damit wie folgt:

def connectedComponents(graph):
def visit(graph, node, anchors, anchor):
'''
anchor ist Anker der aktuellen ZK
'''
if anchors[node] is not None: return # Anker von <node> schon bekannt
anchors[node] = anchor
for neighbor in graph[node]
visit(graph, neighbor, anchors, anchor)

anchors = [None]*len(graph)
for node in range(len(graph)):
visit(graph, node, anchors, node) # node: Anker der naechste ZK = erster Knoten der ZK
return anchors

* Beispiel: ...

==== Union-Find-Algorithmus ====

Eine Alternative (ohne Tiefensuche) waere z.B. ein Union-Find-Algorithmus. Idee dabei ist, dass eingangs jeder Knoten eine eigene ZK bildet, wobei in einer anschliessenden Rekursion Kanten gesucht werden, die zwischen den ZK bestehen.

Initialisierung: jeder Knoten wird als 1 ZK behandelt
Rekursion: fasse ZK zusammen (Union) falls Kante zwischen ihnen existiert
Ergebnis: Array mit dem Anker jedes Knotens

def unionFindCC(graph):
def findAnchor(anchors, k):
'''
#Prueft auf anchors[k]==k
'''
while anchors[k] != k:
k = anchors[k]
return k

def edges(graph):
e = []
for node in range(len(graph)):
for n in graph[node]:
if node < n:
e.append((node, n))
return e

anchors = range(len(graph)) # jeder Knoten ist sein eigener Anker
for edge in edges(graph):
# diese Schleife ordnet die Anker so, dass
# der 1. Anker immer der kleinste ist
a1, a2 = findAnchor(anchors, edge[0]), findAnchor(anchors, edge[1])
if a2 < a1: a2,a1 = a1,a2
if a1 != a2: anchors[a2] = a1
for node in range(len(graph)):
# diese Schleife raeumt mit Indirektionen auf (s. Bsp. (#))
anchors[node] = findAnchor(anchors, node)
return anchors

* Beispiel (#): ...

Eine verbreitete Anwendung fuer dieses Verfahren gibt es in der Bildverarbeitung:

* Beispiel: ...

== Variationen der Tiefensuche (19.06.2008) ==

=== Wichtige Algorithmen, die in der Vorlesung nicht behandelt werden ===

* Max Flow (zur Bestimmung des maximalen Flusses durch ein Netzwerk, z.B. bei Ölpipelines)
* Matching (auch ''Paarung'' genannt): Teilmenge der Kanten eines Graphen, wobei keine zwei Kanten einen gleichen Knoten besitzen
*:Anwendungsbereiche: Zuordnung von Gruppen, z.B. Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot), Universität (Zuordnung Studenten - Übungsgruppen)

=== Vereinfachte Lösung für den ''acyclic''-Algorithmus ===
Zum Finden von Zyklen, bzw. der Feststellung, ob ein Graph azyklisch ist, verwenden wir
wieder eine modifizierte Version der Tiefensuche: Die Knoten werden wieder nach dem System der Tiefensuche besucht, und alle besuchten Knoten in einem Array visited abgespeichert. Es gibt einen Zyklus genau dann, wenn man zu
einem früheren Knoten (außer zum direkten Vorgaenger) zurückkommt.

<code python>
def acyclic(graph):
def visit(graph, node, fromNode, visited):
if visited[node]: # Zyklus entdeckt
return False
visited[node] = True
for neighbor in graph[node]:
if neighbor == fromNode: # überspringe Nachbar, von dem du gekommen bist
continue
if not visit(graph, neighbor, node, visited):
return False # der Graph ist zyklisch
return True # kein Zyklus
visited = [False]*len(graph)
for node in range(len(graph)):
if visited[node]: # schließt aus, dass Knoten besucht wird, der schon besucht war
continue
if not visit(graph, node, None, visited):
return False
return True
</code>

'''Anmerkungen zum Code:'''

* Wenn ein Knoten bereits besucht ist, dann gehört er zur gleichen Zusammenhangskomponente - dies hat allerdings nichts mit einem Zyklus zu tun.
* Ein Graph der einmal zyklisch war wird nie wieder azyklisch.
* Der obige Algorithmus weist Ähnlichkeiten mit den bereits behandelten Algorithmen auf: '''ein guter Algorithmus zeichnet sich dadurch aus, dass mit kleinen Code-Variationen ganz andere Probleme gelöst werden können'''.

=== Kürzeste Wege (Pfade) ===

* Definition: gewichteter Graph

Jeder Kante e ist eine reelle oder natürliche Zahl we zugeordnet (wird auch als
''Kantengewicht'' bezeichnet).

z.B.
* Abstand der Anfangs- und Endknoten

* Durchflusskapazität eines Rohres (für max-Flussprobleme)

* Wechselkurse (Darstellung in einem gerichteten Graph, da jede Kante auch eine Richtung hat. Die Knoten sind die Währungen, die Kanten sind die Wechselkurse. Auf diese Weise lassen sich unterschiedliche Wechselkurse + Bankgebühren darstellen.)

* '''Definition''': Problem des kürzesten Weges

Sei P die Menge aller Wege von u nach v

Puv = {u_v}

und der Weg gegeben durch

u → x1 → x2 → ... → v

dann sind die Kosten eines Weges definiert durch

Kosten (Puv) = <math>\sum\limits_{l \in Pv}</math> we

* gesucht: Pfad u_v, so dass Kosten (u_v) minimal sind

* Lösung: Algorithmus von Dijkstra

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

<code python>
import heapq # heapq ist ein Modul von Python
def dijkstra(graph, start, ziel): # graph: gewichtete Adjazenzliste
heap = []
visited = [None]*len(graph)
visited[start] = start
for neighbor in graph[start]:
heapq.heappush(heap, (neighbor[1], start, neighbor[0])) # neighbor[1]:Kantengewicht,neighbor[0]:Endpunkt d. K.
while len(heap) > 0: # solange der heap nicht leer ist
w, fromNode, node = heapq.heappop(heap)
if visited[node] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
visited[node] = fromNode # baue Vorgänger-Baum
if node == ziel: # da der heap noch nicht leer ist, wird an dieser Stelle ein break benötigt
break
for neighbor in graph[node]:
if visited[neighbor[0]] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
heapq.heappush(heap, (neighbor[1]+w, node, neighbor[0]))
bestPath = []
t = ziel
while t != visited[t]: # Array wird durchlaufen bis der Anker des Pfades gefunden ist, vgl. Union-Search
bestPath.append(t)
t=visited[t]
bestPath.append(start)
return bestPath # bestPath.reverse()
</code>

'''Anmerkungen zum Code:'''
* der graph ist eine gewichtete Adjazenzliste

{|

|-

| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | Endknoten || → || style="background:silver; color:white" | Endknoten || (Nr. der Nachbarn des Knoten 0)

|-

| || style="background:silver; color:white" | 1 || || style="background:silver; color:white" | Gewicht || || style="background:silver; color:white" | Gewicht || (Gewicht der jeweiligen Kante)

|-

| || style="background:silver; color:white" | 2 ||

|-

| || style="background:silver; color:white" | 3 ||

|}
* Eingabe z.B.:
{|
|-
| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | (1, 0.3) || style="background:silver; color:white" | (3, 0.1) || style="background:silver; color:white" | (5, 1.2) ||
|-
| || style="background:silver; color:white" | 1 || → || style="background:silver; color:white" | || style="background:silver; color:white" | || style="background:silver; color:white" | ||
|-
| || style="background:silver; color:white" | 2 ||
|-
| || style="background:silver; color:white" | 3 ||
|-
| || style="background:silver; color:white" | 4 ||
|-
| || style="background:silver; color:white" | 5 ||
|-
| || style="background:silver; color:white" | 6 ||
|}
* heapq() verwendet den 1. Eintrag des Tupels zum sortieren des heap

==== Prinzip des Dijkstra-Algorithmus ====

* Algorithmus ist Tiefensuche mit Prioritätswarteschlange (Heap) statt eines Stapelspeichers (Stack) → vgl. Übung 8

* Die Prioritätswarteschlange speichert die kürzesten Wege, die bereits gefunden worden sind.

* Wenn man die Prioritätswarteschlange (Heap) durch eine Warteschlange (Queue) ersetzt, erhält man Breitensuche.

* Wenn man die Prioritätswarteschlange (Heap) durch einen Stapelspeicher (Stack) ersetzt, erhält man Tiefensuche.

==== Beispiel ====

[[Image:Bsp.jpg]]

* An der Stelle "neighbor[1]" wird eine Zählvariable ''count'' eingefügt, die hoch (Breitensuche) oder runter (Tiefensuche) zählt.

* Die Gewichte werden hoch- oder runtergezählt, so wie die Kanten gesehen wurden.

* Wenn man rückwärts zählt (von 0 abziehen), werden die zuletzt hinzugefügten Kanten expandiert.

* '''Algorithmus von Dijkstra funktioniert nur für positive Kantengewichte
*:<math>\forall</math> we > 0'''

* Bei negativen Kantengewichten könnte es Zyklen geben, die negative Kosten für den ganzen Zyklus haben:

/\ 1. Durchlauf: Kosten -1
1 / \ -4 2. Durchlauf: Kosten -2
/____\ etc.
2

* Verwendung bei arbitragen Geschäften (Börsengeschäfte, die die Preis-, Kurs- und Zinsunterschiede auf verschiedenen Märkten ausnutzen):
*:EURO wurden in YEN, YEN in DOLLAR gewechselt und das Geld hat sich dadurch vermehrt
* Für negative Kantengewichte verwendet man den Bellman-Ford-Allgorithmus, der allerdings langsamer ist, als der Dijkstra-Algorithmus.

==== Komplexität von Dijkstra ====

* Jeder Knoten wird höchstens 1x expandiert (Iteration über die Nachbarn des Knotens).

* Jeder Knoten kann mehrmals im Heap enthalten sein.

* Es sind aber höchstens E (Anzahl der Kanten) Heap-Einträge möglich, da jede Kante höchstens 1 Heap-Eintrag generiert (ein Knoten ist nur dann im Heap, wenn man ihn über eine Kante erreicht hat, die man vorher noch nicht besucht hatte). Deshalb können nie mehr Einträge im Heap sein, als es Kanten gibt. Die Komplexität von heappush(), heappop() ist
O(log E) = O(2 log v) = O(log v)
wenn alle Kanten einen Heap-Eintrag generiert haben.
* Die while-Schleife wird im schlimmsten Fall E mal durchlaufen, deshalb ist die Komplexität von Dijkstra O(E log v).

==== Korrektheit von Dijkstra ====

* Falls
visited[node] (Schleifen-Invariante von while) != None
ist, dann liefert Zurückverfolgen des Pfades von node nach start den kürzesten Pfad von start nach node (gilt für alle Knoten, für die das visited-Feld gesetzt ist).
* Induktionsanfang: visited[start] ist einziger not-None-Fall → Bedingung erfüllt
* Induktionsschritt: wenn visited[node] gesetzt wird, ist es ein kürzester Pfad

==== Indirekter Beweis ====

Set S = {node | visited[node] != None} (alle Knoten, von denen wir den kürzesten Pfad schon kennen)

* u ist der Knoten an der Spitze des Heaps
* fromNode <math>\in</math> S (ein Nachbar von node kommt erst dann in den Heap, wenn visited[node] vorher gesetzt wurde)
* falls u → fromNode → start kein kürzester Pfad wäre, müsste u's Vorgänger in V\S sein
* sei dieser Vorgänger x <math>\notin</math> S, x <math>\not=</math> u
* sei wx das Gewicht der Kante x → u, dann sind die Kosten für start nach u gleich

Kosten(start_u) = Kosten(start_x) + wx

* Annahme des indirekten Beweises:

Kosten(start_fromNode) + wfromNode

* Behauptung des indirekten Beweises:
Es gibt einen anderen Pfad x, so dass die Kosten von start nach x geringer sind

* Da aber gilt:
fromNode <math>\in</math> S und x <math>\notin</math> S

* gilt (Induktionsvoraussetzung):
Kosten(start_fromNode) < Kosten(start_x)

* Falls Kosten(start_x) < Kosten(start_u) müsste x im Heap vor u kommen; daraus folgt, dass u nicht an der Spitze des Heaps sein kann

→ Widerspruch!

→ Die Behauptung, der Weg über x ist besser, kann nicht stimmen.

→ Korrektheit von Dijkstra ist somit bewiesen.

==== Wie kann man Dijkstra noch verbessern? ====

===== A*-Algorithmus =====

* Verbesserung von Dijkstra im typischen Fall, aber die Komplexität ist immer noch =(Elog v) im schlechtesten Fall (die Komplexität kann man nicht verbessern, aber die Laufzeit im typischen Fall).
* Schätzung für jeden Knoten für den restlichen Weg:
geschätzte Gesamtkosten: Kosten(start_node) + Restschätzung(node_ziel)
(exakte Kosten werden durch Dijkstra ermittelt)

'''Idee:'''
* Sortiere den Heap nach geschätzten Gesamtkosten.
* Satz:
Falls jede Schätzung den exakten Weg unterschätzt, werden die gleichen Pfade gefunden, wie
bei Dijkstra (also die korrekten kürzesten Pfade).
(Die Schätzung für den restlichen Weg muss man immer so einrichten, dass der tatsächliche Weg unterschätzt wird. Da keine Straße kürzer sein kann als die Luftlinie, ist die Luftlinie eine geeignete Annahme für A*.)
* Falls der falsche Pfad im Heap eher an die Spitze kommt als der richtige Pfad, findet der A*-Algorithmus den falschen Pfad.
* Wenn der Pfad zum Ziel an der Spitze des Heap ist, dann wird keine Restschätzung mehr benötigt, denn wenn der Zielknoten aus dem Heap herrauskommt, dann hat man die exakte Berechnung. Die Restschätzung ist in diesem Fall 0. Wenn die Schätzung zu klein ist, wird der exakte Weg immer größer sein und zuerst aus dem Heap herauskommen.

[[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])]]
=='''Minimaler Spannbaum'''==
'''(engl.: minimum spanning tree; abgekürzt: MST)'''

:''gegeben'': gewichteter Graph, zusammenhängend 
:''gesucht'': Untermenge <math>E'\subseteq E</math>, so dass <math>\sum_{e\in E} w_e</math> minimal und G' zusammenhängend ist. 
* G'definiert dann einen Baum, denn andernfalls könnte man <math>\sum_{E'}</math>verringern (eine Kante weglassen) ohne die Zusammenhangskomponente zu verletzen. 

* Wenn der Graph nicht zusammenhängend ist, würde man den Spannbaum für jede Zusammenhangskomponente getrennt ausrechnen.
* Der MST ist ähnlich wie der Dijkstra-Algorithmus: Dort ist ein Pfad gesucht bei dem die Summe der Gewicht ü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, wobei ein beliebiger Baum für die Zusammenhangskomponente und beim MST ein minimaler Baum gesucht ist.

;Anwendungen
* '''Wie verbindet man ''n'' Punkte mit möglichst wenigen (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.

Zwei Algorithmen für dieses Problem
(im Vergleich zu Algorithmen für die Zusammenhangskomponente nur leicht verbesserte Algorithmen)

====Algorithmus von Prim====
[http://de.wikipedia.org/wiki/Algorithmus_von_Prim#Hashing_mit_offener_Adressierung Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]

:Idee: starte an der Wurzel (willkürlich gewählter Knoten) und füge jeweils die günstigste Kante hinzu (<math>\rightarrow</math> genau wie beim Dijsktra-Algorithmus, aber die Definitionen, welche Kante die günstigste ist, unterscheiden sich.)

import heapq
def prim(graph): #Graphdatenstruktur ist wie bei Dijsktra
heap = []
visited = [False]*len(graph)
sum = 0 #wird später das Gewicht des Spannbaums sein
r = [] #r ist die Lösung
visited[0] = True #fixed
for neighbor in graph[0]: #willkürlich 0 als Wurzel gewählt
heapq.heappush(heap, (neighbor[1], 0, neighbor[0])) #Heap wird gefüllt
while len(heap):
wn, start, ziel = heapq.heappop(heap)
if visited[ziel]: continue
visited[ziel] = True #wenn visited noch nicht besetzt
sum += wn #Addition des Gewichts der aktuellen Kante
r.append([start, ziel]) #Kante wird an die Lsg. angehängt
for neighbor in graph[ziel]:
if visited[neighbor[0]]: continue
heapq.heappush(heap, (neighbor[1], ziel, neighbor[0]))
return sum, r

====Algorithmus von Kruskal====
[http://de.wikipedia.org/wiki/Algorithmus_von_Kruskal Wikipedia (de)]
[http://en.wikipedia.org/wiki/Kruskal%27s_algorithm (en)]

Eine andere Vorgehensweise zur Bestimmung des minimalen Spannbaums besteht darin, einfach Kanten nacheinander hinzuzufügen und hierbei bei jedem Schritt die kürzeste Kante zu verwenden, die keinen Zyklus bildet. Anders ausgedrückt: Der Algorithmus beginnt mit ''N'' Bäumen; in (''N''-1) Schritten kombiniert er jeweils zwei Bäume (unter Verwendung der kürzesten möglichen Kante), bis nur noch ein Baum übrig bleibt.
Der Algorithmus von J.Kruskal ist seit 1956 bekannt.

* Idee: wie beim Union-Find-Algorithmus für Zusammenhangskomponenten

# Behandle jeden Knoten als Baum für sich
# Fasse zwei Bäume zu einem neuen Baum zusammen

* für MST (im Unterschied zu Union-Find): betrachte dazu die Kanten in aufsteigender Reihenfolge der Gewichte
(priority queue; ignoriere Kanten zwischen Knoten, die sich bereits im gleichem Baum befinden, was sich leicht daran erkennen läßt, dass ihre Anker gleich sind)

* Algorithmus eignet sich besser für das Clusteringproblem, da der Schwellwert von vornerein über die Kantenlänge an den Algorithmus übergeben werden kann. Man hört mit dem Vereinigen auf, wenn die Kantenlänge den Schwellwert überschreitet.
*Es kann keine kürzere Kante als der Schwellwert mehr kommen, da die Kanten vorher sortiert worden sind.

''Komplexität:'' gleich wie beim Dijkstra-Algorithmus, weil jede Kante höchstens einmal in den Heap kommt.
* Aufwand für Heap ist max. <math>E</math> Einträge, da jede Kante nur einmal im Heap sein kann, d.h. Heap hat den Aufwand: <math>O\left(E\log E\right)</math>, falls keine Mehrfachkanten vorhanden: <math>v^2 > E</math> und deshalb: log E < 2 log v.
* Daraus folgt, dass das dasselbe ist wie <math>O \left(E\log v\right)</math>

=> geeignet für Übungsaufgabe

== 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" | 2 ||style="background:silver; color:white" | 1 ||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>

= [http://de.wikipedia.org/wiki/Erfüllbarkeitsproblem_der_Aussagenlogik Erfüllbarkeitsproblem] =

geg.:
* n Boolsche Variablen <math>x_i \in \{True,False\}</math> und deren Negation <math>\neg x_i (i=1..n)</math>
* Logischer Ausdruck in <math>x_i,\neg x_i</math>
** zB <math>(x_1 \vee x_2) \wedge (x_3 \vee x_4)</math> ...

Grammatik eines logischen Ausdrucks(in [http://de.wikipedia.org/wiki/Backus-Naur-Form BNF]):
<EXP> ::= <DISJ>
<DISJ> ::= <CONJ> | <DISJ> <math>\vee</math> <CONJ>
<CONJ> ::= <TERM> | <CONJ> <math>\wedge</math> <TERM>
<TERM> ::= ( <EXPR> ) | ¬( <EXPR> ) | <VAR> | ¬<VAR>
<VAR> ::= <math>x_1</math> | ... | <math>x_n</math>

ges.: Eine Belegung der <math>x_i</math>, so dass der gegebene Ausdruck "True" wird

=== Naive Lösung ===
Probiere alle Bedingungen aus <math>\to</math> Komplexität <math>\mathcal{O}(2^{n}) \!</math> 
'''Im Allgemeinen ist das der effizienteste bekannte Algorithmus'''

== '''Normalformen''' von logischen Ausdrücken ==

=== k-Konjunktionen-Normalform(k-CNF) ===

* ein "Literal" ist eine Variable <math>x_i</math> oder deren Negation
* jeweils ''k'' Literale werden mit <math>\vee</math> in einer '''Disjunktion''' verknüpft
* Disjunktionen werden mit <math>\wedge</math> in einer '''Konjunktion''' verbunden

Grammatik eines Ausdrucks in k-CNF(wieder in [http://de.wikipedia.org/wiki/Backus-Naur-Form BNF]):
<EXP> ::= <CONJ>
<CONJ> ::= <DISJ> | <CONJ> <math>\wedge</math> <DISJ>
<DISJ> ::= ( <LIT> <math>\vee</math> ... <math>\vee</math> <LIT> ) 
<LIT> ::= <VAR> | <math>\neg</math><VAR>
<VAR> ::= <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> ...

Satz:
* Jeder logische Ausdruck kann in polynomieller Zeit in 3-CNF umgewandelt werden
* Im Allgemeinen kann ein logischer Ausdruck nicht in 2-CNF umgeschrieben werden

=== Implikationen-Normalform(INF) ===

Konjunktionen von Implikationen:
* zB <math>(x_1 \to x_2) \wedge (x_2 \to \neg x_3) \wedge (x_4 \to x_3)</math>

Grammatik eines Ausdrucks in INF(you know the drill ;)):
<EXP> ::= <CONJ>
<CONJ> ::= <IMPL> | <CONJ> <math>\wedge</math> <IMPL>
<IMPL> ::= ( <LIT> <math>\to</math> <LIT> )
<LIT> ::= <VAR> | <math>\neg</math><VAR>
<VAR> ::= <math>x_1</math> | ... | <math>x_n</math>

Satz:
* jeder Ausdruck in 2-CNF kann in INF umgewandelt werden (siehe z.B. [http://en.wikipedia.org/wiki/2-satisfiability#Conjunctive_normal_form_and_implicative_normal_form hier]):
*: <math> (x_i \vee x_j) \Leftrightarrow (\neg x_i \to x_j) \wedge (\neg x_j \to x_i) </math>

Außerdem kann jeder Ausdruck in INF als gerichteter Graph dargestellt werden
# Jede Variable und ihre Negation sind 1 Knoten(dh insgesamt 2 Knoten)
# Jede Implikation ist eine gerichtete Kante

== Stark zusammenhängende Komponenten ==

geg.: gerichteter Graph

1. Bestimme die post Order Time (mit Tiefensuche)
2. Transponieren des Graphen <math>G^T</math>
3. Bestimme ConnComp <math>G^T</math> mit bekannten CC Algorithmen, aber so, dass Knoten in absteigender post Order behandelt werden

[[Image:Curva.png|thumb|250px|none]] Beweis: 1.Bilde Komponentengraphen:
'''Knoten:''' jede SCC <math>C_i</math> ist ein Knoten
'''Kanten:''' <math>C_i \rightarrow C_j \Leftrightarrow U_k \rightarrow U_l</math> mit <math>U_k \in C_i</math> und <math>U_l \in C_j</math>

'''*Eigenschaft 1:''' der Komponentengraph ist :''azyklisch'':
<math>pot \left(C_i\right) = max_{U_k \in C_i} pot\left(U_k\right)</math>

'''*Eigenschaft 2:''' falls <math>C_i \rightsquigarrow C_j</math> dann <math>pot \left(C_i\right) > pot \left(C_j\right)</math>
(ausserdem gilt: es gibt keinen Weg <math>C_j \rightsquigarrow C_i</math> )
aber: in transponierten Graphen sind alle Kanten umgedreht

'''*Eigenschaft 3:''' falls <math>{C_j}^T \rightsquigarrow {C_i}^T</math> , dann gilt <math>pot \left({C_i}^T\right) > pot \left({C_j}^T\right)</math>

Eigenschaft 2-3 <math>\Longrightarrow</math> im transponierten Graphen gibt es nie einen Pfad <math>{C_i}^T \rightsquigarrow {C_j}^T</math>

Falls <math>pot \left({C_i}^T\right) > pot \left({C_j}^T\right)</math>

<math>\Longrightarrow</math> Schritt 3 des Algorithmus kann von einem geg. Startknoten ''nur'' die Knoten derselben SCC erreichen

q.e.d.

=== postOrderTime ===

## In einem Baum: besuche erst die Kinder, dann die Wurzel
def postOrderTime(graph):
visited = [None] * len(graph)
def visit(node, count):
#markiert, dass 'node' besucht wurde, aber noch nicht fertig ist
visited[node] = -1
for neighbor in graph[node]:
if visited[neighbor] is not None: continue
count = visit(neighbor, count)
visited[node] = count
count += 1
return count
count = 0
for node in range(len(graph)):
if visited[node] is not None: continue
count = visit(node, count)
return visited

=== transpose ===

## Kehre die Richtung der Pfeile in einem Graphen um (tut nichts fuer ungerichtete Pfeile und Graphen).
def transpose(graph):
grapht = [[] for k in range(len(graph))]
for node in range(len(graph)):
for neighbor in graph[node]:
grapht[neighbor].append(node)
return grapht

=== strongCC ===

## Jede Komponente durch e. Ankerknoten repräsentiert
## Jedes SCC ist die Menge aller Knoten mit identischem Ankterknoten
def strongCC(graph):
# Prinzip: Tiefensuche mit absteigender Post-Order-Time
postOrder = postOrderTime(graph)
# ordered = [(knotenindex, POT), ...]
ordered = zip(range(len(graph)), postOrder)
ordered.sort(key=lambda x: x[1], reverse=True)

grapht = transpose(graph)
anchors = [None] * len(graph)
def visit(node, anchor):
if anchors[node] is not None: return
anchors[node] = anchor
for neighbor in grapht[node]:
visit(neighbor, anchor)

for node in ordered:
visit(node[0], node[0])
return anchors

== Anwendung auf 2-SAT Problem ==

geg.: Implikationen-Normalform, dargestellt als gerichteter Graph.

Eigenschaft: alle Variablen in derselben SCC müssen den gleichen Wert haben, weil

<math>\underbrace{x_i \rightsquigarrow x_j \stackrel{\wedge}{=} x_i \rightarrow x_j; \;\;\; x_j \rightsquigarrow x_i \stackrel{\wedge}{=} x_j \rightarrow x_i}</math>

:::::<math>\;\;\;x_i == x_j</math>

<math>\rightarrow \; x_i \; und \; \neg x_i</math> dürfen nie in derselben SCC sein, weil <math>x_i == \neg x_i</math> ein Widerspruch ist

<math>\Longrightarrow</math> Algorithmus für Erfüllbarkeit von INF: teste diese Eigenschaft für jede stark zusammenhängende Komponente
des Implikationengraphen

'''Das funktioniert leider nicht für k-SAT mit <math>k>2</math>'''

[[Randomisierte Algorithmen|Nächstes Thema]]

Graphen und Graphenalgorithmen

2010-08-12T09:06:14Z

Jschleic: bäume zu Definitionen, einige Typos und Codekorrekturen

== 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 Abbildung) einen Spaziergang zu unternehmen, bei dem jede der 7 Brücken genau einmal überquert wird?

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

Inzwischen haben Graphen ein 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.

;Transponierter Graph: 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 dann 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 transpose(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 ==

=== Tiefensuche in Graphen ===

Sei der Graph gegeben als Liste von Listen = g

def dfs (g,node,v=0):
if v == 0:
v = [0]*len(g) #visited-Liste
v[node] = 1 #besuche node
for t in g[node]: #gehe zu allen Nachbarn
if v[t] == 0: #falls diese noch nicht besucht
dfs(g,t,v) #Rekursion

[[Image:Tiefens.jpg]]

Aufruf dfs(g,1)

=>Folge 1,2,4,3,6,7,5

=== Breitensuche ===

from Queue import *
def bfs(g,startnode)
v = [0]*len(g)
q = Queue()
v[startnode] = 1 #besuche
q.put(startnode) #in Schlange
while not q.empty():
node = q.get()
for t in g[node]:
if v[t] == 0:
v[t] = 1
q.put(t)

Aufgrund von Problemen mit der Implementation von Queue eine neue Version:

def bfs(g,startnode)
v = [0]*len(g)
q = []
v[startnode] = 1 #besuche
q.append(startnode) #in Schlange
while not len(q):
node = q.pop(0)
for t in g[node]:
if v[t] == 0:
v[t] = 1
q.append(t)

[[Image:Breitens.jpg]]

=>Folge 1,2,3,4,5,6,7

== Damenproblem ==

---------------
| | X | | |
|---|---|---|---|
| | | | X |
|---|---|---|---|
| X | | | |
|---|---|---|---|
| | | | X |
---------------

4 Damen auf einem vereinfachten Schachbrett so Positionieren, dass sich keine bedroht.

erster Durchlauf:

[[Image:Suche1.jpg]]

zweiter Durchlauf:

[[Image:Suche2.jpg]]

== Weitere Anwendungen (18.06.08) ==

def dfs(graph):
'''
Diese Tiefensuche tut so noch nichts weiter als zu traversieren
+ graph ist Array,
i-ter Eintrag enthaelt Adjazenzliste (auch Array) des i-ten Knotens,
wobei Knoten nummeriert von 0 ... v-i
'''
def visit(graph, node, visited):
'''
visited ist Array mit Flags fuer besuchte Knoten
'''
if visited[node]: return
visited[node] = True
for neighbor in graph[node]:
visit(graph, neighbor, visited)
visited = [False]*len(graph)
for node in range(len(graph)):
visit(graph, node, visited)

=== Finden von Zusammenhangskomponenten ===

Ein möglicher Einsatz des Verfahrens ist das Finden von Zusammenhangskomponenten (connected components).

* Beispiel: ...

* Definition: CC_i = {u_k, u_l e V: es gibt einen Pfad von u_k nach u_l ("u_l ist von u_k aus erreichbar")
* für gerichtete Graphen gilt zusätzlich: es gibt einen Pfad von u_l nach u_k}

Die Relation CC_i, also die Zusammenhangskomponenten (ZK) bilden eine Aequivalenzrelation,
also kann fuer jede ZK ein Repraesentant bestimmt werden (der sog. "Anker"). Kennt jeder
Knoten seinen Anker, so ist das ZK-Problem geloest.

==== Tiefensuchen-Algorithmus ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden, wobei statt
Knotenbesuche Knotennummern fuer die schon gefundenen Anker gesetzt werden. Ein moeglicher
Algorithmus lautet damit wie folgt:

def connectedComponents(graph):
def visit(graph, node, anchors, anchor):
'''
anchor ist Anker der aktuellen ZK
'''
if anchors[node] is not None: return # Anker von <node> schon bekannt
anchors[node] = anchor
for neighbor in graph[node]
visit(graph, neighbor, anchors, anchor)

anchors = [None]*len(graph)
for node in range(len(graph)):
visit(graph, node, anchors, node) # node: Anker der naechste ZK = erster Knoten der ZK
return anchors

* Beispiel: ...

==== Union-Find-Algorithmus ====

Eine Alternative (ohne Tiefensuche) waere z.B. ein Union-Find-Algorithmus. Idee dabei ist, dass eingangs jeder Knoten eine eigene ZK bildet, wobei in einer anschliessenden Rekursion Kanten gesucht werden, die zwischen den ZK bestehen.

Initialisierung: jeder Knoten wird als 1 ZK behandelt
Rekursion: fasse ZK zusammen (Union) falls Kante zwischen ihnen existiert
Ergebnis: Array mit dem Anker jedes Knotens

def unionFindCC(graph):
def findAnchor(anchors, k):
'''
#Prueft auf anchors[k]==k
'''
while anchors[k] != k:
k = anchors[k]
return k

def edges(graph):
e = []
for node in range(len(graph)):
for n in graph[node]:
if node < n:
e.append((node, n))
return e

anchors = range(len(graph)) # jeder Knoten ist sein eigener Anker
for edge in edges(graph):
# diese Schleife ordnet die Anker so, dass
# der 1. Anker immer der kleinste ist
a1, a2 = findAnchor(anchors, edge[0]), findAnchor(anchors, edge[1])
if a2 < a1: a2,a1 = a1,a2
if a1 != a2: anchors[a2] = a1
for node in range(len(graph)):
# diese Schleife raeumt mit Indirektionen auf (s. Bsp. (#))
anchors[node] = findAnchor(anchors, node)
return anchors

* Beispiel (#): ...

Eine verbreitete Anwendung fuer dieses Verfahren gibt es in der Bildverarbeitung:

* Beispiel: ...

== Variationen der Tiefensuche (19.06.2008) ==

=== Wichtige Algorithmen, die in der Vorlesung nicht behandelt werden ===

* Max Flow (zur Bestimmung des maximalen Flusses durch ein Netzwerk, z.B. bei Ölpipelines)
* Matching (auch ''Paarung'' genannt): Teilmenge der Kanten eines Graphen, wobei keine zwei Kanten einen gleichen Knoten besitzen
*:Anwendungsbereiche: Zuordnung von Gruppen, z.B. Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot), Universität (Zuordnung Studenten - Übungsgruppen)

=== Vereinfachte Lösung für den ''acyclic''-Algorithmus ===
Zum Finden von Zyklen, bzw. der Feststellung, ob ein Graph azyklisch ist, verwenden wir
wieder eine modifizierte Version der Tiefensuche: Die Knoten werden wieder nach dem System der Tiefensuche besucht, und alle besuchten Knoten in einem Array visited abgespeichert. Es gibt einen Zyklus genau dann, wenn man zu
einem früheren Knoten (außer zum direkten Vorgaenger) zurückkommt.

<code python>
def acyclic(graph):
def visit(graph, node, fromNode, visited):
if visited[node]: # Zyklus entdeckt
return False
visited[node] = True
for neighbor in graph[node]:
if neighbor == fromNode: # überspringe Nachbar, von dem du gekommen bist
continue
if not visit(graph, neighbor, node, visited):
return False # der Graph ist zyklisch
return True # kein Zyklus
visited = [False]*len(graph)
for node in range(len(graph)):
if visited[node]: # schließt aus, dass Knoten besucht wird, der schon besucht war
continue
if not visit(graph, node, None, visited):
return False
return True
</code>

'''Anmerkungen zum Code:'''

* Wenn ein Knoten bereits besucht ist, dann gehört er zur gleichen Zusammenhangskomponente - dies hat allerdings nichts mit einem Zyklus zu tun.
* Ein Graph der einmal zyklisch war wird nie wieder azyklisch.
* Der obige Algorithmus weist Ähnlichkeiten mit den bereits behandelten Algorithmen auf: '''ein guter Algorithmus zeichnet sich dadurch aus, dass mit kleinen Code-Variationen ganz andere Probleme gelöst werden können'''.

=== Kürzeste Wege (Pfade) ===

* Definition: gewichteter Graph

Jeder Kante e ist eine reelle oder natürliche Zahl we zugeordnet (wird auch als
''Kantengewicht'' bezeichnet).

z.B.
* Abstand der Anfangs- und Endknoten

* Durchflusskapazität eines Rohres (für max-Flussprobleme)

* Wechselkurse (Darstellung in einem gerichteten Graph, da jede Kante auch eine Richtung hat. Die Knoten sind die Währungen, die Kanten sind die Wechselkurse. Auf diese Weise lassen sich unterschiedliche Wechselkurse + Bankgebühren darstellen.)

* '''Definition''': Problem des kürzesten Weges

Sei P die Menge aller Wege von u nach v

Puv = {u_v}

und der Weg gegeben durch

u → x1 → x2 → ... → v

dann sind die Kosten eines Weges definiert durch

Kosten (Puv) = <math>\sum\limits_{l \in Pv}</math> we

* gesucht: Pfad u_v, so dass Kosten (u_v) minimal sind

* Lösung: Algorithmus von Dijkstra

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

<code python>
import heapq # heapq ist ein Modul von Python
def dijkstra(graph, start, ziel): # graph: gewichtete Adjazenzliste
heap = []
visited = [None]*len(graph)
visited[start] = start
for neighbor in graph[start]:
heapq.heappush(heap, (neighbor[1], start, neighbor[0])) # neighbor[1]:Kantengewicht,neighbor[0]:Endpunkt d. K.
while len(heap) > 0: # solange der heap nicht leer ist
w, fromNode, node = heapq.heappop(heap)
if visited[node] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
visited[node] = fromNode # baue Vorgänger-Baum
if node == ziel: # da der heap noch nicht leer ist, wird an dieser Stelle ein break benötigt
break
for neighbor in graph[node]:
if visited[neighbor[0]] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
heapq.heappush(heap, (neighbor[1]+w, node, neighbor[0]))
bestPath = []
t = ziel
while t != visited[t]: # Array wird durchlaufen bis der Anker des Pfades gefunden ist, vgl. Union-Search
bestPath.append(t)
t=visited[t]
bestPath.append(start)
return bestPath # bestPath.reverse()
</code>

'''Anmerkungen zum Code:'''
* der graph ist eine gewichtete Adjazenzliste

{|

|-

| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | Endknoten || → || style="background:silver; color:white" | Endknoten || (Nr. der Nachbarn des Knoten 0)

|-

| || style="background:silver; color:white" | 1 || || style="background:silver; color:white" | Gewicht || || style="background:silver; color:white" | Gewicht || (Gewicht der jeweiligen Kante)

|-

| || style="background:silver; color:white" | 2 ||

|-

| || style="background:silver; color:white" | 3 ||

|}
* Eingabe z.B.:
{|
|-
| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | (1, 0.3) || style="background:silver; color:white" | (3, 0.1) || style="background:silver; color:white" | (5, 1.2) ||
|-
| || style="background:silver; color:white" | 1 || → || style="background:silver; color:white" | || style="background:silver; color:white" | || style="background:silver; color:white" | ||
|-
| || style="background:silver; color:white" | 2 ||
|-
| || style="background:silver; color:white" | 3 ||
|-
| || style="background:silver; color:white" | 4 ||
|-
| || style="background:silver; color:white" | 5 ||
|-
| || style="background:silver; color:white" | 6 ||
|}
* heapq() verwendet den 1. Eintrag des Tupels zum sortieren des heap

==== Prinzip des Dijkstra-Algorithmus ====

* Algorithmus ist Tiefensuche mit Prioritätswarteschlange (Heap) statt eines Stapelspeichers (Stack) → vgl. Übung 8

* Die Prioritätswarteschlange speichert die kürzesten Wege, die bereits gefunden worden sind.

* Wenn man die Prioritätswarteschlange (Heap) durch eine Warteschlange (Queue) ersetzt, erhält man Breitensuche.

* Wenn man die Prioritätswarteschlange (Heap) durch einen Stapelspeicher (Stack) ersetzt, erhält man Tiefensuche.

==== Beispiel ====

[[Image:Bsp.jpg]]

* An der Stelle "neighbor[1]" wird eine Zählvariable ''count'' eingefügt, die hoch (Breitensuche) oder runter (Tiefensuche) zählt.

* Die Gewichte werden hoch- oder runtergezählt, so wie die Kanten gesehen wurden.

* Wenn man rückwärts zählt (von 0 abziehen), werden die zuletzt hinzugefügten Kanten expandiert.

* '''Algorithmus von Dijkstra funktioniert nur für positive Kantengewichte
*:<math>\forall</math> we > 0'''

* Bei negativen Kantengewichten könnte es Zyklen geben, die negative Kosten für den ganzen Zyklus haben:

/\ 1. Durchlauf: Kosten -1
1 / \ -4 2. Durchlauf: Kosten -2
/____\ etc.
2

* Verwendung bei arbitragen Geschäften (Börsengeschäfte, die die Preis-, Kurs- und Zinsunterschiede auf verschiedenen Märkten ausnutzen):
*:EURO wurden in YEN, YEN in DOLLAR gewechselt und das Geld hat sich dadurch vermehrt
* Für negative Kantengewichte verwendet man den Bellman-Ford-Allgorithmus, der allerdings langsamer ist, als der Dijkstra-Algorithmus.

==== Komplexität von Dijkstra ====

* Jeder Knoten wird höchstens 1x expandiert (Iteration über die Nachbarn des Knotens).

* Jeder Knoten kann mehrmals im Heap enthalten sein.

* Es sind aber höchstens E (Anzahl der Kanten) Heap-Einträge möglich, da jede Kante höchstens 1 Heap-Eintrag generiert (ein Knoten ist nur dann im Heap, wenn man ihn über eine Kante erreicht hat, die man vorher noch nicht besucht hatte). Deshalb können nie mehr Einträge im Heap sein, als es Kanten gibt. Die Komplexität von heappush(), heappop() ist
O(log E) = O(2 log v) = O(log v)
wenn alle Kanten einen Heap-Eintrag generiert haben.
* Die while-Schleife wird im schlimmsten Fall E mal durchlaufen, deshalb ist die Komplexität von Dijkstra O(E log v).

==== Korrektheit von Dijkstra ====

* Falls
visited[node] (Schleifen-Invariante von while) != None
ist, dann liefert Zurückverfolgen des Pfades von node nach start den kürzesten Pfad von start nach node (gilt für alle Knoten, für die das visited-Feld gesetzt ist).
* Induktionsanfang: visited[start] ist einziger not-None-Fall → Bedingung erfüllt
* Induktionsschritt: wenn visited[node] gesetzt wird, ist es ein kürzester Pfad

==== Indirekter Beweis ====

Set S = {node | visited[node] != None} (alle Knoten, von denen wir den kürzesten Pfad schon kennen)

* u ist der Knoten an der Spitze des Heaps
* fromNode <math>\in</math> S (ein Nachbar von node kommt erst dann in den Heap, wenn visited[node] vorher gesetzt wurde)
* falls u → fromNode → start kein kürzester Pfad wäre, müsste u's Vorgänger in V\S sein
* sei dieser Vorgänger x <math>\notin</math> S, x <math>\not=</math> u
* sei wx das Gewicht der Kante x → u, dann sind die Kosten für start nach u gleich

Kosten(start_u) = Kosten(start_x) + wx

* Annahme des indirekten Beweises:

Kosten(start_fromNode) + wfromNode

* Behauptung des indirekten Beweises:
Es gibt einen anderen Pfad x, so dass die Kosten von start nach x geringer sind

* Da aber gilt:
fromNode <math>\in</math> S und x <math>\notin</math> S

* gilt (Induktionsvoraussetzung):
Kosten(start_fromNode) < Kosten(start_x)

* Falls Kosten(start_x) < Kosten(start_u) müsste x im Heap vor u kommen; daraus folgt, dass u nicht an der Spitze des Heaps sein kann

→ Widerspruch!

→ Die Behauptung, der Weg über x ist besser, kann nicht stimmen.

→ Korrektheit von Dijkstra ist somit bewiesen.

==== Wie kann man Dijkstra noch verbessern? ====

===== A*-Algorithmus =====

* Verbesserung von Dijkstra im typischen Fall, aber die Komplexität ist immer noch =(Elog v) im schlechtesten Fall (die Komplexität kann man nicht verbessern, aber die Laufzeit im typischen Fall).
* Schätzung für jeden Knoten für den restlichen Weg:
geschätzte Gesamtkosten: Kosten(start_node) + Restschätzung(node_ziel)
(exakte Kosten werden durch Dijkstra ermittelt)

'''Idee:'''
* Sortiere den Heap nach geschätzten Gesamtkosten.
* Satz:
Falls jede Schätzung den exakten Weg unterschätzt, werden die gleichen Pfade gefunden, wie
bei Dijkstra (also die korrekten kürzesten Pfade).
(Die Schätzung für den restlichen Weg muss man immer so einrichten, dass der tatsächliche Weg unterschätzt wird. Da keine Straße kürzer sein kann als die Luftlinie, ist die Luftlinie eine geeignete Annahme für A*.)
* Falls der falsche Pfad im Heap eher an die Spitze kommt als der richtige Pfad, findet der A*-Algorithmus den falschen Pfad.
* Wenn der Pfad zum Ziel an der Spitze des Heap ist, dann wird keine Restschätzung mehr benötigt, denn wenn der Zielknoten aus dem Heap herrauskommt, dann hat man die exakte Berechnung. Die Restschätzung ist in diesem Fall 0. Wenn die Schätzung zu klein ist, wird der exakte Weg immer größer sein und zuerst aus dem Heap herauskommen.

[[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])]]
=='''Minimaler Spannbaum'''==
'''(engl.: minimum spanning tree; abgekürzt: MST)'''

:''gegeben'': gewichteter Graph, zusammenhängend 
:''gesucht'': Untermenge <math>E'\subseteq E</math>, so dass <math>\sum_{e\in E} w_e</math> minimal und G' zusammenhängend ist. 
* G'definiert dann einen Baum, denn andernfalls könnte man <math>\sum_{E'}</math>verringern (eine Kante weglassen) ohne die Zusammenhangskomponente zu verletzen. 

* Wenn der Graph nicht zusammenhängend ist, würde man den Spannbaum für jede Zusammenhangskomponente getrennt ausrechnen.
* Der MST ist ähnlich wie der Dijkstra-Algorithmus: Dort ist ein Pfad gesucht bei dem die Summe der Gewicht ü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, wobei ein beliebiger Baum für die Zusammenhangskomponente und beim MST ein minimaler Baum gesucht ist.

;Anwendungen
* '''Wie verbindet man ''n'' Punkte mit möglichst wenigen (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.

Zwei Algorithmen für dieses Problem
(im Vergleich zu Algorithmen für die Zusammenhangskomponente nur leicht verbesserte Algorithmen)

====Algorithmus von Prim====
[http://de.wikipedia.org/wiki/Algorithmus_von_Prim#Hashing_mit_offener_Adressierung Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]

:Idee: starte an der Wurzel (willkürlich gewählter Knoten) und füge jeweils die günstigste Kante hinzu (<math>\rightarrow</math> genau wie beim Dijsktra-Algorithmus, aber die Definitionen, welche Kante die günstigste ist, unterscheiden sich.)

import heapq
def prim(graph): #Graphdatenstruktur ist wie bei Dijsktra
heap = []
visited = [False]*len(graph)
sum = 0 #wird später das Gewicht des Spannbaums sein
r = [] #r ist die Lösung
visited[0] = True #fixed
for neighbor in graph[0]: #willkürlich 0 als Wurzel gewählt
heapq.heappush(heap, (neighbor[1], 0, neighbor[0])) #Heap wird gefüllt
while len(heap):
wn, start, ziel = heapq.heappop(heap)
if visited[ziel]: continue
visited[ziel] = True #wenn visited noch nicht besetzt
sum += wn #Addition des Gewichts der aktuellen Kante
r.append([start, ziel]) #Kante wird an die Lsg. angehängt
for neighbor in graph[ziel]:
if visited[neighbor[0]]: continue
heapq.heappush(heap, (neighbor[1], ziel, neighbor[0]))
return sum, r

====Algorithmus von Kruskal====
[http://de.wikipedia.org/wiki/Algorithmus_von_Kruskal Wikipedia (de)]
[http://en.wikipedia.org/wiki/Kruskal%27s_algorithm (en)]

Eine andere Vorgehensweise zur Bestimmung des minimalen Spannbaums besteht darin, einfach Kanten nacheinander hinzuzufügen und hierbei bei jedem Schritt die kürzeste Kante zu verwenden, die keinen Zyklus bildet. Anders ausgedrückt: Der Algorithmus beginnt mit ''N'' Bäumen; in (''N''-1) Schritten kombiniert er jeweils zwei Bäume (unter Verwendung der kürzesten möglichen Kante), bis nur noch ein Baum übrig bleibt.
Der Algorithmus von J.Kruskal ist seit 1956 bekannt.

* Idee: wie beim Union-Find-Algorithmus für Zusammenhangskomponenten

# Behandle jeden Knoten als Baum für sich
# Fasse zwei Bäume zu einem neuen Baum zusammen

* für MST (im Unterschied zu Union-Find): betrachte dazu die Kanten in aufsteigender Reihenfolge der Gewichte
(priority queue; ignoriere Kanten zwischen Knoten, die sich bereits im gleichem Baum befinden, was sich leicht daran erkennen läßt, dass ihre Anker gleich sind)

* Algorithmus eignet sich besser für das Clusteringproblem, da der Schwellwert von vornerein über die Kantenlänge an den Algorithmus übergeben werden kann. Man hört mit dem Vereinigen auf, wenn die Kantenlänge den Schwellwert überschreitet.
*Es kann keine kürzere Kante als der Schwellwert mehr kommen, da die Kanten vorher sortiert worden sind.

''Komplexität:'' gleich wie beim Dijkstra-Algorithmus, weil jede Kante höchstens einmal in den Heap kommt.
* Aufwand für Heap ist max. <math>E</math> Einträge, da jede Kante nur einmal im Heap sein kann, d.h. Heap hat den Aufwand: <math>O\left(E\log E\right)</math>, falls keine Mehrfachkanten vorhanden: <math>v^2 > E</math> und deshalb: log E < 2 log v.
* Daraus folgt, dass das dasselbe ist wie <math>O \left(E\log v\right)</math>

=> geeignet für Übungsaufgabe

== 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" | 2 ||style="background:silver; color:white" | 1 ||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 Sterling 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>

= [http://de.wikipedia.org/wiki/Erfüllbarkeitsproblem_der_Aussagenlogik Erfüllbarkeitsproblem] =

geg.:
* n Boolsche Variablen <math>x_i \in \{True,False\}</math> und deren Negation <math>\neg x_i (i=1..n)</math>
* Logischer Ausdruck in <math>x_i,\neg x_i</math>
** zB <math>(x_1 \vee x_2) \wedge (x_3 \vee x_4)</math> ...

Grammatik eines logischen Ausdrucks(in [http://de.wikipedia.org/wiki/Backus-Naur-Form BNF]):
<EXP> ::= <DISJ>
<DISJ> ::= <CONJ> | <DISJ> <math>\vee</math> <CONJ>
<CONJ> ::= <TERM> | <CONJ> <math>\wedge</math> <TERM>
<TERM> ::= ( <EXPR> ) | ¬( <EXPR> ) | <VAR> | ¬<VAR>
<VAR> ::= <math>x_1</math> | ... | <math>x_n</math>

ges.: Eine Belegung der <math>x_i</math>, so dass der gegebene Ausdruck "True" wird

=== Naive Lösung ===
Probiere alle Bedingungen aus <math>\to</math> Komplexität <math>\mathcal{O}(2^{n}) \!</math> 
'''Im Allgemeinen ist das der effizienteste bekannte Algorithmus'''

== '''Normalformen''' von logischen Ausdrücken ==

=== k-Konjunktionen-Normalform(k-CNF) ===

* ein "Literal" ist eine Variable <math>x_i</math> oder deren Negation
* jeweils ''k'' Literale werden mit <math>\vee</math> in einer '''Disjunktion''' verknüpft
* Disjunktionen werden mit <math>\wedge</math> in einer '''Konjunktion''' verbunden

Grammatik eines Ausdrucks in k-CNF(wieder in [http://de.wikipedia.org/wiki/Backus-Naur-Form BNF]):
<EXP> ::= <CONJ>
<CONJ> ::= <DISJ> | <CONJ> <math>\wedge</math> <DISJ>
<DISJ> ::= ( <LIT> <math>\vee</math> ... <math>\vee</math> <LIT> ) 
<LIT> ::= <VAR> | <math>\neg</math><VAR>
<VAR> ::= <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> ...

Satz:
* Jeder logische Ausdruck kann in polynomieller Zeit in 3-CNF umgewandelt werden
* Im Allgemeinen kann ein logischer Ausdruck nicht in 2-CNF umgeschrieben werden

=== Implikationen-Normalform(INF) ===

Konjunktionen von Implikationen:
* zB <math>(x_1 \to x_2) \wedge (x_2 \to \neg x_3) \wedge (x_4 \to x_3)</math>

Grammatik eines Ausdrucks in INF(you know the drill ;)):
<EXP> ::= <CONJ>
<CONJ> ::= <IMPL> | <CONJ> <math>\wedge</math> <IMPL>
<IMPL> ::= ( <LIT> <math>\to</math> <LIT> )
<LIT> ::= <VAR> | <math>\neg</math><VAR>
<VAR> ::= <math>x_1</math> | ... | <math>x_n</math>

Satz:
* jeder Ausdruck in 2-CNF kann in INF umgewandelt werden (siehe z.B. [http://en.wikipedia.org/wiki/2-satisfiability#Conjunctive_normal_form_and_implicative_normal_form hier]):
*: <math> (x_i \vee x_j) \Leftrightarrow (\neg x_i \to x_j) \wedge (\neg x_j \to x_i) </math>

Außerdem kann jeder Ausdruck in INF als gerichteter Graph dargestellt werden
# Jede Variable und ihre Negation sind 1 Knoten(dh insgesamt 2 Knoten)
# Jede Implikation ist eine gerichtete Kante

== Stark zusammenhängende Komponenten ==

geg.: gerichteter Graph

1. Bestimme die post Order Time (mit Tiefensuche)
2. Transponieren des Graphen <math>G^T</math>
3. Bestimme ConnComp <math>G^T</math> mit bekannten CC Algorithmen, aber so, dass Knoten in absteigender post Order behandelt werden

[[Image:Curva.png|thumb|250px|none]] Beweis: 1.Bilde Komponentengraphen:
'''Knoten:''' jede SCC <math>C_i</math> ist ein Knoten
'''Kanten:''' <math>C_i \rightarrow C_j \Leftrightarrow U_k \rightarrow U_l</math> mit <math>U_k \in C_i</math> und <math>U_l \in C_j</math>

'''*Eigenschaft 1:''' der Komponentengraph ist :''azyklisch'':
<math>pot \left(C_i\right) = max_{U_k \in C_i} pot\left(U_k\right)</math>

'''*Eigenschaft 2:''' falls <math>C_i \rightsquigarrow C_j</math> dann <math>pot \left(C_i\right) > pot \left(C_j\right)</math>
(ausserdem gilt: es gibt keinen Weg <math>C_j \rightsquigarrow C_i</math> )
aber: in transponierten Graphen sind alle Kanten umgedreht

'''*Eigenschaft 3:''' falls <math>{C_j}^T \rightsquigarrow {C_i}^T</math> , dann gilt <math>pot \left({C_i}^T\right) > pot \left({C_j}^T\right)</math>

Eigenschaft 2-3 <math>\Longrightarrow</math> im transponierten Graphen gibt es nie einen Pfad <math>{C_i}^T \rightsquigarrow {C_j}^T</math>

Falls <math>pot \left({C_i}^T\right) > pot \left({C_j}^T\right)</math>

<math>\Longrightarrow</math> Schritt 3 des Algorithmus kann von einem geg. Startknoten ''nur'' die Knoten derselben SCC erreichen

q.e.d.

=== postOrderTime ===

## In einem Baum: besuche erst die Kinder, dann die Wurzel
def postOrderTime(graph):
visited = [None] * len(graph)
def visit(node, count):
#markiert, dass 'node' besucht wurde, aber noch nicht fertig ist
visited[node] = -1
for neighbor in graph[node]:
if visited[neighbor] is not None: continue
count = visit(neighbor, count)
visited[node] = count
count += 1
return count
count = 0
for node in range(len(graph)):
if visited[node] is not None: continue
count = visit(node, count)
return visited

=== transpose ===

## Kehre die Richtung der Pfeile in einem Graphen um (tut nichts fuer ungerichtete Pfeile und Graphen).
def transpose(graph):
grapht = [[] for k in range(len(graph))]
for node in range(len(graph)):
for neighbor in graph[node]:
grapht[neighbor].append(node)
return grapht

=== strongCC ===

## Jede Komponente durch e. Ankerknoten repräsentiert
## Jedes SCC ist die Menge aller Knoten mit identischem Ankterknoten
def strongCC(graph):
# Prinzip: Tiefensuche mit absteigender Post-Order-Time
postOrder = postOrderTime(graph)
# ordered = [(knotenindex, POT), ...]
ordered = zip(range(len(graph)), postOrder)
ordered.sort(key=lambda x: x[1], reverse=True)

grapht = transpose(graph)
anchors = [None] * len(graph)
def visit(node, anchor):
if anchors[node] is not None: return
anchors[node] = anchor
for neighbor in grapht[node]:
visit(neighbor, anchor)

for node in ordered:
visit(node[0], node[0])
return anchors

== Anwendung auf 2-SAT Problem ==

geg.: Implikationen-Normalform, dargestellt als gerichteter Graph.

Eigenschaft: alle Variablen in derselben SCC müssen den gleichen Wert haben, weil

<math>\underbrace{x_i \rightsquigarrow x_j \stackrel{\wedge}{=} x_i \rightarrow x_j; \;\;\; x_j \rightsquigarrow x_i \stackrel{\wedge}{=} x_j \rightarrow x_i}</math>

:::::<math>\;\;\;x_i == x_j</math>

<math>\rightarrow \; x_i \; und \; \neg x_i</math> dürfen nie in derselben SCC sein, weil <math>x_i == \neg x_i</math> ein Widerspruch ist

<math>\Longrightarrow</math> Algorithmus für Erfüllbarkeit von INF: teste diese Eigenschaft für jede stark zusammenhängende Komponente
des Implikationengraphen

'''Das funktioniert leider nicht für k-SAT mit <math>k>2</math>'''

[[Randomisierte Algorithmen|Nächstes Thema]]

Graphen und Graphenalgorithmen

2010-08-12T07:51:05Z

Jschleic: /* Definitionen */ typo

== 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 Abbildung) einen Spaziergang zu unternehmen, bei dem jede der 7 Brücken genau einmal überquert wird?

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

Inzwischen haben Graphen ein 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.

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

;Transponierter Graph: 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 dann 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 transpose(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

== Bäume und Wälder ==

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

== Durchlaufen von Graphen ==

=== Tiefensuche in Graphen ===

Sei der Graph gegeben als Liste von Listen = g

def dfs (g,node,v=0):
if v == 0:
v = [0]*len(g) #visited-Liste
v[node] = 1 #besuche node
for t in g[node]: #gehe zu allen Nachbarn
if v[t] == 0: #falls diese noch nicht besucht
dfs(g,t,v) #Rekursion

[[Image:Tiefens.jpg]]

Aufruf dfs(g,1)

=>Folge 1,2,4,3,6,7,5

=== Breitensuche ===

from Queue import *
def bfs(g,startnode)
v = [0]*len(g)
q = Queue()
v[startnode] = 1 #besuche
q.put(startnode) #in Schlange
while not q.empty():
node = q.get()
for t in g[node]:
if v[t] == 0:
v[t] = 1
q.put(t)

Aufgrund von Problemen mit der Implementation von Queue eine neue Version:

def bfs(g,startnode)
v = [0]*len(g)
q = []
v[startnode] = 1 #besuche
q.append(startnode) #in Schlange
while not len(q):
node = q.pop(0)
for t in g[node]:
if v[t] == 0:
v[t] = 1
q.append(t)

[[Image:Breitens.jpg]]

=>Folge 1,2,3,4,5,6,7

== Damenproblem ==

---------------
| | X | | |
|---|---|---|---|
| | | | X |
|---|---|---|---|
| X | | | |
|---|---|---|---|
| | | | X |
---------------

4 Damen auf einem vereinfachten Schachbrett so Positionieren, dass sich keine bedroht.

erster Durchlauf:

[[Image:Suche1.jpg]]

zweiter Durchlauf:

[[Image:Suche2.jpg]]

== Weitere Anwendungen (18.06.08) ==

def dfs(graph):
'''
Diese Tiefensuche tut so noch nichts weiter als zu traversieren
+ graph ist Array,
i-ter Eintrag enthaelt Adjazenzliste (auch Array) des i-ten Knotens,
wobei Knoten nummeriert von 0 ... v-i
'''
def visit(graph, node, visited):
'''
visited ist Array mit Flags fuer besuchte Knoten
'''
if visited[node]: return
visited[node] = True
for neighbor in graph[node]:
visit(graph, neighbor, visited)

visited = [False]*len(graph)
for node in range(len(graph)):
visit(graph, node, visited)

=== Finden von Zusammenhangskomponenten ===

Ein moeglicher Einsatz des Verfahrens ist das Finden von Zusammenhangskomponenten (connected components).

* Beispiel: ...

* Definition: CC_i = {u_k, u_l e V: es gibt einen Pfad von u_k nach u_l ("u_l ist von u_k aus erreichbar")
* fuer gerichtete Graphen gilt zusaetzlich: es gibt einen Pfad von u_l nach u_k}

Die Relation CC_i, also die Zusammenhangskomponenten (ZK) bilden eine Aequivalenzrelation,
also kann fuer jede ZK ein Repraesentant bestimmt werden (der sog. "Anker"). Kennt jeder
Knoten seinen Anker, so ist das ZK-Problem geloest.

==== Tiefensuchen-Algorithmus ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden, wobei statt
Knotenbesuche Knotennummern fuer die schon gefundenen Anker gesetzt werden. Ein moeglicher
Algorithmus lautet damit wie folgt:

def connectedComponents(graph):
def visit(graph, node, anchors, anchor):
'''
anchor ist Anker der aktuellen ZK
'''
if anchors[node] is not None: return # Anker von <node> schon bekannt
anchors[node] = anchor
for neighbor in graph[node]
visit(graph, neighbor, anchors, anchor)

anchors = [None]*len(graph)
for node in range(len(graph)):
visit(graph, node, anchors, node) # node: Anker der naechste ZK = erster Knoten der ZK
return anchors

* Beispiel: ...

==== Union-Find-Algorithmus ====

Eine Alternative (ohne Tiefensuche) waere z.B. ein Union-Find-Algorithmus. Idee dabei ist, dass eingangs jeder Knoten eine eigene ZK bildet, wobei in einer anschliessenden Rekursion Kanten gesucht werden, die zwischen den ZK bestehen.

Initialisierung: jeder Knoten wird als 1 ZK behandelt
Rekursion: fasse ZK zusammen (Union) falls Kante zwischen ihnen existiert
Ergebnis: Array mit dem Anker jedes Knotens

def unionFindCC(graph):
def findAnchor(anchors, k):
'''
#Prueft auf anchors[k]==k
'''
while anchors[k] != k:
k = anchors[k]
return k

def edges(graph):
e = []
for node in range(len(graph)):
for n in graph[node]:
if node < n:
e.append((node, n))
return e

anchors = range(len(graph)) # jeder Knoten ist sein eigener Anker
for edge in edges(graph):
# diese Schleife ordnet die Anker so, dass
# der 1. Anker immer der kleinste ist
a1, a2 = findAnchor(anchors, edge[0]), findAnchor(anchors, edge[1])
if a2 < a1: a2,a1 = a1,a2
if a1 != a2: anchors[a2] = a1
for node in range(len(graph)):
# diese Schleife raeumt mit Indirektionen auf (s. Bsp. (#))
anchors[node] = findAnchor(anchors, node)

* Beispiel (#): ...

Eine verbreitete Anwendung fuer dieses Verfahren gibt es in der Bildverarbeitung:

* Beispiel: ...

== Variationen der Tiefensuche (19.06.2008) ==

=== Wichtige Algorithmen, die in der Vorlesung nicht behandelt werden ===

* Max Flow (zur Bestimmung des maximalen Flusses durch ein Netzwerk, z.B. bei Ölpipelines)
* Matching (auch ''Paarung'' genannt): Teilmenge der Kanten eines Graphen, wobei keine zwei Kanten einen gleichen Knoten besitzen
*:Anwendungsbereiche: Zuordnung von Gruppen, z.B. Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot), Universität (Zuordnung Studenten - Übungsgruppen)

=== Vereinfachte Lösung für den ''acyclic''-Algorithmus ===
Zum Finden von Zyklen, bzw. der Feststellung, ob ein Graph azyklisch ist, verwenden wir
wieder eine modifizierte Version der Tiefensuche: Die Knoten werden wieder nach dem System der Tiefensuche besucht, und alle besuchten Knoten in einem Array visited abgespeichert. Es gibt einen Zyklus genau dann, wenn man zu
einem früheren Knoten (außer zum direkten Vorgaenger) zurückkommt.

<code python>
def acyclic(graph):
def visit(graph, node, fromNode, visited):
if visited[node]: # Zyklus entdeckt
return False
visited[node] = True
for neighbor in graph[node]:
if neighbor == fromNode: # überspringe Nachbar, von dem du gekommen bist
continue
if not visit(graph, neighbor, node, visited):
return False # der Graph ist zyklisch
return True # kein Zyklus
visited = [False]*len(graph)
for node in range(len(graph)):
if visited[node]: # schließt aus, dass Knoten besucht wird, der schon besucht war
continue
if not visit(graph, node, None, visited):
return False
return True
</code>

'''Anmerkungen zum Code:'''

* Wenn ein Knoten bereits besucht ist, dann gehört er zur gleichen Zusammenhangskomponente - dies hat allerdings nichts mit einem Zyklus zu tun.
* Ein Graph der einmal zyklisch war wird nie wieder azyklisch.
* Der obige Algorithmus weist Ähnlichkeiten mit den bereits behandelten Algorithmen auf: '''ein guter Algorithmus zeichnet sich dadurch aus, dass mit kleinen Code-Variationen ganz andere Probleme gelöst werden können'''.

=== Kürzeste Wege (Pfade) ===

* Definition: gewichteter Graph

Jeder Kante e ist eine reelle oder natürliche Zahl we zugeordnet (wird auch als
''Kantengewicht'' bezeichnet).

z.B.
* Abstand der Anfangs- und Endknoten

* Durchflusskapazität eines Rohres (für max-Flussprobleme)

* Wechselkurse (Darstellung in einem gerichteten Graph, da jede Kante auch eine Richtung hat. Die Knoten sind die Währungen, die Kanten sind die Wechselkurse. Auf diese Weise lassen sich unterschiedliche Wechselkurse + Bankgebühren darstellen.)

* '''Definition''': Problem des kürzesten Weges

Sei P die Menge aller Wege von u nach v

Puv = {u_v}

und der Weg gegeben durch

u → x1 → x2 → ... → v

dann sind die Kosten eines Weges definiert durch

Kosten (Puv) = <math>\sum\limits_{l \in Pv}</math> we

* gesucht: Pfad u_v, so dass Kosten (u_v) minimal sind

* Lösung: Algorithmus von Dijkstra

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

<code python>
import heapq # heapq ist ein Modul von Python
def dijkstra(graph, start, ziel): # graph: gewichtete Adjazenzliste
heap = []
visited = [None]*len(graph)
visited[start] = start
for neighbor in graph[start]:
heapq.heappush(heap, (neighbor[1], start, neighbor[0])) # neighbor[1]:Kantengewicht,neighbor[0]:Endpunkt d. K.
while len(heap) > 0: # solange der heap nicht leer ist
w, fromNode, node = heapq.heappop(heap)
if visited[node] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
visited[node] = fromNode # baue Vorgänger-Baum
if node == ziel: # da der heap noch nicht leer ist, wird an dieser Stelle ein break benötigt
break
for neighbor in graph[node]:
if visited[neighbor[0]] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
heapq.heappush(heap, (neighbor[1]+w, node, neighbor[0]))
bestPath = []
t = ziel
while t != visited[t]: # Array wird durchlaufen bis der Anker des Pfades gefunden ist, vgl. Union-Search
bestPath.append(t)
t=visited[t]
bestPath.append(start)
return bestPath # bestPath.reverse()
</code>

'''Anmerkungen zum Code:'''
* der graph ist eine gewichtete Adjazenzliste

{|

|-

| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | Endknoten || → || style="background:silver; color:white" | Endknoten || (Nr. der Nachbarn des Knoten 0)

|-

| || style="background:silver; color:white" | 1 || || style="background:silver; color:white" | Gewicht || || style="background:silver; color:white" | Gewicht || (Gewicht der jeweiligen Kante)

|-

| || style="background:silver; color:white" | 2 ||

|-

| || style="background:silver; color:white" | 3 ||

|}
* Eingabe z.B.:
{|
|-
| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | (1, 0.3) || style="background:silver; color:white" | (3, 0.1) || style="background:silver; color:white" | (5, 1.2) ||
|-
| || style="background:silver; color:white" | 1 || → || style="background:silver; color:white" | || style="background:silver; color:white" | || style="background:silver; color:white" | ||
|-
| || style="background:silver; color:white" | 2 ||
|-
| || style="background:silver; color:white" | 3 ||
|-
| || style="background:silver; color:white" | 4 ||
|-
| || style="background:silver; color:white" | 5 ||
|-
| || style="background:silver; color:white" | 6 ||
|}
* heapq() verwendet den 1. Eintrag des Tupels zum sortieren des heap

==== Prinzip des Dijkstra-Algorithmus ====

* Algorithmus ist Tiefensuche mit Prioritätswarteschlange (Heap) statt eines Stapelspeichers (Stack) → vgl. Übung 8

* Die Prioritätswarteschlange speichert die kürzesten Wege, die bereits gefunden worden sind.

* Wenn man die Prioritätswarteschlange (Heap) durch eine Warteschlange (Queue) ersetzt, erhält man Breitensuche.

* Wenn man die Prioritätswarteschlange (Heap) durch einen Stapelspeicher (Stack) ersetzt, erhält man Tiefensuche.

==== Beispiel ====

[[Image:Bsp.jpg]]

* An der Stelle "neighbor[1]" wird eine Zählvariable ''count'' eingefügt, die hoch (Breitensuche) oder runter (Tiefensuche) zählt.

* Die Gewichte werden hoch- oder runtergezählt, so wie die Kanten gesehen wurden.

* Wenn man rückwärts zählt (von 0 abziehen), werden die zuletzt hinzugefügten Kanten expandiert.

* '''Algorithmus von Dijkstra funktioniert nur für positive Kantengewichte
*:<math>\forall</math> we > 0'''

* Bei negativen Kantengewichten könnte es Zyklen geben, die negative Kosten für den ganzen Zyklus haben:

/\ 1. Durchlauf: Kosten -1
1 / \ -4 2. Durchlauf: Kosten -2
/____\ etc.
2

* Verwendung bei arbitragen Geschäften (Börsengeschäfte, die die Preis-, Kurs- und Zinsunterschiede auf verschiedenen Märkten ausnutzen):
*:EURO wurden in YEN, YEN in DOLLAR gewechselt und das Geld hat sich dadurch vermehrt
* Für negative Kantengewichte verwendet man den Bellman-Ford-Allgorithmus, der allerdings langsamer ist, als der Dijkstra-Algorithmus.

==== Komplexität von Dijkstra ====

* Jeder Knoten wird höchstens 1x expandiert (Iteration über die Nachbarn des Knotens).

* Jeder Knoten kann mehrmals im Heap enthalten sein.

* Es sind aber höchstens E (Anzahl der Kanten) Heap-Einträge möglich, da jede Kante höchstens 1 Heap-Eintrag generiert (ein Knoten ist nur dann im Heap, wenn man ihn über eine Kante erreicht hat, die man vorher noch nicht besucht hatte). Deshalb können nie mehr Einträge im Heap sein, als es Kanten gibt. Die Komplexität von heappush(), heappop() ist
O(log E) = O(2 log v) = O(log v)
wenn alle Kanten einen Heap-Eintrag generiert haben.
* Die while-Schleife wird im schlimmsten Fall E mal durchlaufen, deshalb ist die Komplexität von Dijkstra O(E log v).

==== Korrektheit von Dijkstra ====

* Falls
visited[node] (Schleifen-Invariante von while) != None
ist, dann liefert Zurückverfolgen des Pfades von node nach start den kürzesten Pfad von start nach node (gilt für alle Knoten, für die das visited-Feld gesetzt ist).
* Induktionsanfang: visited[start] ist einziger not-None-Fall → Bedingung erfüllt
* Induktionsschritt: wenn visited[node] gesetzt wird, ist es ein kürzester Pfad

==== Indirekter Beweis ====

Set S = {node | visited[node] != None} (alle Knoten, von denen wir den kürzesten Pfad schon kennen)

* u ist der Knoten an der Spitze des Heaps
* fromNode <math>\in</math> S (ein Nachbar von node kommt erst dann in den Heap, wenn visited[node] vorher gesetzt wurde)
* falls u → fromNode → start kein kürzester Pfad wäre, müsste u's Vorgänger in V\S sein
* sei dieser Vorgänger x <math>\notin</math> S, x <math>\not=</math> u
* sei wx das Gewicht der Kante x → u, dann sind die Kosten für start nach u gleich

Kosten(start_u) = Kosten(start_x) + wx

* Annahme des indirekten Beweises:

Kosten(start_fromNode) + wfromNode

* Behauptung des indirekten Beweises:
Es gibt einen anderen Pfad x, so dass die Kosten von start nach x geringer sind

* Da aber gilt:
fromNode <math>\in</math> S und x <math>\notin</math> S

* gilt (Induktionsvoraussetzung):
Kosten(start_fromNode) < Kosten(start_x)

* Falls Kosten(start_x) < Kosten(start_u) müsste x im Heap vor u kommen; daraus folgt, dass u nicht an der Spitze des Heaps sein kann

→ Widerspruch!

→ Die Behauptung, der Weg über x ist besser, kann nicht stimmen.

→ Korrektheit von Dijkstra ist somit bewiesen.

==== Wie kann man Dijkstra noch verbessern? ====

===== A*-Algorithmus =====

* Verbesserung von Dijkstra im typischen Fall, aber die Komplexität ist immer noch =(Elog v) im schlechtesten Fall (die Komplexität kann man nicht verbessern, aber die Laufzeit im typischen Fall).
* Schätzung für jeden Knoten für den restlichen Weg:
geschätzte Gesamtkosten: Kosten(start_node) + Restschätzung(node_ziel)
(exakte Kosten werden durch Dijkstra ermittelt)

'''Idee:'''
* Sortiere den Heap nach geschätzten Gesamtkosten.
* Satz:
Falls jede Schätzung den exakten Weg unterschätzt, werden die gleichen Pfade gefunden, wie
bei Dijkstra (also die korrekten kürzesten Pfade).
(Die Schätzung für den restlichen Weg muss man immer so einrichten, dass der tatsächliche Weg unterschätzt wird. Da keine Straße kürzer sein kann als die Luftlinie, ist die Luftlinie eine geeignete Annahme für A*.)
* Falls der falsche Pfad im Heap eher an die Spitze kommt als der richtige Pfad, findet der A*-Algorithmus den falschen Pfad.
* Wenn der Pfad zum Ziel an der Spitze des Heap ist, dann wird keine Restschätzung mehr benötigt, denn wenn der Zielknoten aus dem Heap herrauskommt, dann hat man die exakte Berechnung. Die Restschätzung ist in diesem Fall 0. Wenn die Schätzung zu klein ist, wird der exakte Weg immer größer sein und zuerst aus dem Heap herauskommen.

[[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])]]
=='''Minimaler Spannbaum'''==
'''(engl.: minimum spanning tree; abgekürzt: MST)'''

:''gegeben'': gewichteter Graph, zusammenhängend 
:''gesucht'': Untermenge <math>E'\subseteq E</math>, so dass <math>\sum_{e\in E} w_e</math> minimal und G' zusammenhängend ist. 
* G'definiert dann einen Baum, denn andernfalls könnte man <math>\sum_{E'}</math>verringern (eine Kante weglassen) ohne die Zusammenhangskomponente zu verletzen. 

* Wenn der Graph nicht zusammenhängend ist, würde man den Spannbaum für jede Zusammenhangskomponente getrennt ausrechnen.
* Der MST ist ähnlich wie der Dijkstra-Algorithmus: Dort ist ein Pfad gesucht bei dem die Summe der Gewicht ü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, wobei ein beliebiger Baum für die Zusammenhangskomponente und beim MST ein minimaler Baum gesucht ist.

;Anwendungen
* '''Wie verbindet man ''n'' Punkte mit möglichst wenigen (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.

Zwei Algorithmen für dieses Problem
(im Vergleich zu Algorithmen für die Zusammenhangskomponente nur leicht verbesserte Algorithmen)

====Algorithmus von Prim====
[http://de.wikipedia.org/wiki/Algorithmus_von_Prim#Hashing_mit_offener_Adressierung Wikipedia (de)]
[http://en.wikipedia.org/wiki/Prim%27s_algorithm (en)]

:Idee: starte an der Wurzel (willkürlich gewählter Knoten) und füge jeweils die günstigste Kante hinzu (<math>\rightarrow</math> genau wie beim Dijsktra-Algorithmus, aber die Definitionen, welche Kante die günstigste ist, unterscheiden sich.)

import heapq
def prim(graph): #Graphdatenstruktur ist wie bei Dijsktra
heap = []
visited = [False]*len(graph)
sum = 0 #wird später das Gewicht des Spannbaums sein
r = [] #r ist die Lösung
visited[0] = True #fixed
for neighbor in graph[0]: #willkürlich 0 als Wurzel gewählt
heapq.heappush(heap, (neighbor[1], 0, neighbor[0])) #Heap wird gefüllt
while len(heap):
wn, start, ziel = heapq.heappop(heap)
if visited[ziel]: continue
visited[ziel] = True #wenn visited noch nicht besetzt
sum += wn #Addition des Gewichts der aktuellen Kante
r.append([start, ziel]) #Kante wird an die Lsg. angehängt
for neighbor in graph[ziel]:
if visited[neighbor[0]]: continue
heapq.heappush(heap, (neighbor[1], ziel, neighbor[0]))
return sum, r

====Algorithmus von Kruskal====
[http://de.wikipedia.org/wiki/Algorithmus_von_Kruskal Wikipedia (de)]
[http://en.wikipedia.org/wiki/Kruskal%27s_algorithm (en)]

Eine andere Vorgehensweise zur Bestimmung des minimalen Spannbaums besteht darin, einfach Kanten nacheinander hinzuzufügen und hierbei bei jedem Schritt die kürzeste Kante zu verwenden, die keinen Zyklus bildet. Anders ausgedrückt: Der Algorithmus beginnt mit ''N'' Bäumen; in (''N''-1) Schritten kombiniert er jeweils zwei Bäume (unter Verwendung der kürzesten möglichen Kante), bis nur noch ein Baum übrig bleibt.
Der Algorithmus von J.Kruskal ist seit 1956 bekannt.

* Idee: wie beim Union-Find-Algorithmus für Zusammenhangskomponenten

# Behandle jeden Knoten als Baum für sich
# Fasse zwei Bäume zu einem neuen Baum zusammen

* für MST (im Unterschied zu Union-Find): betrachte dazu die Kanten in aufsteigender Reihenfolge der Gewichte
(priority queue; ignoriere Kanten zwischen Knoten, die sich bereits im gleichem Baum befinden, was sich leicht daran erkennen läßt, dass ihre Anker gleich sind)

* Algorithmus eignet sich besser für das Clusteringproblem, da der Schwellwert von vornerein über die Kantenlänge an den Algorithmus übergeben werden kann. Man hört mit dem Vereinigen auf, wenn die Kantenlänge den Schwellwert überschreitet.
*Es kann keine kürzere Kante als der Schwellwert mehr kommen, da die Kanten vorher sortiert worden sind.

''Komplexität:'' gleich wie beim Dijkstra-Algorithmus, weil jede Kante höchstens einmal in den Heap kommt.
* Aufwand für Heap ist max. <math>E</math> Einträge, da jede Kante nur einmal im Heap sein kann, d.h. Heap hat den Aufwand: <math>O\left(E\log E\right)</math>, falls keine Mehrfachkanten vorhanden: <math>v^2 > E</math> und deshalb: log E < 2 log v.
* Daraus folgt, dass das dasselbe ist wie <math>O \left(E\log v\right)</math>

=> geeignet für Übungsaufgabe

== 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" | 2 ||style="background:silver; color:white" | 1 ||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 Sterling 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>

= [http://de.wikipedia.org/wiki/Erfüllbarkeitsproblem_der_Aussagenlogik Erfüllbarkeitsproblem] =

geg.:
* n Boolsche Variablen <math>x_i \in \{True,False\}</math> und deren Negation <math>\neg x_i (i=1..n)</math>
* Logischer Ausdruck in <math>x_i,\neg x_i</math>
** zB <math>(x_1 \vee x_2) \wedge (x_3 \vee x_4)</math> ...

Grammatik eines logischen Ausdrucks(in [http://de.wikipedia.org/wiki/Backus-Naur-Form BNF]):
<EXP> ::= <DISJ>
<DISJ> ::= <CONJ> | <DISJ> <math>\vee</math> <CONJ>
<CONJ> ::= <TERM> | <CONJ> <math>\wedge</math> <TERM>
<TERM> ::= ( <EXPR> ) | ¬( <EXPR> ) | <VAR> | ¬<VAR>
<VAR> ::= <math>x_1</math> | ... | <math>x_n</math>

ges.: Eine Belegung der <math>x_i</math>, so dass der gegebene Ausdruck "True" wird

=== Naive Lösung ===
Probiere alle Bedingungen aus <math>\to</math> Komplexität <math>\mathcal{O}(2^{n}) \!</math> 
'''Im Allgemeinen ist das der effizienteste bekannte Algorithmus'''

== '''Normalformen''' von logischen Ausdrücken ==

=== k-Konjunktionen-Normalform(k-CNF) ===

* ein "Literal" ist eine Variable <math>x_i</math> oder deren Negation
* jeweils ''k'' Literale werden mit <math>\vee</math> in einer '''Disjunktion''' verknüpft
* Disjunktionen werden mit <math>\wedge</math> in einer '''Konjunktion''' verbunden

Grammatik eines Ausdrucks in k-CNF(wieder in [http://de.wikipedia.org/wiki/Backus-Naur-Form BNF]):
<EXP> ::= <CONJ>
<CONJ> ::= <DISJ> | <CONJ> <math>\wedge</math> <DISJ>
<DISJ> ::= ( <LIT> <math>\vee</math> ... <math>\vee</math> <LIT> ) 
<LIT> ::= <VAR> | <math>\neg</math><VAR>
<VAR> ::= <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> ...

Satz:
* Jeder logische Ausdruck kann in polynomieller Zeit in 3-CNF umgewandelt werden
* Im Allgemeinen kann ein logischer Ausdruck nicht in 2-CNF umgeschrieben werden

=== Implikationen-Normalform(INF) ===

Konjunktionen von Implikationen:
* zB <math>(x_1 \to x_2) \wedge (x_2 \to \neg x_3) \wedge (x_4 \to x_3)</math>

Grammatik eines Ausdrucks in INF(you know the drill ;)):
<EXP> ::= <CONJ>
<CONJ> ::= <IMPL> | <CONJ> <math>\wedge</math> <IMPL>
<IMPL> ::= ( <LIT> <math>\to</math> <LIT> )
<LIT> ::= <VAR> | <math>\neg</math><VAR>
<VAR> ::= <math>x_1</math> | ... | <math>x_n</math>

Satz:
* jeder Ausdruck in 2-CNF kann in INF umgewandelt werden (siehe z.B. [http://en.wikipedia.org/wiki/2-satisfiability#Conjunctive_normal_form_and_implicative_normal_form hier]):
*: <math> (x_i \vee x_j) \Leftrightarrow (\neg x_i \to x_j) \wedge (\neg x_j \to x_i) </math>

Außerdem kann jeder Ausdruck in INF als gerichteter Graph dargestellt werden
# Jede Variable und ihre Negation sind 1 Knoten(dh insgesamt 2 Knoten)
# Jede Implikation ist eine gerichtete Kante

== Stark zusammenhängende Komponenten ==

geg.: gerichteter Graph

1. Bestimme die post Order Time (mit Tiefensuche)
2. Transponieren des Graphen <math>G^T</math>
3. Bestimme ConnComp <math>G^T</math> mit bekannten CC Algorithmen, aber so, dass Knoten in absteigender post Order behandelt werden

[[Image:Curva.png|thumb|250px|none]] Beweis: 1.Bilde Komponentengraphen:
'''Knoten:''' jede SCC <math>C_i</math> ist ein Knoten
'''Kanten:''' <math>C_i \rightarrow C_j \Leftrightarrow U_k \rightarrow U_l</math> mit <math>U_k \in C_i</math> und <math>U_l \in C_j</math>

'''*Eigenschaft 1:''' der Komponentengraph ist :''azyklisch'':
<math>pot \left(C_i\right) = max_{U_k \in C_i} pot\left(U_k\right)</math>

'''*Eigenschaft 2:''' falls <math>C_i \rightsquigarrow C_j</math> dann <math>pot \left(C_i\right) > pot \left(C_j\right)</math>
(ausserdem gilt: es gibt keinen Weg <math>C_j \rightsquigarrow C_i</math> )
aber: in transponierten Graphen sind alle Kanten umgedreht

'''*Eigenschaft 3:''' falls <math>{C_j}^T \rightsquigarrow {C_i}^T</math> , dann gilt <math>pot \left({C_i}^T\right) > pot \left({C_j}^T\right)</math>

Eigenschaft 2-3 <math>\Longrightarrow</math> im transponierten Graphen gibt es nie einen Pfad <math>{C_i}^T \rightsquigarrow {C_j}^T</math>

Falls <math>pot \left({C_i}^T\right) > pot \left({C_j}^T\right)</math>

<math>\Longrightarrow</math> Schritt 3 des Algorithmus kann von einem geg. Startknoten ''nur'' die Knoten derselben SCC erreichen

q.e.d.

=== postOrderTime ===

## In einem Baum: besuche erst die Kinder, dann die Wurzel
def postOrderTime(graph):
visited = [None] * len(graph)
def visit(node, count):
#markiert, dass 'node' besucht wurde, aber noch nicht fertig ist
visited[node] = -1
for neighbor in graph[node]:
if visited[neighbor] is not None: continue
count = visit(neighbor, count)
visited[node] = count
count += 1
return count
count = 0
for node in range(len(graph)):
if visited[node] is not None: continue
count = visit(node, count)
return visited

=== transpose ===

## Kehre die Richtung der Pfeile in einem Graphen um (tut nichts fuer ungerichtete Pfeile und Graphen).
def transpose(graph):
grapht = [[] for k in range(len(graph))]
for node in range(len(graph)):
for neighbor in graph[node]:
grapht[neighbor].append(node)
return grapht

=== strongCC ===

## Jede Komponente durch e. Ankerknoten repräsentiert
## Jedes SCC ist die Menge aller Knoten mit identischem Ankterknoten
def strongCC(graph):
# Prinzip: Tiefensuche mit absteigender Post-Order-Time
postOrder = postOrderTime(graph)
# ordered = [(knotenindex, POT), ...]
ordered = zip(range(len(graph)), postOrder)
ordered.sort(key=lambda x: x[1], reverse=True)

grapht = transpose(graph)
anchors = [None] * len(graph)
def visit(node, anchor):
if anchors[node] is not None: return
anchors[node] = anchor
for neighbor in grapht[node]:
visit(neighbor, anchor)

for node in ordered:
visit(node[0], node[0])
return anchors

== Anwendung auf 2-SAT Problem ==

geg.: Implikationen-Normalform, dargestellt als gerichteter Graph.

Eigenschaft: alle Variablen in derselben SCC müssen den gleichen Wert haben, weil

<math>\underbrace{x_i \rightsquigarrow x_j \stackrel{\wedge}{=} x_i \rightarrow x_j; \;\;\; x_j \rightsquigarrow x_i \stackrel{\wedge}{=} x_j \rightarrow x_i}</math>

:::::<math>\;\;\;x_i == x_j</math>

<math>\rightarrow \; x_i \; und \; \neg x_i</math> dürfen nie in derselben SCC sein, weil <math>x_i == \neg x_i</math> ein Widerspruch ist

<math>\Longrightarrow</math> Algorithmus für Erfüllbarkeit von INF: teste diese Eigenschaft für jede stark zusammenhängende Komponente
des Implikationengraphen

'''Das funktioniert leider nicht für k-SAT mit <math>k>2</math>'''

[[Randomisierte Algorithmen|Nächstes Thema]]

Hashing und assoziative Arrays

2010-08-10T15:06:44Z

Jschleic: /* Implementation */ typo

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

== Assoziative Arrays ==
Assoziative Arrays werden genau wie gewöhnliche Arrays benutzt, sie unterstützen also den lesenden und schreibenden Zugriff über einen Index i
X = a[i]
a[i] = x
Im Unterschied zum gewöhnlichen Array, wo i ein Integer im Bereich <math> i \in 0 \ldots N-1</math> sein muss, kann der Typ von i jetzt ''beliebig'' sein. Eine typische Anwendung ist ein Wörterbuch
x = toEnglish['Baum'] # ergibt 'tree'
In diesem Fall ist der Typ des Index <tt>string</tt>, was in der Praxis der häufigste Fall ist, 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 Index benutzt werden, für den entweder eine Ordnung oder eine Hashfunktion definiert ist. In erstem Fall realisiert man das assoziative Array mit Hilfe eines Suchbaums, in zweiten Fall mit Hilfe einer Hashtabelle.

==Realisierung des assoziativen Arrays als Suchbaum==

Wenn für den Indextyp des assoziativen Arrays eine Ordnung definiert ist (wenn also <tt>i1 < i2</tt> oder <tt>cmp(i1, i2)</tt> unterstützt werden), kann man das Indexierungsproblem auf das Suchproblem zurückführen, indem man die Indizes als Suchschlüssel verwendet. Im einfachsten Fall kann dies mit sequentieller Suche realisiert werden: Man verwendet ein gewöhnliches Array, dessen Einträge (Schlüssel, Daten)-Paare sind. Bei der Frage nach einem Schlüssel wird das betreffende Paar gesucht und die darin gespeicherten Daten zurückgegeben. Dies erfordert aber einen Suchaufwand in O(n). Effizienter geht es mit einem Suchbaum. Die Datenstruktur des Suchbaums muss dafür so erweitert werden, dass zu jedem Schlüssel (=Index) weitere Informationen gespeichert werden können (nämlich der Inhalt des indexierten Feldes). Man erweitert die Node-Klasse um ein Feld "data":
class Node:
def __init__(self, key, data = None):
self.key = key
self.data = data
self.left = self.right = None
Dann kann man eine Klasse <tt>AssociativeArray</tt> realisieren, die die Indexoperationen intern mit Hilfe der Baumsuche implementiert. In Python wird der Zugriffsoperator ''[ ]'' für eine Datenstruktur (also innerhalb einer Klasse) wie folgt implementiert (vgl. die [http://docs.python.org/ref/sequence-types.html Python Docs zum Thema]):
def __setitem__(self, key, value)
so dass im Programmtext dann folgende Syntax möglich ist: <tt>a[key] = value</tt> (schreibender Zugriff auf <tt>a[key]</tt>).
Analog wird der lesende Zugriff <tt>value = a[key]</tt> wie folgt umgesetzt:
def __getitem__(self, key, value)
Der Konstruktor der Klasse <tt>AssociativeArray</tt> initialisiert einen leeren Suchbaum:
class AssociativeArray:
def __init__(self):
self.root = None
self.size = 0
Die Funktion <tt>__setitem__</tt> schaut nach, ob ein Eintrag mit dem betreffenden Index 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, index, data):
node = treeSearch(self.root, index)
if node is None:
self.root = treeInsert(self.root, index)
self.size += 1
node = treeSearch(self.root, index)
node.data = data
(Eine geschicktere Implementation würde natürlich die wiederholten Aufrufe von <tt>treeSearch</tt> und <tt>treeInsert</tt> eliminieren. Dies ändert aber nichts an der Komplexität der Funktion.) Die Funktion <tt>__getitem__</tt> sucht ebenfalls einen Eintrag mit dem gegebenen Index. Wenn er gefunden wird, gibt sie die zugehörigen Daten zurück, andernfalls eine Fehlermeldung:
def __getitem__(self, index):
node = treeSearch(self.root, index)
if node is None:
raise KeyError(index)
else:
return node.data
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 ==

Nun stellt sich die Frage, ob die Suche in einem assoziativen Array auch schneller, möglicherweise sogar in O(1), geht. Die Antwort lautet: Ja, wenn für die Indexklasse eine Hashfunktion definiert ist.

===Hashfunktionen===

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
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.sgi.com/tech/stl/hash_map.html std::hash_map]</tt>, siehe auch [http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc++-v3/src/hashtable.cc GCC hashtable.cc (Primzahlen)] und [http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc++-v3/include/tr1_impl/hashtable_policy.h 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:
53, 97, 193, 398, 769, ...
Die Wahl von Primzahlen hat zur Folge, dass <tt>hash(key) % self.capacity</tt> ''alle'' Bits von h benutzt (Eigenschaft aus der Zahlentheorie). Die Kapizitä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
while True:
if self.array[index] is None or self.array[index].key is None:
# das Feld ist frei (1. Abfrage)
# oder das Feld ist als frei markiert (2. Abfrage)
self.array[index] = HashNode(key, value)
self.size +=1
return
if self.array[index].key == key:
# Es gibt diesen Schlüssel schon,
# überschreibe die Daten
self.array[index].data = value
return
# Letzter Fall: Kollision => neuer Index durch 2. Hashfunktion
index = (5*index+1+h) % self.capacity
h = h >> 5
(für den <tt>>></tt>-Operator, siehe die [http://docs.python.org/ref/shifting.html Python Dokumentation])

Die vorgestellte Implementierung orientiert sich an Pythons interner Dictionary Implementierung, der zugehörige Quelltext (mit ausführlichem Kommentar) findet sich unter [http://svn.python.org/view/*checkout*/python/trunk/Objects/dictobject.c dictobject.c Python Implementation (SVN)]

===== 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 gut Lösung erwiesen.

== Anwendung 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 da N Vergleiche der Buchstaben durchgeführt werden müssen, Vergleiche 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 vorhergehende Hashfunktion 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.

==== Implementation ====
def searchRabinKarp(text, s):
ht, hs, dN = 0, 0, 1
M, N = len(text), len(s)
d, q = 32, 33554393
#q ist eine große Primzahl, aber so,
#dass d*q < 2**32 (um Überlauf zu vermeiden)

#Initialisierung
for k in range(N):
ht = (ht*d + ord(text[k])) % q
#ord() gibt die ASCIInummer des übergebenen Zeichens zurück
hs = (hs*d + ord( s[k] )) % q
dN = (dN*d) % q
#Die Variablen sind jetzt wie folgt initialisiert:
#ht = hash(text[0:N])
#hs = hash(s)
#dN = (d**N) % q

#Hauptschleife
k = 0
while k < M-N:
if hs == ht and s==text[k:k+N]:
return k # search string an Position k gefunden
if k+N < M:
ht = (d*ht - dN * ord(text[k]) + dN*q + ord(text[k+N]) ) % q
k +=1
return -1 # search string nicht gefunden

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

Hashing und assoziative Arrays

2010-08-10T14:57:47Z

Jschleic: /* Komplexität der linearen Verkettung und Wahl der Kapazität */ typo

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

== Assoziative Arrays ==
Assoziative Arrays werden genau wie gewöhnliche Arrays benutzt, sie unterstützen also den lesenden und schreibenden Zugriff über einen Index i
X = a[i]
a[i] = x
Im Unterschied zum gewöhnlichen Array, wo i ein Integer im Bereich <math> i \in 0 \ldots N-1</math> sein muss, kann der Typ von i jetzt ''beliebig'' sein. Eine typische Anwendung ist ein Wörterbuch
x = toEnglish['Baum'] # ergibt 'tree'
In diesem Fall ist der Typ des Index <tt>string</tt>, was in der Praxis der häufigste Fall ist, 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 Index benutzt werden, für den entweder eine Ordnung oder eine Hashfunktion definiert ist. In erstem Fall realisiert man das assoziative Array mit Hilfe eines Suchbaums, in zweiten Fall mit Hilfe einer Hashtabelle.

==Realisierung des assoziativen Arrays als Suchbaum==

Wenn für den Indextyp des assoziativen Arrays eine Ordnung definiert ist (wenn also <tt>i1 < i2</tt> oder <tt>cmp(i1, i2)</tt> unterstützt werden), kann man das Indexierungsproblem auf das Suchproblem zurückführen, indem man die Indizes als Suchschlüssel verwendet. Im einfachsten Fall kann dies mit sequentieller Suche realisiert werden: Man verwendet ein gewöhnliches Array, dessen Einträge (Schlüssel, Daten)-Paare sind. Bei der Frage nach einem Schlüssel wird das betreffende Paar gesucht und die darin gespeicherten Daten zurückgegeben. Dies erfordert aber einen Suchaufwand in O(n). Effizienter geht es mit einem Suchbaum. Die Datenstruktur des Suchbaums muss dafür so erweitert werden, dass zu jedem Schlüssel (=Index) weitere Informationen gespeichert werden können (nämlich der Inhalt des indexierten Feldes). Man erweitert die Node-Klasse um ein Feld "data":
class Node:
def __init__(self, key, data = None):
self.key = key
self.data = data
self.left = self.right = None
Dann kann man eine Klasse <tt>AssociativeArray</tt> realisieren, die die Indexoperationen intern mit Hilfe der Baumsuche implementiert. In Python wird der Zugriffsoperator ''[ ]'' für eine Datenstruktur (also innerhalb einer Klasse) wie folgt implementiert (vgl. die [http://docs.python.org/ref/sequence-types.html Python Docs zum Thema]):
def __setitem__(self, key, value)
so dass im Programmtext dann folgende Syntax möglich ist: <tt>a[key] = value</tt> (schreibender Zugriff auf <tt>a[key]</tt>).
Analog wird der lesende Zugriff <tt>value = a[key]</tt> wie folgt umgesetzt:
def __getitem__(self, key, value)
Der Konstruktor der Klasse <tt>AssociativeArray</tt> initialisiert einen leeren Suchbaum:
class AssociativeArray:
def __init__(self):
self.root = None
self.size = 0
Die Funktion <tt>__setitem__</tt> schaut nach, ob ein Eintrag mit dem betreffenden Index 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, index, data):
node = treeSearch(self.root, index)
if node is None:
self.root = treeInsert(self.root, index)
self.size += 1
node = treeSearch(self.root, index)
node.data = data
(Eine geschicktere Implementation würde natürlich die wiederholten Aufrufe von <tt>treeSearch</tt> und <tt>treeInsert</tt> eliminieren. Dies ändert aber nichts an der Komplexität der Funktion.) Die Funktion <tt>__getitem__</tt> sucht ebenfalls einen Eintrag mit dem gegebenen Index. Wenn er gefunden wird, gibt sie die zugehörigen Daten zurück, andernfalls eine Fehlermeldung:
def __getitem__(self, index):
node = treeSearch(self.root, index)
if node is None:
raise KeyError(index)
else:
return node.data
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 ==

Nun stellt sich die Frage, ob die Suche in einem assoziativen Array auch schneller, möglicherweise sogar in O(1), geht. Die Antwort lautet: Ja, wenn für die Indexklasse eine Hashfunktion definiert ist.

===Hashfunktionen===

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
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.sgi.com/tech/stl/hash_map.html std::hash_map]</tt>, siehe auch [http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc++-v3/src/hashtable.cc GCC hashtable.cc (Primzahlen)] und [http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc++-v3/include/tr1_impl/hashtable_policy.h 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:
53, 97, 193, 398, 769, ...
Die Wahl von Primzahlen hat zur Folge, dass <tt>hash(key) % self.capacity</tt> ''alle'' Bits von h benutzt (Eigenschaft aus der Zahlentheorie). Die Kapizitä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
while True:
if self.array[index] is None or self.array[index].key is None:
# das Feld ist frei (1. Abfrage)
# oder das Feld ist als frei markiert (2. Abfrage)
self.array[index] = HashNode(key, value)
self.size +=1
return
if self.array[index].key == key:
# Es gibt diesen Schlüssel schon,
# überschreibe die Daten
self.array[index].data = value
return
# Letzter Fall: Kollision => neuer Index durch 2. Hashfunktion
index = (5*index+1+h) % self.capacity
h = h >> 5
(für den <tt>>></tt>-Operator, siehe die [http://docs.python.org/ref/shifting.html Python Dokumentation])

Die vorgestellte Implementierung orientiert sich an Pythons interner Dictionary Implementierung, der zugehörige Quelltext (mit ausführlichem Kommentar) findet sich unter [http://svn.python.org/view/*checkout*/python/trunk/Objects/dictobject.c dictobject.c Python Implementation (SVN)]

===== 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 gut Lösung erwiesen.

== Anwendung 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 da N Vergleiche der Buchstaben durchgeführt werden müssen, Vergleiche 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 vorhergehende Hashfunktion 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.

==== Implementation ====
def searchRabinKarp(text, s):
ht, hs, dN = 0, 0, 1
M, N = len(text), len(s)
d, q = 32, 33554393
#q ist eine große Primzahl, aber so,
#dass d*q < 2**32 (um Überlauf zu vermeiden)

#Initialisierung
for k in range(N):
ht = (ht*d + ord(text[k])) % q
#ord() gibt die ASCIInummer des übergebenen Zeichens zurück
hs = (hs*d + ord( s[k] )) % q
dN = (dN*d) % q
#Die Variablen sind jetzt wie folgt initialisiert:
#ht = hash(text[0:N])
#hs = hash(s)
#dN = (d**N) % q

#Hauptschleife
k = 0
while k < M-N:
if hs == ht and s==text[k:k+N]:
return k # serch string an Position k gefunden
if k+N < M:
ht = (d*ht - dN * ord(text[k]) + dN*q + ord(text[k+N]) ) % q
k +=1
return -1 # search string nicht gefunden

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

Hashing und assoziative Arrays

2010-08-10T14:46:57Z

Jschleic: /* Realisierung des assoziativen Arrays als Suchbaum */ typo

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

== Assoziative Arrays ==
Assoziative Arrays werden genau wie gewöhnliche Arrays benutzt, sie unterstützen also den lesenden und schreibenden Zugriff über einen Index i
X = a[i]
a[i] = x
Im Unterschied zum gewöhnlichen Array, wo i ein Integer im Bereich <math> i \in 0 \ldots N-1</math> sein muss, kann der Typ von i jetzt ''beliebig'' sein. Eine typische Anwendung ist ein Wörterbuch
x = toEnglish['Baum'] # ergibt 'tree'
In diesem Fall ist der Typ des Index <tt>string</tt>, was in der Praxis der häufigste Fall ist, 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 Index benutzt werden, für den entweder eine Ordnung oder eine Hashfunktion definiert ist. In erstem Fall realisiert man das assoziative Array mit Hilfe eines Suchbaums, in zweiten Fall mit Hilfe einer Hashtabelle.

==Realisierung des assoziativen Arrays als Suchbaum==

Wenn für den Indextyp des assoziativen Arrays eine Ordnung definiert ist (wenn also <tt>i1 < i2</tt> oder <tt>cmp(i1, i2)</tt> unterstützt werden), kann man das Indexierungsproblem auf das Suchproblem zurückführen, indem man die Indizes als Suchschlüssel verwendet. Im einfachsten Fall kann dies mit sequentieller Suche realisiert werden: Man verwendet ein gewöhnliches Array, dessen Einträge (Schlüssel, Daten)-Paare sind. Bei der Frage nach einem Schlüssel wird das betreffende Paar gesucht und die darin gespeicherten Daten zurückgegeben. Dies erfordert aber einen Suchaufwand in O(n). Effizienter geht es mit einem Suchbaum. Die Datenstruktur des Suchbaums muss dafür so erweitert werden, dass zu jedem Schlüssel (=Index) weitere Informationen gespeichert werden können (nämlich der Inhalt des indexierten Feldes). Man erweitert die Node-Klasse um ein Feld "data":
class Node:
def __init__(self, key, data = None):
self.key = key
self.data = data
self.left = self.right = None
Dann kann man eine Klasse <tt>AssociativeArray</tt> realisieren, die die Indexoperationen intern mit Hilfe der Baumsuche implementiert. In Python wird der Zugriffsoperator ''[ ]'' für eine Datenstruktur (also innerhalb einer Klasse) wie folgt implementiert (vgl. die [http://docs.python.org/ref/sequence-types.html Python Docs zum Thema]):
def __setitem__(self, key, value)
so dass im Programmtext dann folgende Syntax möglich ist: <tt>a[key] = value</tt> (schreibender Zugriff auf <tt>a[key]</tt>).
Analog wird der lesende Zugriff <tt>value = a[key]</tt> wie folgt umgesetzt:
def __getitem__(self, key, value)
Der Konstruktor der Klasse <tt>AssociativeArray</tt> initialisiert einen leeren Suchbaum:
class AssociativeArray:
def __init__(self):
self.root = None
self.size = 0
Die Funktion <tt>__setitem__</tt> schaut nach, ob ein Eintrag mit dem betreffenden Index 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, index, data):
node = treeSearch(self.root, index)
if node is None:
self.root = treeInsert(self.root, index)
self.size += 1
node = treeSearch(self.root, index)
node.data = data
(Eine geschicktere Implementation würde natürlich die wiederholten Aufrufe von <tt>treeSearch</tt> und <tt>treeInsert</tt> eliminieren. Dies ändert aber nichts an der Komplexität der Funktion.) Die Funktion <tt>__getitem__</tt> sucht ebenfalls einen Eintrag mit dem gegebenen Index. Wenn er gefunden wird, gibt sie die zugehörigen Daten zurück, andernfalls eine Fehlermeldung:
def __getitem__(self, index):
node = treeSearch(self.root, index)
if node is None:
raise KeyError(index)
else:
return node.data
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 ==

Nun stellt sich die Frage, ob die Suche in einem assoziativen Array auch schneller, möglicherweise sogar in O(1), geht. Die Antwort lautet: Ja, wenn für die Indexklasse eine Hashfunktion definiert ist.

===Hashfunktionen===

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
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.sgi.com/tech/stl/hash_map.html std::hash_map]</tt>, siehe auch [http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc++-v3/src/hashtable.cc GCC hashtable.cc (Primzahlen)] und [http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc++-v3/include/tr1_impl/hashtable_policy.h 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:
53, 97, 193, 398, 769, ...
Die Wahl von Preimzahlen hat zur Folge, dass <tt>hash(key) % self.capacity</tt> ''alle'' Bits von h benutzt (Eigenschaft aus der Zahlentheorie). Die Kapizitä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
while True:
if self.array[index] is None or self.array[index].key is None:
# das Feld ist frei (1. Abfrage)
# oder das Feld ist als frei markiert (2. Abfrage)
self.array[index] = HashNode(key, value)
self.size +=1
return
if self.array[index].key == key:
# Es gibt diesen Schlüssel schon,
# überschreibe die Daten
self.array[index].data = value
return
# Letzter Fall: Kollision => neuer Index durch 2. Hashfunktion
index = (5*index+1+h) % self.capacity
h = h >> 5
(für den <tt>>></tt>-Operator, siehe die [http://docs.python.org/ref/shifting.html Python Dokumentation])

Die vorgestellte Implementierung orientiert sich an Pythons interner Dictionary Implementierung, der zugehörige Quelltext (mit ausführlichem Kommentar) findet sich unter [http://svn.python.org/view/*checkout*/python/trunk/Objects/dictobject.c dictobject.c Python Implementation (SVN)]

===== 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 gut Lösung erwiesen.

== Anwendung 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 da N Vergleiche der Buchstaben durchgeführt werden müssen, Vergleiche 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 vorhergehende Hashfunktion 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.

==== Implementation ====
def searchRabinKarp(text, s):
ht, hs, dN = 0, 0, 1
M, N = len(text), len(s)
d, q = 32, 33554393
#q ist eine große Primzahl, aber so,
#dass d*q < 2**32 (um Überlauf zu vermeiden)

#Initialisierung
for k in range(N):
ht = (ht*d + ord(text[k])) % q
#ord() gibt die ASCIInummer des übergebenen Zeichens zurück
hs = (hs*d + ord( s[k] )) % q
dN = (dN*d) % q
#Die Variablen sind jetzt wie folgt initialisiert:
#ht = hash(text[0:N])
#hs = hash(s)
#dN = (d**N) % q

#Hauptschleife
k = 0
while k < M-N:
if hs == ht and s==text[k:k+N]:
return k # serch string an Position k gefunden
if k+N < M:
ht = (d*ht - dN * ord(text[k]) + dN*q + ord(text[k+N]) ) % q
k +=1
return -1 # search string nicht gefunden

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

Effizienz

2010-08-10T12:23:07Z

Jschleic: /* Optimierung der Laufzeit */ typo

Bei der Diskussion von Effizienz müssen wir zwischen der Laufzeit eines Algorithmus auf einem bestimmten System und seiner prinzipiellen Leistungsfähigkeit (Algorithmenkomplexität) unterscheiden. Der Benutzer ist natürlich vor allem an der Laufzeit interessiert, denn diese bestimmt letztendlich seine Arbeitsproduktivität. Ein Softwaredesigner hingegen muss eine Implementation wählen, die auf verschiedenen Systemen und in verschiedenen Anwendungen schnell ist. Für ihn sind daher auch Aussagen zur Algorithmenkomplexität sehr wichtig, um den am besten geeigneten Algorithmus auszuwählen.

== Laufzeit ==

Aus Anwendersicht ist ein Algorithmus effizient, wenn er die in der Spezifikation verlangten Laufzeitgrenzen einhält. Ein Algorithmus muss also nicht immer so schnell wie möglich sein, sondern so schnell wie nötig. Dies führt in verschiedenen Anwendungen zu ganz unterschiedliche Laufzeitanforderungen:

* Berechnen des nächsten Steuerkommandos für eine Maschine: ca. 1/1000s
* Berechnen des nächsten Bildes für eine Videopräsentation (z.B. Dekompression von MPEG-kodierten Bildern): ca. 1/25s
: Geringere Bildraten führen zu ruckeligen Filmen.
* Sichtbare Antwort auf ein interaktives Kommando (z.B. Mausklick): ca. 1/2s
: Wird diese Antwortzeit überschritten, vermuten viele Benutzer, dass der Mausklick nicht funktioniert hat, und klicken nochmals, mit eventuell fatalen Folgen. Wenn ein Algorithmus notwendigerweise länger dauert als 1/2s, sollte ein Fortschrittsbalken angezeigt werden.
* Wettervorhersage: muss spätestens am Vorabend des vorhergesagten Tages beendet sein

===Laufzeitvergleich===

Da die Laufzeit für den Benutzer ein so wichtiges Kriterium ist, werden häufig Laufzeitvergleiche durchgeführt. Deren Ergebnisse hängen allerdings von vielen Faktoren ab, die möglicherweise nicht kontrollierbar sind:
* Geschwindigkeit und Anzahl der Prozessoren
* Auslastung des Systems
* Größe des Hauptspeichers und Cache, Geschwindigkeit des Datenbus
* Qualität des Compilers/Optimierers (ist der Compiler für die spezielle Prozessor-Architektur optimiert?)
* Geschick des Programmierers
* Daten (Beispiel Quicksort: Best case und worst case [vorsortierter Input] stark unterschiedlich)
All diese Faktoren sind untereinander abhängig. Laufzeitvergleiche sind daher mit Vorsicht zu interpretieren.
Generell sollten bei Vergleichen möglichst wenige Parameter verändert werden, z.B.
* gleiches Programm (gleiche Kompilierung), gleiche Daten, andere Prozessoren
oder
* gleiche CPU, Daten, andere Programme (Vergleich von Algorithmen)
Zur Verbesserung der Vergleichbarkeit gibt es standardisierte [http://en.wikipedia.org/wiki/Benchmark_(computing) Benchmarks], die bestimmte Aspekte eines Systems unter möglichst realitätsnahen Bedingungen testen. Generell gilt aber: Durch Laufzeitmessung ist schwer festzustellen, ob ein Algorithmus ''prinzipiell'' besser ist als ein anderer. Dafür ist die Analyse der [[Effizienz#Algorithmen-Komplexität|Algorithmenkomplexität]] notwendig.

===Optimierung der Laufzeit===

Wenn sich herausstellt, dass ein bereits implementierter Algorithmus zu langsam läuft, geht man wie folgt vor:

# Man verwendet einen [http://en.wikipedia.org/wiki/Performance_analysis Profiler], um zunächst den Flaschenhals zu bestimmen. Ein Profiler ist ein Hilfsprogramm, das während der Ausführung eines Programms misst, wieviel Zeit in jeder Funktion und Unterfunktion verbraucht wird. Dadurch kann man herausfinden, welcher Teil des Algorithmus überhaupt Probleme bereitet. Donald Knuth gibt z.B. als Erfahrungswert an, dass Programme während des größten Teils ihrer Laufzeit nur 3% des Quellcodes (natürlich mehrmals wiederholt) ausführen [http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf]. Es ist sehr wichtig, diese 3% experimentell zu bestimmen, weil die Erfahrung zeigt, dass man beim Erraten der kritischen Programmteile oft falsch liegt. Man spricht dann von "[http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize premature optimization]", also von voreiliger Optimierung ohne experimentelle Untersuchung der wirklichen Laufzeiten, was laut Knuth "the root of all evil" ist. Der Python-Profiler wird in [http://docs.python.org/lib/profile.html Kapitel 25] der Python-Dokumentation beschrieben.
# Man kann dann versuchen, die kritischen Programmteile zu optimieren.
# Falls der Laufzeitgewinn durch Optimierung zu gering ist, muss man einen prinzipiell schnelleren Algorithmus verwenden, falls es einen gibt.

Einige wichtige Techniken der Programmoptimierung sollen hier erwähnt werden. Wenn man einen optimierenden Compiler verwendet, werden einige Optimierungen automatisch ausgeführt [http://en.wikipedia.org/wiki/Compiler_optimization]. In Python trifft dies jedoch nicht zu. Um den Sinn einiger Optimierungen zu verstehen, benötigt man Grundkenntnisse der Computerarchitektur.

;Elimination von redundantem Code: Es ist offensichtlich überflüssig, dasselbe Ergebnis mehrmals zu berechnen, wenn es auch zwischengespeichert werden könnte. Diese Optimierung wird von vielen automatischen Optimierern unterstützt und kommt im wesentlichen in zwei Ausprägungen vor:
:; common subexpression elimination: In mathematischen Ausdrücken wird ein Teilergebnis häufig mehrmals benötigt. Man betrachte z.B. die Lösung der quadratischen Gleichung <math>x^2+p\,x+q = 0</math>:
x1 = - p / 2.0 + sqrt(p*p/4.0 - q)
x2 = - p / 2.0 - sqrt(p*p/4.0 - q)
::Die mehrmalige Berechnung von Teilausdrücken wird vermieden, wenn man stattdessen schreibt:
p2 = - p / 2.0
r = sqrt(p2*p2 - q)
x1 = p2 + r
x2 = p2 - r
:; loop invariant elimination: Wenn ein Teilausdruck sich in einer Schleife nicht ändert, muss man ihn nicht bei jedem Schleifendurchlauf neu berechnen, sondern kann dies einmal vor Beginn der Schleife tun. Ein typisches Beispiel hierfür ist die Adressierung von Matrizen, die als 1-dimensionales Array gespeichert sind. Angenommen, wir speichern eine NxN Matrix <tt>m</tt> in einem Array <tt>a</tt> der Größe N2, so dass das Matrixelement <tt>mij</tt> durch <tt>a[i + j*N]</tt> indexiert wird. Wir betrachten die Aufgabe, eine Einheitsmatrix zu initialisieren. Ein nicht optimierter Algorithmus dafür lautet:
for j in range(N):
for i in range(N):
if i == j:
a[i + j*N] = 1.0
else:
a[i + j*N] = 0.0
::Der Ausdruck <tt>j*N</tt> wird hier in jedem Schleifendurchlauf erneut berechnet, obwohl sich <tt>j</tt> in der inneren Schleife gar nicht verändert. Man kann deshalb optimieren zu:
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
;Vereinfachung der inneren Schleife: Generell sollte man sich bei der Optimierung auf die innere Schleife eines Algorithmus konzentrieren, weil dieser Code am häufigsten ausgeführt wird. Insbesondere sollte man die Anzahl der Befehle in der inneren Schleife so gering wie möglich halten und teure Befehle vermeiden. Früher waren vor allem Floating-Point Befehle teuer, die man oft durch die schnellere Integer-Arithmetik ersetzt hat, falls dies algorithmisch möglich war (diesen Rat findet man noch oft in der Literatur). Heute hat sich die Hardware so verbessert, dass im Allgemeinen nur noch die Floating-Point Division deutlich langsamer ist als die anderen Operatoren. Im obigen Beispiel der quadratischen Gleichung ist es daher sinnvoll, den Ausdruck
p2 = -p / 2.0
:durch
p2 = -0.5 * p
:zu ersetzen. Dadurch ersetzt man eine Division durch eine Multiplikation und spart außerdem das Negieren von <tt>p</tt>, da der Compiler direkt mit <tt>-0.5</tt> multipliziert.
;Ausnutzung der Prozessor-Pipeline: Moderne Prozessoren führen mehrere Befehle parallel aus. Dies ist möglich, weil jeder Befehl in mehrere Teilschritte zerlegt werden kann. Eine generische Unterteilung in vier Teilschritte ist z.B.:
:# Dekodieren des nächsten Befehls
:# Beschaffen der Daten, die der Befehl verwendet (aus Prozessorregistern, dem Cache, oder dem Hauptspeicher)
:# Ausführen des Befehls
:# Schreiben der Ergebnisse
:Man bezeichnet dies als die "[http://en.wikipedia.org/wiki/Instruction_pipeline instruction pipeline]" des Prozessors (heutige Prozessoren verwenden wesentlich feinere Unterteilungen). Prozessoren werden nun so gebaut, dass mehrere Befehle parallel, auf verschiedenen Ausführungsstufen ausgeführt werden. Wenn Befehl 1 also beim Schreiben der Ergebnisse angelangt ist, kann Befehl 2 die Hardware zum Ausführen des Befehls benutzen, während Befehl 3 seine Daten holt, und Befehl 4 soeben dekodiert wird. Unter bestimmten Bedingungen funktioniert diese Parallelverarbeitung jedoch nicht. Dies gibt Anlass zu Optimierungen:
:;Vermeiden unnötiger Typkonvertierungen: Der Prozessor verarbeitet Interger- und Floating-Point-Befehle in verschiedenen Pipelines, weil die Hardwareanforderungen sehr verschieden sind. Wird jetzt ein Ergebnis von Integer nach Floating-Point umgewandelt oder umgekehrt, muss die jeweils andere Pipeline warten, bis die erste Pipeline ihre Berechnung beendet. Es kann dann besser sein, Berechnungen in Floating-Point zu Ende zu führen, auch wenn sie semantisch eigentlich Integer-Berechnungen sind.
:;Reduzierung der Anzahl von Verzweigungen: Wenn der Code verzweigt (z.B. durch eine <tt>if</tt>- oder <tt>while</tt>-Anweisung), ist nicht klar, welcher Befehl nach der Verzweigung ausgeführt werden soll, bevor Stufe 3 der Pipeline die Verzweigungsbedingung ausgewertet hat. Bis dahin wären die ersten beiden Stufen der Pipeline unbenutzt. Moderne Prozessoren benutzen zwar ausgefeilte Heuristiken, um das Ergebnis der Bedingung vorherzusagen, und führen den hoffentlich richtigen Zweig des Codes spekulativ aus, aber dies funktioniert nicht immer. Man sollte deshalb generell die Anzahl der Verzweigungen minimieren. Als Nebeneffekt führt dies meist auch zu besser lesbarem, verständlicherem Code. Im Matrixbeispiel kann man
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
::durch
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
ersetzen. Die Diagonalelemente <tt>a[j + jN]</tt> werden jetzt zwar zweimal initialisiert (in der Schleife auf Null, dann auf Eins), aber durch Elimination der <tt>if</tt>-Abfrage wird dies wahrscheinlich mehr als ausgeglichen, zumal dadurch die innere Schleife wesentlich vereinfacht wurde.
;Ausnutzen des Prozessor-Cache: Zugriffe auf den Hauptspeicher sind sehr langsam. Deshalb werden stets ganze Speicherseiten auf einmal in den [http://en.wikipedia.org/wiki/Cache Cache] des Prozessors geladen. Wenn unmittelbar nacheinander benutzte Daten auch im Speicher nahe beieinander liegen (sogenannte "[http://en.wikipedia.org/wiki/Locality_of_reference locality of reference]"), ist die Wahrscheinlichkeit groß, dass die als nächstes benötigten Daten bereits im Cache sind und damit schnell gelesen werden können. Bei vielen Algorithmen kann man die Implementation so umordnen, dass die locality of reference verbessert wird, was zu einer drastischen Beschleunigung führt. Im Matrix-Beispiel ist z.B. die Reihenfolge der Schleifen wichtig. Für konstanten Index <tt>j</tt> liegen die Indizes <tt>i</tt> im Speicher hintereinander. Deshalb ist es günstig, in der inneren Schleife über <tt>i</tt> zu iterieren:
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
:Die umgekehrte Reihenfolge der Schleifen ist hingegen ungünstig
for i in range(N):
for j in range(N):
a[i + j*N] = 0.0
a[i + i*N] = 1.0
:Jetzt werden in der inneren Schleife stets N Datenelemente übersprungen. Besonders bei großem N muss man daher häufig den Cache neu füllen, was bei der ersten Implementation nicht notwendig war. (Außerdem verliert man hier die Optimierung <tt>jN = j*N</tt>, die jetzt nicht mehr möglich ist.)

Als Faustregel kann man durch Optimierung eine Verdoppelung der Geschwindigkeit erreichen (in Ausnahmefällen auch mehr). Benötigt man stärkere Verbesserungen, muss man wohl oder übel einen besseren Algorithmus oder einen schnelleren Computer verwenden.

== Algorithmen-Komplexität ==

Komplexitätsbetrachtungen ermöglichen den Vergleich der prinzipiellen Eigenschaften von Algorithmen unabhängig von einer Implementation, Umgebung etc.

Eine einfache Möglichkeit ist das Zählen der Aufrufe einer Schlüsseloperation. Beispiel Sortieren:
* Anzahl der Vergleiche
* Anzahl der Vertauschungen

=== Beispiel: Selection Sort ===

for i in range(len(a)-1):
max = i
for j in range(i+1, len(a)):
if a[j] < a[max]:
max = j
a[max], a[i] = a[i], a[max] # swap

*Anzahl der Vergleiche: Ein Vergleich in jedem Durchlauf der inneren Schleife. Es ergibt sich folgende Komplexität:
*:Ingesamt <math>\sum_{i=0}^{N-2} \sum_{j=i+1}^{N-1}1 = \frac{N}{2} (N-1) \!</math> Vergleiche.

*Anzahl der Vertauschungen (swaps): Eine Vertauschung pro Durchlauf der äußeren Schleife:
*:Insgesamt <math>N-1 \!</math> Vertauschungen

Die Komplexität wird durch die Operationen bestimmt, die am häufigsten ausgeführt werden, hier also die Anzahl der Vergleiche. Die Anzahl der Vertauschungen ist hingegen kein geeignetes Kriterium für die Komplexität von selection sort, weil der Aufwand in der inneren Schleife ignoriert würde.

=== Fallunterscheidung: Worst und Average Case ===

Die Komplexität ist in der Regel eine Funktion der Eingabegröße (Anzahl der Eingabebits, Anzahl der Eingabeelemente). Sie kann aber auch von der Art der Daten abhängen, nicht nur von der Menge, z.B. vorsortierte Daten bei Quicksort. Um von der Art der Daten unabhängig zu werden, kann man zwei Fälle der Komplexität unterscheiden:

* Komplexität im ungünstigsten Fall
*: Der ungünstigste Fall ist die Eingabe gegebener Länge, für die der Algorithmus am langsamsten ist. Der Nachteil dieser Methode besteht darin, dass dieser ungünstige Fall in der Praxis vielleicht gar nicht oder nur selten vorkommt, so dass sich der Algorithmus in Wirklichkeit besser verhält als man nach dieser Analyse erwarten würde. Beim Quicksort-Algorithmus mit zufälliger Wahl des Pivot-Elements müsste z.B. stets das kleinste oder größte Element des aktuellen Intervalls als Pivot-Element gewählt werden, was äußerst unwahrscheinlich ist.
* Komplexität im durchschnittlichen/typischen Fall
*: Der typische Fall ist die mittlere Komplexität des Algorithmus über alle möglichen Eingaben. Dazu muss man die Wahrscheinlichkeit jeder möglichen Eingabe kennen, und berechnet dann die mittlere Laufzeit über dieser Wahrscheinlichkeitsverteilung. Leider ist die Wahrscheinlichkeit der Eingaben oft nicht bekannt, so dass man geeignete Annahmen treffen muss. Bei Sortieralgorithmen können z.B. alle möglichen Permutationen des Eingabearrays als gleich wahrscheinlich angenommen werden, und der typische Fall ist dann die mittlere Komplexität über alle diese Eingaben. Oft hat man jedoch in der Praxis andere Wahrscheinlichkeitsverteilungen, z.B. sind die Daten oft "fast sortiert" (nur wenige Elemente sind an der falschen Stelle). Dann verhält sich der Algorithmus ebenfalls anders als vorhergesagt.

Wir beschränken uns in dieser Vorlesung auf die Komplexität im ungünstigseten Fall. '''Exakte''' Formeln für Komplexität sind aber auch dann schwer zu gewinnen, wie das folgende Beispiel zeigt:

=== Beispiele aus den Übungen (Gemessene Laufzeiten für Mergesort/Selectionsort) ===

* Mergesort: <math>\frac{0,977N\log N}{\log 2} + 0,267N-4.39 \!</math>
*: andere Lösung: <math>1140 N\log(N) - 1819N + 6413 \!</math>
* Selectionsort: <math>\frac{1}{2}N^2 - \frac{1}{2N} - 10^{-12} \!</math>
*: andere Lösung: <math>1275N^2 - 116003^N + 11111144 \!</math>

Aus diesen Formeln wird nicht offensichtlich, welcher Algorithmus besser ist.
Näherung: Betrachte nur '''sehr große Eingaben''' (meist sind alle Algorithmen schnell genug für kleine Eingaben). Dieses Vorgehen wird als '''Asymptotische Komplexität''' bezeichnet (N gegen unendlich).

=== Asymptotische Komplexität am Beispiel Polynom ===

Polynom: <math>a\,x^2+b\,x+c=p\!</math>

<math>x \!</math> sei die Eingabegröße, und wir betrachten die Entwicklung von <math>p \!</math> in Abhängigkeit von <math>x \!</math>.

* <math>x=0 \!</math>
*: <math>p=c \!</math>
* <math>x=1 \!</math>
*: <math>p=a+b+c \!</math>
* <math>x=1000 \!</math>
*: <math>p=1000000a+1000b+c \approx 1000000a\!</math>
* <math>x \to \infty \!</math>
*: <math>p \approx x^2a\!</math>

Für sehr große Eingaben verlieren also ''b'' und ''c'' immer mehr an Bedeutung, so dass am Ende nur noch ''a'' für die Komplexitätsbetrachtung wichtig ist.

== Landau-Symbole ==

Um die asymptotische Komplexität verschiedener Algorithmen miteinander vergleichen zu können, verwendet man die sogenannten [http://de.wikipedia.org/wiki/Landau-Symbole Landau-Symbole]. Das wichtigste Landau-Symbol ist <math>\mathcal{O}</math>, mit dem man eine ''obere Schranke'' <math>f \in \mathcal{O}(g)</math> für die Komplexität angeben kann.

Schreibt man <math>f \in \Omega(g)</math>, so stellt dies eine asymptotische ''untere Schranke'' für die Funktion f dar.

Schließlich bedeutet <math>f \in \Theta(g)</math>, dass die Funktion f genauso schnell wie die Funktion g wächst, das heißt man hat eine asymptotisch ''scharfe Schranke'' für f. Hierzu muss sowohl <math>f\in\mathcal{O}(g)</math> als auch <math>f \in \Omega(g)</math> erfüllt sein.

Im nun folgenden soll auf die verschiedenen Landau-Symbole noch näher eingegeangen werden.

===O-Notation===

Intuitiv gilt: Für große N dominieren die am schnellsten wachsenden Terme einer Funktion. Die Notation <math>f \in \mathcal{O}(g)</math> (sprich "f ist in O von g" oder "f ist von derselben Größenordnung wie g") formalisiert eine solche Abschätzung der asymptotischen Komplexität der Funktion f von oben.
; Asymptotische Komplexität: Für zwei Funktionen f(x) und g(x) gilt
::<math>f(x) \in \mathcal{O}(g(x))</math>
: genau dann wenn es eine Konstante <math>c>0</math> und ein Argument <math>x_0</math> gibt, so dass
::<math>\forall x \ge x_0:\quad f(x) \le c\,g(x)</math>.
:Die Menge <math>\mathcal{O}(g(x))</math> aller durch g(x) abschätzbaren Funktionen ist also formal definiert durch
::<math>\mathcal{O}(g(x)) = \{ f(x)\ |\ \exists c>0: \forall x \ge x_0: 0 \le f(x) \le c\,g(x)\}</math>

Die Idee hinter dieser Definition ist, dass g(x) eine wesentlich einfachere Funktion ist als f(x), die sich aber nach geeigneter Skalierung (Multiplikation mit c) und für große Argumente x im wesentlichen genauso wie f(x) verhält. Man kann deshalb in der Algorithmenanalyse f(x) durch g(x) ersetzen. <math>f(x) \in \mathcal{O}(g(x))</math> spielt für Funktionen eine ähnliche Rolle wie der Operator ≤ für Zahlen: Falls a ≤ b gilt, kann bei einer Abschätzung von oben ebenfalls a durch b ersetzt werden.

==== Ein einfaches Beispiel ====

[[Image:Sqsqrt.png]]

Rot = <math>x^2 \!</math>
Blau = <math>\sqrt{x} \!</math>

<math>\sqrt{x} \in \mathcal{O}(x^2)\!</math> weil <math>\sqrt{x} \le c\,x^2\!</math> für alle <math>x \ge x_0 = 1 \!</math> und <math>c = 1\!</math>, oder auch für <math>x \ge x_0 = 4 \!</math> und <math>c = 1/16</math> (die Wahl von c und x0 in der Definition von O(.) ist beliebig, solange die Bedingungen erfüllt sind).

==== Komplexität bei kleinen Eingaben ====

Algorithmus 1: <math>\mathcal{O}(N^2) \!</math> 
Algorithmus 2: <math>\mathcal{O}(N\log{N}) \!</math>

Algorithmus 2 ist schneller (von geringerer Komplexität) für große Eingaben, aber bei kleinen Eingaben (insbesondere, wenn der Algorithmus in einer Schleife immer wieder mit kleinen Eingaben aufgerufen wird) könnte Algorithmus 1 schneller sein, falls der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor ''c'' bei Algorithmus 2 einen wesentlich größeren Wert hat als bei Algorithmus 1.

==== Eigenschaften der O-Notation (Rechenregeln) ====

# Transitiv:
#: <math>f(x) \in \mathcal{O}(g(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) \in \mathcal{O}(h(x)) \!</math>
# Additiv:
#: <math>f(x) \in \mathcal{O}(h(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) + g(x) \in \mathcal{O}(h(x)) \!</math>
# Für Monome gilt:
#: <math>x^k \in \mathcal{O}(x^k)</math> und
#: <math>x^k \in \mathcal{O}(x^{k+j}), \forall j \ge 0 \!</math>
# Multiplikation mit einer Konstanten:
#: <math>f(x) \in \mathcal{O}(g(x)) \to c\,f(x) \in \mathcal{O}(g(x))\!</math>
#: andere Schreibweise:
#: <math>f(x) = c\,g(x) \to f(x) \in \mathcal{O}(g(x))\!</math>
# Folgerung aus 3. und 4. für Polynome:
#: <math>a_0+a_1\,x + ... + a_n\,x^n \in \mathcal{O}(x^n)\!</math>
#: Beispiel: <math>a\,x^2+b\,x+c \in \mathcal{O}(x^2)\!</math>
# Logarithmus:
#: <math>a, b > 1\!</math>
#: <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>
#: Die Basis des Logarithmus spielt also keine Rolle.
#: Beweis hierfür:
#:: <math>\log_{a}{x} = \frac{\log_{b}{x}}{\log_{b}{a}}\!</math>
#:: Mit <math>c = 1 / \log_{b}{a}\,</math> gilt: <math>\log_{a}{x} = c\,\log_{b}{x}\!</math>.
#:: Wird hier die (zweite) Regel für Multiplikation mit einer Konstanten angewendet, fällt der konstante Faktor weg, also <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>.
#: Insbesondere gilt auch <math>\log_{a}{x} \in \mathcal{O}(\log_{2}{x})\!</math>, es kann also immer der 2er Logarithmus verwendet werden.

==== O-Kalkül ====

Das O-Kalkül definiert wichtige Vereinfachungsregeln for Ausdrücke in O-Notation (Beweise: siehe Übungsaufgabe):

# <math>f(x) \in \mathcal{O}(f(x))\!</math>
# <math>\mathcal{O}(\mathcal{O}(f(x))) \in \mathcal{O}(f(x))\!</math>
# <math>c\,\mathcal{O}(f(x)) \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# <math>\mathcal{O}(f(x))+c \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# Sequenzregel:
#: Wenn zwei nacheinander ausgeführte Programmteile die Komplexität <math>\mathcal{O}(f(x))</math> bzw. <math>\mathcal{O}(g(x))</math> haben, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(f(x))</math> falls <math>g(x) < \mathcal{O}(f(x))</math> bzw.
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(g(x))\!</math> falls <math>f(x) < \mathcal{O}(g(x))</math>.
#: Informell schreibt man auch: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(max(f(x), g(x)))\!</math>.
# Schachtelungsregel bzw. Aufrufregel:
#: Wenn in einer geschachtelten Schleife die äußere Schleife die Komplexität <math>\mathcal{O}(f(x))</math> hat, und die innere <math>\mathcal{O}(g(x))</math>, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) * \mathcal{O}(g(x)) \in \mathcal{O}(f(x) * g(x))\!</math>.
#: Gleiches gilt wenn eine Funktion <math>\mathcal{O}(f(x))</math>-mal aufgerufen wird, und die Komplexität der Funktion selbst <math>\mathcal{O}(g(x))</math> ist.

;Beispiel für 5.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Dies gilt auch für ihre Hintereinanderausführung:
for i in range(N):
a[i] = i
for i in range(N):
print a[i]
;Beispiele für 6.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Ihre Verschachtelung hat daher die Komplexität <math>\mathcal{O}(N^2)</math>.
for i in range(N):
for j in range(N):
a[i*N + j] = i+j
: Dies gilt ebenso, wenn statt der inneren Schleife eine Funktion mit Komplexität <math>\mathcal{O}(N)</math> ausgeführt wird:
for i in range(N):
a[i] = foo(i, N) # <math>\mathrm{foo}(i, N) \in \mathcal{O}(N)</math>

==== O-Kalkül auf das Beispiel des Selectionsort angewandt ====

Selectionsort: Wir hatten gezeigt dass <math>f(N) = \frac{N^2}{2} - \frac{N}{2}</math>. Nach der Regel für Polynome vereinfacht sich dies zu <math>f(N) \in \mathcal{O}\left(\frac{N^2}{2}\right) = \mathcal{O}(N^2)\!</math>.

Alternativ via Schachtelungsregel:
: Die äußere Schleife wird (''N''-1)-mal durchlaufen: <math>N-1 \in \mathcal{O}(N)</math>
: Die innere Schleife wird (''N-i''-1)-mal durchlaufen. Das sind im Mittel ''N''/2 Durchläufe: <math>N/2 \in \mathcal{O}(N)</math>
: Zusammen: <math>\mathcal{O}(N)*\mathcal{O}(N) \in \mathcal{O}(N^2)</math>

Nach beiden Vorgehensweisen kommen wir zur Schlussfolgerung, dass der Selectionsort die asymptotische Komplexität <math>\mathcal{O}(N^2)\!</math> besitzt.

==== Zusammenhang zwischen Komplexität und Laufzeit ====

Wenn eine Operation 1ms dauert, erreichen Algorithmen verschiedener Komplexität folgende Leistungen (wobei angenommen wird, dass der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor immer etwa gleich 1 ist):

{| class="wikitable" style="text-align:left" cellpadding="7"
|+
|-
! Komplexität !! Operationen in 1s !! Operationen in 1min !! Operationen in 1h
|-
! <math>\mathcal{O}(N)</math>
| 1000 || 60.000 || 3.600.000
|-
! <math>\mathcal{O}(N\log_2{N})</math>
| 140 || 4895 || 204094
|-
! <math>\mathcal{O}(N^2)</math>
| 32 || 245 || 1898
|-
! <math>\mathcal{O}(N^3)</math>
| 10 || 39 || 153
|-
! <math>\mathcal{O}(2^N)</math>
| 10 || 16 || 21
|}

==== Exponentielle Komplexität ====
Der letzte Fall <math>\mathcal{O}(2^N)</math> ist von exponentieller Komplexität. Das bedeutet, dass eine Verdopplung des Aufwands nur bewirkt, dass die maximale Problemgröße um eine Konstante wächst. Algorithmen mit exponentieller (oder noch höherer) Komplexität werden deshalb als '''ineffizient''' bezeichnet. Algorithmen mit höchstens polynomieller Komplexität gelten hingegen als effizient.

In der Praxis sind allerdings auch polynomielle Algorithmen mit hohem Exponenten meist zu langsam. Als Faustregel kann man eine praktische Grenze von <math>\mathcal{O}(N^3)</math> ansehen. Bei einer Komplexität von <math>\mathcal{O}(N^3)</math> bewirkt ein verdoppelter Aufwand immer noch eine Steigerung der maximalen Problemgröße um den Faktor <math>\sqrt[3]{2}</math> (also eine ''multiplikative'' Vergrößerung um ca. 25%, statt nur einer additiven Vergrößerung wie bei exponentieller Komplexität).

===<math>\Omega</math>- Notation===

Genauso wie <math>f \in \mathcal{O}(g)</math> eine Art <math>\le</math>-Operator für Funktionen ist, definiert <math>f \in \Omega(g) </math> eine Abschätzung von unten, analog zum <math>\ge</math>-Operator für Zahlen. Formal kann man <math>f(N) \in \Omega(g(N)) </math> genau dann schreiben, falls es eine Konstante <math> c > 0 </math> gibt, so dass

<math> f(N) \ge c \cdot g(N) </math> für <math> N \ge N_0 </math>

gilt.
Man verwendet diese Notation also um abzuschätzen, wie groß der Aufwand (die Komplexität) für einen bestimmten Algorithmus ''mindestens'' ist und nicht ''höchstens'', was man mit der <math>\mathcal{O}</math> - Notation ausdrücken würde.

Ein praktisches Beispiel für eine Anwendung der <math>\Omega</math>- Notation wäre die Fragestellung, ob es ''prinzipiell'' einen besseren Algorithmus für ein bestimmtes Problem gibt. Wie später im Abschnitt [[Suchen#Sortieren_als_Suchproblem|Sortieren als Suchproblem]] gezeigt wird, ist das Sortieren eines Arrays durch paarweise Vergleiche von Elementen immer mindestens von der Komplexität <math> \Omega(N\cdot \ln N) </math>, was konkret bedeutet, dass kein Sortieralgorithmus, der nach diesem Prinzip arbeitet, jemals eine geringere Komplexität als beispielsweise Merge-Sort haben wird. Natürlich kann man den entsprechenden Sortieralgorithmus, also Merge-Sort zum Beispiel, unter Umständen noch optimieren, aber die Komplexität wird erhalten bleiben. Mit diesem Wissen kann man sich viel (vergebliche) Arbeit sparen.

===<math>\Theta</math>- Notation===

<math>f(N) \in \Theta(g(N))</math> ist eine scharfe Abschätzung der asymptotischen Komplexität einer Funktion f.

Damit dies gilt, muss <math>f(N) \in \mathcal{O}(g(N))</math> und ''gleichzeitig'' <math>f(N) \in \Omega(g(N))</math> erfüllt sein.

Dies ist natürlich auch die beste Abschätzung der asymptotischen Komplexität einer Funktion f. Formal bedeutet <math>f(N) \in \Theta(g(N))</math> dass es zwei Konstanten <math> c_1 </math> und <math> c_2 </math>, beide größer als Null, gibt, so dass für alle <math> N \geq N_0 </math> gilt:

<math> c_1 \cdot g(N) \leq f(N) \leq c_2 \cdot g(N) </math>.

In der Praxis wird manchmal statt der <math>\Theta</math>-Notation auch dann die <math>\mathcal{O}</math>-Notation benutzt, wenn eine scharfe Schranke ausgedrückt werden soll. Dies ist zwar formal nicht korrekt, aber man kann die intendierte Bedeutung meist aus dem Kontext erschließen.

== Komplexitätsvergleich zweier Algorithmen ==

In diesem Abschnitt wollen wir der Frage nachgehen, wie ein formaler Beweis für die Behauptung <math> f(N) \in \mathcal{O}(g(N))</math> geschehen kann. Hierbei werden zwei Beweismethoden vorgestellt werden, und zwar der '''Beweis über die Definition der Komplexität''' sowie der '''Beweis durch Dividieren'''.

===Beweis über die Definition der asymptotischen Komplexität===

Die Definition der asymptotischen Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> war:

Es gibt eine Konstante <math> c > 0 </math>, so dass <math> f(N) \le c \cdot g(N) </math> für <math> N \ge N_0 </math> erfüllt ist.

Um also die die asymptotische Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> zu beweisen, muss man die oben erwähnten Konstanten c und <math> N_0 </math> finden, so dass

<math> f(N) \leq c \cdot g(N) </math> für alle <math> N \ge N_0 </math> erfüllt ist.

Dies geschieht zweckmäßigerweise mit dem Beweisprinzip der ''vollständigen Induktion''. Hierbei ist zu zeigen, dass
# <math> f(N_0) \leq g(N_0) </math> für die eine zu bestimmende Konstante <math> N_0 </math> gilt (''Induktionsanfang'') und
# falls <math> f(N) \leq g(N) </math>, dann auch <math> f(N+1) \leq g(N+1) </math> (''Induktionsschritt'') gilt.

===Beweis durch Dividieren===

Hierbei wählt man eine Konstante c und zeigt, dass <math> \lim_{N \rightarrow \infty} \frac{f(N)}{c \cdot g(N)} \leq 1 </math> gilt (für die O-Notation, bei Ω-Notation gilt entsprechend <math>\geq 1 </math>). Man kann dies auch als alternative Definition der Komplexität verwenden.

Als Beispiel betrachten wir die beiden Funktionen <math> f(N) = N \,\lg N </math> und <math> g(N) = N^2 </math> und wollen zeigen, dass <math>f(N) \in \mathcal{O}(g(N))</math> gilt.

Als Konstante c wählen wir <math> c = 1 </math>

<math> \lim_{N \rightarrow \infty} \frac{f(N)}{g(N)} = \lim_{N \rightarrow \infty} \frac{\lg N}{N} = \frac{\infty}{\infty} </math>

Unbestimmte Ausdrücke der Form
<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} </math>,
in denen sowohl <math> f(x) </math> als auch <math> g(x) </math> mit <math> x \rightarrow x_0 </math> gegen Null oder gegen Unendlich streben, kann man manchmal mit den Regeln von [http://de.wikipedia.org/wiki/L%27Hospital%27sche_Regel ''l'Hospital''] berechnen. Danach darf man die Funktionen f und g zur Berechnung des unbestimmten Ausdrucks durch ihre k-ten Ableitungen ersetzen:

<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} = \lim_{x \rightarrow x_0} \frac{f^{(k)}(x)}{g^{(k)}(x)} </math>

In unserem Fall verwenden wir die erste Ableitung und erhalten:
<math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)} = \lim_{N \rightarrow \infty} \frac{1/N}{1} \rightarrow 0 </math>

Damit wurde <math>f(N) \in \mathcal{O}(g(N))</math>, also <math>N \lg N \in \mathcal{O}(N^2)</math> gezeigt.

Man beachte hierbei, dass <math>N \lg N \in \mathcal{O}(N^2)</math> keine enge Grenze für die Komplexität von <math>N \,\lg N</math> darstellt, da der Grenzwert <math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)}\, </math> gegen 0 und nicht gegen eine von Null verschiedene Konstante strebt. In diesem Fall haben wir die Komplexität von <math>N \cdot \lg N </math> also nur nach oben abschätzen können.

===Beispiel für den Komplexitätsvergleich: Gleitender Mittelwert (Running Average)===

Wir berechnen für ein gegebenes Array <tt>a</tt> einen gleitenden Mittelwert über <tt>k</tt> Elemente: 
::<math>r_i = \frac{1}{k} \sum_{j=i-k+1}^i a_j</math> 
Das heisst, für jedes <tt>i</tt> mitteln wir die letzten <tt>k</tt> Elemente von <tt>a</tt> und schreiben das Ergebnis in <tt>r[i]</tt>. Diese Operation ist z.B. bei Börsenkursen wichtig: Neben dem aktuellen Kurs für jeden Tag wird dort meist auch der gleitende Mittelwert der letzten 30 Tage sowie der letzten 200 Tage angegeben. In diesen Mittelwerten erkennt man besser die langfristige Tendenz, weil die täglichen Schwankungen herausgemittelt werden. Wir nehmen außerdem an, dass
* Array-Zugriff hat eine Komplexität von O(1)
* <math>k \ll N</math>, d.h. <math>N-k\approx N</math>.

Die beiden folgenden Algorithmen berechnen die Mittelwerte auf unterschiedliche Art. Der linke folgt der obigen Definition durch eine Summe, während der rechte inkrementell arbeitet: Man kann den Bereich der <tt>k</tt> letzten Werte als Fenster betrachten, das über das Array <tt>a</tt> geschoben wird. Schiebt man das Fenster ein Element weiter, fällt links ein Element heraus, und rechts kommt eins hinzu. Man muss also nicht jedes Mal die Summe neu berechnen, sondern kann den vorigen Wert aktualisieren. Wir werden sehen, dass dies Folgen für die Komplexität des Algorithmus hat.

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1: O(N * k)
! Komplexität
! Version 2: O(N)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|
<tt>for i in range(k):</tt>
|
'''<center>O(k)</center>'''
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|
:: <tt>r[k-1] += a[i]</tt>
|
'''<center>O(1)</center>'''
|-
|
6.
|
:::: <tt>r[j] += a[i]</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(k, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|
:: <tt>r[j] = (a[j] - a[j-k] + r[j-1])</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(len(a)):</tt>
|
'''<center>O(N)</center>'''
|-
|
9.
|

|

|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
10.
|

|

|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Wir zeigen unten dass Version 2 eine geringere Komplexität besitzt, obwohl sie mehr Zeilen benötigt.

Wir haben in der Tabelle die Komplexität jeder Zeile für sich angegeben. Einfache Anweisungen (Berechnungen, Lese- und Schreibzugriffe auf das Array, Zuweiseungen) haben konstante Komplexität, die Komplexität des Schleifenkopfes allein (also der <tt>for</tt>-Anweisung ohne den eingerückten Schleifenkörper) entspricht der Anzahl der Durchläufe. Wir müssen jetzt noch die Verschachtelung der Schleifen und die Nacheinanderausführung von Anweisungen berücksichtigen.

====Berechnung der Komplexität von Version 1====

(Wiederholung der Rechenregeln: siehe Abschnitt [[Effizienz#O-Notation|O-Notation]])

Wir betrachten zunächst die innere Schleife (Zeilen 5 und 6 von Version 1):

Der Schleifenkopf (Zeile 5) hat die Komplexität <math>\mathcal{O}(k)</math>, weil die Schleife k-mal durchlaufen wird. Der Schleifenkörper (Zeile 6) hat die Komplexität <math>\mathcal{O}(1)</math>. Nach der Verschachtelungsregel müssen wir die beiden Komplexitäten multiplizieren, und es ergibt sich:

::<math>\mathcal{O}(k)\cdot\mathcal{O}(1) = \mathcal{O}(k\cdot 1)=\mathcal{O}(k)</math>

Wir betrachten nun die äußere Schleife. Der Schleifenkopf (Zeile 4) wird (N-k)-mal durchlaufen und hat somit eine Komplexität von <math>\mathcal{O}(N)</math>. Der Schleifenkörper (Zeilen 5 bis 7) besteht aus der inneren Schleife (Zeilen 5 und 6) mit der gerade berechneten Komplexität <math>\mathcal{O}(k)</math> sowie einer einfachen Anweisung (Zeile 7) mit Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel wird die Komplexität des Schleifenkörpers durch Addition berechnet:

::<math>\mathcal{O}(k)+\mathcal{O}(1) = \mathcal{O}(\max(k,1)) = \mathcal{O}(k)</math>

Die Komplexität der gesamten äußeren Schleife erhalten wir nach der Verschachtelungsregel wieder durch multiplizieren:

::<math>\mathcal{O}(N)\cdot\mathcal{O}(k) = \mathcal{O}(N\cdot k)</math>

Die übrigen Schritte des Algorithmus werden einfach nacheinander ausgeführt, so dass sie ebenfalls nach der Sequenzregel behandelt werden. Wir erhalten

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(N\cdot k)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,N\cdot k,1)) = \mathcal{O}(N\cdot k)</math>

Der gesamte Algorithmus hat also die Komplexität <math>\mathcal{O}(N\cdot k)</math>.

====Berechnung der Komplexität von Version 2====

Hier gibt es nur einfache Schleifen ohne Verschachtelung. Da der Schleifenkörper jeder Schleife nur einfache Anweisungen der Komplexität <math>\mathcal{O}(1)</math> enthält, ergibt sich die Komplexität der Schleifen nach der Verschachtelungsregel als

::<math>\mathcal{O}(X)\cdot\mathcal{O}(1) = \mathcal{O}(X\cdot 1)=\mathcal{O}(X)</math>

wobei <math>\mathcal{O}(X)</math> die Komplexität des jeweiligen Schleifenkopfes ist. Wir erhalten also für Zeilen 4 und 5: <math>\mathcal{O}(k)</math>, Zeilen 6 und 7: <math>\mathcal{O}(N)</math>, Zeilen 8 und 9: <math>\mathcal{O}(N)</math>. Die Hintereinanderausführung wird nach der Sequenzregel behandelt:

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(k)+\mathcal{O}(N)+\mathcal{O}(N)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,k,N,N,1)) = \mathcal{O}(N)</math>

Dieser Algorithmus hat also nur die Komplexität <math>\mathcal{O}(N)</math>.

====Fazit====

Obwohl Version 2 mehr Schritte benötigt hat sie eine geringere Komplexität, da die for-Schleifen nicht wie bei Version 1 verschachtelt/untergeordnet sind. Bei verschachtelten for-Schleifen muss die Multiplikationsregel angewendet werden → höhere Komplexität.

Die gerade berechnete Komplexität gilt aber nur unter der Annahme, dass Array-Zugriffe konstante Komplexität <math>\mathcal{O}(1)</math> besitzen. Wenn dies nicht der Fall ist, kann sich die Komplexität des Algorithmus drastisch verschlechtern.

{| border="1" cellspacing="0" cellpadding="5"
|Allgemein gilt: 
Algorithmen-Analysen beruhen auf der Annahme, dass Zugriffe auf die Daten optimal schnell sind, dass heißt, dass die für den jeweiligen Algorithmus am besten geeignete Datenstruktur verwendetet wird. → Ansonsten: Komplexitätsverschlechterung!
|}
 

====Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur====

Wir verwende im Mittelwert-Algorithmus eine verkettete Liste anstelle des Eingabe-Arrays a. Wir benötigen dazu eine Funktion, die das j-te Element der Liste zurückgibt. Wie üblich ist die Liste mit Hilfe einer Knotenklasse implementiert:
class Node:
def __init__(self, data):
self.data = data
self.next = None

Die Listenklasse selbst hat ein Feld <tt>head</tt>, das eine Referenz auf den ersten Knoten speichert, und jeder Knoten speichert im Feld <tt>next</tt> eine Referenz auf seinen Nachfolger. Um zum j-ten Element zu gelangen, muss man die Liste sequenziell durchlaufen
def get_jth(list, j):
r = list.head
while j > 0:
r = r.head
j -= 1
return r.data
Die Komplexität dieser Funktion ist offensichtlich <math>\mathcal{O}(j)</math> (Komplexitätsberechnung wie oben). Wir setzen jetzt bei Version 1 des Mittelwert-Algorithmus diese Funktion in Zeile 6 anstelle des Indexzugriffs <tt>a[i]</tt> ein (nur in dieser Zeile wird auf die Elemente des Arrays zugegriffen). Wir erhalten folgende Implementation (die Änderungen sind rot markiert):

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1 mit Liste: O(N * k)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|-
|
6.
|
:::: <tt>r[j] += get_jth(a, i)</tt>
|
'''<center>O(i)</center>'''
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Der Aufruf der Funktion <tt>get_jth</tt> ist jetzt gleichbedeutend mit einer dreifach verschachtelten Schleife (weil <tt>get_jth</tt> ja eine zusatzliche Schleife enthält). Die Anzahl der Operationen in Zeile 4 bis 6 ist jetzt

::<math>f(N,k)=\sum_{j=k-1}^{N-1}\,\sum_{i=j-k+1}^j\,\mathcal{O}(i)</math>

wobei das <math>\mathcal{O}(i)</math> die neue Schleife durch Verwendung der Liste repräsentiert. Mit Mathematica-Hilfe [http://www.wolfram.com/] lässt sich diese Summe exakt ausrechnen

::<math>f(N,k)=\frac{1}{2}(k N^2-k^2 N+k^2-k)\in \mathcal{O}(k N^2)</math>

Die Komplexitätsberechnung erfolgte dabei nach der Regel für Polynome unter Beachtung von <math>k \ll N</math>.

====Fazit:====

Die Komplexität von Version 1 mit einer verketteten Liste wäre O(N2 * k)
'''→ Die richtige Datenstruktur ist wichtig, da es sonst zu einer Komplexitätsverschlechterung kommen kann!'''

Auf Version 2 unseres Running Average-Beispiels hätte eine verkettete Liste allerdings keine Auswirkungen, da die inkrementelle Berechnung der Summen in Zeile 7 weiterhin möglich ist (bei geschickter Implementation!) und somit Version 2 immer noch eine Komplexität von O(N) hätte.

==Amortisierte Komplexität==

Bis jetzt wurde die Komplexität nur im schlechtesten Fall (Worst Case) betrachtet. Bei einigen Algorithmen schwankt die Komplexität im schlechtesten Fall jedoch, wenn man die ungünstige Operation mehrmals hintereinander ausführt. Die amortisierte Komplexität beschäftigt sich mit der durchschnittlichen Komplexität über viele Aufrufe der ungünstigsten Operation.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse Wikipedia: Amortisierte Laufzeitanalyse]]

===Beispiel: Inkrementieren von Binärzahlen===

Frage: Angenommen, das Umdrehen eines Bits einer Binärzahl verursacht Kosten von 1 Einheit. Wir erzeugen die Folge der natürlichen Zahlen durch sukzessives Inkrementieren, von Null beginnend. Bei jeder Inkrementierung werden einige Bits verändert, aber diese Zahl (und damit die Kosten der Inkrementierungen) ''schwanken'' sehr stark. Wir fragen jetzt, was eine Inkrementierung im Durchschnitt kostet?

Um diese Durchschnittskosten zu berechnen, bezahlen wir bei jeder Inkrementierung 2 Einheiten. Wenn davon nach Abzug der Kosten der jeweiligen Operation noch etwas übrig bleibt, wird der Rest dem Guthaben zugeschrieben. Umgekehrt wird ein eventueller Fehlbetrag (wenn eine Inkrementierung mehr als 2 Bits umdreht) aus dem Guthaben gedeckt. Dadurch werden die ansonsten großen Schwankungen der Kosten ausgeglichen:
:: Kosten < Einzahlung → es wird gespart
:: Kosten = Einzahlung → Guthaben bleibt unverändert
:: Kosten > Einzahlung → Guthaben wird für die Kosten verbraucht

{| border="1" cellspacing="0" cellpadding="5"
!Schritte
!Zahlen
!Kosten 
(Anzahl der geänderten Bits)
! Einzahlung
!Guthaben = 
altes Guthaben + Einzahlung - Kosten
|-
|1.
|00001
|1
|'''2'''
|'''1'''
|-
|2.
|00010
|2
|'''2'''
|'''1'''
|-
|3.
|00011
|1
|'''2'''
|'''2'''
|-
|4.
|00100
|3
|'''2'''
|'''1'''
|-
|5.
|00101
|1
|'''2'''
|'''2'''
|-
|6.
|00110
|2
|'''2'''
|'''2'''
|-
|7.
|00111
|1
|'''2'''
|'''3'''
|-
|8.
|01000
|4
|'''2'''
|'''1'''
|-
|}

Die Kosten ergeben sich aus der Anzahl der Ziffern die von 1 nach 0, bzw. von 0 nach 1 verändert werden

Rechnung:

1. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

2. Schritt: Kosten: 2 = Einzahlung: 2 
:: → es wird nicht gespart 
:: → Guthaben bleibt so wie es ist 

3. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

4. Schritt: Kosten: 3 > Einzahlung: 2 
:: → es wird eine 1 vom Guthaben genommen um die Kosten zu zahlen 

usw.

Man erkennt, dass vor teuren Operation (Wechsel von 3 auf 4 bzw. von 7 auf 8) genügend Guthaben angespart wurde, um die Kosten zu decken. Das Guthaben geht bei diesen Operationen immer wieder auf 1 zurück, aber es wird nie vollständig verbraucht (Dies kann natürlich auch mathematisch exakt bewiesen werden, wie wir es unten am Beispiel des dynamische Arrays zeigen). Wir schließen daraus, dass die durchschnittlichen oder '''amortisierten Kosten''' einer Inkrementierungsoperation gleich 2 sind.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Account-Methode Wikipedia Account-Methode]]

====Fazit====
Die amortisierte Komplexität beschäftigt sich mit dem Durchschnitt aller Operation im ungünstigsten Fall. Operationen mit hohen Kosten, die aber nur selten ausgeführt werden, fallen bei der amortisierten Komplexität nicht so ins Gewicht. Bei Algorithmen, die gelegentlich eine "teure" Operation benutzen, ansonsten jedoch "billigen" Operationen aufrufen, kann die amortisierte Komplexität niedriger sein als die Komplexität im schlechtesten (Einzel-)Fall.

In unserem Beispiel fallen die teuren Einzelschritte (z.B. 4. und 8. Schritt) bei den amortisierten Kosten nicht so ins Gewicht, da wir die Kosten aus unserem Guthaben mitbezahlen können. Das Guthaben ist immer groß genug, weil jeder zweite Aufruf eine billige Operation ist, die nur ein Bit umdreht und somit das Ansparen ermöglichen. Diese Betrachtung zeigt, dass die amortisierte (d.h. durchschnittliche) Komplexität des Algoithmus niedriger (nämlich konstant) ist als die Komplexität im schlechtesten Fall.

===statisches Array===

Ein statisches Array hat eine feste Größe N und das Erweitern des Arrays um ein neues Element besitzt eine Komplexität von O(N),
denn es muss ein neues Array mit der Größe N+1 erzeugt werden. 

Anhängen eines weiteren Elements an ein statisches Array:

{| border="1" cellspacing="0" cellpadding="5" align="right"
!Schritte
|'''Array'''
(wie es aussehen könnte)
!Komplexität
|-
|<center>altes Array</center>
|<center>[0,1,2,3]</center>
|<center>-</center>
|-
|1. Array N+1
|<center>[None,None,None,None,None]</center>
|<center>O(N+1) = '''O(N)'''</center>
|-
|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 Daten aus dem alten Array werden in das neue Array mit der Länge N+1 kopiert 
(Die Operation besitzt nur eine Komplexität von O(N), wenn das Kopieren eines Elements eine Komplexität von O(1) besitzt) 
3. 'x' wird an die letzte Stelle des neuen Arrays geschrieben

Additionsregel: 
O(N) + O(N) + O(1) ∈ O(N), falls O(1) ∈ O(N) [O(max(O(N),O(1))] (Bedingung: N > 1)

===dynamisches Array===

Beim dynamischen Array werden mehr Speicherelemente reserviert als zur Zeit benötigt. Wir unterscheiden deshalb

::<tt>capacity</tt> = Anzahl 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 "capacity" 

Ist dieses Array voll, wird ein neues Datenarray der doppelten Größe allokiert, und die Daten werden vom alten ins neue Array kopiert. Die Vorgehensweise
beim Zufügen eines neuen Elements im Fall (size == capacity) ist also
* capacity wird verdoppelt 
: neue capacity = 2 * alte capacity
: (allgemein genügt es auch, wenn capacity wird um einen bestimmten Prozentsatz vergrößert wird,
:: neue capacity = alte capacity * c (mit c > 1, z.B. c = 1.2)
* 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

'''Folge:''' Die Kosten für das Vergrößern 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), wie wir jetzt zeigen:

===Analyse des dynamischen Arrays===

Durchschnitt der Gesamtkosten für N-maliges append = <math>\frac{1}{N} \sum_{i = 1}^N Kosten(i)</math>. Zur Analyse der amortisierten Komplexität wird ein Potential 
::Φi = 2*sizei - capacityi 
eingeführt, wobei das Array nach dem i-ten Einfüge-Schritt die Größe sizei und die Kapizität capacityi hat. Wir nehmen vereinfachend an, dass es keine Löschoperationen gibt. Dann gilt nach dem i-ten Schritt jeweils
::Φi = 2*i - capacityi 

Fall 1: Array ist nicht voll 
Es wird kein Umkopieren benötigt, da das Array noch nicht voll ist 
→ sizei-1 < capacityi-1 
→ capacityi == capacityi-1

Kosten: 1 (für Einfügen des neuen Elements) 
Potenzial vor append: Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append: Φi = 2i - capacityi-1 

amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = 1 + (2i - capacityi-1) - [2(i - 1) - capacityi-1]
::::: = 1 + 2i - capacityi-1 - 2i + 2 + capacityi-1
::::: = 1 + <del>2i</del> - <del>capacityi-1</del> - <del>2i</del> + 2 + <del>capacityi-1</del>
::::: = 1 + 2
::::: = 3 = O(1) → konstant

Fall 2: Array ist voll 
Vor dem i-ten append muss umkopiert werden 
→ sizei-1 == capacityi-1 == i-1 
→ Allokieren eines neuen statischen Arrays mit verdoppelter Kapazität notwendig, also capacityi == 2*capacityi-1

Kosten: (i-1) + 1 (für Umkopieren und Einfügen des neuen Elements) 
Potenzial vor append = Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append = Φi = 2i - 2 capacityi-1 
amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = ((i - 1) + 1) + 2i - 2 capacityi-1 - [2(i-1) - capacityi-1]
::::: = i + <del>2i</del> - 2 capacityi-1 - <del>2i</del> + 2 - capacityi-1
::::: = i + 2 - capacityi-1
::::: = i + 2 - (i - 1) (da capacityi-1 = i-1)
::::: = 3 = O(1) → konstant

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine amortisierte Komplexität von 3 Einheiten hat, also <tt>append</tt> ∈ O(1)'''. Diese Operation kann deshalb gefahrlos in der inneren Schleife eines Algorithmus benutzt werden.

==== Beispiel für 9 Einfügeoperationen ====

{| border="1" cellspacing="0" cellpadding="5"
!Array 
(wie es aussehen könnte)
!size
!capacity
!Kosten für append (einschließlich Umkopieren)
!Summe Kosten
!Durchschnittskosten
!Φi = 2 * size - capacity 
(i = size)
!Potenzialdifferenz 
Δ Φi = Φi - Φi-1
!amortisierte Kosteni 
= Kosteni + Δ Φi
|-
| <center>[None]</center>
| <center>0</center>
| <center>1</center>
| <center>-</center>
| <center>-</center>
| <center>-</center>
| <center>-1</center>
| <center>-</center>
| <center>-</center>
|-
| <center>[a]</center><center>Array ist voll!</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b]</center><center>Array ist voll!</center>
| <center>2</center>
| <center>2</center>
| <center>1 + 1</center>
| <center>3</center>
| <center>3/2</center>
| <center>2</center>
| <center>1</center>
| <center>3</center>
|-
| <center>[a,b,c,None]</center>
| <center>3</center>
| <center>4</center>
| <center>2 + 1</center>
| <center>6</center>
| <center>6/3</center>
| <center>2</center>
| <center>0</center>
| <center>3</center>
|-
| <center>[a,b,c,d]</center><center>Array ist voll!</center>
| <center>4</center>
| <center>4</center>
| <center>1</center>
| <center>7</center>
| <center>7/4</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,None,None,None]</center>
| <center>5</center>
| <center>8</center>
| <center>4 + 1</center>
| <center>12</center>
| <center>12/5</center>
| <center>2</center>
| <center>-2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,None,None]</center>
| <center>6</center>
| <center>8</center>
| <center>1</center>
| <center>13</center>
| <center>13/6</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,None]</center>
| <center>7</center>
| <center>8</center>
| <center>1</center>
| <center>14</center>
| <center>14/7</center>
| <center>6</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h]</center><center>Array ist voll!</center>
| <center>8</center>
| <center>8</center>
| <center>1</center>
| <center>15</center>
| <center>15/8</center>
| <center>8</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h,j,None,None,None, 
None,None,None,None]</center>
| <center>9</center>
| <center>16</center>
| <center>8 + 1</center>
| <center>24</center>
| <center>24/9</center>
| <center>2</center>
| <center>-6</center>
| <center>3</center>
|-
|}

Die durchschnittlichen Kosten betragen stets etwa 2 Einheiten, schwanken allerdings so, dass nicht unmittelbar ersichtlich ist, ob dies für sämtliche Einfügeoperationen gilt. Die amortisierte Komplexität, die mit Hilfe des Potentials berechnet wird, ist hingegen konstant 3, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

[[Suchen|Nächstes Thema]]

Effizienz

2010-08-10T12:18:32Z

Jschleic: /* Optimierung der Laufzeit */ quadrat. Gleichung

Bei der Diskussion von Effizienz müssen wir zwischen der Laufzeit eines Algorithmus auf einem bestimmten System und seiner prinzipiellen Leistungsfähigkeit (Algorithmenkomplexität) unterscheiden. Der Benutzer ist natürlich vor allem an der Laufzeit interessiert, denn diese bestimmt letztendlich seine Arbeitsproduktivität. Ein Softwaredesigner hingegen muss eine Implementation wählen, die auf verschiedenen Systemen und in verschiedenen Anwendungen schnell ist. Für ihn sind daher auch Aussagen zur Algorithmenkomplexität sehr wichtig, um den am besten geeigneten Algorithmus auszuwählen.

== Laufzeit ==

Aus Anwendersicht ist ein Algorithmus effizient, wenn er die in der Spezifikation verlangten Laufzeitgrenzen einhält. Ein Algorithmus muss also nicht immer so schnell wie möglich sein, sondern so schnell wie nötig. Dies führt in verschiedenen Anwendungen zu ganz unterschiedliche Laufzeitanforderungen:

* Berechnen des nächsten Steuerkommandos für eine Maschine: ca. 1/1000s
* Berechnen des nächsten Bildes für eine Videopräsentation (z.B. Dekompression von MPEG-kodierten Bildern): ca. 1/25s
: Geringere Bildraten führen zu ruckeligen Filmen.
* Sichtbare Antwort auf ein interaktives Kommando (z.B. Mausklick): ca. 1/2s
: Wird diese Antwortzeit überschritten, vermuten viele Benutzer, dass der Mausklick nicht funktioniert hat, und klicken nochmals, mit eventuell fatalen Folgen. Wenn ein Algorithmus notwendigerweise länger dauert als 1/2s, sollte ein Fortschrittsbalken angezeigt werden.
* Wettervorhersage: muss spätestens am Vorabend des vorhergesagten Tages beendet sein

===Laufzeitvergleich===

Da die Laufzeit für den Benutzer ein so wichtiges Kriterium ist, werden häufig Laufzeitvergleiche durchgeführt. Deren Ergebnisse hängen allerdings von vielen Faktoren ab, die möglicherweise nicht kontrollierbar sind:
* Geschwindigkeit und Anzahl der Prozessoren
* Auslastung des Systems
* Größe des Hauptspeichers und Cache, Geschwindigkeit des Datenbus
* Qualität des Compilers/Optimierers (ist der Compiler für die spezielle Prozessor-Architektur optimiert?)
* Geschick des Programmierers
* Daten (Beispiel Quicksort: Best case und worst case [vorsortierter Input] stark unterschiedlich)
All diese Faktoren sind untereinander abhängig. Laufzeitvergleiche sind daher mit Vorsicht zu interpretieren.
Generell sollten bei Vergleichen möglichst wenige Parameter verändert werden, z.B.
* gleiches Programm (gleiche Kompilierung), gleiche Daten, andere Prozessoren
oder
* gleiche CPU, Daten, andere Programme (Vergleich von Algorithmen)
Zur Verbesserung der Vergleichbarkeit gibt es standardisierte [http://en.wikipedia.org/wiki/Benchmark_(computing) Benchmarks], die bestimmte Aspekte eines Systems unter möglichst realitätsnahen Bedingungen testen. Generell gilt aber: Durch Laufzeitmessung ist schwer festzustellen, ob ein Algorithmus ''prinzipiell'' besser ist als ein anderer. Dafür ist die Analyse der [[Effizienz#Algorithmen-Komplexität|Algorithmenkomplexität]] notwendig.

===Optimierung der Laufzeit===

Wenn sich herausstellt, dass ein bereits implementierter Algorithmus zu langsam läuft, geht man wie folgt vor:

# Man verwendet einen [http://en.wikipedia.org/wiki/Performance_analysis Profiler], um zunächst den Flaschenhals zu bestimmen. Ein Profiler ist ein Hilfsprogramm, das während der Ausführung eines Programms misst, wieviel Zeit in jeder Funktion und Unterfunktion verbraucht wird. Dadurch kann man herausfinden, welcher Teil des Algorithmus überhaupt Probleme bereitet. Donald Knuth gibt z.B. als Erfahrungswert an, dass Programme während des größten Teils ihrer Laufzeit nur 3% des Quellcodes (natürlich mehrmals wiederholt) ausführen [http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf]. Es ist sehr wichtig, diese 3% experimentell zu bestimmen, weil die Erfahrung zeigt, dass man beim Erraten der kritischen Programmteile oft falsch liegt. Man spricht dann von "[http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize premature optimization]", also von voreiliger Optimierung ohne experimentelle Untersuchung der wirklichen Laufzeiten, was laut Knuth "the root of all evil" ist. Der Python-Profiler wird in [http://docs.python.org/lib/profile.html Kapitel 25] der Python-Dokumentation beschrieben.
# Man kann dann versuchen, die kritischen Programmteile zu optimieren.
# Falls der Laufzeitgewinn durch Optimierung zu gering ist, muss man einen prinzipiell schnelleren Algorithmus verwenden, falls es einen gibt.

Einige wichtige Techniken der Programmoptimierung sollen hier erwähnt werden. Wenn man einen optimierenden Compiler verwendet, werden einige Optimierungen automatisch ausgeführt [http://en.wikipedia.org/wiki/Compiler_optimization]. In Python trifft dies jedoch nicht zu. Um den Sinn einiger Optimierungen zu verstehen, benötigt man Grundkenntnisse der Computerarchitektur.

;Elimination von redundantem Code: Es ist offensichtlich überflüssig, dasselbe Ergebnis mehrmals zu berechnen, wenn es auch zwischengespeichert werden könnte. Diese Optimierung wird von vielen automatischen Optimierern unterstützt und kommt im wesentlichen in zwei Ausprägungen vor:
:; common subexpression elimination: In mathematischen Ausdrücken wird ein Teilergebnis häufig mehrmals benötigt. Man betrachte z.B. die Lösung der quadratischen Gleichung <math>x^2+p\,x+q = 0</math>:
x1 = - p / 2.0 + sqrt(p*p/4.0 - q)
x2 = - p / 2.0 - sqrt(p*p/4.0 - q)
::Die mehrmalige Berechnung von Teilausdrücken wird vermieden, wenn man stattdessen schreibt:
p2 = - p / 2.0
r = sqrt(p2*p2 - q)
x1 = p2 + r
x2 = p2 - r
:; loop invariant elimination: Wenn ein Teilausdruck sich in einer Schleife nicht ändert, muss man ihn nicht bei jedem Schleifendurchlauf neu berechnen, sondern kann dies einmal vor Beginn der Schleife tun. Ein typisches Beispiel hierfür ist die Adressierung von Matrizen, die als 1-dimensionales Array gespeichert sind. Angenommen, wir speichern eine NxN Matrix <tt>m</tt> in einem Array <tt>a</tt> der Größe N2, so dass das Matrixelement <tt>mij</tt> durch <tt>a[i + j*N]</tt> indexiert wird. Wir betrachten die Aufgabe, eine Einheitsmatrix zu initialisieren. Ein nicht optimierter Algorithmus dafür lautet:
for j in range(N):
for i in range(N):
if i == j:
a[i + j*N] = 1.0
else:
a[i + j*N] = 0.0
::Der Ausdruck <tt>j*N</tt> wird hier in jedem Schleifendurchlauf erneut berechnet, obwohl sich <tt>j</tt> in der inneren Schleife gar nicht verändert. Man kann deshalb optimieren zu:
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
;Vereinfachung der inneren Schleife: Generell sollte man sich bei der Optimierung auf die innere Schleife eines Algorithmus konzentrieren, weil dieser Code am häufigsten ausgeführt wird. Insbesondere sollte man die Anzahl der Befehle in der inneren Schleife so gering wie möglich halten und teure Befehle vermeiden. Früher waren vor allem Floating-Point Befehle teuer, die man oft durch die schnellere Integer-Arithmetik ersetzt hat, falls dies algorithmisch möglich war (diesen Rat findet man noch oft in der Literatur). Heute hat sich die Hardware so verbessert, dass im Allgemeinen nur noch die Floating-Point Division deutlich langsamer ist als die anderen Operatoren. Im obigen Beispiel der quadratischen Gleichung ist es daher sinnvoll, den Ausdruck
p2 = -p / 2.0
:durch
p2 = -0.5 * p
:zu ersetzen. Dadurch ersetzt man eine Division durch eine Multiplikation und spart außerdem das Negieren von <tt>p</tt>, da der Compiler direkt mit <tt>-0.5</tt> multipliziert.
;Ausnutzung der Prozessor-Pipeline: Moderne Prozessoren führen mehrere Befehle parallel aus. Dies ist möglich, weil jeder Befehl in mehrere Teilschritte zerlegt werden kann. Eine generische Unterteilung in vier Teilschritte ist z.B.:
:# Dekodieren des nächsten Befehls
:# Beschaffen der Daten, die der Befehl verwendet (aus Prozessorregistern, dem Cache, oder dem Hauptspeicher)
:# Ausführen des Befehls
:# Schreiben der Ergebnisse
:Man bezeichnet dies als die "[http://en.wikipedia.org/wiki/Instruction_pipeline instruction pipeline]" des Prozessors (heutige Prozessoren verwenden wesentlich feinere Unterteilungen). Prozessoren werden nun so gebaut, dass mehrere Befehle parallel, auf verschiedenen Ausführungsstufen ausgeführt werden. Wenn Befehl 1 also beim Schreiben der Ergebnisse angelangt ist, kann Befehl 2 die Hardware zum Ausführen des Befehls benutzen, während Befehl 3 seine Daten holt, und Befehl 4 soeben dekodiert wird. Unter bestimmten Bedingungen funktioniert diese Parallelverarbeitung jedoch nicht. Dies gibt Anlass zu Optimierungen:
:;Vermeiden unnötiger Typkonvertierungen: Der Prozessor verarbeitet Interger- und Floating-Point-Befehle in verschiedenen Pipelines, weil die Hardwareanforderungen sehr verschieden sind. Wird jetzt ein Ergebnis von Integer nach Floating-Point umgewandelt oder umgekehrt, muss die jeweils andere Pipeline warten, bis die erste Pipeline ihre Berechnung beendet. Es kann dann besser sein, Berechnungen in Floating-Point zu Ende zu führen, auch wenn sie semantisch eigentlich Integer-Berechnungen sind.
:;Reduzierung der Anzahl von Verzweigungen: Wenn der Code verzweigt (z.B. durch eine <tt>if</tt>- oder <tt>while</tt>-Anweisung), ist nicht klar, welcher Befehl nach der Verzweigung ausgeführt werden soll, bevor Stufe 3 der Pipiline die Verzweigungsbedingung ausgewertet hat. Bis dahin wären die ersten beiden Stufen der Pipeline unbenutzt. Moderne Prozessoren benutzen zwar ausgefeilte Heuristiken, um das Ergebnis der Bedingung vorherzusagen, und führen den hoffentlich richtigen Zweig des Codes spekulativ aus, aber dies funktioniert nicht immer. Man sollte deshalb generell die Anzahl der Verzweigungen minimieren. Als Nebeneffekt führt dies meist auch zu besser lesbarem, verständlicherem Code. Im Matrixbeispiel kann man
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
::durch
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
ersetzen. Die Diagonalelemente <tt>a[j + jN]</tt> werden jetzt zwar zweimal initialisiert (in der Schleife auf Null, dann auf Eins), aber durch Elimination der <tt>if</tt>-Abfrage wird dies wahrscheinlich mehr als ausgeglichen, zumal dadurch die innere Schleife wesentlich vereinfacht wurde.
;Ausnutzen des Prozessor-Cache: Zugriffe auf den Hauptspeicher sind sehr langsam. Deshalb werden stets ganze Speicherseiten auf einmal in den [http://en.wikipedia.org/wiki/Cache Cache] des Prozessors geladen. Wenn unmittelbar nacheinander benutzte Daten auch im Speicher nahe beieinander liegen (sogenannte "[http://en.wikipedia.org/wiki/Locality_of_reference locality of reference]"), ist die Wahrscheinlichkeit groß, dass die als nächstes benötigten Daten bereits im Cache sind und damit schnell gelesen werden können. Bei vielen Algorithmen kann man die Implementation so umordnen, dass die locality of reference verbessert wird, was zu einer drastischen Beschleunigung führt. Im Matrix-Beispiel ist z.B. die Reihenfolge der Schleifen wichtig. Für konstanten Index <tt>j</tt> liegen die Indizes <tt>i</tt> im Speicher hintereinander. Deshalb ist es günstig, in der inneren Schleife über <tt>i</tt> zu iterieren:
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
:Die umgekehrte Reihenfolge der Schleifen ist hingegen ungünstig
for i in range(N):
for j in range(N):
a[i + j*N] = 0.0
a[i + i*N] = 1.0
:Jetzt werden in der inneren Schleife stets N Datenelemente übersprungen. Besonders bei großem N muss man daher häufig den Cache neu füllen, was bei der ersten Implementation nicht notwendig war. (Ausserdem verliert man hier die Optimierung <tt>jN = j*N</tt>, die jetzt nicht mehr möglich ist.)

Als Faustregel kann man durch Optimierung eine Verdoppelung der Geschwindigkeit erreichen (in Ausnahmefällen auch mehr). Benötigt man stärkere Verbesserungen, muss man wohl oder übel einen besseren Algorithmus oder einen schnelleren Computer verwenden.

== Algorithmen-Komplexität ==

Komplexitätsbetrachtungen ermöglichen den Vergleich der prinzipiellen Eigenschaften von Algorithmen unabhängig von einer Implementation, Umgebung etc.

Eine einfache Möglichkeit ist das Zählen der Aufrufe einer Schlüsseloperation. Beispiel Sortieren:
* Anzahl der Vergleiche
* Anzahl der Vertauschungen

=== Beispiel: Selection Sort ===

for i in range(len(a)-1):
max = i
for j in range(i+1, len(a)):
if a[j] < a[max]:
max = j
a[max], a[i] = a[i], a[max] # swap

*Anzahl der Vergleiche: Ein Vergleich in jedem Durchlauf der inneren Schleife. Es ergibt sich folgende Komplexität:
*:Ingesamt <math>\sum_{i=0}^{N-2} \sum_{j=i+1}^{N-1}1 = \frac{N}{2} (N-1) \!</math> Vergleiche.

*Anzahl der Vertauschungen (swaps): Eine Vertauschung pro Durchlauf der äußeren Schleife:
*:Insgesamt <math>N-1 \!</math> Vertauschungen

Die Komplexität wird durch die Operationen bestimmt, die am häufigsten ausgeführt werden, hier also die Anzahl der Vergleiche. Die Anzahl der Vertauschungen ist hingegen kein geeignetes Kriterium für die Komplexität von selection sort, weil der Aufwand in der inneren Schleife ignoriert würde.

=== Fallunterscheidung: Worst und Average Case ===

Die Komplexität ist in der Regel eine Funktion der Eingabegröße (Anzahl der Eingabebits, Anzahl der Eingabeelemente). Sie kann aber auch von der Art der Daten abhängen, nicht nur von der Menge, z.B. vorsortierte Daten bei Quicksort. Um von der Art der Daten unabhängig zu werden, kann man zwei Fälle der Komplexität unterscheiden:

* Komplexität im ungünstigsten Fall
*: Der ungünstigste Fall ist die Eingabe gegebener Länge, für die der Algorithmus am langsamsten ist. Der Nachteil dieser Methode besteht darin, dass dieser ungünstige Fall in der Praxis vielleicht gar nicht oder nur selten vorkommt, so dass sich der Algorithmus in Wirklichkeit besser verhält als man nach dieser Analyse erwarten würde. Beim Quicksort-Algorithmus mit zufälliger Wahl des Pivot-Elements müsste z.B. stets das kleinste oder größte Element des aktuellen Intervalls als Pivot-Element gewählt werden, was äußerst unwahrscheinlich ist.
* Komplexität im durchschnittlichen/typischen Fall
*: Der typische Fall ist die mittlere Komplexität des Algorithmus über alle möglichen Eingaben. Dazu muss man die Wahrscheinlichkeit jeder möglichen Eingabe kennen, und berechnet dann die mittlere Laufzeit über dieser Wahrscheinlichkeitsverteilung. Leider ist die Wahrscheinlichkeit der Eingaben oft nicht bekannt, so dass man geeignete Annahmen treffen muss. Bei Sortieralgorithmen können z.B. alle möglichen Permutationen des Eingabearrays als gleich wahrscheinlich angenommen werden, und der typische Fall ist dann die mittlere Komplexität über alle diese Eingaben. Oft hat man jedoch in der Praxis andere Wahrscheinlichkeitsverteilungen, z.B. sind die Daten oft "fast sortiert" (nur wenige Elemente sind an der falschen Stelle). Dann verhält sich der Algorithmus ebenfalls anders als vorhergesagt.

Wir beschränken uns in dieser Vorlesung auf die Komplexität im ungünstigseten Fall. '''Exakte''' Formeln für Komplexität sind aber auch dann schwer zu gewinnen, wie das folgende Beispiel zeigt:

=== Beispiele aus den Übungen (Gemessene Laufzeiten für Mergesort/Selectionsort) ===

* Mergesort: <math>\frac{0,977N\log N}{\log 2} + 0,267N-4.39 \!</math>
*: andere Lösung: <math>1140 N\log(N) - 1819N + 6413 \!</math>
* Selectionsort: <math>\frac{1}{2}N^2 - \frac{1}{2N} - 10^{-12} \!</math>
*: andere Lösung: <math>1275N^2 - 116003^N + 11111144 \!</math>

Aus diesen Formeln wird nicht offensichtlich, welcher Algorithmus besser ist.
Näherung: Betrachte nur '''sehr große Eingaben''' (meist sind alle Algorithmen schnell genug für kleine Eingaben). Dieses Vorgehen wird als '''Asymptotische Komplexität''' bezeichnet (N gegen unendlich).

=== Asymptotische Komplexität am Beispiel Polynom ===

Polynom: <math>a\,x^2+b\,x+c=p\!</math>

<math>x \!</math> sei die Eingabegröße, und wir betrachten die Entwicklung von <math>p \!</math> in Abhängigkeit von <math>x \!</math>.

* <math>x=0 \!</math>
*: <math>p=c \!</math>
* <math>x=1 \!</math>
*: <math>p=a+b+c \!</math>
* <math>x=1000 \!</math>
*: <math>p=1000000a+1000b+c \approx 1000000a\!</math>
* <math>x \to \infty \!</math>
*: <math>p \approx x^2a\!</math>

Für sehr große Eingaben verlieren also ''b'' und ''c'' immer mehr an Bedeutung, so dass am Ende nur noch ''a'' für die Komplexitätsbetrachtung wichtig ist.

== Landau-Symbole ==

Um die asymptotische Komplexität verschiedener Algorithmen miteinander vergleichen zu können, verwendet man die sogenannten [http://de.wikipedia.org/wiki/Landau-Symbole Landau-Symbole]. Das wichtigste Landau-Symbol ist <math>\mathcal{O}</math>, mit dem man eine ''obere Schranke'' <math>f \in \mathcal{O}(g)</math> für die Komplexität angeben kann.

Schreibt man <math>f \in \Omega(g)</math>, so stellt dies eine asymptotische ''untere Schranke'' für die Funktion f dar.

Schließlich bedeutet <math>f \in \Theta(g)</math>, dass die Funktion f genauso schnell wie die Funktion g wächst, das heißt man hat eine asymptotisch ''scharfe Schranke'' für f. Hierzu muss sowohl <math>f\in\mathcal{O}(g)</math> als auch <math>f \in \Omega(g)</math> erfüllt sein.

Im nun folgenden soll auf die verschiedenen Landau-Symbole noch näher eingegeangen werden.

===O-Notation===

Intuitiv gilt: Für große N dominieren die am schnellsten wachsenden Terme einer Funktion. Die Notation <math>f \in \mathcal{O}(g)</math> (sprich "f ist in O von g" oder "f ist von derselben Größenordnung wie g") formalisiert eine solche Abschätzung der asymptotischen Komplexität der Funktion f von oben.
; Asymptotische Komplexität: Für zwei Funktionen f(x) und g(x) gilt
::<math>f(x) \in \mathcal{O}(g(x))</math>
: genau dann wenn es eine Konstante <math>c>0</math> und ein Argument <math>x_0</math> gibt, so dass
::<math>\forall x \ge x_0:\quad f(x) \le c\,g(x)</math>.
:Die Menge <math>\mathcal{O}(g(x))</math> aller durch g(x) abschätzbaren Funktionen ist also formal definiert durch
::<math>\mathcal{O}(g(x)) = \{ f(x)\ |\ \exists c>0: \forall x \ge x_0: 0 \le f(x) \le c\,g(x)\}</math>

Die Idee hinter dieser Definition ist, dass g(x) eine wesentlich einfachere Funktion ist als f(x), die sich aber nach geeigneter Skalierung (Multiplikation mit c) und für große Argumente x im wesentlichen genauso wie f(x) verhält. Man kann deshalb in der Algorithmenanalyse f(x) durch g(x) ersetzen. <math>f(x) \in \mathcal{O}(g(x))</math> spielt für Funktionen eine ähnliche Rolle wie der Operator ≤ für Zahlen: Falls a ≤ b gilt, kann bei einer Abschätzung von oben ebenfalls a durch b ersetzt werden.

==== Ein einfaches Beispiel ====

[[Image:Sqsqrt.png]]

Rot = <math>x^2 \!</math>
Blau = <math>\sqrt{x} \!</math>

<math>\sqrt{x} \in \mathcal{O}(x^2)\!</math> weil <math>\sqrt{x} \le c\,x^2\!</math> für alle <math>x \ge x_0 = 1 \!</math> und <math>c = 1\!</math>, oder auch für <math>x \ge x_0 = 4 \!</math> und <math>c = 1/16</math> (die Wahl von c und x0 in der Definition von O(.) ist beliebig, solange die Bedingungen erfüllt sind).

==== Komplexität bei kleinen Eingaben ====

Algorithmus 1: <math>\mathcal{O}(N^2) \!</math> 
Algorithmus 2: <math>\mathcal{O}(N\log{N}) \!</math>

Algorithmus 2 ist schneller (von geringerer Komplexität) für große Eingaben, aber bei kleinen Eingaben (insbesondere, wenn der Algorithmus in einer Schleife immer wieder mit kleinen Eingaben aufgerufen wird) könnte Algorithmus 1 schneller sein, falls der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor ''c'' bei Algorithmus 2 einen wesentlich größeren Wert hat als bei Algorithmus 1.

==== Eigenschaften der O-Notation (Rechenregeln) ====

# Transitiv:
#: <math>f(x) \in \mathcal{O}(g(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) \in \mathcal{O}(h(x)) \!</math>
# Additiv:
#: <math>f(x) \in \mathcal{O}(h(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) + g(x) \in \mathcal{O}(h(x)) \!</math>
# Für Monome gilt:
#: <math>x^k \in \mathcal{O}(x^k)</math> und
#: <math>x^k \in \mathcal{O}(x^{k+j}), \forall j \ge 0 \!</math>
# Multiplikation mit einer Konstanten:
#: <math>f(x) \in \mathcal{O}(g(x)) \to c\,f(x) \in \mathcal{O}(g(x))\!</math>
#: andere Schreibweise:
#: <math>f(x) = c\,g(x) \to f(x) \in \mathcal{O}(g(x))\!</math>
# Folgerung aus 3. und 4. für Polynome:
#: <math>a_0+a_1\,x + ... + a_n\,x^n \in \mathcal{O}(x^n)\!</math>
#: Beispiel: <math>a\,x^2+b\,x+c \in \mathcal{O}(x^2)\!</math>
# Logarithmus:
#: <math>a, b > 1\!</math>
#: <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>
#: Die Basis des Logarithmus spielt also keine Rolle.
#: Beweis hierfür:
#:: <math>\log_{a}{x} = \frac{\log_{b}{x}}{\log_{b}{a}}\!</math>
#:: Mit <math>c = 1 / \log_{b}{a}\,</math> gilt: <math>\log_{a}{x} = c\,\log_{b}{x}\!</math>.
#:: Wird hier die (zweite) Regel für Multiplikation mit einer Konstanten angewendet, fällt der konstante Faktor weg, also <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>.
#: Insbesondere gilt auch <math>\log_{a}{x} \in \mathcal{O}(\log_{2}{x})\!</math>, es kann also immer der 2er Logarithmus verwendet werden.

==== O-Kalkül ====

Das O-Kalkül definiert wichtige Vereinfachungsregeln for Ausdrücke in O-Notation (Beweise: siehe Übungsaufgabe):

# <math>f(x) \in \mathcal{O}(f(x))\!</math>
# <math>\mathcal{O}(\mathcal{O}(f(x))) \in \mathcal{O}(f(x))\!</math>
# <math>c\,\mathcal{O}(f(x)) \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# <math>\mathcal{O}(f(x))+c \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# Sequenzregel:
#: Wenn zwei nacheinander ausgeführte Programmteile die Komplexität <math>\mathcal{O}(f(x))</math> bzw. <math>\mathcal{O}(g(x))</math> haben, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(f(x))</math> falls <math>g(x) < \mathcal{O}(f(x))</math> bzw.
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(g(x))\!</math> falls <math>f(x) < \mathcal{O}(g(x))</math>.
#: Informell schreibt man auch: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(max(f(x), g(x)))\!</math>.
# Schachtelungsregel bzw. Aufrufregel:
#: Wenn in einer geschachtelten Schleife die äußere Schleife die Komplexität <math>\mathcal{O}(f(x))</math> hat, und die innere <math>\mathcal{O}(g(x))</math>, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) * \mathcal{O}(g(x)) \in \mathcal{O}(f(x) * g(x))\!</math>.
#: Gleiches gilt wenn eine Funktion <math>\mathcal{O}(f(x))</math>-mal aufgerufen wird, und die Komplexität der Funktion selbst <math>\mathcal{O}(g(x))</math> ist.

;Beispiel für 5.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Dies gilt auch für ihre Hintereinanderausführung:
for i in range(N):
a[i] = i
for i in range(N):
print a[i]
;Beispiele für 6.: Beide Schleifen haben die Komplexität <math>\mathcal{O}(N)</math>. Ihre Verschachtelung hat daher die Komplexität <math>\mathcal{O}(N^2)</math>.
for i in range(N):
for j in range(N):
a[i*N + j] = i+j
: Dies gilt ebenso, wenn statt der inneren Schleife eine Funktion mit Komplexität <math>\mathcal{O}(N)</math> ausgeführt wird:
for i in range(N):
a[i] = foo(i, N) # <math>\mathrm{foo}(i, N) \in \mathcal{O}(N)</math>

==== O-Kalkül auf das Beispiel des Selectionsort angewandt ====

Selectionsort: Wir hatten gezeigt dass <math>f(N) = \frac{N^2}{2} - \frac{N}{2}</math>. Nach der Regel für Polynome vereinfacht sich dies zu <math>f(N) \in \mathcal{O}\left(\frac{N^2}{2}\right) = \mathcal{O}(N^2)\!</math>.

Alternativ via Schachtelungsregel:
: Die äußere Schleife wird (''N''-1)-mal durchlaufen: <math>N-1 \in \mathcal{O}(N)</math>
: Die innere Schleife wird (''N-i''-1)-mal durchlaufen. Das sind im Mittel ''N''/2 Durchläufe: <math>N/2 \in \mathcal{O}(N)</math>
: Zusammen: <math>\mathcal{O}(N)*\mathcal{O}(N) \in \mathcal{O}(N^2)</math>

Nach beiden Vorgehensweisen kommen wir zur Schlussfolgerung, dass der Selectionsort die asymptotische Komplexität <math>\mathcal{O}(N^2)\!</math> besitzt.

==== Zusammenhang zwischen Komplexität und Laufzeit ====

Wenn eine Operation 1ms dauert, erreichen Algorithmen verschiedener Komplexität folgende Leistungen (wobei angenommen wird, dass der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor immer etwa gleich 1 ist):

{| class="wikitable" style="text-align:left" cellpadding="7"
|+
|-
! Komplexität !! Operationen in 1s !! Operationen in 1min !! Operationen in 1h
|-
! <math>\mathcal{O}(N)</math>
| 1000 || 60.000 || 3.600.000
|-
! <math>\mathcal{O}(N\log_2{N})</math>
| 140 || 4895 || 204094
|-
! <math>\mathcal{O}(N^2)</math>
| 32 || 245 || 1898
|-
! <math>\mathcal{O}(N^3)</math>
| 10 || 39 || 153
|-
! <math>\mathcal{O}(2^N)</math>
| 10 || 16 || 21
|}

==== Exponentielle Komplexität ====
Der letzte Fall <math>\mathcal{O}(2^N)</math> ist von exponentieller Komplexität. Das bedeutet, dass eine Verdopplung des Aufwands nur bewirkt, dass die maximale Problemgröße um eine Konstante wächst. Algorithmen mit exponentieller (oder noch höherer) Komplexität werden deshalb als '''ineffizient''' bezeichnet. Algorithmen mit höchstens polynomieller Komplexität gelten hingegen als effizient.

In der Praxis sind allerdings auch polynomielle Algorithmen mit hohem Exponenten meist zu langsam. Als Faustregel kann man eine praktische Grenze von <math>\mathcal{O}(N^3)</math> ansehen. Bei einer Komplexität von <math>\mathcal{O}(N^3)</math> bewirkt ein verdoppelter Aufwand immer noch eine Steigerung der maximalen Problemgröße um den Faktor <math>\sqrt[3]{2}</math> (also eine ''multiplikative'' Vergrößerung um ca. 25%, statt nur einer additiven Vergrößerung wie bei exponentieller Komplexität).

===<math>\Omega</math>- Notation===

Genauso wie <math>f \in \mathcal{O}(g)</math> eine Art <math>\le</math>-Operator für Funktionen ist, definiert <math>f \in \Omega(g) </math> eine Abschätzung von unten, analog zum <math>\ge</math>-Operator für Zahlen. Formal kann man <math>f(N) \in \Omega(g(N)) </math> genau dann schreiben, falls es eine Konstante <math> c > 0 </math> gibt, so dass

<math> f(N) \ge c \cdot g(N) </math> für <math> N \ge N_0 </math>

gilt.
Man verwendet diese Notation also um abzuschätzen, wie groß der Aufwand (die Komplexität) für einen bestimmten Algorithmus ''mindestens'' ist und nicht ''höchstens'', was man mit der <math>\mathcal{O}</math> - Notation ausdrücken würde.

Ein praktisches Beispiel für eine Anwendung der <math>\Omega</math>- Notation wäre die Fragestellung, ob es ''prinzipiell'' einen besseren Algorithmus für ein bestimmtes Problem gibt. Wie später im Abschnitt [[Suchen#Sortieren_als_Suchproblem|Sortieren als Suchproblem]] gezeigt wird, ist das Sortieren eines Arrays durch paarweise Vergleiche von Elementen immer mindestens von der Komplexität <math> \Omega(N\cdot \ln N) </math>, was konkret bedeutet, dass kein Sortieralgorithmus, der nach diesem Prinzip arbeitet, jemals eine geringere Komplexität als beispielsweise Merge-Sort haben wird. Natürlich kann man den entsprechenden Sortieralgorithmus, also Merge-Sort zum Beispiel, unter Umständen noch optimieren, aber die Komplexität wird erhalten bleiben. Mit diesem Wissen kann man sich viel (vergebliche) Arbeit sparen.

===<math>\Theta</math>- Notation===

<math>f(N) \in \Theta(g(N))</math> ist eine scharfe Abschätzung der asymptotischen Komplexität einer Funktion f.

Damit dies gilt, muss <math>f(N) \in \mathcal{O}(g(N))</math> und ''gleichzeitig'' <math>f(N) \in \Omega(g(N))</math> erfüllt sein.

Dies ist natürlich auch die beste Abschätzung der asymptotischen Komplexität einer Funktion f. Formal bedeutet <math>f(N) \in \Theta(g(N))</math> dass es zwei Konstanten <math> c_1 </math> und <math> c_2 </math>, beide größer als Null, gibt, so dass für alle <math> N \geq N_0 </math> gilt:

<math> c_1 \cdot g(N) \leq f(N) \leq c_2 \cdot g(N) </math>.

In der Praxis wird manchmal statt der <math>\Theta</math>-Notation auch dann die <math>\mathcal{O}</math>-Notation benutzt, wenn eine scharfe Schranke ausgedrückt werden soll. Dies ist zwar formal nicht korrekt, aber man kann die intendierte Bedeutung meist aus dem Kontext erschließen.

== Komplexitätsvergleich zweier Algorithmen ==

In diesem Abschnitt wollen wir der Frage nachgehen, wie ein formaler Beweis für die Behauptung <math> f(N) \in \mathcal{O}(g(N))</math> geschehen kann. Hierbei werden zwei Beweismethoden vorgestellt werden, und zwar der '''Beweis über die Definition der Komplexität''' sowie der '''Beweis durch Dividieren'''.

===Beweis über die Definition der asymptotischen Komplexität===

Die Definition der asymptotischen Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> war:

Es gibt eine Konstante <math> c > 0 </math>, so dass <math> f(N) \le c \cdot g(N) </math> für <math> N \ge N_0 </math> erfüllt ist.

Um also die die asymptotische Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> zu beweisen, muss man die oben erwähnten Konstanten c und <math> N_0 </math> finden, so dass

<math> f(N) \leq c \cdot g(N) </math> für alle <math> N \ge N_0 </math> erfüllt ist.

Dies geschieht zweckmäßigerweise mit dem Beweisprinzip der ''vollständigen Induktion''. Hierbei ist zu zeigen, dass
# <math> f(N_0) \leq g(N_0) </math> für die eine zu bestimmende Konstante <math> N_0 </math> gilt (''Induktionsanfang'') und
# falls <math> f(N) \leq g(N) </math>, dann auch <math> f(N+1) \leq g(N+1) </math> (''Induktionsschritt'') gilt.

===Beweis durch Dividieren===

Hierbei wählt man eine Konstante c und zeigt, dass <math> \lim_{N \rightarrow \infty} \frac{f(N)}{c \cdot g(N)} \leq 1 </math> gilt (für die O-Notation, bei Ω-Notation gilt entsprechend <math>\geq 1 </math>). Man kann dies auch als alternative Definition der Komplexität verwenden.

Als Beispiel betrachten wir die beiden Funktionen <math> f(N) = N \,\lg N </math> und <math> g(N) = N^2 </math> und wollen zeigen, dass <math>f(N) \in \mathcal{O}(g(N))</math> gilt.

Als Konstante c wählen wir <math> c = 1 </math>

<math> \lim_{N \rightarrow \infty} \frac{f(N)}{g(N)} = \lim_{N \rightarrow \infty} \frac{\lg N}{N} = \frac{\infty}{\infty} </math>

Unbestimmte Ausdrücke der Form
<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} </math>,
in denen sowohl <math> f(x) </math> als auch <math> g(x) </math> mit <math> x \rightarrow x_0 </math> gegen Null oder gegen Unendlich streben, kann man manchmal mit den Regeln von [http://de.wikipedia.org/wiki/L%27Hospital%27sche_Regel ''l'Hospital''] berechnen. Danach darf man die Funktionen f und g zur Berechnung des unbestimmten Ausdrucks durch ihre k-ten Ableitungen ersetzen:

<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} = \lim_{x \rightarrow x_0} \frac{f^{(k)}(x)}{g^{(k)}(x)} </math>

In unserem Fall verwenden wir die erste Ableitung und erhalten:
<math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)} = \lim_{N \rightarrow \infty} \frac{1/N}{1} \rightarrow 0 </math>

Damit wurde <math>f(N) \in \mathcal{O}(g(N))</math>, also <math>N \lg N \in \mathcal{O}(N^2)</math> gezeigt.

Man beachte hierbei, dass <math>N \lg N \in \mathcal{O}(N^2)</math> keine enge Grenze für die Komplexität von <math>N \,\lg N</math> darstellt, da der Grenzwert <math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)}\, </math> gegen 0 und nicht gegen eine von Null verschiedene Konstante strebt. In diesem Fall haben wir die Komplexität von <math>N \cdot \lg N </math> also nur nach oben abschätzen können.

===Beispiel für den Komplexitätsvergleich: Gleitender Mittelwert (Running Average)===

Wir berechnen für ein gegebenes Array <tt>a</tt> einen gleitenden Mittelwert über <tt>k</tt> Elemente: 
::<math>r_i = \frac{1}{k} \sum_{j=i-k+1}^i a_j</math> 
Das heisst, für jedes <tt>i</tt> mitteln wir die letzten <tt>k</tt> Elemente von <tt>a</tt> und schreiben das Ergebnis in <tt>r[i]</tt>. Diese Operation ist z.B. bei Börsenkursen wichtig: Neben dem aktuellen Kurs für jeden Tag wird dort meist auch der gleitende Mittelwert der letzten 30 Tage sowie der letzten 200 Tage angegeben. In diesen Mittelwerten erkennt man besser die langfristige Tendenz, weil die täglichen Schwankungen herausgemittelt werden. Wir nehmen außerdem an, dass
* Array-Zugriff hat eine Komplexität von O(1)
* <math>k \ll N</math>, d.h. <math>N-k\approx N</math>.

Die beiden folgenden Algorithmen berechnen die Mittelwerte auf unterschiedliche Art. Der linke folgt der obigen Definition durch eine Summe, während der rechte inkrementell arbeitet: Man kann den Bereich der <tt>k</tt> letzten Werte als Fenster betrachten, das über das Array <tt>a</tt> geschoben wird. Schiebt man das Fenster ein Element weiter, fällt links ein Element heraus, und rechts kommt eins hinzu. Man muss also nicht jedes Mal die Summe neu berechnen, sondern kann den vorigen Wert aktualisieren. Wir werden sehen, dass dies Folgen für die Komplexität des Algorithmus hat.

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1: O(N * k)
! Komplexität
! Version 2: O(N)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|
<tt>for i in range(k):</tt>
|
'''<center>O(k)</center>'''
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|
:: <tt>r[k-1] += a[i]</tt>
|
'''<center>O(1)</center>'''
|-
|
6.
|
:::: <tt>r[j] += a[i]</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(k, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|
:: <tt>r[j] = (a[j] - a[j-k] + r[j-1])</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(len(a)):</tt>
|
'''<center>O(N)</center>'''
|-
|
9.
|

|

|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
10.
|

|

|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Wir zeigen unten dass Version 2 eine geringere Komplexität besitzt, obwohl sie mehr Zeilen benötigt.

Wir haben in der Tabelle die Komplexität jeder Zeile für sich angegeben. Einfache Anweisungen (Berechnungen, Lese- und Schreibzugriffe auf das Array, Zuweiseungen) haben konstante Komplexität, die Komplexität des Schleifenkopfes allein (also der <tt>for</tt>-Anweisung ohne den eingerückten Schleifenkörper) entspricht der Anzahl der Durchläufe. Wir müssen jetzt noch die Verschachtelung der Schleifen und die Nacheinanderausführung von Anweisungen berücksichtigen.

====Berechnung der Komplexität von Version 1====

(Wiederholung der Rechenregeln: siehe Abschnitt [[Effizienz#O-Notation|O-Notation]])

Wir betrachten zunächst die innere Schleife (Zeilen 5 und 6 von Version 1):

Der Schleifenkopf (Zeile 5) hat die Komplexität <math>\mathcal{O}(k)</math>, weil die Schleife k-mal durchlaufen wird. Der Schleifenkörper (Zeile 6) hat die Komplexität <math>\mathcal{O}(1)</math>. Nach der Verschachtelungsregel müssen wir die beiden Komplexitäten multiplizieren, und es ergibt sich:

::<math>\mathcal{O}(k)\cdot\mathcal{O}(1) = \mathcal{O}(k\cdot 1)=\mathcal{O}(k)</math>

Wir betrachten nun die äußere Schleife. Der Schleifenkopf (Zeile 4) wird (N-k)-mal durchlaufen und hat somit eine Komplexität von <math>\mathcal{O}(N)</math>. Der Schleifenkörper (Zeilen 5 bis 7) besteht aus der inneren Schleife (Zeilen 5 und 6) mit der gerade berechneten Komplexität <math>\mathcal{O}(k)</math> sowie einer einfachen Anweisung (Zeile 7) mit Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel wird die Komplexität des Schleifenkörpers durch Addition berechnet:

::<math>\mathcal{O}(k)+\mathcal{O}(1) = \mathcal{O}(\max(k,1)) = \mathcal{O}(k)</math>

Die Komplexität der gesamten äußeren Schleife erhalten wir nach der Verschachtelungsregel wieder durch multiplizieren:

::<math>\mathcal{O}(N)\cdot\mathcal{O}(k) = \mathcal{O}(N\cdot k)</math>

Die übrigen Schritte des Algorithmus werden einfach nacheinander ausgeführt, so dass sie ebenfalls nach der Sequenzregel behandelt werden. Wir erhalten

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(N\cdot k)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,N\cdot k,1)) = \mathcal{O}(N\cdot k)</math>

Der gesamte Algorithmus hat also die Komplexität <math>\mathcal{O}(N\cdot k)</math>.

====Berechnung der Komplexität von Version 2====

Hier gibt es nur einfache Schleifen ohne Verschachtelung. Da der Schleifenkörper jeder Schleife nur einfache Anweisungen der Komplexität <math>\mathcal{O}(1)</math> enthält, ergibt sich die Komplexität der Schleifen nach der Verschachtelungsregel als

::<math>\mathcal{O}(X)\cdot\mathcal{O}(1) = \mathcal{O}(X\cdot 1)=\mathcal{O}(X)</math>

wobei <math>\mathcal{O}(X)</math> die Komplexität des jeweiligen Schleifenkopfes ist. Wir erhalten also für Zeilen 4 und 5: <math>\mathcal{O}(k)</math>, Zeilen 6 und 7: <math>\mathcal{O}(N)</math>, Zeilen 8 und 9: <math>\mathcal{O}(N)</math>. Die Hintereinanderausführung wird nach der Sequenzregel behandelt:

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(k)+\mathcal{O}(N)+\mathcal{O}(N)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,k,N,N,1)) = \mathcal{O}(N)</math>

Dieser Algorithmus hat also nur die Komplexität <math>\mathcal{O}(N)</math>.

====Fazit====

Obwohl Version 2 mehr Schritte benötigt hat sie eine geringere Komplexität, da die for-Schleifen nicht wie bei Version 1 verschachtelt/untergeordnet sind. Bei verschachtelten for-Schleifen muss die Multiplikationsregel angewendet werden → höhere Komplexität.

Die gerade berechnete Komplexität gilt aber nur unter der Annahme, dass Array-Zugriffe konstante Komplexität <math>\mathcal{O}(1)</math> besitzen. Wenn dies nicht der Fall ist, kann sich die Komplexität des Algorithmus drastisch verschlechtern.

{| border="1" cellspacing="0" cellpadding="5"
|Allgemein gilt: 
Algorithmen-Analysen beruhen auf der Annahme, dass Zugriffe auf die Daten optimal schnell sind, dass heißt, dass die für den jeweiligen Algorithmus am besten geeignete Datenstruktur verwendetet wird. → Ansonsten: Komplexitätsverschlechterung!
|}
 

====Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur====

Wir verwende im Mittelwert-Algorithmus eine verkettete Liste anstelle des Eingabe-Arrays a. Wir benötigen dazu eine Funktion, die das j-te Element der Liste zurückgibt. Wie üblich ist die Liste mit Hilfe einer Knotenklasse implementiert:
class Node:
def __init__(self, data):
self.data = data
self.next = None

Die Listenklasse selbst hat ein Feld <tt>head</tt>, das eine Referenz auf den ersten Knoten speichert, und jeder Knoten speichert im Feld <tt>next</tt> eine Referenz auf seinen Nachfolger. Um zum j-ten Element zu gelangen, muss man die Liste sequenziell durchlaufen
def get_jth(list, j):
r = list.head
while j > 0:
r = r.head
j -= 1
return r.data
Die Komplexität dieser Funktion ist offensichtlich <math>\mathcal{O}(j)</math> (Komplexitätsberechnung wie oben). Wir setzen jetzt bei Version 1 des Mittelwert-Algorithmus diese Funktion in Zeile 6 anstelle des Indexzugriffs <tt>a[i]</tt> ein (nur in dieser Zeile wird auf die Elemente des Arrays zugegriffen). Wir erhalten folgende Implementation (die Änderungen sind rot markiert):

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1 mit Liste: O(N * k)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|-
|
6.
|
:::: <tt>r[j] += get_jth(a, i)</tt>
|
'''<center>O(i)</center>'''
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Der Aufruf der Funktion <tt>get_jth</tt> ist jetzt gleichbedeutend mit einer dreifach verschachtelten Schleife (weil <tt>get_jth</tt> ja eine zusatzliche Schleife enthält). Die Anzahl der Operationen in Zeile 4 bis 6 ist jetzt

::<math>f(N,k)=\sum_{j=k-1}^{N-1}\,\sum_{i=j-k+1}^j\,\mathcal{O}(i)</math>

wobei das <math>\mathcal{O}(i)</math> die neue Schleife durch Verwendung der Liste repräsentiert. Mit Mathematica-Hilfe [http://www.wolfram.com/] lässt sich diese Summe exakt ausrechnen

::<math>f(N,k)=\frac{1}{2}(k N^2-k^2 N+k^2-k)\in \mathcal{O}(k N^2)</math>

Die Komplexitätsberechnung erfolgte dabei nach der Regel für Polynome unter Beachtung von <math>k \ll N</math>.

====Fazit:====

Die Komplexität von Version 1 mit einer verketteten Liste wäre O(N2 * k)
'''→ Die richtige Datenstruktur ist wichtig, da es sonst zu einer Komplexitätsverschlechterung kommen kann!'''

Auf Version 2 unseres Running Average-Beispiels hätte eine verkettete Liste allerdings keine Auswirkungen, da die inkrementelle Berechnung der Summen in Zeile 7 weiterhin möglich ist (bei geschickter Implementation!) und somit Version 2 immer noch eine Komplexität von O(N) hätte.

==Amortisierte Komplexität==

Bis jetzt wurde die Komplexität nur im schlechtesten Fall (Worst Case) betrachtet. Bei einigen Algorithmen schwankt die Komplexität im schlechtesten Fall jedoch, wenn man die ungünstige Operation mehrmals hintereinander ausführt. Die amortisierte Komplexität beschäftigt sich mit der durchschnittlichen Komplexität über viele Aufrufe der ungünstigsten Operation.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse Wikipedia: Amortisierte Laufzeitanalyse]]

===Beispiel: Inkrementieren von Binärzahlen===

Frage: Angenommen, das Umdrehen eines Bits einer Binärzahl verursacht Kosten von 1 Einheit. Wir erzeugen die Folge der natürlichen Zahlen durch sukzessives Inkrementieren, von Null beginnend. Bei jeder Inkrementierung werden einige Bits verändert, aber diese Zahl (und damit die Kosten der Inkrementierungen) ''schwanken'' sehr stark. Wir fragen jetzt, was eine Inkrementierung im Durchschnitt kostet?

Um diese Durchschnittskosten zu berechnen, bezahlen wir bei jeder Inkrementierung 2 Einheiten. Wenn davon nach Abzug der Kosten der jeweiligen Operation noch etwas übrig bleibt, wird der Rest dem Guthaben zugeschrieben. Umgekehrt wird ein eventueller Fehlbetrag (wenn eine Inkrementierung mehr als 2 Bits umdreht) aus dem Guthaben gedeckt. Dadurch werden die ansonsten großen Schwankungen der Kosten ausgeglichen:
:: Kosten < Einzahlung → es wird gespart
:: Kosten = Einzahlung → Guthaben bleibt unverändert
:: Kosten > Einzahlung → Guthaben wird für die Kosten verbraucht

{| border="1" cellspacing="0" cellpadding="5"
!Schritte
!Zahlen
!Kosten 
(Anzahl der geänderten Bits)
! Einzahlung
!Guthaben = 
altes Guthaben + Einzahlung - Kosten
|-
|1.
|00001
|1
|'''2'''
|'''1'''
|-
|2.
|00010
|2
|'''2'''
|'''1'''
|-
|3.
|00011
|1
|'''2'''
|'''2'''
|-
|4.
|00100
|3
|'''2'''
|'''1'''
|-
|5.
|00101
|1
|'''2'''
|'''2'''
|-
|6.
|00110
|2
|'''2'''
|'''2'''
|-
|7.
|00111
|1
|'''2'''
|'''3'''
|-
|8.
|01000
|4
|'''2'''
|'''1'''
|-
|}

Die Kosten ergeben sich aus der Anzahl der Ziffern die von 1 nach 0, bzw. von 0 nach 1 verändert werden

Rechnung:

1. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

2. Schritt: Kosten: 2 = Einzahlung: 2 
:: → es wird nicht gespart 
:: → Guthaben bleibt so wie es ist 

3. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

4. Schritt: Kosten: 3 > Einzahlung: 2 
:: → es wird eine 1 vom Guthaben genommen um die Kosten zu zahlen 

usw.

Man erkennt, dass vor teuren Operation (Wechsel von 3 auf 4 bzw. von 7 auf 8) genügend Guthaben angespart wurde, um die Kosten zu decken. Das Guthaben geht bei diesen Operationen immer wieder auf 1 zurück, aber es wird nie vollständig verbraucht (Dies kann natürlich auch mathematisch exakt bewiesen werden, wie wir es unten am Beispiel des dynamische Arrays zeigen). Wir schließen daraus, dass die durchschnittlichen oder '''amortisierten Kosten''' einer Inkrementierungsoperation gleich 2 sind.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Account-Methode Wikipedia Account-Methode]]

====Fazit====
Die amortisierte Komplexität beschäftigt sich mit dem Durchschnitt aller Operation im ungünstigsten Fall. Operationen mit hohen Kosten, die aber nur selten ausgeführt werden, fallen bei der amortisierten Komplexität nicht so ins Gewicht. Bei Algorithmen, die gelegentlich eine "teure" Operation benutzen, ansonsten jedoch "billigen" Operationen aufrufen, kann die amortisierte Komplexität niedriger sein als die Komplexität im schlechtesten (Einzel-)Fall.

In unserem Beispiel fallen die teuren Einzelschritte (z.B. 4. und 8. Schritt) bei den amortisierten Kosten nicht so ins Gewicht, da wir die Kosten aus unserem Guthaben mitbezahlen können. Das Guthaben ist immer groß genug, weil jeder zweite Aufruf eine billige Operation ist, die nur ein Bit umdreht und somit das Ansparen ermöglichen. Diese Betrachtung zeigt, dass die amortisierte (d.h. durchschnittliche) Komplexität des Algoithmus niedriger (nämlich konstant) ist als die Komplexität im schlechtesten Fall.

===statisches Array===

Ein statisches Array hat eine feste Größe N und das Erweitern des Arrays um ein neues Element besitzt eine Komplexität von O(N),
denn es muss ein neues Array mit der Größe N+1 erzeugt werden. 

Anhängen eines weiteren Elements an ein statisches Array:

{| border="1" cellspacing="0" cellpadding="5" align="right"
!Schritte
|'''Array'''
(wie es aussehen könnte)
!Komplexität
|-
|<center>altes Array</center>
|<center>[0,1,2,3]</center>
|<center>-</center>
|-
|1. Array N+1
|<center>[None,None,None,None,None]</center>
|<center>O(N+1) = '''O(N)'''</center>
|-
|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 Daten aus dem alten Array werden in das neue Array mit der Länge N+1 kopiert 
(Die Operation besitzt nur eine Komplexität von O(N), wenn das Kopieren eines Elements eine Komplexität von O(1) besitzt) 
3. 'x' wird an die letzte Stelle des neuen Arrays geschrieben

Additionsregel: 
O(N) + O(N) + O(1) ∈ O(N), falls O(1) ∈ O(N) [O(max(O(N),O(1))] (Bedingung: N > 1)

===dynamisches Array===

Beim dynamischen Array werden mehr Speicherelemente reserviert als zur Zeit benötigt. Wir unterscheiden deshalb

::<tt>capacity</tt> = Anzahl 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 "capacity" 

Ist dieses Array voll, wird ein neues Datenarray der doppelten Größe allokiert, und die Daten werden vom alten ins neue Array kopiert. Die Vorgehensweise
beim Zufügen eines neuen Elements im Fall (size == capacity) ist also
* capacity wird verdoppelt 
: neue capacity = 2 * alte capacity
: (allgemein genügt es auch, wenn capacity wird um einen bestimmten Prozentsatz vergrößert wird,
:: neue capacity = alte capacity * c (mit c > 1, z.B. c = 1.2)
* 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

'''Folge:''' Die Kosten für das Vergrößern 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), wie wir jetzt zeigen:

===Analyse des dynamischen Arrays===

Durchschnitt der Gesamtkosten für N-maliges append = <math>\frac{1}{N} \sum_{i = 1}^N Kosten(i)</math>. Zur Analyse der amortisierten Komplexität wird ein Potential 
::Φi = 2*sizei - capacityi 
eingeführt, wobei das Array nach dem i-ten Einfüge-Schritt die Größe sizei und die Kapizität capacityi hat. Wir nehmen vereinfachend an, dass es keine Löschoperationen gibt. Dann gilt nach dem i-ten Schritt jeweils
::Φi = 2*i - capacityi 

Fall 1: Array ist nicht voll 
Es wird kein Umkopieren benötigt, da das Array noch nicht voll ist 
→ sizei-1 < capacityi-1 
→ capacityi == capacityi-1

Kosten: 1 (für Einfügen des neuen Elements) 
Potenzial vor append: Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append: Φi = 2i - capacityi-1 

amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = 1 + (2i - capacityi-1) - [2(i - 1) - capacityi-1]
::::: = 1 + 2i - capacityi-1 - 2i + 2 + capacityi-1
::::: = 1 + <del>2i</del> - <del>capacityi-1</del> - <del>2i</del> + 2 + <del>capacityi-1</del>
::::: = 1 + 2
::::: = 3 = O(1) → konstant

Fall 2: Array ist voll 
Vor dem i-ten append muss umkopiert werden 
→ sizei-1 == capacityi-1 == i-1 
→ Allokieren eines neuen statischen Arrays mit verdoppelter Kapazität notwendig, also capacityi == 2*capacityi-1

Kosten: (i-1) + 1 (für Umkopieren und Einfügen des neuen Elements) 
Potenzial vor append = Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append = Φi = 2i - 2 capacityi-1 
amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = ((i - 1) + 1) + 2i - 2 capacityi-1 - [2(i-1) - capacityi-1]
::::: = i + <del>2i</del> - 2 capacityi-1 - <del>2i</del> + 2 - capacityi-1
::::: = i + 2 - capacityi-1
::::: = i + 2 - (i - 1) (da capacityi-1 = i-1)
::::: = 3 = O(1) → konstant

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine amortisierte Komplexität von 3 Einheiten hat, also <tt>append</tt> ∈ O(1)'''. Diese Operation kann deshalb gefahrlos in der inneren Schleife eines Algorithmus benutzt werden.

==== Beispiel für 9 Einfügeoperationen ====

{| border="1" cellspacing="0" cellpadding="5"
!Array 
(wie es aussehen könnte)
!size
!capacity
!Kosten für append (einschließlich Umkopieren)
!Summe Kosten
!Durchschnittskosten
!Φi = 2 * size - capacity 
(i = size)
!Potenzialdifferenz 
Δ Φi = Φi - Φi-1
!amortisierte Kosteni 
= Kosteni + Δ Φi
|-
| <center>[None]</center>
| <center>0</center>
| <center>1</center>
| <center>-</center>
| <center>-</center>
| <center>-</center>
| <center>-1</center>
| <center>-</center>
| <center>-</center>
|-
| <center>[a]</center><center>Array ist voll!</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b]</center><center>Array ist voll!</center>
| <center>2</center>
| <center>2</center>
| <center>1 + 1</center>
| <center>3</center>
| <center>3/2</center>
| <center>2</center>
| <center>1</center>
| <center>3</center>
|-
| <center>[a,b,c,None]</center>
| <center>3</center>
| <center>4</center>
| <center>2 + 1</center>
| <center>6</center>
| <center>6/3</center>
| <center>2</center>
| <center>0</center>
| <center>3</center>
|-
| <center>[a,b,c,d]</center><center>Array ist voll!</center>
| <center>4</center>
| <center>4</center>
| <center>1</center>
| <center>7</center>
| <center>7/4</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,None,None,None]</center>
| <center>5</center>
| <center>8</center>
| <center>4 + 1</center>
| <center>12</center>
| <center>12/5</center>
| <center>2</center>
| <center>-2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,None,None]</center>
| <center>6</center>
| <center>8</center>
| <center>1</center>
| <center>13</center>
| <center>13/6</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,None]</center>
| <center>7</center>
| <center>8</center>
| <center>1</center>
| <center>14</center>
| <center>14/7</center>
| <center>6</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h]</center><center>Array ist voll!</center>
| <center>8</center>
| <center>8</center>
| <center>1</center>
| <center>15</center>
| <center>15/8</center>
| <center>8</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h,j,None,None,None, 
None,None,None,None]</center>
| <center>9</center>
| <center>16</center>
| <center>8 + 1</center>
| <center>24</center>
| <center>24/9</center>
| <center>2</center>
| <center>-6</center>
| <center>3</center>
|-
|}

Die durchschnittlichen Kosten betragen stets etwa 2 Einheiten, schwanken allerdings so, dass nicht unmittelbar ersichtlich ist, ob dies für sämtliche Einfügeoperationen gilt. Die amortisierte Komplexität, die mit Hilfe des Potentials berechnet wird, ist hingegen konstant 3, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

[[Suchen|Nächstes Thema]]

Korrektheit

2010-08-10T12:12:42Z

Jschleic: /* Prinzipien für die Generierung von Testdaten */ typo

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
# 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]).
# '''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: Prüfung der syntaktischen Korrektheit, formaler Korrektheitsbeweis und Softwaretest.

== Syntaktische Korrektheit ==

Die syntaktische Korrektheit behandeln wir hier nur kurz und der Vollständigkeit halber. Sie wird 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
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ückgeweisen 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

== Formaler Korrektheitsbeweis ==
=== (Halb-)Automatisches Beweisen ===
Man versucht, die Hypothese H: ''Algorithmus ist korrekt'' entweder mathematisch zu beweisen oder zu widerlegen. Dieses Beweisverfahren heißt dann halbautomatisch, wenn der Mensch in den Entscheidungsprozess miteinbezogen 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. [http://en.wikipedia.org/wiki/Z_notation Z]). 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 (allerding 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/lib/module-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 Tests selbst nur nähreungsweise 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.

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

====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 testes also die Nachbedingungen. Eine abgeschwächte Versionen dieser Methode wird für randomisierte Algorithmen verwendet: Ist die Wahrscheinlichkeitsverteilung der Testeingaben bekannt, kann man die Wahrscheinlichkeitsverteilung der Ergebnisse, oder zumindest wichtige Eigenschaften wie z.B. den Mittelwert, mathematisch vorhersagen. Der Test ermittelt dann, ob die Ausgaben über viele Durchläufe des Algorithmus diese statistischen Eigenschaften aufweisen.

====Arten von Tests====

Man unterscheidet 3 grundlegende Arten von Tests:

;Black-box Tests [http://en.wikipedia.org/wiki/Black_box_testing]: Hier ist dem Tester nur die Spezifikation, aber nicht die Implementation des Algorithmus bekannt. Alle Tests sowie die Eingaben und Referenz-Ergebnisse müssen aus der Spezifikation abgeleitet werden. Die automatisierte Generierung guter Tests aus der Spezifikation ist ein aktives Forschungsgebiet.
;Gray-box Tests (auch Glass-box Tests) [http://www.cse.fau.edu/~maria/COURSES/CEN4010-SE/C13/glass.htm]: Hier kennt der Tester auch die Implementation und kann dadurch Tests entwerfen, die für diese spezielle Implementation besonders aussagekräftig sind. Es besteht allerdings die Gefahr, dass der Tester nicht mehr unvoreingenommen an das Testproblem herangeht, und Zustände, die seiner Meinung nach gar nicht vorkommen können, auch nicht testet (erst später stellt sich heraus, dass diese Zustände doch vorkommen).
;White-box Tests [http://en.wikipedia.org/wiki/White_box_testing]: Hier kann der Tester die Implementation sogar in geeigneter Weise verändern, z.B.
:* explizite Tests für Vor- und Nachbedingungen ("Assertions") einbauen. Dies bietet sich insbesondere in der alpha- und beta-Testphase eines Programms an, um Fehler schnell zu lokalisieren. Auch die unter Windows bekannte Dialogbox "Diesen Fehler bitte auch an Microsoft melden" wird durch solche eingebauten Assertions ausgelöst, wenn das Programm in einen illegalen Zustand geraten ist und abgebrochen werden muss.
:* zusätzlichen Code einbauen, der feststellt, ob alle Teile des Programms auch tatsächlich getestet wurden ("[http://blogs.msdn.com/phuene/archive/2007/05/03/code-coverage-instrumentation.aspx code coverage instrumentation]"). Dieser Code gibt nach dem Testen z.B. aus, welche Programmzeilen von keinem existierenden Test aufgerufen worden sind. Wenn der ausgeführte Code sehr stark von den Daten abhängt (z.B. bei interaktiven Programmen), kann es sehr schwierig sein, die ''coverage'' auf andere Weise festzustellen.
:* absichtlich Bugs einbauen (die automatisch wieder abgeschaltet werden, wenn das Testen vorbei ist). Durch diese "[http://en.wikipedia.org/wiki/Fault_injection fault injection]" kann man herausfinden, ob die Tests mächtig genug sind, vorhandene Bugs zu finden.

====Prinzipien für die Generierung von Testdaten====

;Prinzip der Regressionstests ("[http://en.wikipedia.org/wiki/Regression_testing Regression testing]"): Häufig werden Tests während der Programmentwicklung verwendet, um einen Algorithmus zu debuggen. Sobald der Algorithmus aber funktioniert werden die Tests gelöscht, denn sie werden ja jetzt nicht mehr gebraucht. Dies ist ein schwerwiegender ''Fehler'': Jedes erfolgreiche Programm muss früher oder später weiterentwickelt werden (zumindest die Anpassung an eine neue Betriebssystemversion ist ab und zu notwendig). Jede Änderung birgt aber die Gefahr, dass sich neue Bugs in bisher funktionierenden Code einschleichen. Man sollte deshalb alle Tests aufheben und in einer ''test suite'' sammeln. Durch diese "regression tests" kann man nach jeder Änderung feststellen, ob die alte Funktionalität noch intakt ist, und gegebenenfalls die letzte Änderung einfach rückgängig machen. Tut man dies nicht, kann die Gefahr von unbeabsichtigten destruktiven Änderungen so groß werden, dass das Programm gar nicht mehr weiterentwickelt werden kann. Dies wird drastisch durch den bekannten Spruch "never change a running program" ausgedrückt.

;Prinzip der äquivalenten Eingaben (Domain Partitioning oder Equivalence Partitioning) [http://en.wikipedia.org/wiki/Equivalence_partitioning]: Für ähnliche Eingaben verhält sich ein Algorithmus normalerweise ähnlich, und es hat keinen Sinn, alle diese Eingaben zu testen. Statt dessen teilt (partitioniert) man die Eingabedomäne in Äquivalenzklassen, die vom Algorithmus im wesentlichen gleich behandelt werden. Im obigen Beispiel der Wurzelberechnung ergeben sich zwei Klassen aus der Spezifikation: die negativen Zahlen (für die die Wurzel undefiniert ist und deshalb ein Fehler signalisiert werden muss) und die nicht-negativen Zahlen. Wenn man auch den Quellcode kennt (gray-box testing), kann man die Eingaben oft feiner unterteilen. Z.B. werden häufig unterschiedliche Algorithmen für kleine und für große Eingaben benutzt. Viele Quicksort-Implementationen verwenden beispielsweise für Arrays mit höchstens vier Elementen ein explizites Sortierverfahren, für Arrays der Länge 5 bis 25 selection sort, und erst für größere Arrays das eigentliche Quicksort. Aus der Einteilung der Eingabedomäne ergeben sich zwei wichtige Regeln für die Wahl der Testdaten:
:* Aus jeder Äquivelenzklasse wählt man mindestens einen typischen Vertreter, um das normale Verhalten des Algorithmus in jedem Fall zu testen.
:* Aus jeder Äquivelenzklasse wählt man Randwerte, weil gerade bei diesen Werten am häufigsten Fehler gemacht werden. Im obigen Wurzelbeispiel ist der Randwert die Null, die in der Tat in einer Version des Algorithmus zu einem <TT>ZeroDivisionError</tt> geführt hat. Andere typische Randfehler sind, dass Randelemente dem falschen Algorithmenzweig zugeordnet werden (z.B. wenn bei unserem Wurzelbeispiel die Abfrage am Anfang <tt>if x <= 0:</tt> statt <tt>if x < 0:</tt> gewesen wäre), dass Schleifen um einen Index zu spät beginnen oder zu früh abbrechen ("[http://en.wikipedia.org/wiki/Off-by-one_error Off-by-one errors]"), oder dass ein seltener Randfall gar nicht implementiert ist und einfach zum Absturz führt.

;Prinzip, den Fehler zu reproduzieren (Failure Reproduction): Wenn ein Bug gemeldet wird, welches die Tests bisher übersehen haben, fügt man einen Test hinzu, der dieses Bug findet. Im Zusammenhang mit regression tests ist damit sichergestellt, dass dasselbe Bug nicht noch einmal auftreten kann.

;Prinzip der Code Coverage [http://en.wikipedia.org/wiki/Code_coverage]: Hier stellt man sicher, dass tatsächlich der gesamte Code (oder ein vorher festgelegter hoher Prozentsatz) getestet wurde. Gerade bei komplizierten interaktiven Programmen ist diese "code coverage" mitunter nicht leicht zu erreichen, weil manche Programmteile nur bei sehr seltenen oder obskuren Eingaben ausgeführt werden. Eine minimale code coverage erreicht man allerdings bereits, wenn man in einem black-box-Test die Testdaten nach dem Prinzip der äquivalenten Eingaben auswählt, weil dann aus jeder Äquivalenzklasse mindestens ein Vertreter getestet wird. Im Allgemeinen muss man aber den Quellcode zumindest kennen (gray-box-Test), um geeignete Testdaten für code coverage zu identifizieren. Code coverage kann in verschiednen Graden angestrebt werden
:* Function coverage: Jede Funktion eines Programms sollte mindestens einmal aufgerufen werden.
:* Statement coverage: Jedes Statement (d.h. im wesentlichen jede Programmzeile) sollte mindestens einmal ausgeführt werden. Im obigen Wurzelbeispiel erfordert dies, dass z.B. mindestens einmal eine negative Zahl getestet wird, um die Exception zu prüfen.
:* Condition coverage: Jede Bedingung (explizit in <tt>if</tt>-Bedingungen, implizit in den Abbruchbedingungen von <tt>for</tt>- und <tt>while</tt>-Schleifen) sollte mindestens einmal mit dem Ergebnis <tt>True</tt> und einmal mit dem Ergebnis <tt>False</tt> durchlaufen werden. Im Wurzelbeispiel haben wir die Eingabe <tt>x = 4</tt> gewählt, damit die <tt>while</tt>-Schleife auch einmal beim ersten Aufruf sofort <tt>False</tt> liefert.
:* Path coverage: Jeder Programmpfad (d.h. jede Kombination von Wahrheitswerten bei allen Bedingungen) sollte einmal ausgeführt werden. Dies ist im Allgemeinen unerreichbar, weil es unendlich viele, oder zumindest zu viele verschiedene Pfade gibt.
:Die Qualität der Tests steigt, wenn eine hohe Coverage (am besten 100%) erreicht wird, und/oder man eine mächtigere Art von Coverage fordert.

;Prinzip der erschöpfenden Tests: Wenn ein Algorithmus nur wenige mögliche Eingaben hat, kann man sämtliche Eingaben testen. Bei sehr wichtigen Algorithmen kann das auch dann noch sinnvoll sein, wenn es relativ viele mögliche Eingaben gibt. In den meisten Fällen ist es jedoch zu aufwändig.

;Prinzip der vollständigen Paarung (Pair-wise coverage) [http://citeseer.ist.psu.edu/78354.html]: Wenn ein Algorithmus N Eingabeparameter hat, und jeder Parameter hat Ki mögliche Werte, müssen bei der erschöpfenden Suche K1*...*KN Kombinationen getestet werden. Beschränkt man sich in jedem Parameter auf typische Werte und Randwerte jeder Äquivalenzklasse, kann man Ki zwar drastisch reduzieren, aber das Produkt K1*...*KN wird immer noch sehr groß (bei 4 Parametern und nur 3 möglichen Werten pro Parameter hat man bereits 34=81 mögliche Kombinationen). Sei vij der j-te Wert des Parameters i. Anstatt zu versuchen, alle Kombinationen zu testen, kann man fordern, dass zumindest alle möglichen Paare vij und vmj (i≠m) in mindestens einem Test vorkommen. Gibt es nur zwei Parameter, gewinnt man durch diese Einschränkung natürlich nichts, denn man muss mindestens K1*K2 Tests durchführen. Hat man jedoch 3 Parameter, kann man mit weniger Tests auskommen als zuvor, da jeder Test bis zu drei verschiedene Paarungen abdecken kann (eine für den ersten und zweiten Parameter, eine für den ersten und dritten, eine für den zweiten und dritten). Bei vier Parametern werden sogar sechs Paarungen pro Test abgearbeitet usw. Die Theorie des "experimental design" beschreibt nun, wie man systematisch alle möglichen Paarungen mit möglichst wenigen Tests erzeugt. Es stellt sich heraus, dass man alle Paarungen von 3, 4 oder mehr Parametern oft mit genauso vielen Tests erzeugen kann wie bei 2 Parametern nötig wären. Dazu verwendet man die Methode der [http://en.wikipedia.org/wiki/Latin_square Latin Squares]. Wir beschreiben diese Methode für den einfachen Fall von 3 möglichen Werten pro Parameter.

:Ein Latin Square der Größe 3 ist eine 3x3 Matrix, deren Einträge die Zahlen 1...3 sind, und zwar so, dass jede Zahl genau einmal in jeder Zeile und Spalte vorkommt (ähnlich wie beim Sudoku). Eine mögliche Matrix ist z.B.

:<math>P=\begin{pmatrix}1 & 2 & 3 \\
2 & 3 & 1 \\
3 & 1 & 2\end{pmatrix}</math>
:Man bildet jetzt 9 Kombinationen der Zahlen 1...3, indem man zeilenweise durch die Matrix P geht, und den Zeilenindex (die Nummer der aktuellen Zeile) als erste Zahl, den Spaltenindex als zweite Zahl, und den Eintrag an der aktuallen Position als dritte Zahl verwendet. Man erhält
{| border="1" cellspacing="0" cellpadding="7" align="center"
|-align="center"
|
! Komb. 1
! Komb. 2
! Komb. 3
! Komb. 4
! Komb. 5
! Komb. 6
! Komb. 7
! Komb. 8
! Komb. 9
|-
!Zahl 1 (Zeilenindex)
|align="center" | 1
|align="center" | 1
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 3
|-
! Zahl 2 (Spaltenindex)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|-
! Zahl 3 (aktueller Matrixeintrag von P)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 3
|align="center" | 1
|align="center" | 2
|}

:Diese Tabelle bestimmt, welcher Wert in jedem Test für jeden Parameter verwendet wird. Z.B. wird der erste Test mit v11 (erster Wert des ersten Parameters), v21 (erster Wert des zweiten Parameters), v31 (erster Wert des dritten Parameters) aufgerufen
assertEqual( foo(v11, v21, v31), foo_reference1)
(reference1 ist das korrekte Referenz-Ergebnis für diese Parameterbelegung). Der letzte Test hat die Parameter v13, v23, v32
assertEqual( foo(v13, v23, v32), foo_reference9)
:Man überzeugt sich leicht, dass diese 9 Tests jede mögliche Paarung genau einmal enthalten. Hat der Algorithmus 4 Parameter, benötigt man einen zweiten Latin Square, der zum ersten orthogonal ist. Zwei Latin Squares P und Q heißen orthogonal, wenn alle Paare cij=(Pij, Qij) eindeutig sind, d.h. es gilt cij≠ckl falls i≠k und j≠l. Ein zu dem obigen P orthogonales Q ist z.B.
:<math>Q=\begin{pmatrix}1 & 2 & 3 \\
3 & 1 & 2 \\
2 & 3 & 1\end{pmatrix}</math>
: Jetzt bildet man Kombinationen aus 4 Zahlen, indem man zur obigen Tabelle noch eine vierte Zeile hinzufügt, die die aktuellen Einträge von Q für den jeweiligen Zeilen- und Spaltenindex enthält:
{| border="1" cellspacing="0" cellpadding="7" align="center"
|-align="center"
|
! Komb. 1
! Komb. 2
! Komb. 3
! Komb. 4
! Komb. 5
! Komb. 6
! Komb. 7
! Komb. 8
! Komb. 9
|-
!Zahl 1 (Zeilenindex)
|align="center" | 1
|align="center" | 1
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 3
|-
! Zahl 2 (Spaltenindex)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|-
! Zahl 3 (aktueller Matrixeintrag von P)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 3
|align="center" | 1
|align="center" | 2
|-
! Zahl 4 (aktueller Matrixeintrag von Q)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 1
|}

:Es sind immer noch nur 9 Tests nötig, um alle Paarungen zu erzeugen. Der erste und letzte Test sind nun:
assertEqual( bar(v11, v21, v31, v41), bar_reference1)
...
assertEqual( bar(v13, v23, v32, v41), bar_reference9)
:Die Methode der Latin Squares funktioniert auch, wenn mehr als 3 Belegungen für jeden Parameter möglich sind, und wenn es mehr als 4 Parameter gibt. Für die Einzelheiten verweisen wir auf die Literatur, z.B. [http://citeseer.ist.psu.edu/78354.html], [http://en.wikipedia.org/wiki/Latin_square]. Empirische Untersuchungen haben ergeben, dass die Methode der vollständigen Paarung oft über 90% der Fehler in einem Programm finden kann.

[[Effizienz|Nächstes Thema]]

Korrektheit

2010-08-10T11:05:11Z

Jschleic: /* Vergleich formaler Korrektheitsbeweis und Testen */ Satzbau + typo

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
# 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]).
# '''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: Prüfung der syntaktischen Korrektheit, formaler Korrektheitsbeweis und Softwaretest.

== Syntaktische Korrektheit ==

Die syntaktische Korrektheit behandeln wir hier nur kurz und der Vollständigkeit halber. Sie wird 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
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ückgeweisen 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

== Formaler Korrektheitsbeweis ==
=== (Halb-)Automatisches Beweisen ===
Man versucht, die Hypothese H: ''Algorithmus ist korrekt'' entweder mathematisch zu beweisen oder zu widerlegen. Dieses Beweisverfahren heißt dann halbautomatisch, wenn der Mensch in den Entscheidungsprozess miteinbezogen 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. [http://en.wikipedia.org/wiki/Z_notation Z]). 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 (allerding 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/lib/module-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 Tests selbst nur nähreungsweise 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.

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

====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 testes 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 Prameterbelegung). Der letzte Test hat die Parameter v13, v23, v32
assertEqual( foo(v13, v23, v32), foo_reference9)
:Man überzeugt sich leicht, dass diese 9 Tests jede mögliche Paarung genau einmal enthalten. Hat der Algorithmus 4 Parameter, benötigt man einen zweiten Latin Square, der zum ersten orthogonal ist. Zwei Latin Squares P und Q heißen orthogonal, wenn alle Paare cij=(Pij, Qij) eindeutig sind, d.h. es gilt cij≠ckl falls i≠k und j≠l. Ein zu dem obigen P orthogonales Q ist z.B.
:<math>Q=\begin{pmatrix}1 & 2 & 3 \\
3 & 1 & 2 \\
2 & 3 & 1\end{pmatrix}</math>
: Jetzt bildet man Kombinationen aus 4 Zahlen, indem man zur obigen Tabelle noch eine vierte Zeile hinzufügt, die die aktuellen Einträge von Q für den jeweiligen Zeilen- und Spaltenindex enthält:
{| border="1" cellspacing="0" cellpadding="7" align="center"
|-align="center"
|
! Komb. 1
! Komb. 2
! Komb. 3
! Komb. 4
! Komb. 5
! Komb. 6
! Komb. 7
! Komb. 8
! Komb. 9
|-
!Zahl 1 (Zeilenindex)
|align="center" | 1
|align="center" | 1
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 3
|-
! Zahl 2 (Spaltenindex)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|-
! Zahl 3 (aktueller Matrixeintrag von P)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 3
|align="center" | 1
|align="center" | 2
|-
! Zahl 4 (aktueller Matrixeintrag von Q)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 1
|}

:Es sind immer noch nur 9 Tests nötig, um alle Paarungen zu erzeugen. Der erste und letzte Test sind nun:
assertEqual( bar(v11, v21, v31, v41), bar_reference1)
...
assertEqual( bar(v13, v23, v32, v41), bar_reference9)
:Die Methode der Latin Squares funktioniert auch, wenn mehr als 3 Belegungen für jeden Parameter möglich sind, und wenn es mehr als 4 Parameter gibt. Für die Einzelheiten verweisen wir auf die Literatur, z.B. [http://citeseer.ist.psu.edu/78354.html], [http://en.wikipedia.org/wiki/Latin_square]. Empirische Untersuchungen haben ergeben, dass die Methode der vollständigen Paarung oft über 90% der Fehler in einem Programm finden kann.

[[Effizienz|Nächstes Thema]]

Main Page

2008-09-24T10:48:07Z

Jschleic: Undo revision 4422 by 87.118.120.241 (Talk) spam

== Vorlesung Algorithmen und Datenstrukturen ==

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

Die Vorlesung findet '''mittwochs''' um 11:15 Uhr in INF 227, HS 2 und '''donnerstags''' um 11:15 Uhr in INF 308, HS 2 statt.

=== Klausur und Nachprüfung ===

Die '''Abschlussklausur''' findet am Mittwoch, dem 23.7.2008 von 10:00 bis 12:30 Uhr im HS1, INF 227 (KIP) statt. (Hinweis: Sie benötigen einen Lichtbildausweis, um sich bei der Klausur zu indentifizieren!)

* '''[[Media:Prüfungsteilnehmer.pdf|Liste der Studenten]], die sich verbindlich zur Klausur angemeldet und die notwendige Übungspunktzahl erreicht haben.'''
* '''[[Media:Ergebnis-Klausur-23-07-2008.pdf|Ergebnis der Klausur vom 23.7.2008]]''' (anonymisiert)
* '''Scheine''' können ab 1.9.2008 im Sekretariat Informatik bei Frau Tenschert abgeholt werden.
* Die '''Wiederholungsklausur''' findet am 1.10.2008 um 9:00 Uhr im Seminarraum des [http://hci.iwr.uni-heidelberg.de/contact.php HCI, Speyerer Str. 4], statt.

=== Leistungsnachweise ===
Für alle Leistungsnachweise ist die erfolgreiche Teilnahme an den Übungen erforderlich. Für Leistungspunkte bzw. den Klausurschein muss außerdem die schriftliche Prüfung bestanden werden. Im einzelnen können erworben werden:
* ein benoteter Übungsschein (Magister mit Computerlinguistik im ''Nebenfach'', Physik Diplom)
* ein Klausurschein (Magister mit Computerlinguistik im ''Hauptfach'')
* ein Leistungsnachweis über 9 Leistungspunkte (B.A. Computerlinguistik - alte Studienordnung)
* ein Leistungsnachweis über 8 Leistungspunkte (B.Sc. Informatik, B.A. Computerlinguistik - neue Studienordnung)
* ein Leistungsnachweis über 7 Leistungspunkte (B.Sc. Physik).

=== Übungsbetrieb ===
* Termine der Übungsgruppen:
** Mo 11:00 - 13:00 Uhr, INF 350 (Otto-Meyerhof-Zentrum, Seiteneingang), Raum 014 (Tutor: Rahul Nair, [mailto:rnair(at)gmx(punkt)de rnair (at) gmx (punkt) de])
** Di 11:00 - 13:00 Uhr, INF 350 (Otto-Meyerhof-Zentrum, Seiteneingang), Raum 014 (Tutor: Thomas Gerlach, [mailto:gerlach@kip.uni-heidelberg.de gerlach@kip.uni-heidelberg.de])
** Mi 14:00 - 16:00 Uhr, '''neu: INF 327, Raum SR 5''' (Tutor: Christoph Sommer, [mailto:christoph.sommer@iwr.uni-heidelberg.de christoph.sommer@iwr.uni-heidelberg.de])
** Do 14:00 - 16:00 Uhr, INF 294, Raum -113 (im Untergeschoss, Tutor: Daniel Kondermann, [mailto:daniel.kondermann@iwr.uni-heidelberg.de daniel.kondermann@iwr.uni-heidelberg.de])
* [[Main Page#Übungsaufgaben|Übungsaufgaben]] (Übungszettel mit Abgabetermin, Musterlösungen)
* [[Media:Punktestand.pdf|aktueller Punktestand]] (PDF, anonymisiert, so aktuell, wie von den Tutoren an mich übermittelt -- UK)
* Zur Klausur wird zugelassen, wer mindestens 50% der Übungspunkte erreicht. Außerdem muss jeder Teilnehmer eine Lösung (bzw. einen Teil davon) in der Übungsgruppe vorrechnen. Es gibt verschiedene Möglichkeiten, Zusatzpunkte zu erlangen (Bonusaufgaben, Anfertigung der Wiki-Seiten, gute Mitarbeit in den Übungen).

=== Prüfungsvorbereitung ===

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

=== Literatur ===

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

=== Gliederung der Vorlesung ===

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

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

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

# [[Korrektheit]] (23. - 30.4.2008)
#* 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]] (30.4. - 14.5.2008)
#* 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]] (14. - 21.5.2008)
#* Lineare Suche
#* Binäre Suche in sortierten Arrays, Medianproblem
#* Suchbäume, balancierte Bäume
#* selbst-balancierende Bäume, Rotationen
#* Komplexität der Suche

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

# [[Hashing und assoziative Arrays]] (29.5.und 4.6.2008)
#* 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]] (5.6.2008)
#* Typen der Rekursion und ihre Umwandlung in Iteration
#* Auflösung rekursiver Formeln mittels Master-Methode und Substitutionsmethode

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

# [[Graphen und Graphenalgorithmen]] (12. bis 2.7.2008)
#* 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]] (3. und 9.7.2008)
#* 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]] (10. und 16.7.2008)
#* 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]] (16. und 17.7.2008)
#* die Klassen P und NP
#* NP-Vollständigkeit und Problemreduktion



== Übungsaufgaben ==

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

# [[Media:Übung-1.pdf|Übung]] (Abgabe 17.4.2008) und [[Media:Übung-1-Musterlösung.pdf|Musterlösung]]
#* Python-Tutorial
#* Sieb des Eratosthenes
#* Wert- und Referenzsemantik

# [[Media:Übung-2.pdf|Übung]] (Abgabe 24.4.2008) sowie Musterlösungen für [[Media:muster_blatt2-aufgabe1.pdf|Aufgabe 1]] und [[Media:muster_blatt2-aufgabe2.pdf|Aufgabe 2]]
#* Sortieren: Implementation und Geschwindigkeitsvergleich (Diagramme in Abhängigkeit von Problemgröße)
#* Entwicklung eines effizienten Algorithmus: Bruchfestigkeit von Gläsern

# [[Media:Übung-3.pdf|Übung]] ('''neuer Abgabetermin''' 7.5.2008) und [[Media:Übung-3-Musterlösung.pdf|Musterlösung]]
#* Experimente zur Effektivität von Unit Tests
#* Deque-Datenstruktur: Vor- und Nachbedingungen der Operationen, Implementation und Unit Tests

# [[Media:Übung-4.pdf|Übung]] (Abgabe 15.5.2008) und [[Media:Musterloesung_4.pdf|Musterlösung]]
#* Theoretische Aufgaben zur Komplexität
#* Amortisierte Komplexität von array.append()
#* Optimierung der Matrizenmultiplikation

# [[Media:Übung-5.pdf|Übung]] ('''neuer Abgabetermin''' 29.5.2008) und [[Media:muster_blatt5.pdf|Musterlösung]]
#* Implementation und Analyse eines Binärbaumes
#* Anwendung: einfacher Taschenrechner

# [[Media:Übung-6.pdf|Übung]] (Abgabe 5.6.2008) und [[Media:muster_blatt6.pdf|Musterlösung]]
#* Treap-Datenstruktur: Verbindung von Suchbaum und Heap
#* Anwendung: Worthäufigkeiten (Dazu benötigen Sie das File [http://klimt.iwr.uni-heidelberg.de/mip/people/ukoethe/download/die-drei-musketiere.txt die-drei-musketiere.txt]. Die Zeichenkodierung in diesem File ist Latin-1.)
#* Suche mit linearer Komplexität

# [[Media:Übung-7.pdf|Übung]] (Abgabe 12.6.2008) und [[Media:muster_blatt7.pdf|Musterlösung]]
#* Übungen zu Rekursion und Iteration: Fakultät, Koch-Schneeflocke, Komplexität rekursiver Algorithmen, Umwandlung von Rekursion in Iteration

# [[Media:Übung-8.pdf|Übung]] (Abgabe 19.6.2008) und [[Media:muster_blatt8.pdf|Musterlösung]]
#* Elementare Graphenaufgaben: Aufstellen von Adjazenzmatrizen und Adjazenzlisten, planare Graphen
#* Übungen zur Generizität: Sortieren mit veränderter Ordnung, Iterator für Tiefensuche

# [[Media:Übung-9.pdf|Übung]] (Abgabe 26.6.2008)
#* Fortgeschrittene Graphenaufgaben: Erzeugen einer perfekten Hashfunktion, Routenplaner (Dazu benötigen Sie das File [http://klimt.iwr.uni-heidelberg.de/mip/people/ukoethe/download/entfernungen.txt entfernungen.txt]. Die Zeichenkodierung in diesem File ist Latin-1.)

# [[Media:Übung-10.pdf|Übung]] (Abgabe 3.7.2008) und [[Media:loesung_blatt10.pdf|Musterlösung]] sowie schöne [[Media:ballungsgebiete.pdf|Visualisierung der Ballungsgebiete]] von Thorben Kröger
#* Fortgeschrittene Graphenaufgaben 2: Clusterung mittels minimaler Spannbäume, Problem des Handelsreisenden (Eine neue Version der Datei [http://klimt.iwr.uni-heidelberg.de/mip/people/ukoethe/download/entfernungen.txt entfernungen.txt] ist verfügbar. Dank an Sven Ebser, Joachim Schleicher und Thorben Kröger für Hilfe bei der Verbesserung der Datei.)

# [[Media:Übung-11.pdf|Übung]] (Abgabe 10.7.2008)
#* Erfüllbarkeitsproblem, Anwendung: Heim- und Auswärtsspiele im Fussball (Dazu benötigen sie das File [http://klimt.iwr.uni-heidelberg.de/mip/people/ukoethe/download/bundesliga-paarungen-08-09.txt bundesliga-paarungen-08-09.txt].)
#* Randomisierte Algorithmen: RANSAC für Kreise (Dazu benötigen sie das File [http://klimt.iwr.uni-heidelberg.de/mip/people/ukoethe/download/noisy-circles.txt noisy-circles.txt].)

# [[Media:Übung-12.pdf|Übung]] (Achtung: Abgabe bereits am Mittwoch, 16.7.2008)
#* Greedy-Algorithmen und Dynamische Programmierung

Suchen

2008-07-22T13:44:32Z

Jschleic: /* Komplexitätsanalyse */

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

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

== Überblick über verschiedene Suchmethoden ==

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

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

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

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

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

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

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

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

==Sequentielle Suche==

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

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

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

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

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

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

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

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

==Binäre Suche==

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

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

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

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

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

Der folgende Algorithmus zeigt eine beispielhafte Implementierung der Methode:

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

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

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

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

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

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

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

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

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

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

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

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

== Suchbäume ==

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

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

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

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

Ein ''Suchbaum'' hat zusätzlich die Eigenschaft, dass die Schlüssel jedes Knotens sortiert sind:
;Suchbaumbedingung: Für jeden Knoten des Binärbaumes gilt: Alle Schlüssel im linken Unterbaum sind kleiner als der Schlüssel des gegebenen Knotens, alle Schlüssel im rechten Unterbaum sind größer. Wir wollen hierbei annehmen, dass jeder Schlüssel pro Datensatz nur einmal vorkommt, da sich sonst die >- oder <-Relation nicht mehr strikt erfüllen ließe.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Komplexitätsanalyse ===

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

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

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

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

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

==Selbst-balancierende Suchbäume==

=== Balance eines Suchbaumes ===

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

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

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

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

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

Knoten (und damit ebensoviele Datenelemente).

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

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

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

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

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

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

[[Image:Baum_Rotation.png]]

Die Rotationen werden wie folgt implementiert:

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

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

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

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

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

===Andersson-Bäume===

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

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

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

====Regeln====

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

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

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

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

[[Image:Abild.png]]

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

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

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

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

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

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

Die folgende Illustration verdeutlicht das Verhalten des Andersson-Baumes, wenn die Schlüssel in der Folge [6,5,4,3,2,1] eingefügt werden. Beim einfachen Binärbaum sind solche vorsortierten Daten sehr ungünstig und führen zu entarteten Bäumen mit linearer Zugriffzeit (links). Die Umstrukturierungen beim Andersson-Baum stellen hingegen sicher, dass die Balance immer gewahrt bleibt (rechts). Diese Illustration sollte unbedingt verbessert werden. Die entscheidenden Punkte sind sehr schwer erkennbar, und es gibt auch Fehler.

6,1 5,1
/ -> \
5,1 6,1

5,1 4,1 5,2
/ \ -> \ -> / \
4,1 6,1 5,1 4,1 6,1
\
6,1

5,2 5,2
/ \ -> / \
4,1 6,1 3,1 6,1
/ \
3,1 4,1

5,2 5,2 5,2
/ \ / \ / \
3,1 6,1 -> 2,1 6,1 -> 3,2 6,1
/ \ \ / \
2,1 4,1 3,1 2,1 4,1
\
4,1

5,2 3,2
/ \ / \
3,2 6,1 -> 2,1 5,2
/ \ / \
2,1 4,1 4,1 6,1

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

==Beziehungen zwischen dem Suchproblem und dem Sortierproblem==

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

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

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

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

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

;Komplexität:

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

===Sortieren als Suchproblem===

Stellt man systematisch Fragen, die nur mit True oder False beantwortet werden können, kann dieses Vorgehen auch als Entscheidungsbaum dargestellt werden. [[Image:penka.png|400px]]

Als Beispiel verwenden wir den Algorithmus zum Sortieren von drei Elementen aus der Vorlesung über [[Sortieren]]. Als Eingabe sind drei Zahlen vorgegeben a={1,2,3}, deren Reihenfolge (Permutation) nicht bekannt ist. Wie die Illustration für den linke Hälfte des Entscheidungsbaumes zeigt, können wir die Reihenfolge mit nur 3 Fragen herausbekommen.
[[Image:trueFalseBeisp.png|700px]] (Die Reihenfolge der Antworten ''True, False, True'' kann allerdings gar nicht auftreten, weil sie widersprüchlich ist ('''bitte aus der Graphik löschen!''') Die allgemeine Regel lautet: Wenn es N mögliche Lösungen gibt, muss der Baum N Blätter haben. Wie wir oben gezeigt haben, hat ein Baum mit N Blättern mindestens die Tiefe log(N).

{| border="0" cellspacing="0" cellpadding="5"
|-valign="center"
|[[Image:vollbaum.png|left]]
| vollständiger Baum [http://hci.iwr.uni-heidelberg.de/alda/index.php/Suchen#Balance_eines_Suchbaumes] 2d+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!) = \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

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

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, siehe dazu Übungsaufgabe 6.2.

Sortieren

2008-07-22T12:54:09Z

Jschleic: /* Charakterisierung der Effizienz von Algorithmen */

----
== Laufzeitmesung in Python ==

Verwendung der '''timeit-Bibliothek''' für die Hausaufgabe.

* Importiere das timeit-Modul: <tt>import timeit</tt>
* Teile den Algorithmus in die Initialisierungen und den Teil, dessen Geschwindigkeit gemessen werden soll. Beide Teile werden in jeweils einen (mehrzeiligen) String eingeschlossen:

+--------+ +----+ setup = """ prog = """
| algo | --> |init| +----+ +----+
| | +----+ |init| |prog|
| | +----+ +----+
| | +----+ """ """
| | --> |prog|
+--------+ +----+

* aus den beiden Strings wird ein Timeit-Objekt erzeugt: <tt>t = timeit.Timer(prog, setup)</tt>
* Frage: Wie oft soll die Algorithmik wiederholt werden
:z.B. N = 1000
* Zeit in Sekunden für N Durchläufe: <tt>K = t.timeit(N)</tt>
:Zeit für 1 Durchlauf: K/N

----
3.Stunde am 16.04.2008

==Sortierverfahren==

=== Motivation ===
'''Def:'''
Ein Sortierverfahren ist ein Algorithmus, der dazu dient, eine Liste von Elementen zu sortieren.
* Literatur, siehe Sortierverfahren; Bubblesort 1956, Quicksort 1962. Librarysort 2004

'''Anwendungen'''
* Sortierte Daten sind häufig Vorbedingungen für Suchverfahren (Speziell für effiziente Suchalgorithmen mit Komplexität <math>\mathcal{O}(log(N))</math>)
* Darstellung von Daten gemäß menschlicher Wahrnehmung
* Aus programmiertechnischer Anwendungssicht hat das Sortierproblem allerdings heute an Relevanz verloren da
** gängige Programmiersprachen heute typunabhängige Algorithmen zur Verfügung stellen. Der Programmierer braucht sich deshalb in den meisten Fällen nicht mehr um die Implementierung von Sortieralgorithmen zu kümmern. In C/C++ sorgen dafür beispielsweise Methoden aus der [http://de.wikipedia.org/wiki/Standard_Template_Library STL].
** Festplatten / Hauptspeicher heute weniger limitierenden Charakter haben, so dass Standardsortierverfahren meist ausreichen, während komplizierte, speicher-sparende Sortieralgorithmen nur noch selten benötigt werden.
* Die Kenntnis grundlegender Sortieralgorithmen ist trotzdem immer noch nötig: Einerseits kann man vorgefertigte Bausteine nur dann optimal einsetzen, wenn man weiß, was hinter den Kulissen passiert und andererseits verdeutlicht gerade das Sortierproblem wichtige Prinzipien der Algorithmenentwicklung und -analyse in sehr anschaulicher Form.

=== Vorraussetzungen/ Spielregeln ===

==== Mengentheoretische Anforderungen====
Definition Totale Ordnung/ Total gordnete Menge:
Eine Totale Ordnung / Total geordnete Menge ist eine binäre Relation
<math>R \subseteq M \times M</math> über einer Menge <math>M</math>, die transitiv, antisymmetrisch und total ist. 

<math>R</math> sei dargestellt als infix Notation <math>\le </math> dann, falls M total geordnet, gilt
<math> \forall a,b,c \ \epsilon M </math> 
(1) <math>a \le b \wedge b \le a \Rightarrow a=b </math> (antisymmetrisch) 
(2) <math>a \le b \wedge b \le c \Rightarrow a \le c </math> (transitiv) 
(3) <math>a \le b \vee b \le a </math> (total) 
Bemerkung: aus (3) folgt <math> a \le a </math> (reflexiv) 

''Hab in der Wiki eine gute Seite dazu gefunden [http://de.wikipedia.org/wiki/Ordnungsrelation'' Ordnungsrelation]

==== Datenspeicherung ====

Die Daten liegen typischerweise in Form von Arrays oder verketteten Listen vor. Ja nach Datenstruktur sind andere Sortieralgorithmen am besten geeignet.
;Array:
+---+---+---+---+---+---+---+---+---+
|///| | | | | | | |///|
+---+---+---+---+---+---+---+---+---+
\________________ ____________________/
\/
N
Datenelemente können über Indexoperation a[i] gelesen, überschrieben und miteinander vertauscht werden. Vorteil: Die Zugriffsreihenfolge auf die Datenelemente ist beliebig. Nachteil: Einfügen oder Löschen von Elementen aus dem Array ist relativ aufwändig.

;Vekettete Liste:
+---+ +---+ +---+
| | --> | | --> | | --> Ende
+---+ +---+ +---+

Jeder Knoten der Liste enthält ein Datenelement und einen Zeiger auf den nächsten Knoten. Vorteil: Einfügen und Löschen von Elementen ist effizient möglich. Nachteil: effizienter Zugriff nur auf den Nachfolger eines gegebenen Elements, d.h. Zugriffsreihenfolge ist nicht beliebig.

==== Stabilität ====

Ein Sortierverfahren heißt ''stabil'' falls die relative Reihenfolge gleicher Schlüssel durch die Sortierung nicht verändert wird.

Beispiel: Sortiere eine Liste von Paaren <tt>[(3,7), (4,2), (4,1), (2,2), (2,8)]</tt>, wobei die Reihenfolge nur durch das erste Element (Schlüsselelement) jeden Paares festgelegt wird.
Dann erzeugt ein stabiles Sortierverfahren die Ausgabe
[(2,2), (2,8), (3,7), (4,2), (4,1)]
während die Ausgabe
[(2,2), (2,8), (3,7), (4,1), (4,2)]
nicht stabil ist (die Paare <tt>(4,1), (4,2)</tt> sind vertauscht).

==== Charakterisierung der Effizienz von Algorithmen ====

:(a) Komplexität O(1), O(n), etc. wird in Kapitel [[Effizienz]] erklärt.
:(b) Zählen der notwendigen Vergleiche
:(c) Messen der Laufzeit mit 'timeit' (auf identischen Daten)

'''Rekursive Beziehungen'''
zerlegt die ursprünglichen Probleme in kleinere Probleme und wendet den Algorithmus auf die kleineren Probleme an; daraufhin werden die Teilprobleme zur Lösung des Gesamtproblems verwendet.
d.h. Laufzeit (operativer Vergleich) für N Eingaben hängt von der Laufzeit der Eingaben für die Teilprobleme

'''Aufwand'''

(i) rekursives/ lineares Durchlaufen der Eingabedaten, Bearbeitung einzelner Elemente

C(N)= C(N-1)+ N ; N>1, C(1)= 1 +---+---+---+---+---+---+---+---+---+
= C(N-2) +(N-1)+ N | 7 | 3 | 2 | 5 | 6 | 8 | 1 | 4 | 2 |
= C(N-3) + (N-2) + (N-1) + N +---+---+---+---+---+---+---+---+---+
= ... ________________________/
= C(1) + 2+...+(N-1) +N /
+---+---+---+---+---+---+---+---+---+
N(N+1) N² | 1 | 3 | 2 | 5 | 6 | 8 | 7 | 4 | 2 |
= ----- ~ -- +---+---+---+---+---+---+---+---+---+
2 2

(ii) rekursives halbieren der Menge der Eingabedaten

C(N)= C(N/2)+1 ; N>1, C(1)=0
Aus Gründen der Einfachheit sei N = 2n

C(N)= C(2^n)= C(<math>2^{n-1}</math>) + 1

= C(<math>2^{n-1}</math>) + 1 + 1
= ...

= C(<math>2^0</math>) + n
= n
= <math>log_2 N</math>
+---+---+---+---+-|-+---+---+---+---+
| | | | | | | | | |
+---+---+---+---+-|-+---+---+---+---+
+---+---+---+---+
| | | | |
+---+---+---+---+
+---+---+ +---+
| | | -> | |
+---+---+ +---+

(iii) rekursives halbieren, lineare Bearbeitung, jedes Elements

C(N)= 2C(N/2)+ N; N>1, C(1)= 0
Sei N= <math>2^n</math>
C(N)= C(<math>2^n</math>)= 2C (<math>2^{n-1}</math>)+ <math>2^n</math>
<=> <math> \cfrac{C(2^n)}{2^n}</math> = <math> \cfrac{2C(2^{n-1})}{2^{n-1}}</math>

= <math> \cfrac{2C(2^{n-2})+2^{n-1}}{2^{n-1}}+1</math>
= <math> \cfrac{2C(2^{n-2})}{2^{n-2}}+1 +1</math>
=...
= n
<=> C(<math>2^n</math>)= <math>2^n</math> * n
<=> C= N log<math>_2</math>N

==Selection Sort==

===Algorithmus===

array = [...] # zu sortierendes Array

for i in range(len(array)-1):
min = i
for j in range(i+1, len(array)):
if a[j]< a[min]:
min = j
a[i], a[min] = a[min], a[i] # Vertausche a[i] mit dem kleinsten rechts befindlichen Element
# Elemente links von a[i] und a[i] selbst befinden sich nun in ihrer endgültigen Position

Beispiel: Sortieren der Liste <tt>[S,O,R,T,I,N,G]</tt>.

erste Iteration der äußeren Schleife, Zustand ''vor'' dem Vertauschen:
i=0 min
+---+---+---+---+---+---+---+
| S | O | R | T | I | N | G |
+---+---+---+---+---+---+---+

erste Iteration der äußeren Schleife, Zustand ''nach'' dem Vertauschen:
+---|---+---+---+---+---+---+
| G | O | R | T | I | N | S |
+---|---+---+---+---+---+---+

zweite Iteration der äußeren Schleife:
i=1 min
+---|---+---+---+---+---+---+
| G | O | R | T | I | N | S |
+---|---+---+---+---+---+---+

weitere Iterationen:
i=2 min
+---+---|---+---+---+---+---+
| G | I | R | T | O | N | S |
+---+---|---+---+---+---+---+

i=3 min
+---+---+---|---+---+---+---+
| G | I | N | T | O | R | S |
+---+---+---|---+---+---+---+

i=4 min
+---+---+---+---+---+---+---+
| G | I | N | O | T | R | S |
+---+---+---+---+---+---+---+
...

===Laufzeit===

Da in jeder Iteration der ''inneren'' Schleife ein Vergleich <tt>a[j]< a[min]</tt> durchgeführt wird, ist die Anzahl der Vergleiche ein gutes Maß für den Aufwand des Algorithmus und damit für die Laufzeit. Sei C(N) die Anzahl der notwendigen Vergleiche, um ein Array der Größe N zu sortieren. Die Arbeitsweise des Algorithmus kann dann so beschrieben werden: Führe N-1 Vergleiche aus, bringe das kleinste Element an die erste Stelle, und fahre mit dem Sortieren des Rest-Arrays (Größe N-1) rechts des ersten Elements fort. Dafür sind nach Definition noch C(N-1) Vergleiche nötig. Es gilt also:
:::<math>C(N) = C(N-1) + (N-1)</math>
C(N-1) können wir nach der gleichen Formel einsetzen, und erhalten:
:::<math>C(N) = C(N-2) + (N-2) + (N-1)</math>
Wir können in dieser Weise weiter fortfahren. Bei C(1) wird das Einsetzen beendet, denn für ein Array der Länge 1 sind keine Vergleiche mehr nötig, also C(1) = 0. Wir erhalten somit
:::<math>C(N) = C(N-3) + (N-3) + (N-2) + (N-1)</math>
:::<math>...</math>
:::<math>C(N) = C(1) + 1 + 2 + ...+ (N-2)+ (N-1)</math>
:::<math>C(N) = 0 + 1 + 2 + ...+ (N-2)+ (N-1)</math>
Nach der Gaußschen Summenformel ist dies
:::<math>C(N) = \frac {(N-1)N}{2}\approx \cfrac {(N^2)}{2}</math> (für große N).

In jedem Durchlauf der äußeren Schleife werden außerdem zwei Elemente ausgetauscht. Es gilt für die Anzahl der Austauschoperationen
:::<math>A(N)= N-1</math>

===Stabilität===

Selection Sort ist stabil, wenn die Vergleiche durch <tt>a[j] < a[min]</tt> erfolgen, weil dann immer das erste Element mit einem gegebenen Schlüssel als erster nach vorn gebracht wird. Bei Vergleichen <tt>a[j] <= a[min]</tt> wird hingegen das letzte Element zuerst nach vorn gebracht, somit ist Selection Sort dann nicht stabil.

==Insertion Sort==

* wird in der Übungsgruppe behandelt, siehe auch in der [http://de.wikipedia.org/wiki/Insertionsort WikiPedia]
* Erweiterung: [http://en.wikipedia.org/wiki/Shell_sort Shell sort]

== Mergesort ==

===Algorithmus ===

Zugrunde liegende Idee:
* Zerlege das Problem in zwei möglichst gleich große Teilprobleme ("Teile und herrsche"-Prinzip -- divide and conquer)
* Löse die Teilprobleme rekursiv
* Führe die Teillösungen über Mischen (merging) in richtig sortierter Weise zusammen.
Der Algorithmus besteht somit aus zwei Teilen

====Zusammenführen -- merge====

a und b sind zwei sortierte Listen, die in eine sortierte Ergebnisliste kombiniert werden.

def merge(a,b):
c = [] # zunächst leere Ergebnisliste
i, j = 0, 0
while i < len(a) and j < len(b):
# wähle des kleinste der noch nicht angefügten Elemente
if a[i] <= b[j]:
c.append(a[i])
i += 1
else:
c.append(b[j])
j += 1
# eine Liste ist jetzt aufgebraucht => der Rest der anderen wird einfach an c angehängt
if i < len(a):
c += a[i:]
else:
c += b[j:]
return c

====rekursives Sortieren====

def mergeSort(a): # a ist das zu sortierende Array
if len(a) <= 1:
return a # Rekursionsabschluß: leere Arrays und Arrays mit einem Element müssen nicht sortiert werden
else:
left = a[:len(a)/2] # linkes Teilarray
right = a[len(a)/2:] # rechtes Teilarray
leftSorted = mergeSort(left) # rekursives Sortieren der Teilarrays
rightSorted = mergeSort(right) # ...
return merge(leftSorted, rightSorted) # Zusammenführen der Teilarrays

Bei der Sortierung mit Mergesort wird das Array immer in zwei Teile geteilt. → Es entsteht ein Binärbaum der Tiefe <math>\log_2 N</math>.

Beispiel: Sortieren der Liste <tt>[S,O,R,T,I,N,G]</tt>.

Der Algorithmus läuft in der folgenden Skizze zunächst rekursiv von unten nach oben (Zerlegen in Teillisten), danach werden die sortierten Teillisten von oben nach unten zusammengeführt (diese sortierten Teillisten sind in der Skizze dargestellt).

Schritt 0:
S 0 R T I N G S O R T I N G #Arraylänge: N/8 Vergleiche: 0
Schritt 1: \ / \ / \ / /
OS RT IN G OS RT IN / #Arraylänge: N/4 Vergleiche: 3 * 2 = 6
Schritt 2: \ / \ /
ORST GIN ORST GIN #Arraylänge: N/2 Vergleiche: 4 + 3 = 7
\ /
Schritt3: \ /
GINORST GINORST #Arraylänge: N Vergleiche: N = 7

===Laufzeit ===

Man erkennt an der Skizze, dass der Rekursionsbaum für ein Array der Länge N die Tiefe log N hat. Auf jeder Ebene werden weniger als N Vergleiche ausgeführt, so dass insgesamt weniger als N*log N Vergleiche benötigt werden. Dies ist natürlich wesentlich effizienter als die (N-1)*N/2 Vergleiche von Selection Sort. Mathematisch exakt kann man die Anzahl der Vergleiche durch die folgende Rekursionsformel berechnen:
:::<math>C(N) = C(\lfloor N/2\rfloor) + C(\lceil N/2\rceil) + N</math>
Der Aufwand ergibt sich aus dem Aufwand für die beiden Teilprobleme plus dem Aufwand für N Vergleiche beim Zusammenführen der sortierten Teillisten. Dabei stehen die Zeichen <math>\lfloor \rfloor</math> und <math>\lceil \rceil</math> für abrunden bzw. aufrunden, weil ein Problem mit ungeradem N nicht in zwei exakt gkeiche Teile geteilt werden kann. Um diese Komplikation zu vermeiden, beschränken wir uns im folgenden auf den Fall <math>N = 2^n</math> (mit etwas höherem Aufwand kann man zeigen, dass diese Einschränkung nicht notwendig ist und die Resultate für alle N gelten). Die vereinfachte Aufwandsformel lautet:
:::<math>C(N) = 2 C(N/2) + N</math>
Durch Einsetzen der Formel für N/2 erhalten wir:
:::<math>C(N) = 2 (2 C(N/4) + N/2) + N = 4 C(N/4) + N + N</math>
:::<math>C(N) = 4 (2 C(N/8) + N/4) + N + N = 8 C(N/8) + N + N + N</math>
:::<math>...</math>
Die Rekursion endet, weil für ein Array der Größe <math>N=1</math> keine Vergleiche mehr benötigt werden, also <math>C(1) = 0</math> gilt. Mit <math>N=2^n</math> ist dies aber gerade nach <math>n = \log_2 N</math> Zerlegungen der Fall. Merge Sort benötigt also
:::<math>C(N) = N + ... + N = n \cdot N = N\cdot \log_2 N</math>
Vergleiche.

===Weitere Eigenschaften von MergeSort ===

* Mergesort ist '''stabil''': wegen des Vergleichs <tt>a[i] <= b[j]</tt> wird die Position gleicher Schlüssel im Algorithmus <tt>merge(a,b)</tt> nicht verändert -- bei gleichem Schlüssel hat, wie gefordert, das linke Element Vorrang.
* Mergesort ist '''unempfindlich gegenüber der ursprünglichen Reihenfolge der Eingabedaten'''. Grund dafür ist
** die vollständige Aufteilung des Ausgangsarrays in Arrays der Länge 1 und
** dass <tt>merge(a,b)</tt> die Vorsortierung nicht ausnutzt, d.h. die Komplexität von <tt>merge(a,b)</tt> ist sortierungsunabhängig.
* Diese Eigenschaft kann unerwünscht sein, wenn ein Teil des Arrays oder gar das ganze Array schon sortiert ist. Es wird nämlich in jedem Fall das ganze Array neu sortiert.
* Merge Sort eignet sich für das Sortieren von '''verketteten Listen''', weil die Listenelemente stets von vorn nach hinten durchlaufen werden. In diesem Fall muss <tt>merge(a, b)</tt> keine neue Liste <tt>c</tt> für das Ergebnis anlegen, sondern kann einfach die Verkettung der Listenelemente von <tt>a</tt> und <tt>b</tt> entsprechend anpassen. In diesem Sinne arbeitet Merge Sort auf verketten Listen "in place", d.h. es wird kein zusätzlicher Speicher benötigt.
* Im Gegensatz dazu benötigt <tt>merge(a,b)</tt> zusätzlichen Speicher für das Ergebnis <tt>c</tt>, wenn die Daten in einem Array gegeben sind.

== Quicksort ==

* Quicksort wurde in den 60er Jahren von Charles Antony Richard Hoare [http://de.wikipedia.org/wiki/C._A._R._Hoare] entwickelt. Es gibt viele Implementierungen von Quicksort, vgl. [http://de.wikipedia.org/wiki/Quicksort].
* Dieser Algorithmus gehört zu den "Teile und herrsche"-Algorithmen (divide-and-conquer) und ist der Standardalgorithmus für Sortieren.
* Im Gegensatz zu Merge Sort wird das Problem aber nicht immer in zwei fast gleich große Teilprobleme zerlegt. Dadurch vermeidet man, dass zusätzlicher Speicher benötigt wird (Quick Sort arbeitet auch für Arrays "in place"). Allerdings erkauft man sich dies dadurch, dass Quick Sort bei ungünstigen Eingaben (die Bedeutung von "ungünstig" ist je nach Implementation verschieden) nicht effizient arbeitet. Da solche Eingaben jedoch in der Praxis fast nie vorkommen, tut dies der Beliebtheit von Quicksort keinen Abbruch.

=== Algorithmus===

Wie Merge Sort arbeitet Quick Sort rekursiv. Hier werden die Daten allerdings zuerst vorbereitet (in der Funktion <tt>partition</tt>), und danach erfolgt der rekursive Aufruf:

def quicksort(a, l, r):
"""a ist das zu sortierende Array,
l und r sind die linke und rechte Grenze des zu sortierenden Bereichs"""

if r > l: # Rekursionsabschluss: wenn r <= l, ist der Bereich leer und muss nicht mehr sortiert werden
i = partition(a, l, r) # i ist der Index des sog. Pivot-Elements (s. u.)
quicksort(a, l, i-1) # rekursives Sortieren der beiden Teilarrays
quicksort(a, i+1, r) # ...

Der Schlüssel des Algorithmus ist offensichtlich die Funktion <tt>partition</tt>. Diese wählt ein Element des Arrays aus (das Pivot-Element) und bringt es an die richtige Stelle (also an den Index <tt>i</tt>, der von <tt>partition</tt> zurückgegeben wird). Ausserdem stellt sie sicher, dass alle Elemente in der linken Teilliste (Index < <tt>i</tt>) kleiner als <tt>a[i]</tt>, und alle Elemente in der rechten Teilliste größer also <tt>a[i]</tt> sind:
# <math>a[i]</math> ist sortiert, d.h. dieses Element ist am endgültigen Platz.
# <math>\forall x \in \left\{ a \left[ l \right] , ... a \left[ i-1 \right] \right\} : x \leq a \left[ i \right]</math>
# <math>\forall x \in \left\{ a \left[ i+1 \right], ... a \left[ r \right] \right\} : x \geq a \left[ i \right]</math>

l r
+---+---+---+---+---+---+---+---+---+
Array: | | | | |\\\| | | | |
+---+---+---+---+---+---+---+---+---+
\______ _____/ i \______ _____/
\/ \/
<=a[i] >=a[i] (a[i] ist das Pivot-Element)

Die Position von <tt>i</tt> richtet sich also offensichtlich danach, wie viele Elemente im Bereich <tt>l</tt> bis <tt>r</tt> kleiner bzw. größer als das gewählte Pivot-Element sind. Der Wahl eines guten Pivot-Elements kommt demnach eine große Bedeutung zu (s.u.).

In der einfachsten Version wird <tt>partition</tt> wie folgt definiert:

def partition(a, l, r):
pivot = a[r] # Pivot-Element. Hier wird willkürlich das letzte Element verwendet.
i = l # i und j sind Laufvariablen
j = r - 1

while True:
while a[i] <= pivot and i < r:
i += 1 # finde von links das erste Element > pivot
while a[j] >= pivot and j > l:
j -= 1 # finde von rechts den ersten Eintrag <= pivot
if i >= j: break # keine weiteren Elemente zum Tauschen => Schleife beenden
a[i], a[j] = a[j], a[i] # a[i] und a[j] sind beide auf der falschen Seite des Pivot => vertausche sie
if a[i] > pivot:
a[i], a[r] = a[r], a[i]
return i

Die folgende Skizze verdeutlicht das Austauschen

p
+---+---+---+---+---+---+---+---+---+
Array: | | | | | | | | |\\\|
+---+---+---+---+---+---+---+---+---+
------> a[i]>p a[j]<p <-----
| |
+---------------+
Diese zwei Elemente werden ausgetauscht.

Dies wird wiederholt, bis sich die Zeiger treffen oder einander überholt haben. Am Schluss wird das Pivot-Element an die richtige Stelle verschoben:

p
+---+---+---+---+---+---+---+---+---+
Array: | | | | |\\\| | | | |
+---+---+---+---+---+---+---+---+---+
i
-----------------> <-----------------

Beispiel: Partitionieren des Arrays <tt>[A,S,O,R,T,I,N,G,E,X,A,M,P,L,E]</tt> mit Pivot 'E'.

l,i --> <-- j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | S | O | R | T | I | N | G | E | X | A | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i <--------- Vertauschen ---------> j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | S | O | R | T | I | N | G | E | X | A | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i <-------------------> j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | O | R | T | I | N | G | E | X | S | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

j i r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | R | T | I | N | G | O | X | S | M | P | L | E | --> Hier wird die
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Schleife verlassen.

j i <---------------------------------------> r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | R | T | I | N | G | O | X | S | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | E | T | I | N | G | O | X | S | M | P | L | R | --> Hier wird partition() beendet.
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Weitere ausführliche Erklärungen der Implementation findet man bei Sedgewick.

=== Laufzeit===

Wir müssen hier den schlechtesten und den typischen Fall unterscheiden. Der schlechteste Fall tritt ein, wenn das Array bereits sortiert ist. Dann ist das Pivot-Element immer bereits am richtigen Platz, so dass <tt>partition(a, l, r)</tt> stets den Index <tt>i = r</tt> zurück. Daher wird das Array niemals in zwei etwa gleichgroße Teile zerlegt. Die Anzahl der Vergleiche ergibt sich als

:::<math>C(N) = (N+1) + C(N-1) + C(0)</math>
:::<math>C(0) = 0</math>

mit (N+1) Vergleichen in <tt>partition()</tt>. Durch sukzessives Einsetzen erhalten wir:

:::<math>C(N) = (N+1) + (N) + (N-1) + ... + 1 = (N+1) N / 2</math>

In diesem Fall ist Quick Sort also nicht schneller als Selection Sort. Wir beschreiben mögliche Verbesserungen unten. Im typischen Fall (wenn nämlich das Array zufällig sortiert ist) sieht die Situation wesentlich besser aus. Bei zufälliger Sortierung wird jeder Index mit gleicher Wahrscheinlichkeit zur Pivot-Position. Wir mitteln deshalb über alle möglichen Positionen:

:::<math>C(N) = (N+1) + \frac{1}{N} \sum_{k=1}^{N} \left[ C(k-1) + C(N-k) \right]</math> für <math> N>0</math>

wobei <math>k</math> über alle möglichen Teilungspunkte läuft. Die Summe (der mittlere Aufwand über alle möglichen Zerlegungen) kann vereinfacht werden zu
:::<math>\frac{1}{N} \sum_{k=1}^{N} \left[ C(k-1) + C(N-k) \right] = 2 \frac{1}{N} \sum_{k=1}^{N} C(k-1) </math>
Die Auflösung der Formel ist etwas trickreich. Wir multiplizieren zunächst beide Seiten mit N:

:::<math>
N \cdot C(N) = N \left[ (N+1) + \frac{2}{N} \sum_{k=1}^{N} C(k-1) \right] = N (N+1) + 2\; \sum_{k=1}^{N} C(k-1)</math>

Durch die Substitution <math>N \rightarrow N-1</math> erhalten wir die entsprechende Formel für N-1:

:::<math>
(N-1) \cdot C(N-1) = (N-1) N + 2\; \sum_{k=1}^{N-1} C(k-1)</math>

Wir subtrahieren die Formel für N-1 von der Formel für N und eliminieren dadurch die Summe (nur der letzte Summend der ersten Summe bleibt übrig):
:::<math>
\begin{array}{rcl}
N \cdot C(N) - (N-1) \cdot C(N-1) &=& N(N+1) + 2\;\sum_{k=1}^{N} C(k-1) - (N-1) N - 2\;\sum_{k=1}^{N-1} C(k-1)\\
&&\\
N \cdot C(N) - (N-1) \cdot C(N-1) &=& N(N+1) - (N-1) N + 2 C(N-1)
\end{array}
</math>
Durch Vereinfachen erhalten wir die rekurrente Beziehung
:::<math>
N \cdot C(N) = (N+1)\cdot C(N-1) + 2 N</math>
Wir teilen jetzt beide Seiten durch <math>(N+1)N</math>
:::<math>
\frac{C(N)}{N+1} = \frac{C(N-1)}{N} + \frac{2}{N+1} </math>
Sukzessives Einsetzen der Formel für <math> C(N-1), C(N-2) </math> etc. bis <math>C(1)=0</math> liefert
:::<math>
\frac{C(N)}{N+1} = \frac{C(N-2)}{N-1} + \frac{2}{N} + \frac{2}{N+1} = \frac{C(2)}{3} + \sum_{k=3}^N\frac{2}{k+1} </math>
Für hinreichend große N kann die Summe sehr genau durch ein Integral approximiert werden. Der konstanten Term kann vernachlässigt werden:
:::<math>
\frac{C(N)}{N+1} \approx 2 \sum_{k=3}^{N} \frac{1}{k+1} \approx 2 \int_1^N \frac{1}{k} dk = 2 \cdot \ln(N)</math>
Somit benötigt Quick Sort im typischen Fall
:::<math>C(N)\approx 2 N\cdot\ln(N) \approx 1.38 N\cdot\log_2(N)</math>
Vergleiche. Quick Sort ist demnach etwa genauso schnell wie Merge Sort (in der Praxis sogar etwas schneller, da die innere Schleife von Quick Sort etwas einfacher ist).

=== Verbesserungen des Quicksort-Algorithmus ===

==== Beseitigung der Rekursion ====
Eine Verbesserung beseitigt die Rekursion durch Verwendung eines Stacks. Nach jeder Partitionierung wird das größere Teilintervall auf dem Stack abgelegt und das kleinere Teilintervall direkt weiterverarbeitet (hierdurch wird sichergestellt, dass die maximale Größe des Stacks minimiert wird).

def quicksortNonRecursive(a, l, r):
stack = [(l,r)] # initialisiere den Stack
while len(stack) > 0:
if r > l:
i = partition(a, l, r)
if (i-l) > (r-i):
stack.append((l,i-1))
l = i+1
else:
stack.append((i+1, r))
r = i-1
else:
l, r = stack.pop()

Die ist die Methode der ''Endrekursionsbeseitigung'', die wir im Kapitel [[Iteration versus Rekursion]] ausführlich behandeln. Die folgende Skizze verdeutlicht die Verwendung des Stacks.

+---+---+---+---+---+---+---+
| Q | U | I | C | K | S | O |
+---+---+---+---+---+---+---+

+---+---+---+===+---+---+---+
| K | C | I |=O=| Q | S | U |
+---+---+---+===+---+---+---+
\_________/
push

+---+===+---+
| C |=I=| K |
+---+===+---+
\_/
push

+===+
|=C=|
+===+

+===+
|=K=|
+===+

+---+---+===+
| Q | S |=U=|
+---+---+===+

+---+===+
| Q |=S=|
+---+===+

+===+
|=Q=|
+===+

+---+---+---+---+---+---+---+
| C | I | K | O | Q | S | U |
+---+---+---+---+---+---+---+

==== Alternatives Sortieren kleiner Intervalle ====

Für kleine Arrays (bis zu einer gegebenen Größe K) ist das "Teile und herrsche"-Prinzip nicht die effizienteste Herangehensweise. Insbesondere kann man ein Array mit maximal 3 Elementen direkt sortieren:
def sortThree(a, l, r):
if r > l and a[l+1] < a[l]: # Stelle sicher, dass a[l] und a[l+1] relativ zueinander sortiert sind.
a[l], a[l+1] = a[l+1], a[l]
if r == l + 2:
if a[r] < a[l]: # Stelle sicher, dass a[l] und a[r] relativ zueinander sortiert sind.
a[l], a[r] = a[r], a[l] # Danach ist a[l] auf jeden Fall das kleinste Element.
if a[r] < a[r-1]: # Stelle sicher, dass a[r-1] und a[r] relativ zueinander sortiert sind.
a[r], a[r-1] = a[r-1], a[r] # Jetzt ist a[r] auf jeden Fall das größte Element und das Array damit sortiert.

In die Funktion <tt>quicksort()</tt> wird jetzt ein Aufruf dieser Funktion eingefügt:
if r > l + 2:
# wie bisher
elif r > l:
sortThree(a, l, r)

==== Günstige Selektion des Pivot-Elements ====
Durch geschickte Wahl des Pivot-Elements kann man erreichen, dass der ungünstigste Fall (quadratische Laufzeit) nur mit sehr kleiner Wahrscheinlichkeit eintritt. Zwei Möglichkeiten haben sich bewährt:
# Anstatt des letzten Elements des Teilarrays wählt man ein zufälliges Element (mit Hilfe eines Zufallszahlengenerators). Dadurch wird Quick Sort unempfindlich gegenüber bereits sortierten Arrays, weil die Teilung im Mittel wie bei einem zufällig sortierten Array erfolgt (typischer Fall in obiger Laufzeitberechnung).
# Median (mittlerer Wert) von drei Elementen: Verwende den Median des ersten, mittleren und letzten Elements jedes Teilarrays als Pivot-Element.
In beiden Fällen ist es praktisch ausgeschlossen, dass ein Eingabearray so angeordnet ist, dass in jedem Teilarray gerade das kleinste oder größte Element als Pivot gewählt wird. Nur dann könnte der ungünstigste Fall jedoch eintreten, was somit effektiv verhindert wird.

Sortieren

2008-07-22T12:53:47Z

Jschleic: /* Mengentheoretische Anforderungen */ Formeln verschönert

----
== Laufzeitmesung in Python ==

Verwendung der '''timeit-Bibliothek''' für die Hausaufgabe.

* Importiere das timeit-Modul: <tt>import timeit</tt>
* Teile den Algorithmus in die Initialisierungen und den Teil, dessen Geschwindigkeit gemessen werden soll. Beide Teile werden in jeweils einen (mehrzeiligen) String eingeschlossen:

+--------+ +----+ setup = """ prog = """
| algo | --> |init| +----+ +----+
| | +----+ |init| |prog|
| | +----+ +----+
| | +----+ """ """
| | --> |prog|
+--------+ +----+

* aus den beiden Strings wird ein Timeit-Objekt erzeugt: <tt>t = timeit.Timer(prog, setup)</tt>
* Frage: Wie oft soll die Algorithmik wiederholt werden
:z.B. N = 1000
* Zeit in Sekunden für N Durchläufe: <tt>K = t.timeit(N)</tt>
:Zeit für 1 Durchlauf: K/N

----
3.Stunde am 16.04.2008

==Sortierverfahren==

=== Motivation ===
'''Def:'''
Ein Sortierverfahren ist ein Algorithmus, der dazu dient, eine Liste von Elementen zu sortieren.
* Literatur, siehe Sortierverfahren; Bubblesort 1956, Quicksort 1962. Librarysort 2004

'''Anwendungen'''
* Sortierte Daten sind häufig Vorbedingungen für Suchverfahren (Speziell für effiziente Suchalgorithmen mit Komplexität <math>\mathcal{O}(log(N))</math>)
* Darstellung von Daten gemäß menschlicher Wahrnehmung
* Aus programmiertechnischer Anwendungssicht hat das Sortierproblem allerdings heute an Relevanz verloren da
** gängige Programmiersprachen heute typunabhängige Algorithmen zur Verfügung stellen. Der Programmierer braucht sich deshalb in den meisten Fällen nicht mehr um die Implementierung von Sortieralgorithmen zu kümmern. In C/C++ sorgen dafür beispielsweise Methoden aus der [http://de.wikipedia.org/wiki/Standard_Template_Library STL].
** Festplatten / Hauptspeicher heute weniger limitierenden Charakter haben, so dass Standardsortierverfahren meist ausreichen, während komplizierte, speicher-sparende Sortieralgorithmen nur noch selten benötigt werden.
* Die Kenntnis grundlegender Sortieralgorithmen ist trotzdem immer noch nötig: Einerseits kann man vorgefertigte Bausteine nur dann optimal einsetzen, wenn man weiß, was hinter den Kulissen passiert und andererseits verdeutlicht gerade das Sortierproblem wichtige Prinzipien der Algorithmenentwicklung und -analyse in sehr anschaulicher Form.

=== Vorraussetzungen/ Spielregeln ===

==== Mengentheoretische Anforderungen====
Definition Totale Ordnung/ Total gordnete Menge:
Eine Totale Ordnung / Total geordnete Menge ist eine binäre Relation
<math>R \subseteq M \times M</math> über einer Menge <math>M</math>, die transitiv, antisymmetrisch und total ist. 

<math>R</math> sei dargestellt als infix Notation <math>\le </math> dann, falls M total geordnet, gilt
<math> \forall a,b,c \ \epsilon M </math> 
(1) <math>a \le b \wedge b \le a \Rightarrow a=b </math> (antisymmetrisch) 
(2) <math>a \le b \wedge b \le c \Rightarrow a \le c </math> (transitiv) 
(3) <math>a \le b \vee b \le a </math> (total) 
Bemerkung: aus (3) folgt <math> a \le a </math> (reflexiv) 

''Hab in der Wiki eine gute Seite dazu gefunden [http://de.wikipedia.org/wiki/Ordnungsrelation'' Ordnungsrelation]

==== Datenspeicherung ====

Die Daten liegen typischerweise in Form von Arrays oder verketteten Listen vor. Ja nach Datenstruktur sind andere Sortieralgorithmen am besten geeignet.
;Array:
+---+---+---+---+---+---+---+---+---+
|///| | | | | | | |///|
+---+---+---+---+---+---+---+---+---+
\________________ ____________________/
\/
N
Datenelemente können über Indexoperation a[i] gelesen, überschrieben und miteinander vertauscht werden. Vorteil: Die Zugriffsreihenfolge auf die Datenelemente ist beliebig. Nachteil: Einfügen oder Löschen von Elementen aus dem Array ist relativ aufwändig.

;Vekettete Liste:
+---+ +---+ +---+
| | --> | | --> | | --> Ende
+---+ +---+ +---+

Jeder Knoten der Liste enthält ein Datenelement und einen Zeiger auf den nächsten Knoten. Vorteil: Einfügen und Löschen von Elementen ist effizient möglich. Nachteil: effizienter Zugriff nur auf den Nachfolger eines gegebenen Elements, d.h. Zugriffsreihenfolge ist nicht beliebig.

==== Stabilität ====

Ein Sortierverfahren heißt ''stabil'' falls die relative Reihenfolge gleicher Schlüssel durch die Sortierung nicht verändert wird.

Beispiel: Sortiere eine Liste von Paaren <tt>[(3,7), (4,2), (4,1), (2,2), (2,8)]</tt>, wobei die Reihenfolge nur durch das erste Element (Schlüsselelement) jeden Paares festgelegt wird.
Dann erzeugt ein stabiles Sortierverfahren die Ausgabe
[(2,2), (2,8), (3,7), (4,2), (4,1)]
während die Ausgabe
[(2,2), (2,8), (3,7), (4,1), (4,2)]
nicht stabil ist (die Paare <tt>(4,1), (4,2)</tt> sind vertauscht).

==== Charakterisierung der Effizienz von Algorithmen ====

:(a) Komplexität O( 1), O(n), etc. wird in Kapitel [[Effizienz]] erklärt.
:(b) Zählen der notwendigen Vergleiche
:(c) Messen der Laufzeit mit 'timeit' (auf identischen Daten)

'''Rekursive Beziehungen'''
zerlegt die ursprünglichen Probleme in kleinere Probleme und wendet den Algorithmus auf die kleineren Probleme an; daraufhin werden die Teilprobleme zur Lösung des Gesamtproblems verwendet.
d.h. Laufzeit (operativer Vergleich) für N Eingaben hängt von der Laufzeit der Eingaben für die Teilprobleme

'''Aufwand'''

(i) rekursives/ lineares Durchlaufen der Eingabedaten, Bearbeitung einzelner Elemente

C(N)= C(N-1)+ N ; N>1, C(1)= 1 +---+---+---+---+---+---+---+---+---+
= C(N-2) +(N-1)+ N | 7 | 3 | 2 | 5 | 6 | 8 | 1 | 4 | 2 |
= C(N-3) + (N-2) + (N-1) + N +---+---+---+---+---+---+---+---+---+
= ... ________________________/
= C(1) + 2+...+(N-1) +N /
+---+---+---+---+---+---+---+---+---+
N(N+1) N² | 1 | 3 | 2 | 5 | 6 | 8 | 7 | 4 | 2 |
= ----- ~ -- +---+---+---+---+---+---+---+---+---+
2 2

(ii) rekursives halbieren der Menge der Eingabedaten

C(N)= C(N/2)+1 ; N>1, C(1)=0
Aus Gründen der Einfachheit sei N = 2n

C(N)= C(2^n)= C(<math>2^{n-1}</math>) + 1

= C(<math>2^{n-1}</math>) + 1 + 1
= ...

= C(<math>2^0</math>) + n
= n
= <math>log_2 N</math>
+---+---+---+---+-|-+---+---+---+---+
| | | | | | | | | |
+---+---+---+---+-|-+---+---+---+---+
+---+---+---+---+
| | | | |
+---+---+---+---+
+---+---+ +---+
| | | -> | |
+---+---+ +---+

(iii) rekursives halbieren, lineare Bearbeitung, jedes Elements

C(N)= 2C(N/2)+ N; N>1, C(1)= 0
Sei N= <math>2^n</math>
C(N)= C(<math>2^n</math>)= 2C (<math>2^{n-1}</math>)+ <math>2^n</math>
<=> <math> \cfrac{C(2^n)}{2^n}</math> = <math> \cfrac{2C(2^{n-1})}{2^{n-1}}</math>

= <math> \cfrac{2C(2^{n-2})+2^{n-1}}{2^{n-1}}+1</math>
= <math> \cfrac{2C(2^{n-2})}{2^{n-2}}+1 +1</math>
=...
= n
<=> C(<math>2^n</math>)= <math>2^n</math> * n
<=> C= N log<math>_2</math>N

==Selection Sort==

===Algorithmus===

array = [...] # zu sortierendes Array

for i in range(len(array)-1):
min = i
for j in range(i+1, len(array)):
if a[j]< a[min]:
min = j
a[i], a[min] = a[min], a[i] # Vertausche a[i] mit dem kleinsten rechts befindlichen Element
# Elemente links von a[i] und a[i] selbst befinden sich nun in ihrer endgültigen Position

Beispiel: Sortieren der Liste <tt>[S,O,R,T,I,N,G]</tt>.

erste Iteration der äußeren Schleife, Zustand ''vor'' dem Vertauschen:
i=0 min
+---+---+---+---+---+---+---+
| S | O | R | T | I | N | G |
+---+---+---+---+---+---+---+

erste Iteration der äußeren Schleife, Zustand ''nach'' dem Vertauschen:
+---|---+---+---+---+---+---+
| G | O | R | T | I | N | S |
+---|---+---+---+---+---+---+

zweite Iteration der äußeren Schleife:
i=1 min
+---|---+---+---+---+---+---+
| G | O | R | T | I | N | S |
+---|---+---+---+---+---+---+

weitere Iterationen:
i=2 min
+---+---|---+---+---+---+---+
| G | I | R | T | O | N | S |
+---+---|---+---+---+---+---+

i=3 min
+---+---+---|---+---+---+---+
| G | I | N | T | O | R | S |
+---+---+---|---+---+---+---+

i=4 min
+---+---+---+---+---+---+---+
| G | I | N | O | T | R | S |
+---+---+---+---+---+---+---+
...

===Laufzeit===

Da in jeder Iteration der ''inneren'' Schleife ein Vergleich <tt>a[j]< a[min]</tt> durchgeführt wird, ist die Anzahl der Vergleiche ein gutes Maß für den Aufwand des Algorithmus und damit für die Laufzeit. Sei C(N) die Anzahl der notwendigen Vergleiche, um ein Array der Größe N zu sortieren. Die Arbeitsweise des Algorithmus kann dann so beschrieben werden: Führe N-1 Vergleiche aus, bringe das kleinste Element an die erste Stelle, und fahre mit dem Sortieren des Rest-Arrays (Größe N-1) rechts des ersten Elements fort. Dafür sind nach Definition noch C(N-1) Vergleiche nötig. Es gilt also:
:::<math>C(N) = C(N-1) + (N-1)</math>
C(N-1) können wir nach der gleichen Formel einsetzen, und erhalten:
:::<math>C(N) = C(N-2) + (N-2) + (N-1)</math>
Wir können in dieser Weise weiter fortfahren. Bei C(1) wird das Einsetzen beendet, denn für ein Array der Länge 1 sind keine Vergleiche mehr nötig, also C(1) = 0. Wir erhalten somit
:::<math>C(N) = C(N-3) + (N-3) + (N-2) + (N-1)</math>
:::<math>...</math>
:::<math>C(N) = C(1) + 1 + 2 + ...+ (N-2)+ (N-1)</math>
:::<math>C(N) = 0 + 1 + 2 + ...+ (N-2)+ (N-1)</math>
Nach der Gaußschen Summenformel ist dies
:::<math>C(N) = \frac {(N-1)N}{2}\approx \cfrac {(N^2)}{2}</math> (für große N).

In jedem Durchlauf der äußeren Schleife werden außerdem zwei Elemente ausgetauscht. Es gilt für die Anzahl der Austauschoperationen
:::<math>A(N)= N-1</math>

===Stabilität===

Selection Sort ist stabil, wenn die Vergleiche durch <tt>a[j] < a[min]</tt> erfolgen, weil dann immer das erste Element mit einem gegebenen Schlüssel als erster nach vorn gebracht wird. Bei Vergleichen <tt>a[j] <= a[min]</tt> wird hingegen das letzte Element zuerst nach vorn gebracht, somit ist Selection Sort dann nicht stabil.

==Insertion Sort==

* wird in der Übungsgruppe behandelt, siehe auch in der [http://de.wikipedia.org/wiki/Insertionsort WikiPedia]
* Erweiterung: [http://en.wikipedia.org/wiki/Shell_sort Shell sort]

== Mergesort ==

===Algorithmus ===

Zugrunde liegende Idee:
* Zerlege das Problem in zwei möglichst gleich große Teilprobleme ("Teile und herrsche"-Prinzip -- divide and conquer)
* Löse die Teilprobleme rekursiv
* Führe die Teillösungen über Mischen (merging) in richtig sortierter Weise zusammen.
Der Algorithmus besteht somit aus zwei Teilen

====Zusammenführen -- merge====

a und b sind zwei sortierte Listen, die in eine sortierte Ergebnisliste kombiniert werden.

def merge(a,b):
c = [] # zunächst leere Ergebnisliste
i, j = 0, 0
while i < len(a) and j < len(b):
# wähle des kleinste der noch nicht angefügten Elemente
if a[i] <= b[j]:
c.append(a[i])
i += 1
else:
c.append(b[j])
j += 1
# eine Liste ist jetzt aufgebraucht => der Rest der anderen wird einfach an c angehängt
if i < len(a):
c += a[i:]
else:
c += b[j:]
return c

====rekursives Sortieren====

def mergeSort(a): # a ist das zu sortierende Array
if len(a) <= 1:
return a # Rekursionsabschluß: leere Arrays und Arrays mit einem Element müssen nicht sortiert werden
else:
left = a[:len(a)/2] # linkes Teilarray
right = a[len(a)/2:] # rechtes Teilarray
leftSorted = mergeSort(left) # rekursives Sortieren der Teilarrays
rightSorted = mergeSort(right) # ...
return merge(leftSorted, rightSorted) # Zusammenführen der Teilarrays

Bei der Sortierung mit Mergesort wird das Array immer in zwei Teile geteilt. → Es entsteht ein Binärbaum der Tiefe <math>\log_2 N</math>.

Beispiel: Sortieren der Liste <tt>[S,O,R,T,I,N,G]</tt>.

Der Algorithmus läuft in der folgenden Skizze zunächst rekursiv von unten nach oben (Zerlegen in Teillisten), danach werden die sortierten Teillisten von oben nach unten zusammengeführt (diese sortierten Teillisten sind in der Skizze dargestellt).

Schritt 0:
S 0 R T I N G S O R T I N G #Arraylänge: N/8 Vergleiche: 0
Schritt 1: \ / \ / \ / /
OS RT IN G OS RT IN / #Arraylänge: N/4 Vergleiche: 3 * 2 = 6
Schritt 2: \ / \ /
ORST GIN ORST GIN #Arraylänge: N/2 Vergleiche: 4 + 3 = 7
\ /
Schritt3: \ /
GINORST GINORST #Arraylänge: N Vergleiche: N = 7

===Laufzeit ===

Man erkennt an der Skizze, dass der Rekursionsbaum für ein Array der Länge N die Tiefe log N hat. Auf jeder Ebene werden weniger als N Vergleiche ausgeführt, so dass insgesamt weniger als N*log N Vergleiche benötigt werden. Dies ist natürlich wesentlich effizienter als die (N-1)*N/2 Vergleiche von Selection Sort. Mathematisch exakt kann man die Anzahl der Vergleiche durch die folgende Rekursionsformel berechnen:
:::<math>C(N) = C(\lfloor N/2\rfloor) + C(\lceil N/2\rceil) + N</math>
Der Aufwand ergibt sich aus dem Aufwand für die beiden Teilprobleme plus dem Aufwand für N Vergleiche beim Zusammenführen der sortierten Teillisten. Dabei stehen die Zeichen <math>\lfloor \rfloor</math> und <math>\lceil \rceil</math> für abrunden bzw. aufrunden, weil ein Problem mit ungeradem N nicht in zwei exakt gkeiche Teile geteilt werden kann. Um diese Komplikation zu vermeiden, beschränken wir uns im folgenden auf den Fall <math>N = 2^n</math> (mit etwas höherem Aufwand kann man zeigen, dass diese Einschränkung nicht notwendig ist und die Resultate für alle N gelten). Die vereinfachte Aufwandsformel lautet:
:::<math>C(N) = 2 C(N/2) + N</math>
Durch Einsetzen der Formel für N/2 erhalten wir:
:::<math>C(N) = 2 (2 C(N/4) + N/2) + N = 4 C(N/4) + N + N</math>
:::<math>C(N) = 4 (2 C(N/8) + N/4) + N + N = 8 C(N/8) + N + N + N</math>
:::<math>...</math>
Die Rekursion endet, weil für ein Array der Größe <math>N=1</math> keine Vergleiche mehr benötigt werden, also <math>C(1) = 0</math> gilt. Mit <math>N=2^n</math> ist dies aber gerade nach <math>n = \log_2 N</math> Zerlegungen der Fall. Merge Sort benötigt also
:::<math>C(N) = N + ... + N = n \cdot N = N\cdot \log_2 N</math>
Vergleiche.

===Weitere Eigenschaften von MergeSort ===

* Mergesort ist '''stabil''': wegen des Vergleichs <tt>a[i] <= b[j]</tt> wird die Position gleicher Schlüssel im Algorithmus <tt>merge(a,b)</tt> nicht verändert -- bei gleichem Schlüssel hat, wie gefordert, das linke Element Vorrang.
* Mergesort ist '''unempfindlich gegenüber der ursprünglichen Reihenfolge der Eingabedaten'''. Grund dafür ist
** die vollständige Aufteilung des Ausgangsarrays in Arrays der Länge 1 und
** dass <tt>merge(a,b)</tt> die Vorsortierung nicht ausnutzt, d.h. die Komplexität von <tt>merge(a,b)</tt> ist sortierungsunabhängig.
* Diese Eigenschaft kann unerwünscht sein, wenn ein Teil des Arrays oder gar das ganze Array schon sortiert ist. Es wird nämlich in jedem Fall das ganze Array neu sortiert.
* Merge Sort eignet sich für das Sortieren von '''verketteten Listen''', weil die Listenelemente stets von vorn nach hinten durchlaufen werden. In diesem Fall muss <tt>merge(a, b)</tt> keine neue Liste <tt>c</tt> für das Ergebnis anlegen, sondern kann einfach die Verkettung der Listenelemente von <tt>a</tt> und <tt>b</tt> entsprechend anpassen. In diesem Sinne arbeitet Merge Sort auf verketten Listen "in place", d.h. es wird kein zusätzlicher Speicher benötigt.
* Im Gegensatz dazu benötigt <tt>merge(a,b)</tt> zusätzlichen Speicher für das Ergebnis <tt>c</tt>, wenn die Daten in einem Array gegeben sind.

== Quicksort ==

* Quicksort wurde in den 60er Jahren von Charles Antony Richard Hoare [http://de.wikipedia.org/wiki/C._A._R._Hoare] entwickelt. Es gibt viele Implementierungen von Quicksort, vgl. [http://de.wikipedia.org/wiki/Quicksort].
* Dieser Algorithmus gehört zu den "Teile und herrsche"-Algorithmen (divide-and-conquer) und ist der Standardalgorithmus für Sortieren.
* Im Gegensatz zu Merge Sort wird das Problem aber nicht immer in zwei fast gleich große Teilprobleme zerlegt. Dadurch vermeidet man, dass zusätzlicher Speicher benötigt wird (Quick Sort arbeitet auch für Arrays "in place"). Allerdings erkauft man sich dies dadurch, dass Quick Sort bei ungünstigen Eingaben (die Bedeutung von "ungünstig" ist je nach Implementation verschieden) nicht effizient arbeitet. Da solche Eingaben jedoch in der Praxis fast nie vorkommen, tut dies der Beliebtheit von Quicksort keinen Abbruch.

=== Algorithmus===

Wie Merge Sort arbeitet Quick Sort rekursiv. Hier werden die Daten allerdings zuerst vorbereitet (in der Funktion <tt>partition</tt>), und danach erfolgt der rekursive Aufruf:

def quicksort(a, l, r):
"""a ist das zu sortierende Array,
l und r sind die linke und rechte Grenze des zu sortierenden Bereichs"""

if r > l: # Rekursionsabschluss: wenn r <= l, ist der Bereich leer und muss nicht mehr sortiert werden
i = partition(a, l, r) # i ist der Index des sog. Pivot-Elements (s. u.)
quicksort(a, l, i-1) # rekursives Sortieren der beiden Teilarrays
quicksort(a, i+1, r) # ...

Der Schlüssel des Algorithmus ist offensichtlich die Funktion <tt>partition</tt>. Diese wählt ein Element des Arrays aus (das Pivot-Element) und bringt es an die richtige Stelle (also an den Index <tt>i</tt>, der von <tt>partition</tt> zurückgegeben wird). Ausserdem stellt sie sicher, dass alle Elemente in der linken Teilliste (Index < <tt>i</tt>) kleiner als <tt>a[i]</tt>, und alle Elemente in der rechten Teilliste größer also <tt>a[i]</tt> sind:
# <math>a[i]</math> ist sortiert, d.h. dieses Element ist am endgültigen Platz.
# <math>\forall x \in \left\{ a \left[ l \right] , ... a \left[ i-1 \right] \right\} : x \leq a \left[ i \right]</math>
# <math>\forall x \in \left\{ a \left[ i+1 \right], ... a \left[ r \right] \right\} : x \geq a \left[ i \right]</math>

l r
+---+---+---+---+---+---+---+---+---+
Array: | | | | |\\\| | | | |
+---+---+---+---+---+---+---+---+---+
\______ _____/ i \______ _____/
\/ \/
<=a[i] >=a[i] (a[i] ist das Pivot-Element)

Die Position von <tt>i</tt> richtet sich also offensichtlich danach, wie viele Elemente im Bereich <tt>l</tt> bis <tt>r</tt> kleiner bzw. größer als das gewählte Pivot-Element sind. Der Wahl eines guten Pivot-Elements kommt demnach eine große Bedeutung zu (s.u.).

In der einfachsten Version wird <tt>partition</tt> wie folgt definiert:

def partition(a, l, r):
pivot = a[r] # Pivot-Element. Hier wird willkürlich das letzte Element verwendet.
i = l # i und j sind Laufvariablen
j = r - 1

while True:
while a[i] <= pivot and i < r:
i += 1 # finde von links das erste Element > pivot
while a[j] >= pivot and j > l:
j -= 1 # finde von rechts den ersten Eintrag <= pivot
if i >= j: break # keine weiteren Elemente zum Tauschen => Schleife beenden
a[i], a[j] = a[j], a[i] # a[i] und a[j] sind beide auf der falschen Seite des Pivot => vertausche sie
if a[i] > pivot:
a[i], a[r] = a[r], a[i]
return i

Die folgende Skizze verdeutlicht das Austauschen

p
+---+---+---+---+---+---+---+---+---+
Array: | | | | | | | | |\\\|
+---+---+---+---+---+---+---+---+---+
------> a[i]>p a[j]<p <-----
| |
+---------------+
Diese zwei Elemente werden ausgetauscht.

Dies wird wiederholt, bis sich die Zeiger treffen oder einander überholt haben. Am Schluss wird das Pivot-Element an die richtige Stelle verschoben:

p
+---+---+---+---+---+---+---+---+---+
Array: | | | | |\\\| | | | |
+---+---+---+---+---+---+---+---+---+
i
-----------------> <-----------------

Beispiel: Partitionieren des Arrays <tt>[A,S,O,R,T,I,N,G,E,X,A,M,P,L,E]</tt> mit Pivot 'E'.

l,i --> <-- j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | S | O | R | T | I | N | G | E | X | A | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i <--------- Vertauschen ---------> j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | S | O | R | T | I | N | G | E | X | A | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i <-------------------> j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | O | R | T | I | N | G | E | X | S | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

j i r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | R | T | I | N | G | O | X | S | M | P | L | E | --> Hier wird die
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Schleife verlassen.

j i <---------------------------------------> r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | R | T | I | N | G | O | X | S | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | E | T | I | N | G | O | X | S | M | P | L | R | --> Hier wird partition() beendet.
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Weitere ausführliche Erklärungen der Implementation findet man bei Sedgewick.

=== Laufzeit===

Wir müssen hier den schlechtesten und den typischen Fall unterscheiden. Der schlechteste Fall tritt ein, wenn das Array bereits sortiert ist. Dann ist das Pivot-Element immer bereits am richtigen Platz, so dass <tt>partition(a, l, r)</tt> stets den Index <tt>i = r</tt> zurück. Daher wird das Array niemals in zwei etwa gleichgroße Teile zerlegt. Die Anzahl der Vergleiche ergibt sich als

:::<math>C(N) = (N+1) + C(N-1) + C(0)</math>
:::<math>C(0) = 0</math>

mit (N+1) Vergleichen in <tt>partition()</tt>. Durch sukzessives Einsetzen erhalten wir:

:::<math>C(N) = (N+1) + (N) + (N-1) + ... + 1 = (N+1) N / 2</math>

In diesem Fall ist Quick Sort also nicht schneller als Selection Sort. Wir beschreiben mögliche Verbesserungen unten. Im typischen Fall (wenn nämlich das Array zufällig sortiert ist) sieht die Situation wesentlich besser aus. Bei zufälliger Sortierung wird jeder Index mit gleicher Wahrscheinlichkeit zur Pivot-Position. Wir mitteln deshalb über alle möglichen Positionen:

:::<math>C(N) = (N+1) + \frac{1}{N} \sum_{k=1}^{N} \left[ C(k-1) + C(N-k) \right]</math> für <math> N>0</math>

wobei <math>k</math> über alle möglichen Teilungspunkte läuft. Die Summe (der mittlere Aufwand über alle möglichen Zerlegungen) kann vereinfacht werden zu
:::<math>\frac{1}{N} \sum_{k=1}^{N} \left[ C(k-1) + C(N-k) \right] = 2 \frac{1}{N} \sum_{k=1}^{N} C(k-1) </math>
Die Auflösung der Formel ist etwas trickreich. Wir multiplizieren zunächst beide Seiten mit N:

:::<math>
N \cdot C(N) = N \left[ (N+1) + \frac{2}{N} \sum_{k=1}^{N} C(k-1) \right] = N (N+1) + 2\; \sum_{k=1}^{N} C(k-1)</math>

Durch die Substitution <math>N \rightarrow N-1</math> erhalten wir die entsprechende Formel für N-1:

:::<math>
(N-1) \cdot C(N-1) = (N-1) N + 2\; \sum_{k=1}^{N-1} C(k-1)</math>

Wir subtrahieren die Formel für N-1 von der Formel für N und eliminieren dadurch die Summe (nur der letzte Summend der ersten Summe bleibt übrig):
:::<math>
\begin{array}{rcl}
N \cdot C(N) - (N-1) \cdot C(N-1) &=& N(N+1) + 2\;\sum_{k=1}^{N} C(k-1) - (N-1) N - 2\;\sum_{k=1}^{N-1} C(k-1)\\
&&\\
N \cdot C(N) - (N-1) \cdot C(N-1) &=& N(N+1) - (N-1) N + 2 C(N-1)
\end{array}
</math>
Durch Vereinfachen erhalten wir die rekurrente Beziehung
:::<math>
N \cdot C(N) = (N+1)\cdot C(N-1) + 2 N</math>
Wir teilen jetzt beide Seiten durch <math>(N+1)N</math>
:::<math>
\frac{C(N)}{N+1} = \frac{C(N-1)}{N} + \frac{2}{N+1} </math>
Sukzessives Einsetzen der Formel für <math> C(N-1), C(N-2) </math> etc. bis <math>C(1)=0</math> liefert
:::<math>
\frac{C(N)}{N+1} = \frac{C(N-2)}{N-1} + \frac{2}{N} + \frac{2}{N+1} = \frac{C(2)}{3} + \sum_{k=3}^N\frac{2}{k+1} </math>
Für hinreichend große N kann die Summe sehr genau durch ein Integral approximiert werden. Der konstanten Term kann vernachlässigt werden:
:::<math>
\frac{C(N)}{N+1} \approx 2 \sum_{k=3}^{N} \frac{1}{k+1} \approx 2 \int_1^N \frac{1}{k} dk = 2 \cdot \ln(N)</math>
Somit benötigt Quick Sort im typischen Fall
:::<math>C(N)\approx 2 N\cdot\ln(N) \approx 1.38 N\cdot\log_2(N)</math>
Vergleiche. Quick Sort ist demnach etwa genauso schnell wie Merge Sort (in der Praxis sogar etwas schneller, da die innere Schleife von Quick Sort etwas einfacher ist).

=== Verbesserungen des Quicksort-Algorithmus ===

==== Beseitigung der Rekursion ====
Eine Verbesserung beseitigt die Rekursion durch Verwendung eines Stacks. Nach jeder Partitionierung wird das größere Teilintervall auf dem Stack abgelegt und das kleinere Teilintervall direkt weiterverarbeitet (hierdurch wird sichergestellt, dass die maximale Größe des Stacks minimiert wird).

def quicksortNonRecursive(a, l, r):
stack = [(l,r)] # initialisiere den Stack
while len(stack) > 0:
if r > l:
i = partition(a, l, r)
if (i-l) > (r-i):
stack.append((l,i-1))
l = i+1
else:
stack.append((i+1, r))
r = i-1
else:
l, r = stack.pop()

Die ist die Methode der ''Endrekursionsbeseitigung'', die wir im Kapitel [[Iteration versus Rekursion]] ausführlich behandeln. Die folgende Skizze verdeutlicht die Verwendung des Stacks.

+---+---+---+---+---+---+---+
| Q | U | I | C | K | S | O |
+---+---+---+---+---+---+---+

+---+---+---+===+---+---+---+
| K | C | I |=O=| Q | S | U |
+---+---+---+===+---+---+---+
\_________/
push

+---+===+---+
| C |=I=| K |
+---+===+---+
\_/
push

+===+
|=C=|
+===+

+===+
|=K=|
+===+

+---+---+===+
| Q | S |=U=|
+---+---+===+

+---+===+
| Q |=S=|
+---+===+

+===+
|=Q=|
+===+

+---+---+---+---+---+---+---+
| C | I | K | O | Q | S | U |
+---+---+---+---+---+---+---+

==== Alternatives Sortieren kleiner Intervalle ====

Für kleine Arrays (bis zu einer gegebenen Größe K) ist das "Teile und herrsche"-Prinzip nicht die effizienteste Herangehensweise. Insbesondere kann man ein Array mit maximal 3 Elementen direkt sortieren:
def sortThree(a, l, r):
if r > l and a[l+1] < a[l]: # Stelle sicher, dass a[l] und a[l+1] relativ zueinander sortiert sind.
a[l], a[l+1] = a[l+1], a[l]
if r == l + 2:
if a[r] < a[l]: # Stelle sicher, dass a[l] und a[r] relativ zueinander sortiert sind.
a[l], a[r] = a[r], a[l] # Danach ist a[l] auf jeden Fall das kleinste Element.
if a[r] < a[r-1]: # Stelle sicher, dass a[r-1] und a[r] relativ zueinander sortiert sind.
a[r], a[r-1] = a[r-1], a[r] # Jetzt ist a[r] auf jeden Fall das größte Element und das Array damit sortiert.

In die Funktion <tt>quicksort()</tt> wird jetzt ein Aufruf dieser Funktion eingefügt:
if r > l + 2:
# wie bisher
elif r > l:
sortThree(a, l, r)

==== Günstige Selektion des Pivot-Elements ====
Durch geschickte Wahl des Pivot-Elements kann man erreichen, dass der ungünstigste Fall (quadratische Laufzeit) nur mit sehr kleiner Wahrscheinlichkeit eintritt. Zwei Möglichkeiten haben sich bewährt:
# Anstatt des letzten Elements des Teilarrays wählt man ein zufälliges Element (mit Hilfe eines Zufallszahlengenerators). Dadurch wird Quick Sort unempfindlich gegenüber bereits sortierten Arrays, weil die Teilung im Mittel wie bei einem zufällig sortierten Array erfolgt (typischer Fall in obiger Laufzeitberechnung).
# Median (mittlerer Wert) von drei Elementen: Verwende den Median des ersten, mittleren und letzten Elements jedes Teilarrays als Pivot-Element.
In beiden Fällen ist es praktisch ausgeschlossen, dass ein Eingabearray so angeordnet ist, dass in jedem Teilarray gerade das kleinste oder größte Element als Pivot gewählt wird. Nur dann könnte der ungünstigste Fall jedoch eintreten, was somit effektiv verhindert wird.

Greedy-Algorithmen und Dynamische Programmierung

2008-07-22T10:44:45Z

Jschleic: /* Dynamische Programmierung */ Programmierung <-> Optimierung

== Einführung ==
:Viele Probleme sind durch einen Entscheidungsbaum systematisch lösbar.
:Dabei wird die zu suchende Lösung auf den optimalen Weg durch den Entscheidungsbaum reduziert.

=== Beispiel ===
:''Erklärung des Algorithmus ist zu finden in [[Graphen und Graphenalgorithmen]]''
:Traveling Salesman Problem mit 4 Knoten

[[Image:tsm_points.JPG]]

:'''Dabei entsteht folgender Entscheidungsbaum:'''

[[Image:tsm4.JPG]]

::'''Vorteil des Entscheidungsbaums:''' Lösungsmöglichkeiten werden nicht übersehen
::'''Nachteil:''' Eventuell muss der gesamte Baum durchsucht werden (exponentielle Komplexität)
:Um diesen Nachteil auszugleichen gibt es verschiedene Verfahren:
:* Divide & Conquer (Problem auf triviale Teilprobleme zurückführen, welche jeweils einfach zu lösen sind)
:* Greedy Algorithmen
:* Dynamische Programmierung

== Greedy Algorithmen ==
:Greedy (dt. "Gierig") Algorithmen entscheiden an jedem Knoten '''lokal''' über die beste Fortsetzung der Suche,
:d.h. es wird jeweils die beste Entscheidung im Kleinen getroffen - ohne Rücksicht auf Konsequenzen für den gesamten Suchverlauf.

=== Beispiele ===
==== Anwendung beim Traveling Salesman Problem ====
:''Erklärung des Algorithmus ist zu finden in [[Graphen und Graphenalgorithmen]]''
:Reise immer zum nächstgelegenen, noch nicht besuchten Knoten:

[[Image:tsm_greedyb.JPG]]

:In diesem Beispiel wurde eine optimale Lösung gefunden. '''Dies muss im Allgemeinen aber nicht immer der Fall sein!'''

==== Anwendung beim Algorithmus von Kruskal für Minium Spanning Tree ====
:''Erklärung des Algorithmus ist zu finden in [[Graphen und Graphenalgorithmen]]''
:* Sortiere die Kanten nach Gewicht
:* Wähle stets die Kante mit niedrigstem Gewicht (d.h. im Allgemeinen die nächsgelegene), die keinen Zyklus verursacht

:Hierbei wird der Minimum Spanning Tree stets gefunden.

== Dynamische Programmierung ==
(''Programmierung'' bezieht sich hier nicht auf spezielle Programmiersprachen, sondern meint vielmehr die Optimierung des Programmablaufs)

:Oft ist dasselbe Teilproblem in mehreren Pfaden vorhanden.
=== Beispiel ===

[[Image:fib1.JPG]]

:Im Beispiel mit Fibonacci-Zahlen wird Fib(2) gleich dreimal benötigt.

:Zur Erinnerung: Die Fibonacci-Folge <math>(f_0, f_1,\ldots)</math> ist durch das rekursive Bildungsgesetz
:<math> f_n = f_{n-1} + f_{n-2}\ </math>   für <math>n\geq 2</math>
:mit den Anfangswerten
:<math>f_0=0\ </math>   und   <math>f_1=1\ </math>
:definiert.

=== Konzept der Dynamische Programmierung ===
:Jedes Teilproblem soll nur einmal gelöst werden, d.h. einige Knoten werden mehrmals genutzt:

[[Image:fib2.JPG]]

:Wie im Beispiel erkennbar, hat sich die Zahl der Knoten drastisch reduziert (von 9 auf 5).
:Allerdings müssen die '''Graphen jetzt gerichtet''' sein.

:Wenn der neue Graph '''azyklisch''' ist, kann man die Teilprobleme so anordnen, dass jedes
:* nur einmal gelöst wird
:* nur von bereits gelösten Teilproblemen abhängt

:Wenn der Graph nicht azyklisch ist (weil z.B. Teilproblem A die Lösung von Teilproblem B erfordert und umgekehrt),
:ist die Dynamische Programmierung auf dieses Problem nicht anwendbar.

==== Dynamisch programmierter Dijkstra Alrogithmus ====
:''Erklärung des Algorithmus ist zu finden in [[Graphen und Graphenalgorithmen]]''
:Löse Teilprobleme entsprechend ihrer Priorität, d.h. Priorität definiert die Ordnung

:'''Problem:''' Der Suchbaum ist bei diesem Algorithmus ungerichtet

:'''Lösung:''' Die Richtung der Kanten wird festgelegt, wenn man die Nachbarn eines Knotens in die Queue eingefügt
:Wenn man den Abstand vom Start bestimmt (Teilproblem), ist der Abstand von allen näher gelegenen bereits bekannt.

[[Image:dijkstra.JPG]]

== Greedy oder Dynamische Programmierung? ==
:Für viele Probleme gibt es unterschiedliche Entscheidungsräume und/oder unterschiedliche Entscheidungskriterien.
:Ein und dasselbe Problem kann also mit einer der Darstellungen (Greedy, Dynamische Programmierung, weitere...) effizient lösbar sein, mit anderen eventuell nicht.
:Das finden einer geeigneten Darstellung ist also eine zentrale Herausforderung.

== Anwendungsbeispiel: Interval Scheduling ==
:'''gegeben:'''
::Mehrere Aufgaben mit unterschiedlichen Anfangszeiten <math>s_i</math> und Endzeiten <math>f_i</math>.
::Es kann immer nur eine Aufgabe gleichzeitig bearbeitet werden: zwei Aktivitäten sind kompatibel, wenn deren Zeiten sich nicht überlappen.
::<math>a_k\,\text{komp}\, a_j \Leftrightarrow s_k\geq f_j\, \or \, s_j\geq f_k</math>
:'''gesucht:'''
::Arbeitsplan um möglichst viele Aufgaben nacheinander abzuarbeiten.
::Dabei haben alle Aufgaben dieselbe Priorität, obwohl die Dauer oft unterschiedlich ist.

=== Mögliche Lösungsansätze für einen Greedy Algorithmus ===
:# Wähle (unter kompatiblen) die Aktivität, die als erste startet
:# '''Wähle (unter kompatiblen) die Aktivität, die als erste endet (oder: die als letzte startet)'''
:# Wähle (unter kompatiblen) die Aktivität, die am kürzesten dauert
:# Wähle (unter kompatiblen) die Aktivität, die die wenigsten Inkompatibilitäten (überlappungen mit anderen Aktivitäten) hat

'''Ungünstige Ansätze:'''
:In den folgenden Beispielen werden die Aktivitäten mit | als Anfangs- bzw Endzeit markiert, --- steht für den Verlauf einer Aktivität.
:Weiter rechts bedeutet später in der Zeit.
:'''Gegenbeispiel zu 1.'''
<math>L_1=</math> |--| |--| |--| |--|
<math>L_2=</math>|---------------------|
<math>|L_1|</math>=4 <math>|L_2|</math>=1
:Der Ansatz würde Lösung 2 wählen, da die lange Aktivität am frühesten beginnt. Es wird dann nur 1 statt der optimalen 4 abgearbeitet.
:'''Gegenbeispiel zu 3.'''
<math>L_1=</math>|---------| |---------|
<math>L_2=</math> |----|
<math>|L_1|</math>=2 <math>|L_2|</math>=1
:Der Ansatz würde Lösung 2 wählen, da die mittlere Aktivität am kürzesten dauert. Es wird dann nur 1 statt der optimalen 2 abgearbeitet.
:'''Gegenbeispiel zu 4. (Anzahl der Inkompatibilitäten stehen jeweils in der Mitte der Aktivität)'''
|-3-| |-4-| |-4-| |-3-|
|-4-| |-2-| |-4-|
|-4-| |-4-|
|-4-| |-4-|
:Der Ansatz würde erst die mit 2, dann die beiden mit 3 Inkompatibilitäten wählen. Es werden dann nur 3 statt der optimalen 4 (obere Zeile) abgearbeitet.

Es verbleibt der 2. Ansatz, dessen Optimalität noch zu beweisen ist...

== Greedy Stays Ahead ==
==== Idee der Beweismethode ====
'''Es genügt zu zeigen:'''
:die Greedy-Lösung ist nicht schlechter als die optimale Lösung

=== Beweis der Optimalität des 2. Ansatzes mit ''Greedy Stays Ahead'' ===
==== Ansatz ====
:Wähle (unter kompatiblen) die Aktivität, die als erste endet (oder: die als letzte startet)
:Die Wahl dieses Ansatzes sei <math>U={i_1,...,i_k}</math>.
:Eine (unbekannte) optimale Lösung sei <math>O={j_1,...,j_m}</math>.

==== Ziel ====
:Die Lösung des Ansatzes soll genausoviele Aktivitäten schaffen wie die optimale Lösung (d.h. k=m)
==== Voraussetzungen ====
:* Sortiere <math>i_1,...,i_k</math> nach aufsteigender Endzeit <math>f_i</math>
:* Sortiere <math>j_1,...,j_m</math> nach aufsteigender Endzeit <math>f_j</math>

(Da die Aktivitäten kompatibel sind, werden die Anfangszeiten automatisch auch sortiert)

==== Schritt 1 ====
:Für die Indizes <math>p\leq r</math> (inbesondere <math>p=r</math>) gilt: <math>f(i_p)\leq f(j_r)</math>
==== Beweis durch vollständige Induktion ====
:'''Induktions-Anfang:'''
::<math>f(i_1)\leq f(j_1)</math>, da <math>i_1</math> die erste Aktivität ist, die überhaupt endet
:'''Induktions-Voraussetzung:'''
::<math>f(i_{r-1})\leq f(j_{r-1})</math>
:'''Induktions-Schritt:'''
::Wegen Kompatibilität gilt:
::<math>f(j_{r-1})\leq s(j_r)</math>
::=> <math>f(i_{r-1})\leq s(i_r)</math>
::=> Die Greedy Strategie ''kann'' Aktivität <math>j_r</math> wählen, denn sie ist kompatibel mit <math>i_{r-1}</math>
::* Wenn die Greedy Strategie tatsächlich <math>j_r</math> wählt, folgt daraus:
:::<math>f(i_r)=f(j_r)</math>
::* Wenn nicht, kann nur gelten:
:::<math>f(i_r)\leq f(j_r)</math>

==== Schritt 2 ====
:Zu zeigen: <math>k=m</math>
==== Beweis durch Widerspruchsannahme ====
:* Falls <math>m<k</math>, wäre die Lösung der Strategie besser als die optimale.
:* Angenommen <math>m>k</math>, dann enthält <math>O</math> eine Aktivität <math>j_{k+1}</math>.

:Nach Schritt 1 gilt:
::<math>f(i_k)\leq f(j_k)\leq f(j_{k+1})</math>

:Wegen Kompatibilität gilt aber:
::<math>s(j_{k+1})\geq f(j_k)\geq f(i_k)</math>
:-> Die Greedy Strategie hätte also noch die Aktivität <math>j_{k+1}</math> wählen können.
:-> Widerspruch zur Annahme, dass die Greedy Strategie durchgelaufen ist, bis keine Aktivität mehr hinzugefügt werden kann
:-> m>k ist falsch
:-> m=k ist richtig

=== Beispiel zur Dynamischen Programmierung: Weighted Intervall Scheduling ===
:Die Problemstellung ähnelt dem des normalen Intervall Scheduling, hier haben die Aktivitäten aber Gewichte <math>w_i</math>
:(z.B. Bringt eine längere Aufgabe in einem Übunsgzettel in der Regel auch mehr Punkte, d.h. sie hat eine hohe Gewichtung)
==== Ziel ====
:Wähle die Aktivitäten so, dass der Gewinn (Summe der Gewichtungen der bearbeiteten Aktivitäten) maximal wird.
==== Ansatz ====
:* Sortiere Aktivitäten nach ihrer Endzeit.
:* Definiere eine Funktion <math>p(i)</math>, welche für die Aktivität steht, die vor <math>a_i</math> endet, mit <math>a_i</math> kompatibel ist, unter allen Aktivitäten mit diesen Eigenschaften die letzte (d.h. mit der spätesten Endzeit) ist.

In folgendem Beispiel wird die Aktivität <math>a_i</math> mit der Symbolik |-!-| betrachtet um deren p-Funktion zu evaluieren.

Für die p-Funktion kommen lediglich die Funktionen mit der Symbolik |===| und |====| in Frage, die untere der beiden ist die gesuchte Aktivität.
|====| |-!-| |--|
|===| |-----| |----|

:Trivial ist, dass <math>a_n</math> entweder zur Lösung gehört, oder nicht:

[[Image:wis1.JPG]]

:Dadurch ergibt sich folgende Funktion:
:<math>OPT(n)=\begin{cases}
\ \;\, \{a_n\}\cup OPT(p(n))\\
\ \;\, OPT(a_{n-1})
\end{cases}
</math>

:Um den höchstmöglichen Gewinn zu erzielen, wird <math>\{a_n\}\cup OPT(p(n))</math> verwendet falls gilt:
:<math>w_n + Gewinn(OPT(p(n))\leq Gewinn(OPT(n-1))</math>

:Ansonsten wird <math>OPT(a_{n-1})</math> angewandt.

== Erinnerung: Intervalle ==

[[Image:bild1.JPG]]

Sortiere Intervalle nach aufsteigender <math> f_{i} </math>:
:Gewinn <math>(a_{n})</math> = max <math>(w_{n})</math> + Gewinn (p(n)), Gewinn <math> (a_{n-1})</math>
:Gewinn <math> (a_{n-1})</math> = max (<math>w_{n-1}</math> + Gewinn <math>(p(n-1)</math>), Gewinn <math> (a_{n-2})</math>
:usw.

[[Image:bild2.JPG]]

Bearbeite Teilprobleme in Reihenfolge der Sortierung
:=> azyklischer Graph
:(a2 hängt von a1 ab, a3 von a2, a4 von a2 und a3 usw.)

Wie erkennt man, ob der Graph azyklisch ist, und wie fndet man die Reihenfolge?
* azyklischer, gerichteter Graph: „directed acyclic graph“ – DAG
* Ein Graph ist genau dann ein DAG, wenn es eine topologische Sortierung der Knoten gibt.
:Def.: Zeichne die Knoten so auf eine Gerade, dass alle Kanten nach rechts/in dieselbe Richtung zeigen

[[Image:bild3.JPG]]

:=> arbeite topologische Sortierung von rechts nach links ab.

=== Beispiel ===
Wie erklärt man einem zerstreuten Professor, wie er sich morgens anziehen soll?

[[Image:bild4.JPG]]

:=> Die topologische Sortierung ist hier nicht eindeutig, z.B. ist nicht klar, ob zuerst die Strümpfe angezogen werden sollen oder die Unterhose. Wann die Uhr angelegt werden soll, ist überhaupt nicht festgelegt. Mit dieser Beschreibung käme der arme Professor wohl kaum zurecht.

[[Image:bild5.JPG]]

== Zwei Algorithmen zum Finden der topologischen Sortierung ==

=== 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 vorhandenen Knoten (also 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]]

Bild: Ein zyklischer Graph

=== Algorithmus 2 ===
Verwende Tiefensuche, um die Finishing Time zu bestimmen
: => zeichne Knoten nach abnehmender Finishing Time auf die Gerade

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

[[Image:bild7.JPG]]

Fälle:
# Matche a[i] mit b[j]. Falls a[i] == b[j], ist das gut. Andernfalls entstehen Kosten <math>K_{a[i], b[j]}</math>
# Wir überspringen a[i] oder b[j], => Kosten L

:gesucht: Alignment mit minimalen Kosten

[[Image:bild8.JPG]]

Lösung:
:Suche kürzesten Pfad von links oben nach rechts unten (z.B. mit dem [[Graphen und Graphenalgorithmen#Algorithmus von Dijkstra|Algorithmus von Dijkstra]])
:In unserem Beispiel von oben:

[[Image:bild9.JPG]]

=== Problemlösung durch einen Entscheidungsbaum ===
Greedy Algorithm und dynamische Programmierung:
Transformationen des Problems, sodass '''nicht''' der ganze Entscheidungsbaum durchlaufen werden muss.
=> effizient

* bei vielen Problemen ist keine Möglichkeit bekannt, das vollständige Durchlaufen des Entscheidungsbaumes zu vermeiden, z.B. [[Graphen_und_Graphenalgorithmen#Problem_des_Handlungsreisenden | Problem des Handlungsreisenden]] (TSP), 3-SAT
* Frage: Gibt es prinzipiell keinen effizienten Algorithmus, oder sind wir nur zu blöd?
* Derzeitiger Stand: viele dieser Probleme sind fundamental äquivalent „NP complete problems“ – „NP vollständig“ (NP = "nicht-deterministisch polynomiell")

Greedy-Algorithmen und Dynamische Programmierung

2008-07-22T10:41:37Z

Jschleic: /* Problemlösung durch einen Entscheidungsbaum */ Link korrigiert

== Einführung ==
:Viele Probleme sind durch einen Entscheidungsbaum systematisch lösbar.
:Dabei wird die zu suchende Lösung auf den optimalen Weg durch den Entscheidungsbaum reduziert.

=== Beispiel ===
:''Erklärung des Algorithmus ist zu finden in [[Graphen und Graphenalgorithmen]]''
:Traveling Salesman Problem mit 4 Knoten

[[Image:tsm_points.JPG]]

:'''Dabei entsteht folgender Entscheidungsbaum:'''

[[Image:tsm4.JPG]]

::'''Vorteil des Entscheidungsbaums:''' Lösungsmöglichkeiten werden nicht übersehen
::'''Nachteil:''' Eventuell muss der gesamte Baum durchsucht werden (exponentielle Komplexität)
:Um diesen Nachteil auszugleichen gibt es verschiedene Verfahren:
:* Divide & Conquer (Problem auf triviale Teilprobleme zurückführen, welche jeweils einfach zu lösen sind)
:* Greedy Algorithmen
:* Dynamische Programmierung

== Greedy Algorithmen ==
:Greedy (dt. "Gierig") Algorithmen entscheiden an jedem Knoten '''lokal''' über die beste Fortsetzung der Suche,
:d.h. es wird jeweils die beste Entscheidung im Kleinen getroffen - ohne Rücksicht auf Konsequenzen für den gesamten Suchverlauf.

=== Beispiele ===
==== Anwendung beim Traveling Salesman Problem ====
:''Erklärung des Algorithmus ist zu finden in [[Graphen und Graphenalgorithmen]]''
:Reise immer zum nächstgelegenen, noch nicht besuchten Knoten:

[[Image:tsm_greedyb.JPG]]

:In diesem Beispiel wurde eine optimale Lösung gefunden. '''Dies muss im Allgemeinen aber nicht immer der Fall sein!'''

==== Anwendung beim Algorithmus von Kruskal für Minium Spanning Tree ====
:''Erklärung des Algorithmus ist zu finden in [[Graphen und Graphenalgorithmen]]''
:* Sortiere die Kanten nach Gewicht
:* Wähle stets die Kante mit niedrigstem Gewicht (d.h. im Allgemeinen die nächsgelegene), die keinen Zyklus verursacht

:Hierbei wird der Minimum Spanning Tree stets gefunden.

== Dynamische Programmierung ==
(''Programmierung'' hat hier eine Bedeutung die sich nicht auf Programmiersprachen bezieht)

:Oft ist dasselbe Teilproblem in mehreren Pfaden vorhanden.
=== Beispiel ===

[[Image:fib1.JPG]]

:Im Beispiel mit Fibonacci-Zahlen wird Fib(2) gleich dreimal benötigt.

:Zur Erinnerung: Die Fibonacci-Folge <math>(f_0, f_1,\ldots)</math> ist durch das rekursive Bildungsgesetz
:<math> f_n = f_{n-1} + f_{n-2}\ </math>   für <math>n\geq 2</math>
:mit den Anfangswerten
:<math>f_0=0\ </math>   und   <math>f_1=1\ </math>
:definiert.

=== Konzept der Dynamische Programmierung ===
:Jedes Teilproblem soll nur einmal gelöst werden, d.h. einige Knoten werden mehrmals genutzt:

[[Image:fib2.JPG]]

:Wie im Beispiel erkennbar, hat sich die Zahl der Knoten drastisch reduziert (von 9 auf 5).
:Allerdings müssen die '''Graphen jetzt gerichtet''' sein.

:Wenn der neue Graph '''azyklisch''' ist, kann man die Teilprobleme so anordnen, dass jedes
:* nur einmal gelöst wird
:* nur von bereits gelösten Teilproblemen abhängt

:Wenn der Graph nicht azyklisch ist (weil z.B. Teilproblem A die Lösung von Teilproblem B erfordert und umgekehrt),
:ist die Dynamische Programmierung auf dieses Problem nicht anwendbar.

==== Dynamisch programmierter Dijkstra Alrogithmus ====
:''Erklärung des Algorithmus ist zu finden in [[Graphen und Graphenalgorithmen]]''
:Löse Teilprobleme entsprechend ihrer Priorität, d.h. Priorität definiert die Ordnung

:'''Problem:''' Der Suchbaum ist bei diesem Algorithmus ungerichtet

:'''Lösung:''' Die Richtung der Kanten wird festgelegt, wenn man die Nachbarn eines Knotens in die Queue eingefügt
:Wenn man den Abstand vom Start bestimmt (Teilproblem), ist der Abstand von allen näher gelegenen bereits bekannt.

[[Image:dijkstra.JPG]]

== Greedy oder Dynamische Programmierung? ==
:Für viele Probleme gibt es unterschiedliche Entscheidungsräume und/oder unterschiedliche Entscheidungskriterien.
:Ein und dasselbe Problem kann also mit einer der Darstellungen (Greedy, Dynamische Programmierung, weitere...) effizient lösbar sein, mit anderen eventuell nicht.
:Das finden einer geeigneten Darstellung ist also eine zentrale Herausforderung.

== Anwendungsbeispiel: Interval Scheduling ==
:'''gegeben:'''
::Mehrere Aufgaben mit unterschiedlichen Anfangszeiten <math>s_i</math> und Endzeiten <math>f_i</math>.
::Es kann immer nur eine Aufgabe gleichzeitig bearbeitet werden: zwei Aktivitäten sind kompatibel, wenn deren Zeiten sich nicht überlappen.
::<math>a_k\,\text{komp}\, a_j \Leftrightarrow s_k\geq f_j\, \or \, s_j\geq f_k</math>
:'''gesucht:'''
::Arbeitsplan um möglichst viele Aufgaben nacheinander abzuarbeiten.
::Dabei haben alle Aufgaben dieselbe Priorität, obwohl die Dauer oft unterschiedlich ist.

=== Mögliche Lösungsansätze für einen Greedy Algorithmus ===
:# Wähle (unter kompatiblen) die Aktivität, die als erste startet
:# '''Wähle (unter kompatiblen) die Aktivität, die als erste endet (oder: die als letzte startet)'''
:# Wähle (unter kompatiblen) die Aktivität, die am kürzesten dauert
:# Wähle (unter kompatiblen) die Aktivität, die die wenigsten Inkompatibilitäten (überlappungen mit anderen Aktivitäten) hat

'''Ungünstige Ansätze:'''
:In den folgenden Beispielen werden die Aktivitäten mit | als Anfangs- bzw Endzeit markiert, --- steht für den Verlauf einer Aktivität.
:Weiter rechts bedeutet später in der Zeit.
:'''Gegenbeispiel zu 1.'''
<math>L_1=</math> |--| |--| |--| |--|
<math>L_2=</math>|---------------------|
<math>|L_1|</math>=4 <math>|L_2|</math>=1
:Der Ansatz würde Lösung 2 wählen, da die lange Aktivität am frühesten beginnt. Es wird dann nur 1 statt der optimalen 4 abgearbeitet.
:'''Gegenbeispiel zu 3.'''
<math>L_1=</math>|---------| |---------|
<math>L_2=</math> |----|
<math>|L_1|</math>=2 <math>|L_2|</math>=1
:Der Ansatz würde Lösung 2 wählen, da die mittlere Aktivität am kürzesten dauert. Es wird dann nur 1 statt der optimalen 2 abgearbeitet.
:'''Gegenbeispiel zu 4. (Anzahl der Inkompatibilitäten stehen jeweils in der Mitte der Aktivität)'''
|-3-| |-4-| |-4-| |-3-|
|-4-| |-2-| |-4-|
|-4-| |-4-|
|-4-| |-4-|
:Der Ansatz würde erst die mit 2, dann die beiden mit 3 Inkompatibilitäten wählen. Es werden dann nur 3 statt der optimalen 4 (obere Zeile) abgearbeitet.

Es verbleibt der 2. Ansatz, dessen Optimalität noch zu beweisen ist...

== Greedy Stays Ahead ==
==== Idee der Beweismethode ====
'''Es genügt zu zeigen:'''
:die Greedy-Lösung ist nicht schlechter als die optimale Lösung

=== Beweis der Optimalität des 2. Ansatzes mit ''Greedy Stays Ahead'' ===
==== Ansatz ====
:Wähle (unter kompatiblen) die Aktivität, die als erste endet (oder: die als letzte startet)
:Die Wahl dieses Ansatzes sei <math>U={i_1,...,i_k}</math>.
:Eine (unbekannte) optimale Lösung sei <math>O={j_1,...,j_m}</math>.

==== Ziel ====
:Die Lösung des Ansatzes soll genausoviele Aktivitäten schaffen wie die optimale Lösung (d.h. k=m)
==== Voraussetzungen ====
:* Sortiere <math>i_1,...,i_k</math> nach aufsteigender Endzeit <math>f_i</math>
:* Sortiere <math>j_1,...,j_m</math> nach aufsteigender Endzeit <math>f_j</math>

(Da die Aktivitäten kompatibel sind, werden die Anfangszeiten automatisch auch sortiert)

==== Schritt 1 ====
:Für die Indizes <math>p\leq r</math> (inbesondere <math>p=r</math>) gilt: <math>f(i_p)\leq f(j_r)</math>
==== Beweis durch vollständige Induktion ====
:'''Induktions-Anfang:'''
::<math>f(i_1)\leq f(j_1)</math>, da <math>i_1</math> die erste Aktivität ist, die überhaupt endet
:'''Induktions-Voraussetzung:'''
::<math>f(i_{r-1})\leq f(j_{r-1})</math>
:'''Induktions-Schritt:'''
::Wegen Kompatibilität gilt:
::<math>f(j_{r-1})\leq s(j_r)</math>
::=> <math>f(i_{r-1})\leq s(i_r)</math>
::=> Die Greedy Strategie ''kann'' Aktivität <math>j_r</math> wählen, denn sie ist kompatibel mit <math>i_{r-1}</math>
::* Wenn die Greedy Strategie tatsächlich <math>j_r</math> wählt, folgt daraus:
:::<math>f(i_r)=f(j_r)</math>
::* Wenn nicht, kann nur gelten:
:::<math>f(i_r)\leq f(j_r)</math>

==== Schritt 2 ====
:Zu zeigen: <math>k=m</math>
==== Beweis durch Widerspruchsannahme ====
:* Falls <math>m<k</math>, wäre die Lösung der Strategie besser als die optimale.
:* Angenommen <math>m>k</math>, dann enthält <math>O</math> eine Aktivität <math>j_{k+1}</math>.

:Nach Schritt 1 gilt:
::<math>f(i_k)\leq f(j_k)\leq f(j_{k+1})</math>

:Wegen Kompatibilität gilt aber:
::<math>s(j_{k+1})\geq f(j_k)\geq f(i_k)</math>
:-> Die Greedy Strategie hätte also noch die Aktivität <math>j_{k+1}</math> wählen können.
:-> Widerspruch zur Annahme, dass die Greedy Strategie durchgelaufen ist, bis keine Aktivität mehr hinzugefügt werden kann
:-> m>k ist falsch
:-> m=k ist richtig

=== Beispiel zur Dynamischen Programmierung: Weighted Intervall Scheduling ===
:Die Problemstellung ähnelt dem des normalen Intervall Scheduling, hier haben die Aktivitäten aber Gewichte <math>w_i</math>
:(z.B. Bringt eine längere Aufgabe in einem Übunsgzettel in der Regel auch mehr Punkte, d.h. sie hat eine hohe Gewichtung)
==== Ziel ====
:Wähle die Aktivitäten so, dass der Gewinn (Summe der Gewichtungen der bearbeiteten Aktivitäten) maximal wird.
==== Ansatz ====
:* Sortiere Aktivitäten nach ihrer Endzeit.
:* Definiere eine Funktion <math>p(i)</math>, welche für die Aktivität steht, die vor <math>a_i</math> endet, mit <math>a_i</math> kompatibel ist, unter allen Aktivitäten mit diesen Eigenschaften die letzte (d.h. mit der spätesten Endzeit) ist.

In folgendem Beispiel wird die Aktivität <math>a_i</math> mit der Symbolik |-!-| betrachtet um deren p-Funktion zu evaluieren.

Für die p-Funktion kommen lediglich die Funktionen mit der Symbolik |===| und |====| in Frage, die untere der beiden ist die gesuchte Aktivität.
|====| |-!-| |--|
|===| |-----| |----|

:Trivial ist, dass <math>a_n</math> entweder zur Lösung gehört, oder nicht:

[[Image:wis1.JPG]]

:Dadurch ergibt sich folgende Funktion:
:<math>OPT(n)=\begin{cases}
\ \;\, \{a_n\}\cup OPT(p(n))\\
\ \;\, OPT(a_{n-1})
\end{cases}
</math>

:Um den höchstmöglichen Gewinn zu erzielen, wird <math>\{a_n\}\cup OPT(p(n))</math> verwendet falls gilt:
:<math>w_n + Gewinn(OPT(p(n))\leq Gewinn(OPT(n-1))</math>

:Ansonsten wird <math>OPT(a_{n-1})</math> angewandt.

== Erinnerung: Intervalle ==

[[Image:bild1.JPG]]

Sortiere Intervalle nach aufsteigender <math> f_{i} </math>:
:Gewinn <math>(a_{n})</math> = max <math>(w_{n})</math> + Gewinn (p(n)), Gewinn <math> (a_{n-1})</math>
:Gewinn <math> (a_{n-1})</math> = max (<math>w_{n-1}</math> + Gewinn <math>(p(n-1)</math>), Gewinn <math> (a_{n-2})</math>
:usw.

[[Image:bild2.JPG]]

Bearbeite Teilprobleme in Reihenfolge der Sortierung
:=> azyklischer Graph
:(a2 hängt von a1 ab, a3 von a2, a4 von a2 und a3 usw.)

Wie erkennt man, ob der Graph azyklisch ist, und wie fndet man die Reihenfolge?
* azyklischer, gerichteter Graph: „directed acyclic graph“ – DAG
* Ein Graph ist genau dann ein DAG, wenn es eine topologische Sortierung der Knoten gibt.
:Def.: Zeichne die Knoten so auf eine Gerade, dass alle Kanten nach rechts/in dieselbe Richtung zeigen

[[Image:bild3.JPG]]

:=> arbeite topologische Sortierung von rechts nach links ab.

=== Beispiel ===
Wie erklärt man einem zerstreuten Professor, wie er sich morgens anziehen soll?

[[Image:bild4.JPG]]

:=> Die topologische Sortierung ist hier nicht eindeutig, z.B. ist nicht klar, ob zuerst die Strümpfe angezogen werden sollen oder die Unterhose. Wann die Uhr angelegt werden soll, ist überhaupt nicht festgelegt. Mit dieser Beschreibung käme der arme Professor wohl kaum zurecht.

[[Image:bild5.JPG]]

== Zwei Algorithmen zum Finden der topologischen Sortierung ==

=== 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 vorhandenen Knoten (also 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]]

Bild: Ein zyklischer Graph

=== Algorithmus 2 ===
Verwende Tiefensuche, um die Finishing Time zu bestimmen
: => zeichne Knoten nach abnehmender Finishing Time auf die Gerade

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

[[Image:bild7.JPG]]

Fälle:
# Matche a[i] mit b[j]. Falls a[i] == b[j], ist das gut. Andernfalls entstehen Kosten <math>K_{a[i], b[j]}</math>
# Wir überspringen a[i] oder b[j], => Kosten L

:gesucht: Alignment mit minimalen Kosten

[[Image:bild8.JPG]]

Lösung:
:Suche kürzesten Pfad von links oben nach rechts unten (z.B. mit dem [[Graphen und Graphenalgorithmen#Algorithmus von Dijkstra|Algorithmus von Dijkstra]])
:In unserem Beispiel von oben:

[[Image:bild9.JPG]]

=== Problemlösung durch einen Entscheidungsbaum ===
Greedy Algorithm und dynamische Programmierung:
Transformationen des Problems, sodass '''nicht''' der ganze Entscheidungsbaum durchlaufen werden muss.
=> effizient

* bei vielen Problemen ist keine Möglichkeit bekannt, das vollständige Durchlaufen des Entscheidungsbaumes zu vermeiden, z.B. [[Graphen_und_Graphenalgorithmen#Problem_des_Handlungsreisenden | Problem des Handlungsreisenden]] (TSP), 3-SAT
* Frage: Gibt es prinzipiell keinen effizienten Algorithmus, oder sind wir nur zu blöd?
* Derzeitiger Stand: viele dieser Probleme sind fundamental äquivalent „NP complete problems“ – „NP vollständig“ (NP = "nicht-deterministisch polynomiell")

Randomisierte Algorithmen

2008-07-22T10:35:52Z

Jschleic: /* Mersenne Twister */

== 1. Randomisierte Algorithmen ==

'''Def.:''' Algorithmen, die bei Entscheidung oder bei der Wahl der Parameter Zufallszahlen benutzen

'''Bsp.:''' Lösen des K-SAT-Problems durch RA
geg.: logischer Ausdruck in K-CNF (n Variablen, m Klauseln, k Variablen pro Klausel)

<math>\underbrace {\underbrace {\left(x_1 \vee x_3 \vee...\right)}_{k\; Variablen} \wedge \left( x_2 \vee x_4 \vee...\right)}_{m\;Klauseln}</math>

for i in range (trials): #Anzahl der Versuche
#Bestimme eine Zufallsbelegung des <math>\{ x_i \}</math>:
for j in range (steps):
if <math>\{ x_i \}</math> erfüllt alle Klauseln: return <math>\{ x_i \}</math>
#wähle zufällig eine Klausel, die nicht erfüllt ist und negiere zufällig eine der Variablen in dieser Klausel
(die Klausel ist jetzt erfüllt)
return None

Eigenschaft: falls <math>k>2</math> : steps *trials <math>\in O\left(\Alpha^n \right) \Alpha >1</math>

z.B. <math>k=3</math> steps=3*n, trials=<math>\left(\frac{4}3\right)^n</math>

aber: bei <math>k=2</math> sind im Mittel nur steps=<math>O\left(n^2\right)</math> nötig, trials=<math>O\left(1\right)</math>

----

'''-Zufallsbelegung hat <math>t\leq n</math> richtige Variablen (im Mittel <math>t\approx \frac {n} 2</math>)'''

Negieren einer Variable ändert t um 1,
u.Z. <math>t\rightarrow t+1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac 1 k</math>)
::::::::::<math>t\rightarrow t-1</math> mit Wahrscheinlichkeit <math>\frac 1 2</math> ::(für beliebiges k: <math>\frac {k-1} k</math>)

'''-Wieviele Schritte braucht man im Mittel, um zu einer Lösung mit t Richtigen zu kommen?'''

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

<math>S\left(n\right)=0</math> #Abbruchbedingung der Schleife

<math>S\left(0\right) = S\left( 1\right) + 1 \Longrightarrow S\left(t\right) = n^2-t^2</math>

'''Probe:''' <math>S\left(n\right)=n^2-n^2=0</math>

<math>S\left(0\right) =n^2-0^2</math>

<math>=S\left(1\right)+1</math>

<math>\;=n^2-1^2+1</math>

<math>\;=n^2</math>
<math>S\left(t\right)=\frac 1 2 \left(n^2-\left(t-1\right)^2\right) + \frac 1 2 \left(n^2-\left(t+1\right)^2\right)+1</math>

<math>=\frac 1 2 n^2-\frac 1 2 \left( t^2-2t+1\right) + \frac 1 2 n^2-\frac 1 2</math>

<math>=\left(t^2+2t+1\right)</math>

<math>\;=n^2-t^2</math>

'''Das ist das Random Walk Problem'''

Im ungünstigsten Fall (t=0) werden im Mittel <math>n^2</math> Schritte benötigt, um durch random walk nach t=n zu gelangen.

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

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

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

'''Messpunkte:'''

übliche Lösung: Methode der kleinsten Quadrate

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

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

'''Lineares Gleichungssystem'''

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

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

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

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

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

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

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

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

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

----

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

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

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

RANSAC-Algorithmus

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

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

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

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

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

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

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

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

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

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

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

:::*Lösung:

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

:::*speziell:

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

----

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

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

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

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

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

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

== ''' Zufallszahlen ''' ==

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

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

\end{array}</math>

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

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

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

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

\end{array}</math>

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

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

\end{array}</math>

::stark geclustert ist.

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

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

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

\end{array}</math>

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

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

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

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

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

* schnell

class Random:
def __init__(self, seed):
self.N = 624
self.state = [0]*624
self.state = zufällig mit Hilfe des ''seeds'' initialisieren (einfacher ZZG)
self.i = 0 # zählt mit in welchem Zustand wir gerade aufhalten

def __call__(self):
N,M = 624, 397
i = self.i
r = (self.state[i] & 0x80000000)|(self.state[(i+1)%N] & 0x7FFFFFFF) # aktualisieren
if self.state[(i+1)%N]&1: # des Zustands
r^= 0x9908B0DF
self.state[i] = self.state[(i+1)%N]*^r

y = self.state[i]
self.i = (self.i + 1)%N
# bits verwürfeln
y ^= (y>>11)
y ^= ((y>>7) & 0x9D2C5680)
y ^= ((y>>15) & 0xEFC60000)
y ^= (y>>18)
return y

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

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

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

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

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

|}

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

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

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

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

Container

2008-07-22T09:26:13Z

Jschleic: /* Beispiele */ Gliederung

der Begriff '''Container''' stammt ursprünglich aus der Schiffahrt,
Container kann mehrere Bedeutungen annehmen.

'''in der Schifffahrt''': 
Behälter der Güter lagern und transportieren kann.

'''in der Datenverarbeitung''': 
- '''Computertechnik''': eine Dateiformat die verschiedenartige Datenformate enthalten kann. (siehe [http://de.wikipedia.org/wiki/Containerformat Containerformat]) 
- '''Server''': Teil einer Server-Software und Enterprise Java Beans (EJB) verwaltet. Der Container speichert die Daten und prüft die Verfügbarkeit für jeden autorisierten Client. (siehe [http://de.wikipedia.org/wiki/EJB-Container EJB-Container]) 
- '''in Programmiersprachen''': Einige Programmiersprachen wie Java oder C++ verfügen über Containerklassen. In C++ sind sie in der Stardbibliothek [http://de.wikipedia.org/wiki/C%2B%2B-Standardbibliothek C++Standardbibliothek] 
- '''in der Informatik''' (und bei uns in der Vorlesung): ein abstraktes Objekt, das Elemente des gleichen Typs speichert (Array, Liste, Dictionary,...) siehe auch [http://de.wikipedia.org/wiki/Datenstruktur Datenstrukturen]

==Mögliche Operationen==

Welche Operationen hätte man denn gerne bei einer solchen Container-Datenstruktur?
Was benötigen Algorithmen häufig? Wie sollten die Daten organisiert sein, damit Algorithmen effizient damit arbeiten können? 
Eine solche Anforderungsanalyse ist sehr aufwendig und kann sich über Jahre erstrecken, weil Erfahrungen gesammelt werden müssen, welche Anforderungen an Datenstrukturen in vielen Algorithmen immer wieder auftreten. 
Wir listen im folgenden nur das Resultat, also die wichtigsten Operationen von Container-Datenstrukturen auf.

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)
|-
|'''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 im Kapitel [[Hashing und assoziative Arrays]].
===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 belibiebige 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, die 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 kleinsten 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

2008-07-22T09:14:56Z

Jschleic: Gliederung

der Begriff '''Container''' stammt ursprünglich aus der Schiffahrt,
Container kann mehrere Bedeutungen annehmen.

'''in der Schifffahrt''': 
Behälter der Güter lagern und transportieren kann.

'''in der Datenverarbeitung''': 
- '''Computertechnik''': eine Dateiformat die verschiedenartige Datenformate enthalten kann. (siehe [http://de.wikipedia.org/wiki/Containerformat Containerformat]) 
- '''Server''': Teil einer Server-Software und Enterprise Java Beans (EJB) verwaltet. Der Container speichert die Daten und prüft die Verfügbarkeit für jeden autorisierten Client. (siehe [http://de.wikipedia.org/wiki/EJB-Container EJB-Container]) 
- '''in Programmiersprachen''': Einige Programmiersprachen wie Java oder C++ verfügen über Containerklassen. In C++ sind sie in der Stardbibliothek [http://de.wikipedia.org/wiki/C%2B%2B-Standardbibliothek C++Standardbibliothek] 
- '''in der Informatik''' (und bei uns in der Vorlesung): ein abstraktes Objekt, das Elemente des gleichen Typs speichert (Array, Liste, Dictionary,...) siehe auch [http://de.wikipedia.org/wiki/Datenstruktur Datenstrukturen]

==Mögliche Operationen==

Welche Operationen hätte man denn gerne bei einer solchen Container-Datenstruktur?
Was benötigen Algorithmen häufig? Wie sollten die Daten organisiert sein, damit Algorithmen effizient damit arbeiten können? 
Eine solche Anforderungsanalyse ist sehr aufwendig und kann sich über Jahre erstrecken, weil Erfahrungen gesammelt werden müssen, welche Anforderungen an Datenstrukturen in vielen Algorithmen immer wieder auftreten. 
Wir listen im folgenden nur das Resultat, also die wichtigsten Operationen von Container-Datenstrukturen auf.

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)
|-
|'''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.

;'''(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 im Kapitel [[Hashing und assoziative Arrays]].
;'''(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 belibiebige 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()
;'''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) 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]].
;'''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, die 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 kleinsten 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]].

Effizienz

2008-07-22T09:03:31Z

Jschleic: typo

Bei der Diskussion von Effizienz müssen wir zwischen der Laufzeit eines Algorithmus auf einem bestimmten System und seiner prinzipiellen Leistungsfähigkeit (Algorithmenkomplexität) unterscheiden. Der Benutzer ist natürlich vor allem an der Laufzeit interessiert, denn diese bestimmt letztendlich seine Arbeitsproduktivität. Ein Softwaredesigner hingegen muss eine Implementation wählen, die auf verschiedenen Systemen und in verschiedenen Anwendungen schnell ist. Für ihn sind daher auch Aussagen zur Algorithmenkomplexität sehr wichtig, um den am besten geeigneten Algorithmus auszuwählen.

== Laufzeit ==

Aus Anwendersicht ist ein Algorithmus effizient, wenn er die in der Spezifikation verlangten Laufzeitgrenzen einhält. Ein Algorithmus muss also nicht immer so schnell wie möglich sein, sondern so schnell wie nötig. Dies führt in verschiedenen Anwendungen zu ganz unterschiedliche Laufzeitanforderungen:

* Berechnen des nächsten Steuerkommandos für eine Maschine: ca. 1/1000s
* Berechnen des nächsten Bildes für eine Videopräsentation (z.B. Dekompression von MPEG-kodierten Bildern): ca. 1/25s
: Geringere Bildraten führen zu ruckeligen Filmen.
* Sichtbare Antwort auf ein interaktives Kommando (z.B. Mausklick): ca. 1/2s
: Wird diese Antwortzeit überschritten, vermuten viele Benutzer, dass der Mausklick nicht funktioniert hat, und klicken nochmals, mit eventuell fatalen Folgen. Wenn ein Algorithmus notwendigerweise länger dauert als 1/2s, sollte ein Fortschrittsbalken angezeigt werden.
* Wettervorhersage: muss spätestens am Vorabend des vorhergesagten Tages beendet sein

===Laufzeitvergleich===

Da die Laufzeit für den Benutzer ein so wichtiges Kriterium ist, werden häufig Laufzeitvergleiche durchgeführt. Deren Ergebnisse hängen allerdings von vielen Faktoren ab, die möglicherweise nicht kontrollierbar sind:
* Geschwindigkeit und Anzahl der Prozessoren
* Auslastung des Systems
* Größe des Hauptspeichers und Cache, Geschwindigkeit des Datenbus
* Qualität des Compilers/Optimierers (ist der Compiler für die spezielle Prozessor-Architektur optimiert?)
* Geschick des Programmierers
* Daten (Beispiel Quicksort: Best case und worst case [vorsortierter Input] stark unterschiedlich)
All diese Faktoren sind untereinander abhängig. Laufzeitvergleiche sind daher mit Vorsicht zu interpretieren.
Generell sollten bei Vergleichen möglichst wenige Parameter verändert werden, z.B.
* gleiches Programm (gleiche Kompilierung), gleiche Daten, andere Prozessoren
oder
* gleiche CPU, Daten, andere Programme (Vergleich von Algorithmen)
Zur Verbesserung der Vergleichbarkeit gibt es standardisierte [http://en.wikipedia.org/wiki/Benchmark_(computing) Benchmarks], die bestimmte Aspekte eines Systems unter möglichst realitätsnahen Bedingungen testen. Generell gilt aber: Durch Laufzeitmessung ist schwer festzustellen, ob ein Algorithmus ''prinzipiell'' besser ist als ein anderer. Dafür ist die Analyse der [[Effizienz#Algorithmen-Komplexität|Algorithmenkomplexität]] notwendig.

===Optimierung der Laufzeit===

Wenn sich herausstellt, dass ein bereits implementierter Algorithmus zu langsam läuft, geht man wie folgt vor:

# Man verwendet einen [http://en.wikipedia.org/wiki/Performance_analysis Profiler], um zunächst den Flaschenhals zu bestimmen. Ein Profiler ist ein Hilfsprogramm, das während der Ausführung eines Programms misst, wieviel Zeit in jeder Funktion und Unterfunktion verbraucht wird. Dadurch kann man herausfinden, welcher Teil des Algorithmus überhaupt Probleme bereitet. Donald Knuth gibt z.B. als Erfahrungswert an, dass Programme während des größten Teils ihrer Laufzeit nur 3% des Quellcodes (natürlich mehrmals wiederholt) ausführen [http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf]. Es ist sehr wichtig, diese 3% experimentell zu bestimmen, weil die Erfahrung zeigt, dass man beim Erraten der kritischen Programmteile oft falsch liegt. Man spricht dann von "[http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize premature optimization]", also von voreiliger Optimierung ohne experimentelle Untersuchung der wirklichen Laufzeiten, was laut Knuth "the root of all evil" ist. Der Python-Profiler wird in [http://docs.python.org/lib/profile.html Kapitel 25] der Python-Dokumentation beschrieben.
# Man kann dann versuchen, die kritischen Programmteile zu optimieren.
# Falls der Laufzeitgewinn durch Optimierung zu gering ist, muss man einen prinzipiell schnelleren Algorithmus verwenden, falls es einen gibt.

Einige wichtige Techniken der Programmoptimierung sollen hier erwähnt werden. Wenn man einen optimierenden Compiler verwendet, werden einige Optimierungen automatisch ausgeführt [http://en.wikipedia.org/wiki/Compiler_optimization]. In Python trifft dies jedoch nicht zu. Um den Sinn einiger Optimierungen zu verstehen, benötigt man Grundkenntnisse der Computerarchitektur.

;Elimination von redundantem Code: Es ist offensichtlich überflüssig, dasselbe Ergebnis mehrmals zu berechnen, wenn es auch zwischengespeichert werden könnte. Diese Optimierung wird von vielen automatischen Optimierern unterstützt und kommt im wesentlichen in zwei Ausprägungen vor:
:; common subexpression elimination: In mathematischen Ausdrücken wird ein Teilergebnis häufig mehrmals benötigt. Man betrachte z.B. die Lösung der quadratischen Gleichung <math>x^2+p\,x+q</math>:
x1 = - p / 2.0 + sqrt(p*p/4.0 - q)
x2 = - p / 2.0 - sqrt(p*p/4.0 - q)
::Die mehrmalige Berechnung von Teilausdrücken wird vermieden, wenn man stattdessen schreibt:
p2 = - p / 2.0
r = sqrt(p2*p2 - q)
x1 = p2 + r
x2 = p2 - r
:; loop invariant elimination: Wenn ein Teilausdruck sich in einer Schleife nicht ändert, muss man ihn nicht bei jedem Schleifendurchlauf neu berechnen, sondern kann dies einmal vor Beginn der Schleife tun. Ein typisches Beispiel hierfür ist die Adressierung von Matrizen, die als 1-dimensionales Array gespeichert sind. Angenommen, wir speichern eine NxN Matrix <tt>m</tt> in einem Array <tt>a</tt> der Größe N2, so dass das Matrixelement <tt>mij</tt> durch <tt>a[i + j*N]</tt> indexiert wird. Wir betrachten die Aufgabe, eine Einheitsmatrix zu initialisieren. Ein nicht optimierter Algorithmus dafür lautet:
for j in range(N):
for i in range(N):
if i == j:
a[i + j*N] = 1.0
else:
a[i + j*N] = 0.0
::Der Ausdruck <tt>j*N</tt> wird hier in jedem Schleifendurchlauf erneut berechnet, obwohl sich <tt>j</tt> in der inneren Schleife gar nicht verändert. Man kann deshalb optimieren zu:
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
;Vereinfachung der inneren Schleife: Generell sollte man sich bei der Optimierung auf die innere Schleife eines Algorithmus konzentrieren, weil dieser Code am häufigsten ausgeführt wird. Insbesondere sollte man die Anzahl der Befehle in der inneren Schleife so gering wie möglich halten und teure Befehle vermeiden. Früher waren vor allem Floating-Point Befehle teuer, die man oft durch die schnellere Integer-Arithmetik ersetzt hat, falls dies algorithmisch möglich war (diesen Rat findet man noch oft in der Literatur). Heute hat sich die Hardware so verbessert, dass im Allgemeinen nur noch die Floating-Point Division deutlich langsamer ist als die anderen Operatoren. Im obigen Beispiel der quadratischen Gleichung ist es daher sinnvoll, den Ausdruck
p2 = -p / 2.0
:durch
p2 = -0.5 * p
:zu ersetzen. Dadurch ersetzt man eine Division durch eine Multiplikation und spart außerdem das Negieren von <tt>p</tt>, da der Compiler direkt mit <tt>-0.5</tt> multipliziert.
;Ausnutzung der Prozessor-Pipeline: Moderne Prozessoren führen mehrere Befehle parallel aus. Dies ist möglich, weil jeder Befehl in mehrere Teilschritte zerlegt werden kann. Eine generische Unterteilung in vier Teilschritte ist z.B.:
:# Dekodieren des nächsten Befehls
:# Beschaffen der Daten, die der Befehl verwendet (aus Prozessorregistern, dem Cache, oder dem Hauptspeicher)
:# Ausführen des Befehls
:# Schreiben der Ergebnisse
:Man bezeichnet dies als die "[http://en.wikipedia.org/wiki/Instruction_pipeline instruction pipeline]" des Prozessors (heutige Prozessoren verwenden wesentlich feinere Unterteilungen). Prozessoren werden nun so gebaut, dass mehrere Befehle parallel, auf verschiedenen Ausführungsstufen ausgeführt werden. Wenn Befehl 1 also beim Schreiben der Ergebnisse angelangt ist, kann Befehl 2 die Hardware zum Ausführen des Befehls benutzen, während Befehl 3 seine Daten holt, und Befehl 4 soeben dekodiert wird. Unter bestimmten Bedingungen funktioniert diese Parallelverarbeitung jedoch nicht. Dies gibt Anlass zu Optimierungen:
:;Vermeiden unnötiger Typkonvertierungen: Der Prozessor verarbeitet Interger- und Floating-Point-Befehle in verschiedenen Pipelines, weil die Hardwareanforderungen sehr verschieden sind. Wird jetzt ein Ergebnis von Integer nach Floating-Point umgewandelt oder umgekehrt, muss die jeweils andere Pipeline warten, bis die erste Pipeline ihre Berechnung beendet. Es kann dann besser sein, Berechnungen in Floating-Point zu Ende zu führen, auch wenn sie semantisch eigentlich Integer-Berechnungen sind.
:;Reduzierung der Anzahl von Verzweigungen: Wenn der Code verzweigt (z.B. durch eine <tt>if</tt>- oder <tt>while</tt>-Anweisung), ist nicht klar, welcher Befehl nach der Verzweigung ausgeführt werden soll, bevor Stufe 3 der Pipiline die Verzweigungsbedingung ausgewertet hat. Bis dahin wären die ersten beiden Stufen der Pipeline unbenutzt. Moderne Prozessoren benutzen zwar ausgefeilte Heuristiken, um das Ergebnis der Bedingung vorherzusagen, und führen den hoffentlich richtigen Zweig des Codes spekulativ aus, aber dies funktioniert nicht immer. Man sollte deshalb generell die Anzahl der Verzweigungen minimieren. Als Nebeneffekt führt dies meist auch zu besser lesbarem, verständlicherem Code. Im Matrixbeispiel kann man
for j in range(N):
jN = j*N
for i in range(N):
if i == j:
a[i + jN] = 1.0
else:
a[i + jN] = 0.0
::durch
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
ersetzen. Die Diagonalelemente <tt>a[j + jN]</tt> werden jetzt zwar zweimal initialisiert (in der Schleife auf Null, dann auf Eins), aber durch Elimination der <tt>if</tt>-Abfrage wird dies wahrscheinlich mehr als ausgeglichen, zumal dadurch die innere Schleife wesentlich vereinfacht wurde.
;Ausnutzen des Prozessor-Cache: Zugriffe auf den Hauptspeicher sind sehr langsam. Deshalb werden stets ganze Speicherseiten auf einmal in den [http://en.wikipedia.org/wiki/Cache Cache] des Prozessors geladen. Wenn unmittelbar nacheinander benutzte Daten auch im Speicher nahe beieinander liegen (sogenannte "[http://en.wikipedia.org/wiki/Locality_of_reference locality of reference]"), ist die Wahrscheinlichkeit groß, dass die als nächstes benötigten Daten bereits im Cache sind und damit schnell gelesen werden können. Bei vielen Algorithmen kann man die Implementation so umordnen, dass die locality of reference verbessert wird, was zu einer drastischen Beschleunigung führt. Im Matrix-Beispiel ist z.B. die Reihenfolge der Schleifen wichtig. Für konstanten Index <tt>j</tt> liegen die Indizes <tt>i</tt> im Speicher hintereinander. Deshalb ist es günstig, in der inneren Schleife über <tt>i</tt> zu iterieren:
for j in range(N):
jN = j*N
for i in range(N):
a[i + jN] = 0.0
a[j + jN] = 1.0
:Die umgekehrte Reihenfolge der Schleifen ist hingegen ungünstig
for i in range(N):
for j in range(N):
a[i + j*N] = 0.0
a[i + i*N] = 1.0
:Jetzt werden in der inneren Schleife stets N Datenelemente übersprungen. Besonders bei großem N muss man daher häufig den Cache neu füllen, was bei der ersten Implementation nicht notwendig war. (Ausserdem verliert man hier die Optimierung <tt>jN = j*N</tt>, die jetzt nicht mehr möglich ist.)

Als Faustregel kann man durch Optimierung eine Verdoppelung der Geschwindigkeit erreichen (in Ausnahmefällen auch mehr). Benötigt man stärkere Verbesserungen, muss man wohl oder übel einen besseren Algorithmus oder einen schnelleren Computer verwenden.

== Algorithmen-Komplexität ==

Komplexitätsbetrachtungen ermöglichen den Vergleich der prinzipiellen Eigenschaften von Algorithmen unabhängig von einer Implementation, Umgebung etc.

Eine einfache Möglichkeit ist das Zählen der Aufrufe einer Schlüsseloperation. Beispiel Sortieren:
* Anzahl der Vergleiche
* Anzahl der Vertauschungen

=== Beispiel: Selection Sort ===

for i in range(len(a)-1):
max = i
for j in range(i+1, len(a)):
if a[j] < a[max]:
max = j
a[max], a[i] = a[i], a[max] # swap

*Anzahl der Vergleiche: Ein Vergleich in jedem Durchlauf der inneren Schleife. Es ergibt sich folgende Komplexität:
*:Ingesamt <math>\sum_{i=0}^{N-2} \sum_{j=i+1}^{N-1}1 = \frac{N}{2} (N-1) \!</math> Vergleiche.

*Anzahl der Vertauschungen (swaps): Eine Vertauschung pro Durchlauf der äußeren Schleife:
*:Insgesamt <math>N-1 \!</math> Vertauschungen

Die Komplexität wird durch die Operationen bestimmt, die am häufigsten ausgeführt werden, hier also die Anzahl der Vergleiche. Die Anzahl der Vertauschungen ist hingegen kein geeignetes Kriterium für die Komplexität von selection sort, weil der Aufwand in der inneren Schleife ignoriert würde.

=== Fallunterscheidung: Worst und Average Case ===

Die Komplexität ist in der Regel eine Funktion der Eingabegröße (Anzahl der Eingabebits, Anzahl der Eingabeelemente). Sie kann aber auch von der Art der Daten abhängen, nicht nur von der Menge, z.B. vorsortierte Daten bei Quicksort. Um von der Art der Daten unabhängig zu werden, kann man zwei Fälle der Komplexität unterscheiden:

* Komplexität im ungünstigsten Fall
*: Der ungünstigste Fall ist die Eingabe gegebener Länge, für die der Algorithmus am langsamsten ist. Der Nachteil dieser Methode besteht darin, dass dieser ungünstige Fall in der Praxis vielleicht gar nicht oder nur selten vorkommt, so dass sich der Algorithmus in Wirklichkeit besser verhält als man nach dieser Analyse erwarten würde. Beim Quicksort-Algorithmus mit zufälliger Wahl des Pivot-Elements müsste z.B. stets das kleinste oder größte Element des aktuellen Intervalls als Pivot-Element gewählt werden, was äußerst unwahrscheinlich ist.
* Komplexität im durchschnittlichen/typischen Fall
*: Der typische Fall ist die mittlere Komplexität des Algorithmus über alle möglichen Eingaben. Dazu muss man die Wahrscheinlichkeit jeder möglichen Eingabe kennen, und berechnet dann die mittlere Laufzeit über dieser Wahrscheinlichkeitsverteilung. Leider ist die Wahrscheinlichkeit der Eingaben oft nicht bekannt, so dass man geeignete Annahmen treffen muss. Bei Sortieralgorithmen können z.B. alle möglichen Permutationen des Eingabearrays als gleich wahrscheinlich angenommen werden, und der typische Fall ist dann die mittlere Komplexität über alle diese Eingaben. Oft hat man jedoch in der Praxis andere Wahrscheinlichkeitsverteilungen, z.B. sind die Daten oft "fast sortiert" (nur wenige Elemente sind an der falschen Stelle). Dann verhält sich der Algorithmus ebenfalls anders als vorhergesagt.

Wir beschränken uns in dieser Vorlesung auf die Komplexität im ungünstigseten Fall. '''Exakte''' Formeln für Komplexität sind aber auch dann schwer zu gewinnen, wie das folgende Beispiel zeigt:

=== Beispiele aus den Übungen (Gemessene Laufzeiten für Mergesort/Selectionsort) ===

* Mergesort: <math>\frac{0,977N\log N}{\log 2} + 0,267N-4.39 \!</math>
*: andere Lösung: <math>1140 N\log(N) - 1819N + 6413 \!</math>
* Selectionsort: <math>\frac{1}{2}N^2 - \frac{1}{2N} - 10^{-12} \!</math>
*: andere Lösung: <math>1275N^2 - 116003^N + 11111144 \!</math>

Aus diesen Formeln wird nicht offensichtlich, welcher Algorithmus besser ist.
Näherung: Betrachte nur '''sehr große Eingaben''' (meist sind alle Algorithmen schnell genug für kleine Eingaben). Dieses Vorgehen wird als '''Asymptotische Komplexität''' bezeichnet (N gegen unendlich).

=== Asymptotische Komplexität am Beispiel Polynom ===

Polynom: <math>a\,x^2+b\,x+c=p\!</math>

<math>x \!</math> sei die Eingabegröße, und wir betrachten die Entwicklung von <math>p \!</math> in Abhängigkeit von <math>x \!</math>.

* <math>x=0 \!</math>
*: <math>p=c \!</math>
* <math>x=1 \!</math>
*: <math>p=a+b+c \!</math>
* <math>x=1000 \!</math>
*: <math>p=1000000a+1000b+c \approx 1000000a\!</math>
* <math>x \to \infty \!</math>
*: <math>p \approx x^2a\!</math>

Für sehr große Eingaben verlieren also ''b'' und ''c'' immer mehr an Bedeutung, so dass am Ende nur noch ''a'' für die Komplexitätsbetrachtung wichtig ist.

== Landau-Symbole ==

Um die asymptotische Komplexität verschiedener Algorithmen miteinander vergleichen zu können, verwendet man die sogenannten [http://de.wikipedia.org/wiki/Landau-Symbole Landau-Symbole]. Das wichtigste Landau-Symbol ist <math>\mathcal{O}</math>, mit dem man eine ''obere Schranke'' <math>f \in \mathcal{O}(g)</math> für die Komplexität angeben kann.

Schreibt man <math>f \in \Omega(g)</math>, so stellt dies eine asymptotische ''untere Schranke'' für die Funktion f dar.

Schließlich bedeutet <math>f \in \Theta(g)</math>, dass die Funktion f genauso schnell wie die Funktion g wächst, das heißt man hat eine asymptotisch ''scharfe Schranke'' für f. Hierzu muss sowohl <math>f\in\mathcal{O}(g)</math> als auch <math>f \in \Omega(g)</math> erfüllt sein.

Im nun folgenden soll auf die verschiedenen Landau-Symbole noch näher eingegeangen werden.

===O-Notation===

Intuitiv gilt: Für große N dominieren die am schnellsten wachsenden Terme einer Funktion. Die Notation <math>f \in \mathcal{O}(g)</math> (sprich "f ist in O von g" oder "f ist von derselben Größenordnung wie g") formalisiert eine solche Abschätzung der asymptotischen Komplexität der Funktion f von oben.
; Asymptotische Komplexität: Für zwei Funktionen f(x) und g(x) gilt
::<math>f(x) \in \mathcal{O}(g(x))</math>
: genau dann wenn es eine Konstante <math>c>0</math> und ein Argument <math>x_0</math> gibt, so dass
::<math>\forall x \ge x_0:\quad f(x) \le c\,g(x)</math>.
:Die Menge <math>\mathcal{O}(g(x))</math> aller durch g(x) abschätzbaren Funktionen ist also formal definiert durch
::<math>\mathcal{O}(g(x)) = \{ f(x)\ |\ \exists c>0: \forall x \ge x_0: 0 \le f(x) \le c\,g(x)\}</math>

Die Idee hinter dieser Definition ist, dass g(x) eine wesentlich einfachere Funktion ist als f(x), die sich aber nach geeigneter Skalierung (Multiplikation mit c) und für große Argumente x im wesentlichen genauso wie f(x) verhält. Man kann deshalb in der Algorithmenanalyse f(x) durch g(x) ersetzen. <math>f(x) \in \mathcal{O}(g(x))</math> spielt für Funktionen eine ähnliche Rolle wie der Operator ≤ für Zahlen: Falls a ≤ b gilt, kann bei einer Abschätzung von oben ebenfalls a durch b ersetzt werden.

==== Ein einfaches Beispiel ====

[[Image:Sqsqrt.png]]

Rot = <math>x^2 \!</math>
Blau = <math>\sqrt{x} \!</math>

<math>\sqrt{x} \in \mathcal{O}(x^2)\!</math> weil <math>\sqrt{x} \le c\,x^2\!</math> für alle <math>x \ge x_0 = 1 \!</math> und <math>c = 1\!</math>, oder auch für <math>x \ge x_0 = 4 \!</math> und <math>c = 1/16</math> (die Wahl von c und x0 in der Definition von O(.) ist beliebig, solange die Bedingungen erfüllt sind).

==== Komplexität bei kleinen Eingaben ====

Algorithmus 1: <math>\mathcal{O}(N^2) \!</math> 
Algorithmus 2: <math>\mathcal{O}(N\log{N}) \!</math>

Algorithmus 2 ist schneller (von geringerer Komplexität) für große Eingaben, aber bei kleinen Eingaben (insbesondere, wenn der Algorithmus in einer Schleife immer wieder mit kleinen Eingaben aufgerufen wird) könnte Algorithmus 1 schneller sein, falls der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor ''c'' bei Algorithmus 2 einen wesentlich größeren Wert hat als bei Algorithmus 1.

==== Eigenschaften der O-Notation (Rechenregeln) ====

# Transitiv:
#: <math>f(x) \in \mathcal{O}(g(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) \in \mathcal{O}(h(x)) \!</math>
# Additiv:
#: <math>f(x) \in \mathcal{O}(h(x)) \land g(x) \in \mathcal{O}(h(x)) \to f(x) + g(x) \in \mathcal{O}(h(x)) \!</math>
# Für Monome gilt:
#: <math>x^k \in \mathcal{O}(x^k)</math> und
#: <math>x^k \in \mathcal{O}(x^{k+j}), \forall j \ge 0 \!</math>
# Multiplikation mit einer Konstanten:
#: <math>f(x) \in \mathcal{O}(g(x)) \to c\,f(x) \in \mathcal{O}(g(x))\!</math>
#: andere Schreibweise:
#: <math>f(x) = c\,g(x) \to f(x) \in \mathcal{O}(g(x))\!</math>
# Folgerung aus 3. und 4. für Polynome:
#: <math>a_0+a_1\,x + ... + a_n\,x^n \in \mathcal{O}(x^n)\!</math>
#: Beispiel: <math>a\,x^2+b\,x+c \in \mathcal{O}(x^2)\!</math>
# Logarithmus:
#: <math>a, b > 1\!</math>
#: <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>
#: Die Basis des Logarithmus spielt also keine Rolle.
#: Beweis hierfür:
#:: <math>\log_{a}{x} = \frac{\log_{b}{x}}{\log_{b}{a}}\!</math>
#:: Mit <math>c = 1 / \log_{b}{a}\,</math> gilt: <math>\log_{a}{x} = c\,\log_{b}{x}\!</math>.
#:: Wird hier die (zweite) Regel für Multiplikation mit einer Konstanten angewendet, fällt der konstante Faktor weg, also <math>\log_{a}{x} \in \mathcal{O}(\log_{b}{x})\!</math>.
#: Insbesondere gilt auch <math>\log_{a}{x} \in \mathcal{O}(\log_{2}{x})\!</math>, es kann also immer der 2er Logarithmus verwendet werden.

==== O-Kalkül ====

Das O-Kalkül definiert wichtige Vereinfachungsregeln for Ausdrücke in O-Notation (Beweise: siehe Übungsaufgabe):

# <math>f(x) \in \mathcal{O}(f(x))\!</math>
# <math>\mathcal{O}(\mathcal{O}(f(x))) \in \mathcal{O}(f(x))\!</math>
# <math>c\,\mathcal{O}(f(x)) \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# <math>\mathcal{O}(f(x))+c \in \mathcal{O}(f(x))\,</math> für jede Konstante ''c''
# Sequenzregel:
#: Wenn zwei nacheinander ausgeführte Programmteile die Komplexität <math>\mathcal{O}(f(x))</math> bzw. <math>\mathcal{O}(g(x))</math> haben, gilt für beide gemeinsam:
#: <math>\mathcal{O}(f(x)) + \mathcal{O}(g(x)) \in \mathcal{O}(f(x))</math> falls <math>g(x) \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) \in \mathcal{O}(N^2)\!</math>.

Alternativ via Schachtelungsregel:
: Die äußere Schleife wird (''N''-1)-mal durchlaufen: <math>N-1 \in \mathcal{O}(N)</math>
: Die innere Schleife wird (''N-i''-1)-mal durchlaufen. Das sind im Mittel ''N''/2 Durchläufe: <math>N/2 \in \mathcal{O}(N)</math>
: Zusammen: <math>\mathcal{O}(N)*\mathcal{O}(N) \in \mathcal{O}(N^2)</math>

Nach beiden Vorgehensweisen kommen wir zur Schlussfolgerung, dass der Selectionsort die asymptotische Komplexität <math>\mathcal{O}(N^2)\!</math> besitzt.

==== Zusammenhang zwischen Komplexität und Laufzeit ====

Wenn eine Operation 1ms dauert, erreichen Algorithmen verschiedener Komplexität folgende Leistungen (wobei angenommen wird, dass der in der <math>\mathcal{O}</math>-Notation verborgene konstante Faktor immer etwa gleich 1 ist):

{| class="wikitable" style="text-align:left" cellpadding="7"
|+
|-
! Komplexität !! Operationen in 1s !! Operationen in 1min !! Operationen in 1h
|-
! <math>\mathcal{O}(N)</math>
| 1000 || 60.000 || 3.600.000
|-
! <math>\mathcal{O}(N\log_2{N})</math>
| 140 || 4895 || 204094
|-
! <math>\mathcal{O}(N^2)</math>
| 32 || 245 || 1898
|-
! <math>\mathcal{O}(N^3)</math>
| 10 || 39 || 153
|-
! <math>\mathcal{O}(2^N)</math>
| 10 || 16 || 21
|}

==== Exponentielle Komplexität ====
Der letzte Fall <math>\mathcal{O}(2^N)</math> ist von exponentieller Komplexität. Das bedeutet, dass eine Verdopplung des Aufwands nur bewirkt, dass die maximale Problemgröße um eine Konstante wächst. Algorithmen mit exponentieller (oder noch höherer) Komplexität werden deshalb als '''ineffizient''' bezeichnet. Algorithmen mit höchstens polynomieller Komplexität gelten hingegen als effizient.

In der Praxis sind allerdings auch polynomielle Algorithmen mit hohem Exponenten meist zu langsam. Als Faustregel kann man eine praktische Grenze von <math>\mathcal{O}(N^3)</math> ansehen. Bei einer Komplexität von <math>\mathcal{O}(N^3)</math> bewirkt ein verdoppelter Aufwand immer noch eine Steigerung der maximalen Problemgröße um den Faktor <math>\sqrt[3]{2}</math> (also eine ''multiplikative'' Vergrößerung um ca. 25%, statt nur einer additiven Vergrößerung wie bei exponentieller Komplexität).

===<math>\Omega</math>- Notation===

Genauso wie <math>f \in \mathcal{O}(g)</math> eine Art <math>\le</math>-Operator für Funktionen ist, definiert <math>f \in \Omega(g) </math> eine Abschätzung von unten, analog zum <math>\ge</math>-Operator für Zahlen. Formal kann man <math>f(N) \in \Omega(g(N)) </math> genau dann schreiben, falls es eine Konstante <math> c > 0 </math> gibt, so dass

<math> f(N) \ge c \cdot g(N) </math> für <math> N \ge N_0 </math>

gilt.
Man verwendet diese Notation also um abzuschätzen, wie groß der Aufwand (die Komplexität) für einen bestimmten Algorithmus ''mindestens'' ist und nicht ''höchstens'', was man mit der <math>\mathcal{O}</math> - Notation ausdrücken würde.

Ein praktisches Beispiel für eine Anwendung der <math>\Omega</math>- Notation wäre die Fragestellung, ob es ''prinzipiell'' einen besseren Algorithmus für ein bestimmtes Problem gibt. Wie später im Abschnitt [[Suchen#Sortieren_als_Suchproblem|Sortieren als Suchproblem]] gezeigt wird, ist das Sortieren eines Arrays durch paarweise Vergleiche von Elementen immer mindestens von der Komplexität <math> \Omega(N\cdot \ln N) </math>, was konkret bedeutet, dass kein Sortieralgorithmus, der nach diesem Prinzip arbeitet, jemals eine geringere Komplexität als beispielsweise Merge-Sort haben wird. Natürlich kann man den entsprechenden Sortieralgorithmus, also Merge-Sort zum Beispiel, unter Umständen noch optimieren, aber die Komplexität wird erhalten bleiben. Mit diesem Wissen kann man sich viel (vergebliche) Arbeit sparen.

===<math>\Theta</math>- Notation===

<math>f(N) \in \Theta(g(N))</math> ist eine scharfe Abschätzung der asymptotischen Komplexität einer Funktion f.

Damit dies gilt, muss <math>f(N) \in \mathcal{O}(g(N))</math> und ''gleichzeitig'' <math>f(N) \in \Omega(g(N))</math> erfüllt sein.

Dies ist natürlich auch die beste Abschätzung der asymptotischen Komplexität einer Funktion f. Formal bedeutet <math>f(N) \in \Theta(g(N))</math> dass es zwei Konstanten <math> c_1 </math> und <math> c_2 </math>, beide größer als Null, gibt, so dass für alle <math> N \geq N_0 </math> gilt:

<math> c_1 \cdot g(N) \leq f(N) \leq c_2 \cdot g(N) </math>.

In der Praxis wird manchmal statt der <math>\Theta</math>-Notation auch dann die <math>\mathcal{O}</math>-Notation benutzt, wenn eine scharfe Schranke ausgedrückt werden soll. Dies ist zwar formal nicht korrekt, aber man kann die intendierte Bedeutung meist aus dem Kontext erschließen.

== Komplexitätsvergleich zweier Algorithmen ==

In diesem Abschnitt wollen wir der Frage nachgehen, wie ein formaler Beweis für die Behauptung <math> f(N) \in \mathcal{O}(g(N))</math> geschehen kann. Hierbei werden zwei Beweismethoden vorgestellt werden, und zwar der '''Beweis über die Definition der Komplexität''' sowie der '''Beweis durch Dividieren'''.

===Beweis über die Definition der asymptotischen Komplexität===

Die Definition der asymptotischen Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> war:

Es gibt eine Konstante <math> c > 0 </math>, so dass <math> f(N) \le c \cdot g(N) </math> für <math> N \ge N_0 </math> erfüllt ist.

Um also die die asymptotische Komplexität <math>f(N) \in \mathcal{O}(g(N))</math> zu beweisen, muss man die oben erwähnten Konstanten c und <math> N_0 </math> finden, so dass

<math> f(N) \leq c \cdot g(N) </math> für alle <math> N \ge N_0 </math> erfüllt ist.

Dies geschieht zweckmäßigerweise mit dem Beweisprinzip der ''vollständigen Induktion''. Hierbei ist zu zeigen, dass
# <math> f(N_0) \leq g(N_0) </math> für die eine zu bestimmende Konstante <math> N_0 </math> gilt (''Induktionsanfang'') und
# falls <math> f(N) \leq g(N) </math>, dann auch <math> f(N+1) \leq g(N+1) </math> (''Induktionsschritt'') gilt.

===Beweis durch Dividieren===

Hierbei wählt man eine Konstante c und zeigt, dass <math> \lim_{N \rightarrow \infty} \frac{f(N)}{c \cdot g(N)} \leq 1 </math> gilt (für die O-Notation, bei Ω-Notation gilt entsprechend <math>\geq 1 </math>). Man kann dies auch als alternative Definition der Komplexität verwenden.

Als Beispiel betrachten wir die beiden Funktionen <math> f(N) = N \,\lg N </math> und <math> g(N) = N^2 </math> und wollen zeigen, dass <math>f(N) \in \mathcal{O}(g(N))</math> gilt.

Als Konstante c wählen wir <math> c = 1 </math>

<math> \lim_{N \rightarrow \infty} \frac{f(N)}{g(N)} = \lim_{N \rightarrow \infty} \frac{\lg N}{N} = \frac{\infty}{\infty} </math>

Unbestimmte Ausdrücke der Form
<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} </math>,
in denen sowohl <math> f(x) </math> als auch <math> g(x) </math> mit <math> x \rightarrow x_0 </math> gegen Null oder gegen Unendlich streben, kann man manchmal mit den Regeln von [http://de.wikipedia.org/wiki/L%27Hospital%27sche_Regel ''l'Hospital''] berechnen. Danach darf man die Funktionen f und g zur Berechnung des unbestimmten Ausdrucks durch ihre k-ten Ableitungen ersetzen:

<math> \lim_{x \rightarrow x_0} \frac{f(x)}{g(x)} = \lim_{x \rightarrow x_0} \frac{f^{(k)}(x)}{g^{(k)}(x)} </math>

In unserem Fall verwenden wir die erste Ableitung und erhalten:
<math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)} = \lim_{N \rightarrow \infty} \frac{1/N}{1} \rightarrow 0 </math>

Damit wurde <math>f(N) \in \mathcal{O}(g(N))</math>, also <math>N \lg N \in \mathcal{O}(N^2)</math> gezeigt.

Man beachte hierbei, dass <math>N \lg N \in \mathcal{O}(N^2)</math> keine enge Grenze für die Komplexität von <math>N \,\lg N</math> darstellt, da der Grenzwert <math> \lim_{N \rightarrow \infty} \frac{f'(x)}{g'(x)}\, </math> gegen 0 und nicht gegen eine von Null verschiedene Konstante strebt. In diesem Fall haben wir die Komplexität von <math>N \cdot \lg N </math> also nur nach oben abschätzen können.

===Beispiel für den Komplexitätsvergleich: Gleitender Mittelwert (Running Average)===

Wir berechnen für ein gegebenes Array <tt>a</tt> einen gleitenden Mittelwert über <tt>k</tt> Elemente: 
::<math>r_i = \frac{1}{k} \sum_{j=i-k+1}^i a_j</math> 
Das heisst, für jedes <tt>i</tt> mitteln wir die letzten <tt>k</tt> Elemente von <tt>a</tt> und schreiben das Ergebnis in <tt>r[i]</tt>. Diese Operation ist z.B. bei Börsenkursen wichtig: Neben dem aktuellen Kurs für jeden Tag wird dort meist auch der gleitende Mittelwert der letzten 30 Tage sowie der letzten 200 Tage angegeben. In diesen Mittelwerten erkennt man besser die langfristige Tendenz, weil die täglichen Schwankungen herausgemittelt werden. Wir nehmen außerdem an, dass
* Array-Zugriff hat eine Komplexität von O(1)
* <math>k \ll N</math>, d.h. <math>N-k\approx N</math>.

Die beiden folgenden Algorithmen berechnen die Mittelwerte auf unterschiedliche Art. Der linke folgt der obigen Definition durch eine Summe, während der rechte inkrementell arbeitet: Man kann den Bereich der <tt>k</tt> letzten Werte als Fenster betrachten, das über das Array <tt>a</tt> geschoben wird. Schiebt man das Fenster ein Element weiter, fällt links ein Element heraus, und rechts kommt eins hinzu. Man muss also nicht jedes Mal die Summe neu berechnen, sondern kann den vorigen Wert aktualisieren. Wir werden sehen, dass dies Folgen für die Komplexität des Algorithmus hat.

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1: O(N * k)
! Komplexität
! Version 2: O(N)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|
<tt>for i in range(k):</tt>
|
'''<center>O(k)</center>'''
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|
:: <tt>r[k-1] += a[i]</tt>
|
'''<center>O(1)</center>'''
|-
|
6.
|
:::: <tt>r[j] += a[i]</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(k, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|
:: <tt>r[j] = (a[j] - a[j-k] + r[j-1])</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|
<tt>for j in range(len(a)):</tt>
|
'''<center>O(N)</center>'''
|-
|
9.
|

|

|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
10.
|

|

|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Wir zeigen unten dass Version 2 eine geringere Komplexität besitzt, obwohl sie mehr Zeilen benötigt.

Wir haben in der Tabelle die Komplexität jeder Zeile für sich angegeben. Einfache Anweisungen (Berechnungen, Lese- und Schreibzugriffe auf das Array, Zuweiseungen) haben konstante Komplexität, die Komplexität des Schleifenkopfes allein (also der <tt>for</tt>-Anweisung ohne den eingerückten Schleifenkörper) entspricht der Anzahl der Durchläufe. Wir müssen jetzt noch die Verschachtelung der Schleifen und die Nacheinanderausführung von Anweisungen berücksichtigen.

====Berechnung der Komplexität von Version 1====

(Wiederholung der Rechenregeln: siehe Abschnitt [[Effizienz#O-Notation|O-Notation]])

Wir betrachten zunächst die innere Schleife (Zeilen 5 und 6 von Version 1):

Der Schleifenkopf (Zeile 5) hat die Komplexität <math>\mathcal{O}(k)</math>, weil die Schleife k-mal durchlaufen wird. Der Schleifenkörper (Zeile 6) hat die Komplexität <math>\mathcal{O}(1)</math>. Nach der Verschachtelungsregel müssen wir die beiden Komplexitäten multiplizieren, und es ergibt sich:

::<math>\mathcal{O}(k)\cdot\mathcal{O}(1) = \mathcal{O}(k\cdot 1)=\mathcal{O}(k)</math>

Wir betrachten nun die äußere Schleife. Der Schleifenkopf (Zeile 4) wird (N-k)-mal durchlaufen und hat somit eine Komplexität von <math>\mathcal{O}(N)</math>. Der Schleifenkörper (Zeilen 5 bis 7) besteht aus der inneren Schleife (Zeilen 5 und 6) mit der gerade berechneten Komplexität <math>\mathcal{O}(k)</math> sowie einer einfachen Anweisung (Zeile 7) mit Komplexität <math>\mathcal{O}(1)</math>. Nach der Sequenzregel wird die Komplexität des Schleifenkörpers durch Addition berechnet:

::<math>\mathcal{O}(k)+\mathcal{O}(1) = \mathcal{O}(\max(k,1)) = \mathcal{O}(k)</math>

Die Komplexität der gesamten äußeren Schleife erhalten wir nach der Verschachtelungsregel wieder durch multiplizieren:

::<math>\mathcal{O}(N)\cdot\mathcal{O}(k) = \mathcal{O}(N\cdot k)</math>

Die übrigen Schritte des Algorithmus werden einfach nacheinander ausgeführt, so dass sie ebenfalls nach der Sequenzregel behandelt werden. Wir erhalten

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(N\cdot k)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,N\cdot k,1)) = \mathcal{O}(N\cdot k)</math>

Der gesamte Algorithmus hat also die Komplexität <math>\mathcal{O}(N\cdot k)</math>.

====Berechnung der Komplexität von Version 2====

Hier gibt es nur einfache Schleifen ohne Verschachtelung. Da der Schleifenkörper jeder Schleife nur einfache Anweisungen der Komplexität <math>\mathcal{O}(1)</math> enthält, ergibt sich die Komplexität der Schleifen nach der Verschachtelungsregel als

::<math>\mathcal{O}(X)\cdot\mathcal{O}(1) = \mathcal{O}(X\cdot 1)=\mathcal{O}(X)</math>

wobei <math>\mathcal{O}(X)</math> die Komplexität des jeweiligen Schleifenkopfes ist. Wir erhalten also für Zeilen 4 und 5: <math>\mathcal{O}(k)</math>, Zeilen 6 und 7: <math>\mathcal{O}(N)</math>, Zeilen 8 und 9: <math>\mathcal{O}(N)</math>. Die Hintereinanderausführung wird nach der Sequenzregel behandelt:

::<math>\mathcal{O}(N)+\mathcal{O}(1)+\mathcal{O}(k)+\mathcal{O}(N)+\mathcal{O}(N)+\mathcal{O}(1) = \mathcal{O}(\max(N,1,k,N,N,1)) = \mathcal{O}(N)</math>

Dieser Algorithmus hat also nur die Komplexität <math>\mathcal{O}(N)</math>.

====Fazit====

Obwohl Version 2 mehr Schritte benötigt hat sie eine geringere Komplexität, da die for-Schleifen nicht wie bei Version 1 verschachtelt/untergeordnet sind. Bei verschachtelten for-Schleifen muss die Multiplikationsregel angewendet werden → höhere Komplexität.

Die gerade berechnete Komplexität gilt aber nur unter der Annahme, dass Array-Zugriffe konstante Komplexität <math>\mathcal{O}(1)</math> besitzen. Wenn dies nicht der Fall ist, kann sich die Komplexität des Algorithmus drastisch verschlechtern.

{| border="1" cellspacing="0" cellpadding="5"
|Allgemein gilt: 
Algorithmen-Analysen beruhen auf der Annahme, dass Zugriffe auf die Daten optimal schnell sind, dass heißt, dass die für den jeweiligen Algorithmus am besten geeignete Datenstruktur verwendetet wird. → Ansonsten: Komplexitätsverschlechterung!
|}
 

====Beispiel für eine Verschlechterung der Komplexität durch Verwendung einer nicht optimalen Datenstruktur====

Wir verwende im Mittelwert-Algorithmus eine verkettete Liste anstelle des Eingabe-Arrays a. Wir benötigen dazu eine Funktion, die das j-te Element der Liste zurückgibt. Wie üblich ist die Liste mit Hilfe einer Knotenklasse implementiert:
class Node:
def __init__(self, data):
self.data = data
self.next = None

Die Listenklasse selbst hat ein Feld <tt>head</tt>, das eine Referenz auf den ersten Knoten speichert, und jeder Knoten speichert im Feld <tt>next</tt> eine Referenz auf seinen Nachfolger. Um zum j-ten Element zu gelangen, muss man die Liste sequenziell durchlaufen
def get_jth(list, j):
r = list.head
while j > 0:
r = r.head
j -= 1
return r.data
Die Komplexität dieser Funktion ist offensichtlich <math>\mathcal{O}(j)</math> (Komplexitätsberechnung wie oben). Wir setzen jetzt bei Version 1 des Mittelwert-Algorithmus diese Funktion in Zeile 6 anstelle des Indexzugriffs <tt>a[i]</tt> ein (nur in dieser Zeile wird auf die Elemente des Arrays zugegriffen). Wir erhalten folgende Implementation (die Änderungen sind rot markiert):

{| border="1" cellspacing="0" cellpadding="2"
|-
! Programmzeile
! Version 1 mit Liste: O(N * k)
! Komplexität
|-
|
1.
|
<tt>r = [0] * len(a)</tt>
|
'''<center>O(N)</center>'''
|-
|
2.
|
<tt>if k > len(a):</tt>
|
'''<center>O(1)</center>'''
|-
|
3.
|
:: <tt>raise RuntimeError ("k zu groß")</tt>
|

|-
|
4.
|
<tt>for j in range(k-1, len(a)):</tt>
|
<center>O(N-k+1) = '''O(N)'''</center>
|-
|
5.
|
:: <tt>for i in range(j-k+1, j+1):</tt>
|
'''<center>O(k)</center>'''
|-
|
6.
|
:::: <tt>r[j] += get_jth(a, i)</tt>
|
'''<center>O(i)</center>'''
|-
|
7.
|
:: <tt>r[j] /= float(k)</tt>
|
'''<center>O(1)</center>'''
|-
|
8.
|
<tt>return r</tt>
|
'''<center>O(1)</center>'''
|}

Der Aufruf der Funktion <tt>get_jth</tt> ist jetzt gleichbedeutend mit einer dreifach verschachtelten Schleife (weil <tt>get_jth</tt> ja eine zusatzliche Schleife enthält). Die Anzahl der Operationen in Zeile 4 bis 6 ist jetzt

::<math>f(N,k)=\sum_{j=k-1}^{N-1}\,\sum_{i=j-k+1}^j\,\mathcal{O}(i)</math>

wobei das <math>\mathcal{O}(i)</math> die neue Schleife durch Verwendung der Liste repräsentiert. Mit Mathematica-Hilfe [http://www.wolfram.com/] lässt sich diese Summe exakt ausrechnen

::<math>f(N,k)=\frac{1}{2}(k N^2-k^2 N+k^2-k)\in \mathcal{O}(k N^2)</math>

Die Komplexitätsberechnung erfolgte dabei nach der Regel für Polynome unter Beachtung von <math>k \ll N</math>.

====Fazit:====

Die Komplexität von Version 1 mit einer verketteten Liste wäre O(N2 * k)
'''→ Die richtige Datenstruktur ist wichtig, da es sonst zu einer Komplexitätsverschlechterung kommen kann!'''

Auf Version 2 unseres Running Average-Beispiels hätte eine verkettete Liste allerdings keine Auswirkungen, da die inkrementelle Berechnung der Summen in Zeile 7 weiterhin möglich ist (bei geschickter Implementation!) und somit Version 2 immer noch eine Komplexität von O(N) hätte.

==Amortisierte Komplexität==

Bis jetzt wurde die Komplexität nur im schlechtesten Fall (Worst Case) betrachtet. Bei einigen Algorithmen schwankt die Komplexität im schlechtesten Fall jedoch, wenn man die ungünstige Operation mehrmals hintereinander ausführt. Die amortisierte Komplexität beschäftigt sich mit der durchschnittlichen Komplexität über viele Aufrufe der ungünstigsten Operation.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse Wikipedia: Amortisierte Laufzeitanalyse]]

===Beispiel: Inkrementieren von Binärzahlen===

Frage: Angenommen, das Umdrehen eines Bits einer Binärzahl verursacht Kosten von 1 Einheit. Wir erzeugen die Folge der natürlichen Zahlen durch sukzessives Inkrementieren, von Null beginnend. Bei jeder Inkrementierung werden einige Bits verändert, aber diese Zahl (und damit die Kosten der Inkrementierungen) ''schwanken'' sehr stark. Wir fragen jetzt, was eine Inkrementierung im Durchschnitt kostet?

Um diese Durchschnittskosten zu berechnen, bezahlen wir bei jeder Inkrementierung 2 Einheiten. Wenn davon nach Abzug der Kosten der jeweiligen Operation noch etwas übrig bleibt, wird der Rest dem Guthaben zugeschrieben. Umgekehrt wird ein eventueller Fehlbetrag (wenn eine Inkrementierung mehr als 2 Bits umdreht) aus dem Guthaben gedeckt. Dadurch werden die ansonsten großen Schwankungen der Kosten ausgeglichen:
:: Kosten < Einzahlung → es wird gespart
:: Kosten = Einzahlung → Guthaben bleibt unverändert
:: Kosten > Einzahlung → Guthaben wird für die Kosten verbraucht

{| border="1" cellspacing="0" cellpadding="5"
!Schritte
!Zahlen
!Kosten 
(Anzahl der geänderten Bits)
! Einzahlung
!Guthaben = 
altes Guthaben + Einzahlung - Kosten
|-
|1.
|00001
|1
|'''2'''
|'''1'''
|-
|2.
|00010
|2
|'''2'''
|'''1'''
|-
|3.
|00011
|1
|'''2'''
|'''2'''
|-
|4.
|00100
|3
|'''2'''
|'''1'''
|-
|5.
|00101
|1
|'''2'''
|'''2'''
|-
|6.
|00110
|2
|'''2'''
|'''2'''
|-
|7.
|00111
|1
|'''2'''
|'''3'''
|-
|8.
|01000
|4
|'''2'''
|'''1'''
|-
|}

Die Kosten ergeben sich aus der Anzahl der Ziffern die von 1 nach 0, bzw. von 0 nach 1 verändert werden

Rechnung:

1. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

2. Schritt: Kosten: 2 = Einzahlung: 2 
:: → es wird nicht gespart 
:: → Guthaben bleibt so wie es ist 

3. Schritt: Kosten: 1 < Einzahlung: 2 
:: → es wird gespart 

4. Schritt: Kosten: 3 > Einzahlung: 2 
:: → es wird eine 1 vom Guthaben genommen um die Kosten zu zahlen 

usw.

Man erkennt, dass vor teuren Operation (Wechsel von 3 auf 4 bzw. von 7 auf 8) genügend Guthaben angespart wurde, um die Kosten zu decken. Das Guthaben geht bei diesen Operationen immer wieder auf 1 zurück, aber es wird nie vollständig verbraucht (Dies kann natürlich auch mathematisch exakt bewiesen werden, wie wir es unten am Beispiel des dynamische Arrays zeigen). Wir schließen daraus, dass die durchschnittlichen oder '''amortisierten Kosten''' einer Inkrementierungsoperation gleich 2 sind.

Zum weiter Lesen: [[http://de.wikipedia.org/wiki/Account-Methode Wikipedia Account-Methode]]

====Fazit====
Die amortisierte Komplexität beschäftigt sich mit dem Durchschnitt aller Operation im ungünstigsten Fall. Operationen mit hohen Kosten, die aber nur selten ausgeführt werden, fallen bei der amortisierten Komplexität nicht so ins Gewicht. Bei Algorithmen, die gelegentlich eine "teure" Operation benutzen, ansonsten jedoch "billigen" Operationen aufrufen, kann die amortisierte Komplexität niedriger sein als die Komplexität im schlechtesten (Einzel-)Fall.

In unserem Beispiel fallen die teuren Einzelschritte (z.B. 4. und 8. Schritt) bei den amortisierten Kosten nicht so ins Gewicht, da wir die Kosten aus unserem Guthaben mitbezahlen können. Das Guthaben ist immer groß genug, weil jeder zweite Aufruf eine billige Operation ist, die nur ein Bit umdreht und somit das Ansparen ermöglichen. Diese Betrachtung zeigt, dass die amortisierte (d.h. durchschnittliche) Komplexität des Algoithmus niedriger (nämlich konstant) ist als die Komplexität im schlechtesten Fall.

===statisches Array===

Ein statisches Array hat eine feste Größe N und das Erweitern des Arrays um ein neues Element besitzt eine Komplexität von O(N),
denn es muss ein neues Array mit der Größe N+1 erzeugt werden. 

Anhängen eines weiteren Elements an ein statisches Array:

{| border="1" cellspacing="0" cellpadding="5" align="right"
!Schritte
|'''Array'''
(wie es aussehen könnte)
!Komplexität
|-
|<center>altes Array</center>
|<center>[0,1,2,3]</center>
|<center>-</center>
|-
|1. Array N+1
|<center>[None,None,None,None,None]</center>
|<center>O(N+1) = '''O(N)'''</center>
|-
|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 Daten aus dem alten Array werden in das neue Array mit der Länge N+1 kopiert 
(Die Operation besitzt nur eine Komplexität von O(N), wenn das Kopieren eines Elements eine Komplexität von O(1) besitzt) 
3. 'x' wird an die letzte Stelle des neuen Arrays geschrieben

Additionsregel: 
O(N) + O(N) + O(1) ∈ O(N), falls O(1) ∈ O(N) [O(max(O(N),O(1))] (Bedingung: N > 1)

===dynamisches Array===

Beim dynamischen Array werden mehr Speicherelemente reserviert als zur Zeit benötigt. Wir unterscheiden deshalb

::<tt>capacity</tt> = Anzahl 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 "capacity" 

Ist dieses Array voll, wird ein neues Datenarray der doppelten Größe allokiert, und die Daten werden vom alten ins neue Array kopiert. Die Vorgehensweise
beim Zufügen eines neuen Elements im Fall (size == capacity) ist also
* capacity wird verdoppelt 
: neue capacity = 2 * alte capacity
: (allgemein genügt es auch, wenn capacity wird um einen bestimmten Prozentsatz vergrößert wird,
:: neue capacity = alte capacity * c (mit c > 1, z.B. c = 1.2)
* 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

'''Folge:''' Die Kosten für das Vergrößern 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), wie wir jetzt zeigen:

===Analyse des dynamischen Arrays===

Durchschnitt der Gesamtkosten für N-maliges append = <math>\frac{1}{N} \sum_{i = 1}^N Kosten(i)</math>. Zur Analyse der amortisierten Komplexität wird ein Potential 
::Φi = 2*sizei - capacityi 
eingeführt, wobei das Array nach dem i-ten Einfüge-Schritt die Größe sizei und die Kapizität capacityi hat. Wir nehmen vereinfachend an, dass es keine Löschoperationen gibt. Dann gilt nach dem i-ten Schritt jeweils
::Φi = 2*i - capacityi 

Fall 1: Array ist nicht voll 
Es wird kein Umkopieren benötigt, da das Array noch nicht voll ist 
→ sizei-1 < capacityi-1 
→ capacityi == capacityi-1

Kosten: 1 (für Einfügen des neuen Elements) 
Potenzial vor append: Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append: Φi = 2i - capacityi-1 

amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = 1 + (2i - capacityi-1) - [2(i - 1) - capacityi-1]
::::: = 1 + 2i - capacityi-1 - 2i + 2 + capacityi-1
::::: = 1 + <del>2i</del> - <del>capacityi-1</del> - <del>2i</del> + 2 + <del>capacityi-1</del>
::::: = 1 + 2
::::: = 3 = O(1) → konstant

Fall 2: Array ist voll 
Vor dem i-ten append muss umkopiert werden 
→ sizei-1 == capacityi-1 == i-1 
→ Allokieren eines neuen statischen Arrays mit verdoppelter Kapazität notwendig, also capacityi == 2*capacityi-1

Kosten: (i-1) + 1 (für Umkopieren und Einfügen des neuen Elements) 
Potenzial vor append = Φi-1 = 2(i - 1) - capacityi-1 
Potenzial nach append = Φi = 2i - 2 capacityi-1 
amortisierte Kosten = Kosteni + Φ(i) - Φ(i-1)
::::: = ((i - 1) + 1) + 2i - 2 capacityi-1 - [2(i-1) - capacityi-1]
::::: = i + <del>2i</del> - 2 capacityi-1 - <del>2i</del> + 2 - capacityi-1
::::: = i + 2 - capacityi-1
::::: = i + 2 - (i - 1) (da capacityi-1 = i-1)
::::: = 3 = O(1) → konstant

'''Damit wurde bewiesen, dass die Operation <tt>append</tt> beim dynamischen Array eine amortisierte Komplexität von 3 Einheiten hat, also <tt>append</tt> ∈ O(1)'''. Diese Operation kann deshalb gefahrlos in der inneren Schleife eines Algorithmus benutzt werden.

==== Beispiel für 9 Einfügeoperationen ====

{| border="1" cellspacing="0" cellpadding="5"
!Array 
(wie es aussehen könnte)
!size
!capacity
!Kosten für append (einschließlich Umkopieren)
!Summe Kosten
!Durchschnittskosten
!Φi = 2 * size - capacity 
(i = size)
!Potenzialdifferenz 
Δ Φi = Φi - Φi-1
!amortisierte Kosteni 
= Kosteni + Δ Φi
|-
| <center>[None]</center>
| <center>0</center>
| <center>1</center>
| <center>-</center>
| <center>-</center>
| <center>-</center>
| <center>-1</center>
| <center>-</center>
| <center>-</center>
|-
| <center>[a]</center><center>Array ist voll!</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>1</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b]</center><center>Array ist voll!</center>
| <center>2</center>
| <center>2</center>
| <center>1 + 1</center>
| <center>3</center>
| <center>3/2</center>
| <center>2</center>
| <center>1</center>
| <center>3</center>
|-
| <center>[a,b,c,None]</center>
| <center>3</center>
| <center>4</center>
| <center>2 + 1</center>
| <center>6</center>
| <center>6/3</center>
| <center>2</center>
| <center>0</center>
| <center>3</center>
|-
| <center>[a,b,c,d]</center><center>Array ist voll!</center>
| <center>4</center>
| <center>4</center>
| <center>1</center>
| <center>7</center>
| <center>7/4</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,None,None,None]</center>
| <center>5</center>
| <center>8</center>
| <center>4 + 1</center>
| <center>12</center>
| <center>12/5</center>
| <center>2</center>
| <center>-2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,None,None]</center>
| <center>6</center>
| <center>8</center>
| <center>1</center>
| <center>13</center>
| <center>13/6</center>
| <center>4</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,None]</center>
| <center>7</center>
| <center>8</center>
| <center>1</center>
| <center>14</center>
| <center>14/7</center>
| <center>6</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h]</center><center>Array ist voll!</center>
| <center>8</center>
| <center>8</center>
| <center>1</center>
| <center>15</center>
| <center>15/8</center>
| <center>8</center>
| <center>2</center>
| <center>3</center>
|-
| <center>[a,b,c,d,e,f,g,h,j,None,None,None, 
None,None,None,None]</center>
| <center>9</center>
| <center>16</center>
| <center>8 + 1</center>
| <center>24</center>
| <center>24/9</center>
| <center>2</center>
| <center>-6</center>
| <center>3</center>
|-
|}

Die durchschnittlichen Kosten betragen stets etwa 2 Einheiten, schwanken allerdings so, dass nicht unmittelbar ersichtlich ist, ob dies für sämtliche Einfügeoperationen gilt. Die amortisierte Komplexität, die mit Hilfe des Potentials berechnet wird, ist hingegen konstant 3, wie auch im obigen Beweis für alle Einfügeoperationen allgemein gezeigt wurde.

Korrektheit

2008-07-22T09:02:00Z

Jschleic: typo

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
# 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]).
# '''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: Prüfung der syntaktischen Korrektheit, formaler Korrektheitsbeweis und Softwaretest.

== Syntaktische Korrektheit ==

Die syntaktische Korrektheit behandeln wir hier nur kurz und der Vollständigkeit halber. Sie wird 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
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ückgeweisen 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

== Formaler Korrektheitsbeweis ==
=== (Halb-)Automatisches Beweisen ===
Man versucht, die Hypothese H: ''Algorithmus ist korrekt'' entweder mathematisch zu beweisen oder zu widerlegen. Dieses Beweisverfahren heißt dann halbautomatisch, wenn der Mensch in den Entscheidungsprozess miteinbezogen 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. [http://en.wikipedia.org/wiki/Z_notation Z]). 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 vorgesellt worden sind, ist nun die Frage, welcher der beiden Vorgänge der bessere ist, aufzugreifen. 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 (allerding 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/lib/module-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 Tests selbst nur nähreungsweise 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.

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

====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 testes 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 äquvalenten 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) gestestet 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 Prameterbelegung). Der letzte Test hat die Parameter v13, v23, v32
assertEqual( foo(v13, v23, v32), foo_reference9)
:Man überzeugt sich leicht, dass diese 9 Tests jede mögliche Paarung genau einmal enthalten. Hat der Algorithmus 4 Parameter, benötigt man einen zweiten Latin Square, der zum ersten orthogonal ist. Zwei Latin Squares P und Q heißen orthogonal, wenn alle Paare cij=(Pij, Qij) eindeutig sind, d.h. es gilt cij≠ckl falls i≠k und j≠l. Ein zu dem obigen P orthogonales Q ist z.B.
:<math>Q=\begin{pmatrix}1 & 2 & 3 \\
3 & 1 & 2 \\
2 & 3 & 1\end{pmatrix}</math>
: Jetzt bildet man Kombinationen aus 4 Zahlen, indem man zur obigen Tabelle noch eine vierte Zeile hinzufügt, die die aktuellen Einträge von Q für den jeweiligen Zeilen- und Spaltenindex enthält:
{| border="1" cellspacing="0" cellpadding="7" align="center"
|-align="center"
|
! Komb. 1
! Komb. 2
! Komb. 3
! Komb. 4
! Komb. 5
! Komb. 6
! Komb. 7
! Komb. 8
! Komb. 9
|-
!Zahl 1 (Zeilenindex)
|align="center" | 1
|align="center" | 1
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 3
|-
! Zahl 2 (Spaltenindex)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|-
! Zahl 3 (aktueller Matrixeintrag von P)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 3
|align="center" | 1
|align="center" | 2
|-
! Zahl 4 (aktueller Matrixeintrag von Q)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 1
|}

:Es sind immer noch nur 9 Tests nötig, um alle Paarungen zu erzeugen. Der erste und letzte Test sind nun:
assertEqual( bar(v11, v21, v31, v41), bar_reference1)
...
assertEqual( bar(v13, v23, v32, v41), bar_reference9)
:Die Methode der Latin Squares funktioniert auch, wenn mehr als 3 Belegungen für jeden Parameter möglich sind, und wenn es mehr als 4 Parameter gibt. Für die Einzelheiten verweisen wir auf die Literatur, z.B. [http://citeseer.ist.psu.edu/78354.html], [http://en.wikipedia.org/wiki/Latin_square]. Empirische Untersuchungen haben ergeben, dass die Methode der vollständigen Paarung oft über 90% der Fehler in einem Programm finden kann.

Korrektheit

2008-07-22T08:59:17Z

Jschleic: typos

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. Der 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
# 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]).
# '''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: Prüfung der syntaktischen Korrektheit, formaler Korrektheitsbeweis und Softwaretest.

== Syntaktische Korrektheit ==

Die syntaktische Korrektheit behandeln wir hier nur kurz und der Vollständigkeit halber. Sie wird 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
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ückgeweisen 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

== Formaler Korrektheitsbeweis ==
=== (Halb-)Automatisches Beweisen ===
Man versucht, die Hypothese H: ''Algorithmus ist korrekt'' entweder mathematisch zu beweisen oder zu widerlegen. Dieses Beweisverfahren heißt dann halbautomatisch, wenn der Mensch in den Entscheidungsprozess miteinbezogen 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. [http://en.wikipedia.org/wiki/Z_notation Z]). 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 vorgesellt worden sind, ist nun die Frage, welcher der beiden Vorgänge der bessere ist, aufzugreifen. 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 (allerding 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/lib/module-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 Tests selbst nur nähreungsweise 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.

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

====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 testes 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 äquvalenten 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) gestestet 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 Prameterbelegung). Der letzte Test hat die Parameter v13, v23, v32
assertEqual( foo(v13, v23, v32), foo_reference9)
:Man überzeugt sich leicht, dass diese 9 Tests jede mögliche Paarung genau einmal enthalten. Hat der Algorithmus 4 Parameter, benötigt man einen zweiten Latin Square, der zum ersten orthogonal ist. Zwei Latin Squares P und Q heißen orthogonal, wenn alle Paare cij=(Pij, Qij) eindeutig sind, d.h. es gilt cij≠ckl falls i≠k und j≠l. Ein zu dem obigen P orthogonales Q ist z.B.
:<math>Q=\begin{pmatrix}1 & 2 & 3 \\
3 & 1 & 2 \\
2 & 3 & 1\end{pmatrix}</math>
: Jetzt bildet man Kombinationen aus 4 Zahlen, indem man zur obigen Tabelle noch eine vierte Zeile hinzufügt, die die aktuellen Einträge von Q für den jeweiligen Zeilen- und Spaltenindex enthält:
{| border="1" cellspacing="0" cellpadding="7" align="center"
|-align="center"
|
! Komb. 1
! Komb. 2
! Komb. 3
! Komb. 4
! Komb. 5
! Komb. 6
! Komb. 7
! Komb. 8
! Komb. 9
|-
!Zahl 1 (Zeilenindex)
|align="center" | 1
|align="center" | 1
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 3
|-
! Zahl 2 (Spaltenindex)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 3
|-
! Zahl 3 (aktueller Matrixeintrag von P)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 2
|align="center" | 3
|align="center" | 1
|align="center" | 3
|align="center" | 1
|align="center" | 2
|-
! Zahl 4 (aktueller Matrixeintrag von Q)
|align="center" | 1
|align="center" | 2
|align="center" | 3
|align="center" | 3
|align="center" | 1
|align="center" | 2
|align="center" | 2
|align="center" | 3
|align="center" | 1
|}

:Es sind immer noch nur 9 Tests nötig, um alle Paarungen zu erzeugen. Der erste und letzte Test sind nun:
assertEqual( bar(v11, v21, v31, v41), bar_reference1)
...
assertEqual( bar(v13, v23, v32, v41), bar_reference9)
:Die Methode der Latin Squares funktioniert auch, wenn mehr als 3 Belegungen für jeden Parameter möglich sind, und wenn es mehr als 4 Parameter gibt. Für die Einzelheiten verweisen wir auf die Literatur, z.B. [http://citeseer.ist.psu.edu/78354.html], [http://en.wikipedia.org/wiki/Latin_square]. Empirische Untersuchungen haben ergeben, dass die Methode der vollständigen Paarung oft über 90% der Fehler in einem Programm finden kann.

Sortieren

2008-07-22T08:55:13Z

Jschleic: typos

----
== Laufzeitmesung in Python ==

Verwendung der '''timeit-Bibliothek''' für die Hausaufgabe.

* Importiere das timeit-Modul: <tt>import timeit</tt>
* Teile den Algorithmus in die Initialisierungen und den Teil, dessen Geschwindigkeit gemessen werden soll. Beide Teile werden in jeweils einen (mehrzeiligen) String eingeschlossen:

+--------+ +----+ setup = """ prog = """
| algo | --> |init| +----+ +----+
| | +----+ |init| |prog|
| | +----+ +----+
| | +----+ """ """
| | --> |prog|
+--------+ +----+

* aus den beiden Strings wird ein Timeit-Objekt erzeugt: <tt>t = timeit.Timer(prog, setup)</tt>
* Frage: Wie oft soll die Algorithmik wiederholt werden
:z.B. N = 1000
* Zeit in Sekunden für N Durchläufe: <tt>K = t.timeit(N)</tt>
:Zeit für 1 Durchlauf: K/N

----
3.Stunde am 16.04.2008

==Sortierverfahren==

=== Motivation ===
'''Def:'''
Ein Sortierverfahren ist ein Algorithmus, der dazu dient, eine Liste von Elementen zu sortieren.
* Literatur, siehe Sortierverfahren; Bubblesort 1956, Quicksort 1962. Librarysort 2004

'''Anwendungen'''
* Sortierte Daten sind häufig Vorbedingungen für Suchverfahren (Speziell für effiziente Suchalgorithmen mit Komplexität <math>\mathcal{O}(log(N))</math>)
* Darstellung von Daten gemäß menschlicher Wahrnehmung
* Aus programmiertechnischer Anwendungssicht hat das Sortierproblem allerdings heute an Relevanz verloren da
** gängige Programmiersprachen heute typunabhängige Algorithmen zur Verfügung stellen. Der Programmierer braucht sich deshalb in den meisten Fällen nicht mehr um die Implementierung von Sortieralgorithmen zu kümmern. In C/C++ sorgen dafür beispielsweise Methoden aus der [http://de.wikipedia.org/wiki/Standard_Template_Library STL].
** Festplatten / Hauptspeicher heute weniger limitierenden Charakter haben, so dass Standardsortierverfahren meist ausreichen, während komplizierte, speicher-sparende Sortieralgorithmen nur noch selten benötigt werden.
* Die Kenntnis grundlegender Sortieralgorithmen ist trotzdem immer noch nötig: Einerseits kann man vorgefertigte Bausteine nur dann optimal einsetzen, wenn man weiß, was hinter den Kulissen passiert und andererseits verdeutlicht gerade das Sortierproblem wichtige Prinzipien der Algorithmenentwicklung und -analyse in sehr anschaulicher Form.

=== Vorraussetzungen/ Spielregeln ===

==== Mengentheoretische Anforderungen====
Definition Totale Ordnung/ Total gordnete Menge:
Eine Totale Ordnung / Total geordnete Menge ist eine binäre Relation
<math>R \subseteq M \times M</math> über einer Menge <math>M</math>, die transitiv, antisymmetrisch und total ist. 

<math>R</math> sei dargestellt als infix Notation <math>\le </math> dann, falls M total geordnet, gilt
<math> \forall a,b,c \ \epsilon M </math> 
(1) <math>a \le b \bigwedge b \le a \Rightarrow a=b </math> (antisymmetrisch) 
(2) <math>a \le b \bigwedge b \le c \Rightarrow a \le c </math> (transitiv) 
(3) <math>a \le b \bigvee b \le a </math> (total) 
Bemerkung: aus (3) folgt <math> a \le a </math> (reflexiv) 

''Hab in der Wiki eine gute Seite dazu gefunden [http://de.wikipedia.org/wiki/Ordnungsrelation'' Ordnungsrelation]

==== Datenspeicherung ====

Die Daten liegen typischerweise in Form von Arrays oder verketteten Listen vor. Ja nach Datenstruktur sind andere Sortieralgorithmen am besten geeignet.
;Array:
+---+---+---+---+---+---+---+---+---+
|///| | | | | | | |///|
+---+---+---+---+---+---+---+---+---+
\________________ ____________________/
\/
N
Datenelemente können über Indexoperation a[i] gelesen, überschrieben und miteinander vertauscht werden. Vorteil: Die Zugriffsreihenfolge auf die Datenelemente ist beliebig. Nachteil: Einfügen oder Löschen von Elementen aus dem Array ist relativ aufwändig.

;Vekettete Liste:
+---+ +---+ +---+
| | --> | | --> | | --> Ende
+---+ +---+ +---+

Jeder Knoten der Liste enthält ein Datenelement und einen Zeiger auf den nächsten Knoten. Vorteil: Einfügen und Löschen von Elementen ist effizient möglich. Nachteil: effizienter Zugriff nur auf den Nachfolger eines gegebenen Elements, d.h. Zugriffsreihenfolge ist nicht beliebig.

==== Stabilität ====

Ein Sortierverfahren heißt ''stabil'' falls die relative Reihenfolge gleicher Schlüssel durch die Sortierung nicht verändert wird.

Beispiel: Sortiere eine Liste von Paaren <tt>[(3,7), (4,2), (4,1), (2,2), (2,8)]</tt>, wobei die Reihenfolge nur durch das erste Element (Schlüsselelement) jeden Paares festgelegt wird.
Dann erzeugt ein stabiles Sortierverfahren die Ausgabe
[(2,2), (2,8), (3,7), (4,2), (4,1)]
während die Ausgabe
[(2,2), (2,8), (3,7), (4,1), (4,2)]
nicht stabil ist (die Paare <tt>(4,1), (4,2)</tt> sind vertauscht).

==== Charakterisierung der Effizienz von Algorithmen ====

:(a) Komplexität O( 1), O(n), etc. wird in Kapitel [[Effizienz]] erklärt.
:(b) Zählen der notwendigen Vergleiche
:(c) Messen der Laufzeit mit 'timeit' (auf identischen Daten)

'''Rekursive Beziehungen'''
zerlegt die ursprünglichen Probleme in kleinere Probleme und wendet den Algorithmus auf die kleineren Probleme an; daraufhin werden die Teilprobleme zur Lösung des Gesamtproblems verwendet.
d.h. Laufzeit (operativer Vergleich) für N Eingaben hängt von der Laufzeit der Eingaben für die Teilprobleme

'''Aufwand'''

(i) rekursives/ lineares Durchlaufen der Eingabedaten, Bearbeitung einzelner Elemente

C(N)= C(N-1)+ N ; N>1, C(1)= 1 +---+---+---+---+---+---+---+---+---+
= C(N-2) +(N-1)+ N | 7 | 3 | 2 | 5 | 6 | 8 | 1 | 4 | 2 |
= C(N-3) + (N-2) + (N-1) + N +---+---+---+---+---+---+---+---+---+
= ... ________________________/
= C(1) + 2+...+(N-1) +N /
+---+---+---+---+---+---+---+---+---+
N(N+1) N² | 1 | 3 | 2 | 5 | 6 | 8 | 7 | 4 | 2 |
= ----- ~ -- +---+---+---+---+---+---+---+---+---+
2 2

(ii) rekursives halbieren der Menge der Eingabedaten

C(N)= C(N/2)+1 ; N>1, C(1)=0
Aus Gründen der Einfachheit sei N = 2n

C(N)= C(2^n)= C(<math>2^{n-1}</math>) + 1

= C(<math>2^{n-1}</math>) + 1 + 1
= ...

= C(<math>2^0</math>) + n
= n
= <math>log_2 N</math>
+---+---+---+---+-|-+---+---+---+---+
| | | | | | | | | |
+---+---+---+---+-|-+---+---+---+---+
+---+---+---+---+
| | | | |
+---+---+---+---+
+---+---+ +---+
| | | -> | |
+---+---+ +---+

(iii) rekursives halbieren, lineare Bearbeitung, jedes Elements

C(N)= 2C(N/2)+ N; N>1, C(1)= 0
Sei N= <math>2^n</math>
C(N)= C(<math>2^n</math>)= 2C (<math>2^{n-1}</math>)+ <math>2^n</math>
<=> <math> \cfrac{C(2^n)}{2^n}</math> = <math> \cfrac{2C(2^{n-1})}{2^{n-1}}</math>

= <math> \cfrac{2C(2^{n-2})+2^{n-1}}{2^{n-1}}+1</math>
= <math> \cfrac{2C(2^{n-2})}{2^{n-2}}+1 +1</math>
=...
= n
<=> C(<math>2^n</math>)= <math>2^n</math> * n
<=> C= N log<math>_2</math>N

==Selection Sort==

===Algorithmus===

array = [...] # zu sortierendes Array

for i in range(len(array)-1):
min = i
for j in range(i+1, len(array)):
if a[j]< a[min]:
min = j
a[i], a[min] = a[min], a[i] # Vertausche a[i] mit dem kleinsten rechts befindlichen Element
# Elemente links von a[i] und a[i] selbst befinden sich nun in ihrer endgültigen Position

Beispiel: Sortieren der Liste <tt>[S,O,R,T,I,N,G]</tt>.

erste Iteration der äußeren Schleife, Zustand ''vor'' dem Vertauschen:
i=0 min
+---+---+---+---+---+---+---+
| S | O | R | T | I | N | G |
+---+---+---+---+---+---+---+

erste Iteration der äußeren Schleife, Zustand ''nach'' dem Vertauschen:
+---|---+---+---+---+---+---+
| G | O | R | T | I | N | S |
+---|---+---+---+---+---+---+

zweite Iteration der äußeren Schleife:
i=1 min
+---|---+---+---+---+---+---+
| G | O | R | T | I | N | S |
+---|---+---+---+---+---+---+

weitere Iterationen:
i=2 min
+---+---|---+---+---+---+---+
| G | I | R | T | O | N | S |
+---+---|---+---+---+---+---+

i=3 min
+---+---+---|---+---+---+---+
| G | I | N | T | O | R | S |
+---+---+---|---+---+---+---+

i=4 min
+---+---+---+---+---+---+---+
| G | I | N | O | T | R | S |
+---+---+---+---+---+---+---+
...

===Laufzeit===

Da in jeder Iteration der ''inneren'' Schleife ein Vergleich <tt>a[j]< a[min]</tt> durchgeführt wird, ist die Anzahl der Vergleiche ein gutes Maß für den Aufwand des Algorithmus und damit für die Laufzeit. Sei C(N) die Anzahl der notwendigen Vergleiche, um ein Array der Größe N zu sortieren. Die Arbeitsweise des Algorithmus kann dann so beschrieben werden: Führe N-1 Vergleiche aus, bringe das kleinste Element an die erste Stelle, und fahre mit dem Sortieren des Rest-Arrays (Größe N-1) rechts des ersten Elements fort. Dafür sind nach Definition noch C(N-1) Vergleiche nötig. Es gilt also:
:::<math>C(N) = C(N-1) + (N-1)</math>
C(N-1) können wir nach der gleichen Formel einsetzen, und erhalten:
:::<math>C(N) = C(N-2) + (N-2) + (N-1)</math>
Wir können in dieser Weise weiter fortfahren. Bei C(1) wird das Einsetzen beendet, denn für ein Array der Länge 1 sind keine Vergleiche mehr nötig, also C(1) = 0. Wir erhalten somit
:::<math>C(N) = C(N-3) + (N-3) + (N-2) + (N-1)</math>
:::<math>...</math>
:::<math>C(N) = C(1) + 1 + 2 + ...+ (N-2)+ (N-1)</math>
:::<math>C(N) = 0 + 1 + 2 + ...+ (N-2)+ (N-1)</math>
Nach der Gaußschen Summenformel ist dies
:::<math>C(N) = \frac {(N-1)N}{2}\approx \cfrac {(N^2)}{2}</math> (für große N).

In jedem Durchlauf der äußeren Schleife werden außerdem zwei Elemente ausgetauscht. Es gilt für die Anzahl der Austauschoperationen
:::<math>A(N)= N-1</math>

===Stabilität===

Selection Sort ist stabil, wenn die Vergleiche durch <tt>a[j] < a[min]</tt> erfolgen, weil dann immer das erste Element mit einem gegebenen Schlüssel als erster nach vorn gebracht wird. Bei Vergleichen <tt>a[j] <= a[min]</tt> wird hingegen das letzte Element zuerst nach vorn gebracht, somit ist Selection Sort dann nicht stabil.

==Insertion Sort==

* wird in der Übungsgruppe behandelt, siehe auch in der [http://de.wikipedia.org/wiki/Insertionsort WikiPedia]
* Erweiterung: [http://en.wikipedia.org/wiki/Shell_sort Shell sort]

== Mergesort ==

===Algorithmus ===

Zugrunde liegende Idee:
* Zerlege das Problem in zwei möglichst gleich große Teilprobleme ("Teile und herrsche"-Prinzip -- divide and conquer)
* Löse die Teilprobleme rekursiv
* Führe die Teillösungen über Mischen (merging) in richtig sortierter Weise zusammen.
Der Algorithmus besteht somit aus zwei Teilen

====Zusammenführen -- merge====

a und b sind zwei sortierte Listen, die in eine sortierte Ergebnisliste kombiniert werden.

def merge(a,b):
c = [] # zunächst leere Ergebnisliste
i, j = 0, 0
while i < len(a) and j < len(b):
# wähle des kleinste der noch nicht angefügten Elemente
if a[i] <= b[j]:
c.append(a[i])
i += 1
else:
c.append(b[j])
j += 1
# eine Liste ist jetzt aufgebraucht => der Rest der anderen wird einfach an c angehängt
if i < len(a):
c += a[i:]
else:
c += b[j:]
return c

====rekursives Sortieren====

def mergeSort(a): # a ist das zu sortierende Array
if len(a) <= 1:
return a # Rekursionsabschluß: leere Arrays und Arrays mit einem Element müssen nicht sortiert werden
else:
left = a[:len(a)/2] # linkes Teilarray
right = a[len(a)/2:] # rechtes Teilarray
leftSorted = mergeSort(left) # rekursives Sortieren der Teilarrays
rightSorted = mergeSort(right) # ...
return merge(leftSorted, rightSorted) # Zusammenführen der Teilarrays

Bei der Sortierung mit Mergesort wird das Array immer in zwei Teile geteilt. → Es entsteht ein Binärbaum der Tiefe <math>\log_2 N</math>.

Beispiel: Sortieren der Liste <tt>[S,O,R,T,I,N,G]</tt>.

Der Algorithmus läuft in der folgenden Skizze zunächst rekursiv von unten nach oben (Zerlegen in Teillisten), danach werden die sortierten Teillisten von oben nach unten zusammengeführt (diese sortierten Teillisten sind in der Skizze dargestellt).

Schritt 0:
S 0 R T I N G S O R T I N G #Arraylänge: N/8 Vergleiche: 0
Schritt 1: \ / \ / \ / /
OS RT IN G OS RT IN / #Arraylänge: N/4 Vergleiche: 3 * 2 = 6
Schritt 2: \ / \ /
ORST GIN ORST GIN #Arraylänge: N/2 Vergleiche: 4 + 3 = 7
\ /
Schritt3: \ /
GINORST GINORST #Arraylänge: N Vergleiche: N = 7

===Laufzeit ===

Man erkennt an der Skizze, dass der Rekursionsbaum für ein Array der Länge N die Tiefe log N hat. Auf jeder Ebene werden weniger als N Vergleiche ausgeführt, so dass insgesamt weniger als N*log N Vergleiche benötigt werden. Dies ist natürlich wesentlich effizienter als die (N-1)*N/2 Vergleiche von Selection Sort. Mathematisch exakt kann man die Anzahl der Vergleiche durch die folgende Rekursionsformel berechnen:
:::<math>C(N) = C(\lfloor N/2\rfloor) + C(\lceil N/2\rceil) + N</math>
Der Aufwand ergibt sich aus dem Aufwand für die beiden Teilprobleme plus dem Aufwand für N Vergleiche beim Zusammenführen der sortierten Teillisten. Dabei stehen die Zeichen <math>\lfloor \rfloor</math> und <math>\lceil \rceil</math> für abrunden bzw. aufrunden, weil ein Problem mit ungeradem N nicht in zwei exakt gkeiche Teile geteilt werden kann. Um diese Komplikation zu vermeiden, beschränken wir uns im folgenden auf den Fall <math>N = 2^n</math> (mit etwas höherem Aufwand kann man zeigen, dass diese Einschränkung nicht notwendig ist und die Resultate für alle N gelten). Die vereinfachte Aufwandsformel lautet:
:::<math>C(N) = 2 C(N/2) + N</math>
Durch Einsetzen der Formel für N/2 erhalten wir:
:::<math>C(N) = 2 (2 C(N/4) + N/2) + N = 4 C(N/4) + N + N</math>
:::<math>C(N) = 4 (2 C(N/8) + N/4) + N + N = 8 C(N/8) + N + N + N</math>
:::<math>...</math>
Die Rekursion endet, weil für ein Array der Größe <math>N=1</math> keine Vergleiche mehr benötigt werden, also <math>C(1) = 0</math> gilt. Mit <math>N=2^n</math> ist dies aber gerade nach <math>n = \log_2 N</math> Zerlegungen der Fall. Merge Sort benötigt also
:::<math>C(N) = N + ... + N = n \cdot N = N\cdot \log_2 N</math>
Vergleiche.

===Weitere Eigenschaften von MergeSort ===

* Mergesort ist '''stabil''': wegen des Vergleichs <tt>a[i] <= b[j]</tt> wird die Position gleicher Schlüssel im Algorithmus <tt>merge(a,b)</tt> nicht verändert -- bei gleichem Schlüssel hat, wie gefordert, das linke Element Vorrang.
* Mergesort ist '''unempfindlich gegenüber der ursprünglichen Reihenfolge der Eingabedaten'''. Grund dafür ist
** die vollständige Aufteilung des Ausgangsarrays in Arrays der Länge 1 und
** dass <tt>merge(a,b)</tt> die Vorsortierung nicht ausnutzt, d.h. die Komplexität von <tt>merge(a,b)</tt> ist sortierungsunabhängig.
* Diese Eigenschaft kann unerwünscht sein, wenn ein Teil des Arrays oder gar das ganze Array schon sortiert ist. Es wird nämlich in jedem Fall das ganze Array neu sortiert.
* Merge Sort eignet sich für das Sortieren von '''verketteten Listen''', weil die Listenelemente stets von vorn nach hinten durchlaufen werden. In diesem Fall muss <tt>merge(a, b)</tt> keine neue Liste <tt>c</tt> für das Ergebnis anlegen, sondern kann einfach die Verkettung der Listenelemente von <tt>a</tt> und <tt>b</tt> entsprechend anpassen. In diesem Sinne arbeitet Merge Sort auf verketten Listen "in place", d.h. es wird kein zusätzlicher Speicher benötigt.
* Im Gegensatz dazu benötigt <tt>merge(a,b)</tt> zusätzlichen Speicher für das Ergebnis <tt>c</tt>, wenn die Daten in einem Array gegeben sind.

== Quicksort ==

* Quicksort wurde in den 60er Jahren von Charles Antony Richard Hoare [http://de.wikipedia.org/wiki/C._A._R._Hoare] entwickelt. Es gibt viele Implementierungen von Quicksort, vgl. [http://de.wikipedia.org/wiki/Quicksort].
* Dieser Algorithmus gehört zu den "Teile und herrsche"-Algorithmen (divide-and-conquer) und ist der Standardalgorithmus für Sortieren.
* Im Gegensatz zu Merge Sort wird das Problem aber nicht immer in zwei fast gleich große Teilprobleme zerlegt. Dadurch vermeidet man, dass zusätzlicher Speicher benötigt wird (Quick Sort arbeitet auch für Arrays "in place"). Allerdings erkauft man sich dies dadurch, dass Quick Sort bei ungünstigen Eingaben (die Bedeutung von "ungünstig" ist je nach Implementation verschieden) nicht effizient arbeitet. Da solche Eingaben jedoch in der Praxis fast nie vorkommen, tut dies der Beliebtheit von Quicksort keinen Abbruch.

=== Algorithmus===

Wie Merge Sort arbeitet Quick Sort rekursiv. Hier werden die Daten allerdings zuerst vorbereitet (in der Funktion <tt>partition</tt>), und danach erfolgt der rekursive Aufruf:

def quicksort(a, l, r):
"""a ist das zu sortierende Array,
l und r sind die linke und rechte Grenze des zu sortierenden Bereichs"""

if r > l: # Rekursionsabschluss: wenn r <= l, ist der Bereich leer und muss nicht mehr sortiert werden
i = partition(a, l, r) # i ist der Index des sog. Pivot-Elements (s. u.)
quicksort(a, l, i-1) # rekursives Sortieren der beiden Teilarrays
quicksort(a, i+1, r) # ...

Der Schlüssel des Algorithmus ist offensichtlich die Funktion <tt>partition</tt>. Diese wählt ein Element des Arrays aus (das Pivot-Element) und bringt es an die richtige Stelle (also an den Index <tt>i</tt>, der von <tt>partition</tt> zurückgegeben wird). Ausserdem stellt sie sicher, dass alle Elemente in der linken Teilliste (Index < <tt>i</tt>) kleiner als <tt>a[i]</tt>, und alle Elemente in der rechten Teilliste größer also <tt>a[i]</tt> sind:
# <math>a[i]</math> ist sortiert, d.h. dieses Element ist am endgültigen Platz.
# <math>\forall x \in \left\{ a \left[ l \right] , ... a \left[ i-1 \right] \right\} : x \leq a \left[ i \right]</math>
# <math>\forall x \in \left\{ a \left[ i+1 \right], ... a \left[ r \right] \right\} : x \geq a \left[ i \right]</math>

l r
+---+---+---+---+---+---+---+---+---+
Array: | | | | |\\\| | | | |
+---+---+---+---+---+---+---+---+---+
\______ _____/ i \______ _____/
\/ \/
<=a[i] >=a[i] (a[i] ist das Pivot-Element)

Die Position von <tt>i</tt> richtet sich also offensichtlich danach, wie viele Elemente im Bereich <tt>l</tt> bis <tt>r</tt> kleiner bzw. größer als das gewählte Pivot-Element sind. Der Wahl eines guten Pivot-Elements kommt demnach eine große Bedeutung zu (s.u.).

In der einfachsten Version wird <tt>partition</tt> wie folgt definiert:

def partition(a, l, r):
pivot = a[r] # Pivot-Element. Hier wird willkürlich das letzte Element verwendet.
i = l # i und j sind Laufvariablen
j = r - 1

while True:
while a[i] <= pivot and i < r:
i += 1 # finde von links das erste Element > pivot
while a[j] >= pivot and j > l:
j -= 1 # finde von rechts den ersten Eintrag <= pivot
if i >= j: break # keine weiteren Elemente zum Tauschen => Schleife beenden
a[i], a[j] = a[j], a[i] # a[i] und a[j] sind beide auf der falschen Seite des Pivot => vertausche sie
if a[i] > pivot:
a[i], a[r] = a[r], a[i]
return i

Die folgende Skizze verdeutlicht das Austauschen

p
+---+---+---+---+---+---+---+---+---+
Array: | | | | | | | | |\\\|
+---+---+---+---+---+---+---+---+---+
------> a[i]>p a[j]<p <-----
| |
+---------------+
Diese zwei Elemente werden ausgetauscht.

Dies wird wiederholt, bis sich die Zeiger treffen oder einander überholt haben. Am Schluss wird das Pivot-Element an die richtige Stelle verschoben:

p
+---+---+---+---+---+---+---+---+---+
Array: | | | | |\\\| | | | |
+---+---+---+---+---+---+---+---+---+
i
-----------------> <-----------------

Beispiel: Partitionieren des Arrays <tt>[A,S,O,R,T,I,N,G,E,X,A,M,P,L,E]</tt> mit Pivot 'E'.

l,i --> <-- j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | S | O | R | T | I | N | G | E | X | A | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i <--------- Vertauschen ---------> j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | S | O | R | T | I | N | G | E | X | A | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i <-------------------> j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | O | R | T | I | N | G | E | X | S | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

j i r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | R | T | I | N | G | O | X | S | M | P | L | E | --> Hier wird die
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Schleife verlassen.

j i <---------------------------------------> r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | R | T | I | N | G | O | X | S | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | E | T | I | N | G | O | X | S | M | P | L | R | --> Hier wird partition() beendet.
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Weitere ausführliche Erklärungen der Implementation findet man bei Sedgewick.

=== Laufzeit===

Wir müssen hier den schlechtesten und den typischen Fall unterscheiden. Der schlechteste Fall tritt ein, wenn das Array bereits sortiert ist. Dann ist das Pivot-Element immer bereits am richtigen Platz, so dass <tt>partition(a, l, r)</tt> stets den Index <tt>i = r</tt> zurück. Daher wird das Array niemals in zwei etwa gleichgroße Teile zerlegt. Die Anzahl der Vergleiche ergibt sich als

:::<math>C(N) = (N+1) + C(N-1) + C(0)</math>
:::<math>C(0) = 0</math>

mit (N+1) Vergleichen in <tt>partition()</tt>. Durch sukzessives Einsetzen erhalten wir:

:::<math>C(N) = (N+1) + (N) + (N-1) + ... + 1 = (N+1) N / 2</math>

In diesem Fall ist Quick Sort also nicht schneller als Selection Sort. Wir beschreiben mögliche Verbesserungen unten. Im typischen Fall (wenn nämlich das Array zufällig sortiert ist) sieht die Situation wesentlich besser aus. Bei zufälliger Sortierung wird jeder Index mit gleicher Wahrscheinlichkeit zur Pivot-Position. Wir mitteln deshalb über alle möglichen Positionen:

:::<math>C(N) = (N+1) + \frac{1}{N} \sum_{k=1}^{N} \left[ C(k-1) + C(N-k) \right]</math> für <math> N>0</math>

wobei <math>k</math> über alle möglichen Teilungspunkte läuft. Die Summe (der mittlere Aufwand über alle möglichen Zerlegungen) kann vereinfacht werden zu
:::<math>\frac{1}{N} \sum_{k=1}^{N} \left[ C(k-1) + C(N-k) \right] = 2 \frac{1}{N} \sum_{k=1}^{N} C(k-1) </math>
Die Auflösung der Formel ist etwas trickreich. Wir multiplizieren zunächst beide Seiten mit N:

:::<math>
N \cdot C(N) = N \left[ (N+1) + \frac{2}{N} \sum_{k=1}^{N} C(k-1) \right] = N (N+1) + 2\; \sum_{k=1}^{N} C(k-1)</math>

Durch die Substitution <math>N \rightarrow N-1</math> erhalten wir die entsprechende Formel für N-1:

:::<math>
(N-1) \cdot C(N-1) = (N-1) N + 2\; \sum_{k=1}^{N-1} C(k-1)</math>

Wir subtrahieren die Formel für N-1 von der Formel für N und eliminieren dadurch die Summe (nur der letzte Summend der ersten Summe bleibt übrig):
:::<math>
\begin{array}{rcl}
N \cdot C(N) - (N-1) \cdot C(N-1) &=& N(N+1) + 2\;\sum_{k=1}^{N} C(k-1) - (N-1) N - 2\;\sum_{k=1}^{N-1} C(k-1)\\
&&\\
N \cdot C(N) - (N-1) \cdot C(N-1) &=& N(N+1) - (N-1) N + 2 C(N-1)
\end{array}
</math>
Durch Vereinfachen erhalten wir die rekurrente Beziehung
:::<math>
N \cdot C(N) = (N+1)\cdot C(N-1) + 2 N</math>
Wir teilen jetzt beide Seiten durch <math>(N+1)N</math>
:::<math>
\frac{C(N)}{N+1} = \frac{C(N-1)}{N} + \frac{2}{N+1} </math>
Sukzessives Einsetzen der Formel für <math> C(N-1), C(N-2) </math> etc. bis <math>C(1)=0</math> liefert
:::<math>
\frac{C(N)}{N+1} = \frac{C(N-2)}{N-1} + \frac{2}{N} + \frac{2}{N+1} = \frac{C(2)}{3} + \sum_{k=3}^N\frac{2}{k+1} </math>
Für hinreichend große N kann die Summe sehr genau durch ein Integral approximiert werden. Der konstanten Term kann vernachlässigt werden:
:::<math>
\frac{C(N)}{N+1} \approx 2 \sum_{k=3}^{N} \frac{1}{k+1} \approx 2 \int_1^N \frac{1}{k} dk = 2 \cdot \ln(N)</math>
Somit benötigt Quick Sort im typischen Fall
:::<math>C(N)\approx 2 N\cdot\ln(N) \approx 1.38 N\cdot\log_2(N)</math>
Vergleiche. Quick Sort ist demnach etwa genauso schnell wie Merge Sort (in der Praxis sogar etwas schneller, da die innere Schleife von Quick Sort etwas einfacher ist).

=== Verbesserungen des Quicksort-Algorithmus ===

==== Beseitigung der Rekursion ====
Eine Verbesserung beseitigt die Rekursion durch Verwendung eines Stacks. Nach jeder Partitionierung wird das größere Teilintervall auf dem Stack abgelegt und das kleinere Teilintervall direkt weiterverarbeitet (hierdurch wird sichergestellt, dass die maximale Größe des Stacks minimiert wird).

def quicksortNonRecursive(a, l, r):
stack = [(l,r)] # initialisiere den Stack
while len(stack) > 0:
if r > l:
i = partition(a, l, r)
if (i-l) > (r-i):
stack.append((l,i-1))
l = i+1
else:
stack.append((i+1, r))
r = i-1
else:
l, r = stack.pop()

Die ist die Methode der ''Endrekursionsbeseitigung'', die wir im Kapitel [[Iteration versus Rekursion]] ausführlich behandeln. Die folgende Skizze verdeutlicht die Verwendung des Stacks.

+---+---+---+---+---+---+---+
| Q | U | I | C | K | S | O |
+---+---+---+---+---+---+---+

+---+---+---+===+---+---+---+
| K | C | I |=O=| Q | S | U |
+---+---+---+===+---+---+---+
\_________/
push

+---+===+---+
| C |=I=| K |
+---+===+---+
\_/
push

+===+
|=C=|
+===+

+===+
|=K=|
+===+

+---+---+===+
| Q | S |=U=|
+---+---+===+

+---+===+
| Q |=S=|
+---+===+

+===+
|=Q=|
+===+

+---+---+---+---+---+---+---+
| C | I | K | O | Q | S | U |
+---+---+---+---+---+---+---+

==== Alternatives Sortieren kleiner Intervalle ====

Für kleine Arrays (bis zu einer gegebenen Größe K) ist das "Teile und herrsche"-Prinzip nicht die effizienteste Herangehensweise. Insbesondere kann man ein Array mit maximal 3 Elementen direkt sortieren:
def sortThree(a, l, r):
if r > l and a[l+1] < a[l]: # Stelle sicher, dass a[l] und a[l+1] relativ zueinander sortiert sind.
a[l], a[l+1] = a[l+1], a[l]
if r == l + 2:
if a[r] < a[l]: # Stelle sicher, dass a[l] und a[r] relativ zueinander sortiert sind.
a[l], a[r] = a[r], a[l] # Danach ist a[l] auf jeden Fall das kleinste Element.
if a[r] < a[r-1]: # Stelle sicher, dass a[r-1] und a[r] relativ zueinander sortiert sind.
a[r], a[r-1] = a[r-1], a[r] # Jetzt ist a[r] auf jeden Fall das größte Element und das Array damit sortiert.

In die Funktion <tt>quicksort()</tt> wird jetzt ein Aufruf dieser Funktion eingefügt:
if r > l + 2:
# wie bisher
elif r > l:
sortThree(a, l, r)

==== Günstige Selektion des Pivot-Elements ====
Durch geschickte Wahl des Pivot-Elements kann man erreichen, dass der ungünstigste Fall (quadratische Laufzeit) nur mit sehr kleiner Wahrscheinlichkeit eintritt. Zwei Möglichkeiten haben sich bewährt:
# Anstatt des letzten Elements des Teilarrays wählt man ein zufälliges Element (mit Hilfe eines Zufallszahlengenerators). Dadurch wird Quick Sort unempfindlich gegenüber bereits sortierten Arrays, weil die Teilung im Mittel wie bei einem zufällig sortierten Array erfolgt (typischer Fall in obiger Laufzeitberechnung).
# Median (mittlerer Wert) von drei Elementen: Verwende den Median des ersten, mittleren und letzten Elements jedes Teilarrays als Pivot-Element.
In beiden Fällen ist es praktisch ausgeschlossen, dass ein Eingabearray so angeordnet ist, dass in jedem Teilarray gerade das kleinste oder größte Element als Pivot gewählt wird. Nur dann könnte der ungünstigste Fall jedoch eintreten, was somit effektiv verhindert wird.

Einführung

2008-07-22T08:49:39Z

Jschleic: /* Definition von Datenstrukturen */ typos

== 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 gezeigt werden, dass 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://webhome.idirect.com/~totton/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
| x[i] = x[j] - c
| P; P
| WHILE x[i] != 0 DO P DONE
wobei <tt>c</tt> ein beliebiges ganzahliges Literal (eine ausgeschriebene ganze Zahl) und <tt>x[i]</tt> die Speicherzelle <tt>i</tt> bezeichnet. 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.

Die Zerlegung jedes Problems in Form eines WHILE-Programms (oder eines äquivalenten Formalismus der Berechenbarkeitstheorie) ist für unsere Zwecke aber zu feinkörnig: Sie würde bedeuten, dass alle Algorithmen auf einem sehr einfachen Prozessor in Assembler programmiert werden müssten. Statt dessen 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 unrsprü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]] Standbild Al Chwarizmis in Teheran
|}

== Definition von Datenstrukturen ==

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}. Eine '''Datenstruktur''' 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 welcher Datenstruktur sie sich befinden. Man betrachte z.B. die Folge von 32 Bits:
11111100011000100110010101101110
Wenn wir diese Folge als eine einzige Gruppe betrachten und als positive ganze Zahl in Binärdarstellung (unsigned integer) interpretieren, ergibt sich die Dezimalzahl 4234306926. Interpretieren wir dieselbe Gruppe als vorzeichenbehaftete ganze Zahl in [http://de.wikipedia.org/wiki/Zweierkomplement Zweierkomplement]-Darstellung (signed integer), ergibt sich statt dessen die Dezimalzahl -60660370. 
Alternativ können wir die Folge in vier Gruppen zu 8 Bit gruppieren, und die Gruppen als Zeichencodes im Latin-1 Zeichensatz interpretieren. Wir erhalten die Zeichenkette "üben":
11111100 01100010 01100101 01101110 => üben
Interpretieren wir dieselben Gruppen hingegen als Farbe im RGBA System, erhalten wir ein halbtransparentes Rosa (Rot: 252, Grün: 98, Blau: 101, Alpha: 110). 
Eine weitere Interpretation ist diejenige als 32-Bit Gleitkommazahl gemäß [http://en.wikipedia.org/wiki/IEEE_floating-point_standard IEEE Standard 754] (float). Dabei wird die Folge in Gruppen zu 1 Bit, 8 Bit und 23 Bit eingeteilt:
1 11111000 11000100110010101101110
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> (Hier gilt <tt>s = 1</tt>, <tt>exp = 248</tt> und <tt>m = 6448494</tt>). Die Umrechnung in eine Gleitkommazahl erfolgt, gemäß IEEE Standard, nach folgender 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.

{| border="0" cellspacing="0" cellpadding="5"
|-valign="top"
| Die Bedeutung der einzelnen Gruppen ist dem Computer normalerweise nicht explizit bekannt. Vielmehr wird sie implizit durch die ''Menge der darauf ausführbaren Operationen'' definiert. Man bezeichnet die Verbindung einer Datenrepräsentation mit einer Menge von erlaubten Operationen als '''(Daten-)Typ''' oder als '''Klasse'''. Man kann sich die drei Möglichkeiten "Gruppierung von Daten", "Bedeutung der Gruppen" und "Menge der darauf ausführbaren Operatoren" als Ecken eines Dreiecks vorstellen. Definiert man zwei Ecken des Dreiecks, ist auch die dritte weitgehend festgelegt. Offensichtlich gibt es dafür drei Möglichkeiten: Legt man "Gruppierung" und "Bedeutung" fest, erhalten wir eine Datenstruktur, und bei "Gruppierung" plus "Operatoren" einen Klasse bzw. einen Typ. Die dritte Möglichkeit ist die Defnition der Menge der Operatoren und der Bedeutung. In diesem Fall hat man für die Festlegung der (internen) Gruppierung der Daten, also für die Implementation, noch verhältnismäßig viel Freiheit. Man bezeichnet diese Möglichkeit deshalb als '''Abstrakte Datentypen''' (ADTs). Wir kommen im Kapitel [[Generizität]] auf ADTs zurück.
| [[Image:Dt dreieck.png]]
|}

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 dass 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 andern 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 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.

Iteration versus Rekursion

2008-07-21T11:08:37Z

Jschleic: /* Version 1: Naive rekursive Implementation */ Grafik eigefügt

==Rekursion in der Informatik:==

Einen Funktion f ist '''rekursiv''' wenn sie sich selbst aufruft.
Die Funktion heißt ''indirekt-rekursiv'' wenn sie sich selbst aufruft über den Umweg einer anderen Funktion (oder mehrerer anderer Funktionen).

Beispiel einer indirekten Rekursion:

'''foo''' ---> '''bar''' ---> '''foo'''
ruft auf ruft auf

===Entscheidende Eigenschaften der Rekursion===

* Jeder Aufruf einer rekursiven Funktion f hat sein eigenes Set von lokalen Variablen, d.h. der rekursive Aufruf hat die gleichen Anweisungen auszuführen, aber er hat seine eigenen Daten. Betrachten wir z.B. die rekursive Funktion
def f(n):
r = f(n-1)
... # weiterer Code
return r

:Für ein gegebenes n erhalten wir die Aufrufkette:
f(n) 1.Ebene
f(n-1) 2.Ebene
f(n-2) 3.Ebene
...
:Die Funktionsaufrufe der verschiedenen Ebenen werden so ausgeführt, als ob wir für jede Ebene eine eigene Funktion f1(n1), f2(n2), f3(n3) usw. definiert hätten:

f1(n1) 1.Ebene ---> n1 = n
f2(n2) 2.Ebene ---> n2 = n1-1
f3(n3) 3.Ebene ---> n3 = n2-1 = n1-2 = n-2
...
:Die Funktionen f1(n1), f2(n2), f3(n3) enthalten alle den gleichen Code, aber mit unterschiedlich benannten Variablen n1, n2, n3. Durch diese Umbenennungen sollte die obige Aussage deutlich werden.

* Jede rekursive Funktion muß mindestens '''einen''' nicht-rekursiven Zweig haben. Dieser Zweig wird als '''Basisfall''' oder '''Rekursionsabschluss''' bezeichnet.

* Jeder rekursive Aufruf muß über endlich viele Stufen auf einen Basisfall zurückgeführt werden, denn sonst erhält man eine Endlosrekursion (und das ist fast so übel wie eine Endlosschleife -- "fast" deshalb, weil die Endlosrekursion spätestens dann abbricht wenn der Speicher voll ist --> siehe Übung 7 Aufgabe 1).

* Die Anzahl der rekursiven Aufrufe bis zum Rekursionsabschluss bezeichnet man als '''Rekursionstiefe d'''.

* Jede rekursive Funktion kann in eine iterative Funktion umgewandelt werden, die statt rekursiver Aufrufe eine Schleife enthält. Wir beschreiben dies unten anhand von Beispielen.

 

===Arten der Rekursion===

Die Arten der Rekursion sind hier nicht vollständig angegeben, es gibt noch weitere. Aber die hier folgenden sind für die Programmierung am wichtigsten.

====Lineare Rekursion====

* Jeder Ausführungspfad durch die Funktion f enthält höchstens einen rekursiven Aufruf.
* Höchstens einen, weil mindestens ein Pfad existieren muss, der keinen rekursiven Aufruf enthält (der Basisfall).
:⇒ Das Ergebnis der Aufrufe ist eine 1-dimensionale "Rekursionskette".

====Baumrekursion====
(auch Kaskadenrekursion) 

* Mindestens ein Ausführungspfad durch die Funktion enthält mindestens 2 rekursive Aufrufe.
* Baumrekursion ist damit das Gegenteil der linearen Rekursion.
:⇒ Das Ergebnis der Aufrufe ist ein verzweigter "Rekursionsbaum". Ein baum-rekursiver Algorithmus ist deshalb häufig ineffizient: Wird der Pfad mit mehreren rekursiven Aufrufen mindestens Ω(d)-mal ausgeführt (wobei d die Rekursionstiefe) ist, entsteht ein Rekursionsbaum mit O(2d) Knoten, also ein Algorithmus mit exponentieller Komplexität.

====Course-of-values recursion====

* Das Ergebnis des rekursiven Aufrufes für Argument n hängt nur von den Ergebnissen der letzten p-Aufrufe, also für Argument n-1,n-2,...,n-p ab (wobei p eine Konstante ist).

====Primitive Rekursion====

* Spezialfall der course-of-values recursion mit p=1.
:⇒ Das ist auch ein Spezialfall der linearen Rekursion, denn wenn das Ergebnis nur von einem rekursiven Aufruf abhängt, kann kein Rekursionsbaum entstehen.

====Endrekursion====

* In jedem rekursiven Ausführungspfad ist der rekursive Aufruf der letzte Befehl vor dem return-Befehl.
:⇒ Das ist ein Spezialfall der linearen Rekursion, denn es kann nur einen letzten Befehl vor jedem return geben, ein zweiter rekursiver Aufruf könnte allenfalls der vorletzte Befehl sein.

==Beispiele und Umwandlung in Iteration==

===Beispiel für alle Rekursionsarten: Fibonacci-Zahlen===

Wir verdeutlichen die verschiedenen Rekursionsarten und ihre Umwandlung in iterative Algorithmen am Beispiel der Fibonacci-Zahlen.

;Fibonacci-Zahlen: Die n-te Fibonacci-Zahl ist gemäß der folgenden Rekursionsformel definiert.
:::f0=0
:::f1=1
:::fn=fn-1+fn-2
:Es ergibt sich die Folge:
:::fk=0, 1, 1, 2, 3, 5, 8, 13,....., (⇒ Die Reihe wächst exponentiell an.)

Im folgenden zeigen wir 5 verschiedene Algorithmen zu Berechnung der n-ten Fibonacci-Zahl:

====Version 1: Naive rekursive Implementation====

Implementiert man einfach die rekursive Formel der Definition, erhält man:

def fib1(n): # Funtion berechnet die n-te Fibonacci-Zahl
if n <= 1:
return n # Rekursionsabschluss
return fib1(n-1) + fib1(n-2) # Baumrekursion

Die Funktion fib1(n) ist ein Beispiel für eine Baumrekursion mit exponentieller Komplexität.
Der Aufrufbaum sieht dann wie folgt aus:
[[Image:Fibrek.png]]


Im Falle der Fibonacci-Zahlen ist dies ein ungünstiger Algorithmus, weil viele Teilergebnise wiederholt berechnet werden (z.B. fn-2 und fn-3).
Aber einige Probleme sind echt Baumrekursiv, z.B. das Ausrechnen der möglichen Züge beim Schachspiel.

 
;Es gilt folgender grundlegender Satz:
Jeder rekursiver Algorithmus kann mit Hilfe eines Stacks in einen iterativen Algorithmus umgewandelt werden (d.h. mit einer Schleife statt einer Rekursion). Das bedeutet, dass rekursive Programme gleichmächtig sind wie Programme mit Schleifen (z.B. WHILE-Programme, siehe [[Einführung#Zur Frage der elementaren Schritte|erste Vorlesung]]), d.h. gleichmächtig wie die Turing-Maschine. Die Komplexität des Algorithmus ändert sich durch die Umwandlung nicht.
 

====Version 2: Umwandlung in einen iterativen Algorithmus mit Stack====

def fib2(n):
stack = [n] # der Stack enthält als erstes Teilproblem das ursprüngliche Problem "n-te Fibonacci-Zahl berechnen"
f = 0 # f wird später die Lösung enthalten

while len(stack) > 0: # solange noch was auf dem Stack liegt, ist noch Arbeit zu tun
k = stack.pop() # Teilproblem von Stack entnehmen und lösen
if k <= 1:
f += k # entweder: Teilergebnis zur Lösung addieren (das war vorher der Rekursionsabschluss)
else:
stack.append(k-1) # oder: zwei neue Teilprobleme auf dem Stack ablegen
stack.append(k-2) # (das waren vorher die rekursiven Aufrufe)
return f

====Version 3: Course-of-values recursion====

Wie man unmittelbar aus der Definitione erkennt, ist die Berechnung der Fibonacci-Zahlen Course-of-values rekursiv mit p=2. Eine entsprechende Implementation verwendet eine Hilfsunfktion, die immer die Ergebnisse der p letzten Aufrufe zurückgibt:

def fib3(n):
if n == 0: return 0 # Rekursionsabschluss
f1,f2 = fib3Impl(n) # Hilfsfuntion, f1 ist die Fibonacci-Zahl von n und f2 ist dei Fibonacci-Zahl von (n-1)
return f1

Die Hilfsfunktion enthält jetzt die eigentliche Rekursion. Sie berechnet die Fibonacci-Zahlen fk und fk-1 aus den Zahlen fk-1 und fk-2:

def fib3Impl(n):
if n == 1: return 1, 0 # gebe die Fibonacci-Zahl von 1 und die davor zurück
else: # rekursiver Aufruf
f1,f2 = fib3Impl(n-1) # f1 ist Fibonacci-Zahl von (n-1), f2 die von (n-2)
return f1 + f2, f1 # gebe neue Fibonacci-Zahl fn=f1+f2 und die vorherige (fn-1=f1) zurück.

⇒ Diese Implementation ist jetzt linear-rekursiv (aber nicht endrekursiv). Sie hat damit lineare Komplexität und nicht exponentielle wie die beiden vorherigen Versionen.

 
;Es gilt folgender Satz:
Jede Course-of-values Rekursion kann in Endrekursion umgewandelt werden.
 

====Version 4: Endrekursiv====

Man gelangt von der Course-of-values recursion zur Endrekursion, indem man einfach die Berechnungsreihenfolge umkehrt: statt rückwärts von fn nach f0 zu arbeiten, arbeitet man vorwärts von f0 nach fn. Dazu muss der Hilfsfunktion eine Zählvariable übergeben werden, die angibt, wie viele Schritte noch bis zum Ziel fn verbleiben. Außerdem erhält die Hilfsfunktion die beiden vorherigen Fibonacci-Zahlen als Argument übergeben:

def fib4(n)
if n == 0:
return 0
else:
return fib4Impl(0, 1, n)

Die Hilfsfunktion:

def fib4Impl(f1, f2, counter)
if counter == 1:
return f2
else:
return fib4Impl(f2, f1+f2, counter-1) # f2 ist die vorletzte Fibonacci-Zahl,
# f1+f2 wird die neue Fibonacci-Zahl und wir müssen counter um 1 herunterzählen

Beispiel mit n=3:

{| border="1" cellspacing="0" cellpadding="7"
|-align="center"
|
!  f1 
!  f2 
! counter
|-
| fib4Impl 1.Aufruf
|align="center"| 0
|align="center"| 1
|align="left"| 3
|-
| fib4Impl 2.Aufruf
|align="center"| 1
|align="center"| 1
|align="left"| 2
|-
| fib4Impl 3.Aufruf
|align="center"| 1
|align="center"| 2
| 1 ⇒ Rekursionsabschluss ⇒ return 2
|}

⇒ Ergebnis von fib4(3) (die 3. Fibonacci-Zahl) ist 2.

 
;Es gilt folgender grundlegender Satz:
Jede endrekursive Funktion kann ohne Stack in eine iterative Funktion umgewandelt werden.
 

Bei einigen Programmiersprachen (z.B. Lisp, Scheme) wird dies von Compiler sogar automatisch erledigt (als Programmoptimierung, weil Iteration im allgemeinen schneller ist als Rekursion).

====Version 5: Umwandlung in einen iterativen Algorithmus ohne Stack====

def fib5(n):
f1, f2 = 0, 1
while n > 0:
f1, f2 = f2, f1+f2
n -= 1
return f1

Das ist genau das gleiche wie <tt>fib4Impl</tt>. Aber anstelle eines rekursiven Aufrufes werden einfach die Variablen f1 und f2 wiederverwendet (mit den neuen Werten überschrieben). Dies ist möglich, weil die originalen Werte nicht mehr benötigt werden, denn der rekursive Aufruf bei <tt>fib4Impl</tt> war der letzte Befehl vor dem return (Endrekursion!).

===Beispiel für die Umwandlung von Rekursion in Iteration: treeSort===

Input:
* ein balancierter Binärbaum, repräsentiert durch seinen Wurzelknoten <tt>root</tt>
* ein leeres dynamisches Array a, das später die sortierten Elemente des Baums enthalten wird
Aufgerufen wird:

treeSort(root,a) # kopiert Elemente des Baums sortiert in Array a

Wiederholung des rekursiven Algorithmus (vergleiche Abschnitt "[[Suchen#Sortieren mit Hilfe eines selbst-balancierenden Suchbaums|Sortieren mit Hilfe eines selbst-balancierenden Suchbaums]]"):

def treeSort(node,a):
if node is None:
return
treeSort(node.left,a)
a.append(node.key)
treeSort(node.right,a)

Dieser Algorithmus ist baumrekursiv, was nicht weiter überrascht, denn die Rekursion dient ja zur Traversierung eines Baumes. In diesem Fall führt Baumrekursion nicht zu exponentieller Komplexität, weil die Tiefe des Baum nur O(log N) ist. Dadurch benötigt <tt>treeSort</tt> nur O(2log N) = O(N) Schritte zum Auslesen des Baumes (das Füllen das Baumes benötigt allerdings O(N log N) Schritte und dominiert den Algorithmus).

Die Implementation als iterative Funktion erfolgt mit Hilfe eines Stacks und einer Hilfsfunktion <tt>traverseLeft</tt>, die den Stack füllt:

def treeSortIterative(root, a):
stack = []
traverseLeft(root, stack) # fülle Stack mit den Knoten des linken Teilbaums von root
while len(stack) > 0:
node = stack.pop()
a.append(node.key)
traverseLeft(node.right, stack) # fülle Stack mit den Knoten des linken Teilbaums von node.right

Hilfsfunktion:

def traverseLeft(node, stack):
while node is not None:
stack.append(node)
node = node.left

 

==Auflösung rekursiver Gleichungen==

Um die Komplexität eines rekursiven Algorithmus zu berechen, müssen wir die notwendige Schrittzahl für ein Problem der Größe N bestimmen. Die Schrittzahl einer rekursiven Funktion setzt sich zusammen aus den Schritten, die in der Funktion selbst ausgeführt werden, sowie denen, die die verschiednenen rekursiven Aufrufe beitragen. Um dies allgemein auszudrücken, nehmen wir an, dass jeder rekursive Aufruf sich auf ein Teilproblem des originalen Problems bezieht. Die Größe des i-ten Teilproblems sei n/bi (wenn wir also auf dem Originalproblem weiterarbeiten, gilt bi=1), und es soll ai Teilprobleme dieser Größe geben. Dann wird die gesuchte Schrittzahl durch folgende Formel ausgedrückt:

:::<math>\underbrace{T(n)}_{\mbox{Schrittzahl}} = \underbrace{ a_1T\left(\frac{n}{b_1}\right)+a_2T\left(\frac{n}{b_2}\right)+\cdots+a_kT\left(\frac{n}{b_k}\right) }_{\mbox{rekursive Teilprobleme}}
+\underbrace{f(n)}_{\mbox{nicht-rekursiver Teil}}</math>

Bemerkung: Im allgemeinen arbeiten die rekursiven Aufrufe auf Teilproblemen ganzzahliger Größe. Daher muss man <math>\frac{n}{b_i}</math> gegebenenfalls aufrunden <math>\left\lceil\frac{n}{b_i}\right\rceil</math> oder abrunden <math>\left\lfloor\frac{n}{b_i}\right\rfloor</math>. Diese Rundungen spielen für die Auflösung der Formeln meist keine Rolle, weil die Rundungsfehler für große n vernachlässigbar sind.

Rekursionsformeln dieses Typs haben wir z.B. im Kapitel [[Sortieren]] bereits behandelt. Hier wollen wir allgemeine Strategien angeben, wie man die rekursive Form dieser Formeln in eine explizite Form (die keine Ausdrücke der Art <math>T\left(\frac{n}{b_i}\right)</math> mehr enthält) überführt .

===Master-Theorem===

Im Speziallfall k=1 (d.h. alle Unterprobleme haben die gleiche Größe) vereinfacht sich obige Formel zu:
:::<math>T(n) = a\,T\left(\frac{n}{b}\right)+f(n)</math>
Hier gibt es mit dem Master-Theorem eine sehr allgemeine Regel, wie man dies in eine explizite Form bringt. Einen Beweis für das Master-Theorem findet man z.B. bei T. Cormen, C. Leiserson, R.Rivest: "Algorithmen - eine Einführung".

Wir definieren zunächst den '''Rekursionsexponenten''':
:::<math>\rho=\log_b (a)</math>
Ja nach dem Verhalten des nicht-rekursiven Anteils unterscheiden wir 3 Fälle

====Fall 1:====

Falls die Funktion f(n) sehr effizient ist, so dass für ihre Komplexität gilt
:::<math>f(n) \in O(n^{\rho-\epsilon}) , \epsilon>0</math> 
In diesem Fall dominieren die Kosten der Rekursion, und die Komplexität der rekursiven Funktion ergibt sich aus dem Rekursionsexponenten
:::<math>T(n) =\Theta(n^{\rho})</math>

====Fall 2:====

Wenn die Funktion f(n) genauso effizient ist wie die Rekursion, wenn also gilt
:::<math>f(n) \in \Theta(n^{\rho}) </math> 
dann addieren sich die Kosten für f(n) und für die Rekursion, und wir erhalten:
:::<math>T(n) =\Theta(n^{\rho}\cdot\log n)</math>

====Fall 3:====

Wenn die Funktion f(n) nicht sehr effizient ist, so dass für ihre Komplexität gilt
:::<math>f(n) \in \Omega(n^{\rho+\epsilon})</math>
kann das Master-Theorem nur dann eine Aussage machen, wenn außerdem gilt
:::<math>a\,f\left(\frac{n}{b}\right)\le c\,f(n)\,\textrm{mit}\,c<1</math>
Jetzt dominieren die Kosten von f(n), und die Komplexität wird
:::<math>T(n) =\Theta(f(n))</math>

====Beispiel: Merge Sort====
Im Falle von Merge Sort wird das Problem in zwei gleiche Teile zerlegt, die beide rekursiv sortiert werden (es gilt also a=2, b=2). Das Zusammenfügen der beiden Teile erfordert Θ(n) Vergleiche. Wir erhalten also die Formel
:::<math>T(n) = \underbrace{ 2\,T\left(\frac{1}{2}\right)}_{\mbox{rekursive Aufrufe von MergeSort}}+\underbrace {\Theta(n)}_{\textrm{Merge}}</math>
Für den Rekursionsexponenten erhalten wir
:::<math>\rho=log_2 2 = 1</math>
Mit f(n) ∈ Θ(n) = Θ(nρ) trifft Fall 2 zu, und wir erhalten für die Komplexität von MergeSort das bereits bekannte Ergebnis:
:::<math>T(n) \in \Theta(n^ \rho \log n) = \Theta(n\,\log n)</math>

====Fälle die nicht durch das Master-Theorem abgedeckt sind:====
* wenn <math>k \ > 1</math>: rekursive Teilprobleme verschiedener Grösse
* wenn <math>f(n) \in O\left(\frac{n^\rho}{\log n}\right)</math>: Die Komplexität von f(n) liegt genau zwischen den Fällen 1 und 2.
* wenn <math>f(n) \in \Omega\left(n^\rho \log n\right)</math>: Die Komplexität von f(n) liegt genau zwischen den Fällen 2 und 3.
* wenn für alle c<1 gilt <math>a\,f\left(\frac{n}{b}\right)> c\,f(n)</math>: Die Komplexität der Funktion f(n) auf den reduzierten Problemen ist zu groß.

===Rekursionsbäume und Substitutionsmethode===

Wenn das Master-Theorem nicht anwendbar ist, muss man die Rekursionsformel selbst auflösen. Dies gilt zum Beispiel, wenn der Algorithmus das Problem in zwei ungleich große Teile zerlegt. Wir betrachten das folgende Beispiel, bei dem das Problem in Teile der Größe 1/3 und 2/3 zerlegt wird und das Zusammenfügen der Teile c*n Schritte erfordert:
:::<math>T(n) = \underbrace{ T\left(\frac{n}{3}\right)}_{\frac{1}{3}\mbox{ der Daten}}+\underbrace {T\left(\frac{2n}{3}\right)}_{\frac{2}{3}\mbox{ der Daten}} +\underbrace {c\cdot n}_{\mbox{Zusammenfügen}}</math> 
Wir bilden zuerst den Rekursionsbaum dieses Problems, wobei für jeden Knoten die Größe des Teilproblems angegeben ist, das dieser Knoeten lösen muss:

n
/ \
/ \
/ \
/ \
/ \
(n/3) (2n/3)
/ \ / \
/ \ / \
/ \ / \
(n/9) (2n/9) (2n/9) (4n/9)

Jeder Knoten ruft rekursiv seine Kindknoten auf und fügt dann deren Teilprobleme zusammen. Wir berechnen den Aufwand, den allein das Zusammenfügen auf jeder Ebene des Baumes verursacht. Auf der obersten Ebene (Ebene 1) gibt es nur ein Teilproblem, und der Aufwand ist c*n. Auf Ebene 2 haben wir zwei Teilprobleme mit Aufwand
:::<math>c\,\frac{n}{3}</math> und <math>c\,\frac{2\,n}{3}</math>
Der Gesamtaufwand für das Zusammenfügen auf Ebene 2 ist die Summe dieser Ausdrücke, wir erhalten also wieder c*n. Für Ebene 3 gilt wiederum
:::<math>c\left(\frac{n}{9}+\frac{2\,n}{9}+\frac{2\,n}{9}+\frac{4\,n}{9}\right)=c\,n</math>
Offensichtlich gilt also für alle Ebenen, dass das Zusammenfügen der Teilprobleme insgesamt c*n Schritte erfordert. Zur Berechnung des Gesamtaufwands müssen wir nun noch die Anzahl der Ebenen, also die Tiefe d des Baumes, schätzen. Die Rekursion muss spätestens dann enden, wenn ein Teilproblem der Größe 1 erriecht wird, weil dies nicht weiter zerlegt werden kann. Die Rekursion endet also, wenn
:::<math>\left(\frac{2}{3}\right)^d n=1</math>.
Auflösen dieser Formel nach d ergibt
:::<math>d=\log_\frac{3}{2}(n)</math>
Wir leiten daraus die '''Vermutung''' ab, dass für die Komplexität unseres Algorithmus gilt
:::<math>T(n) \in O\left(\log_\frac{3}{2}(n)\cdot c\cdot n\right)</math>
Nach den Regeln der O-Notation vereinfacht sich dies aber zu
:::<math>T(n) \in O\left(n\,\log n\right)</math>
Diese Vermutung muss aber noch formal bewiesen werden (der Rekursionsbaum reicht als Beweis nicht aus). Der Beweis erfolgt durch die '''Substitutionsmethode'''. Das bedeutet, dass wir unsere Vermutung auf der rechten Seite der Rekursionsformel einsetzen und beweisen, dass eine wahre Aussage herauskommt. Für hinreichend große n und hinreichend großes d kann die Vermutung geschrieben werden als
:::<math>T(n) \le d\,n\,\mbox{ld}(n) </math>
(wir haben hier willkürlich Logarithmen zu Basis 2 eingesetzt -- die Basis in der O-Notation ist bekanntlich beliebig). Einsetzen in die Rekursionsformel liefert
:::<math>T(n) \le T\left(\frac{n}{3}\right)+ T\left(\frac{2n}{3}\right)+ c\,n \le d\,\frac{n}{3}\,\mbox{ld}\left(\frac{n}{3}\right)+ d\,\frac{2n}{3}\,\mbox{ld}\left(\frac{2n}{3}\right)+ c\,n</math>
Durch Ausmultiplizieren der Klammern und Trennen der Logarithmen von Quotionten in Differenzen von Logarithmen erhalten wir
:::<math> T(n) \le d\frac{1}{3}\,n\,\mbox{ld}(n)-d\,\frac{1}{3}\,n\,\mbox{ld}(3)+d\,\frac{2}{3}\,n\,\mbox{ld}(n)+d\,\frac{2}{3}\,n\,\mbox{ld}(2)-d\,\frac{2}{3}\,n\,\mbox{ld}(3)+c\,n</math>
Unter Beachtung von ld(2)=1 können wir die Terme wie folgt zusammenfassen
:::<math> T(n) \le d\,n\,\mbox{ld}(n)-d\,n\left(\mbox{ld}(3)-\frac{2}{3}\right)+c\,n</math>
Falls unsere Vermutung richtig ist, muss die rechte Seite kleiner oder gleich <math>d\,n\,\mbox{ld}(n) </math> sein. Um dies zeigen zu können, setzen wir
:::<math> d \ge \frac{c}{\mbox{ld}(3)-\frac{2}{3}}\, \Leftrightarrow\, d\left(\mbox{ld}(3)-\frac{2}{3}\right) \ge c</math>
(nach den Regeln der O-Notation kann d beliebig gewählt werden, solange es hinreichend groß ist).
Wenn wir die Konstante c mit Hilfe dieses Ausdrucks ersetzen, erhalten wir
:::<math> T(n) \le d\,n\,\mbox{ld}(n)-d\,n\left(\mbox{ld}(3)-\frac{2}{3}\right)+c\,n \le
d\,n\,\mbox{ld}(n)-d\,n\left(\mbox{ld}(3)-\frac{2}{3}\right)+d\left(\mbox{ld}(3)-\frac{2}{3}\right)n</math>
Die beiden letzten Terme heben sich aber gerade weg, und es bleibt übrig:
:::<math> T(n) \le d\,n\,\mbox{ld}(n)</math>
und somit
:::<math>T(n) \in O\left(n\,\log n\right)</math>
w.z.b.w.

Allgemein gilt, dass eine ungleiche Aufteilung in Teilprobleme die Komplexität eines rekursiven Algorithmus nicht verschlechtert, falls das Teilungsverhältnis konstant bleibt, falls der nichtrekursive Aufwand f(n) auf jeder Ebene in O(n) ist. Das gilt aber nicht, wenn das Problem immer in ein Teilproblem konstanter Größe und den Rest geteilt wird. Dann gilt mit einer Konstante p
:::<math>T(n) = T(p) + T(n-p) + c\cdot n</math>
und das Teilungsverhältnis wird umso schlechter, je größer n wird. Dies ist gerade der ungünstige Fall bei Quicksort, und wir haben gesehen, dass sich die Komplexität hier auf O(n2) verschlechtert.

File:Fibrek.jpg

2008-07-21T11:06:55Z

Jschleic: Baumrekursion zur Berechnung der Fibonacci-Zahlen

Baumrekursion zur Berechnung der Fibonacci-Zahlen

File:Fibrek.png

2008-07-21T11:04:58Z

Jschleic: uploaded a new version of "Image:Fibrek.png"

Baum zur rekursiven Berechnung ein Fibonacci-Zahl

File:Fibrek.png

2008-07-21T10:55:43Z

Jschleic: Baum zur rekursiven Berechnung ein Fibonacci-Zahl

Baum zur rekursiven Berechnung ein Fibonacci-Zahl

Generizität

2008-06-26T12:46:05Z

Jschleic: /* Iteratoren */

Ziel von generischer Programmierung [http://de.wikipedia.org/wiki/Generische_Programmierung] ist es, Algorithmen und Datenstrukturen so zu entwerfen und zu implementieren, dass sie möglichst vielfältig verwendbar sind.

'''Gemeint sind :'''

*verschiedene Anwendungen
*mit vielen Kombinationsmöglichkeiten
*als wiederverwendbare Bibliothek

--> ''' ohne Neuimplementation '''
*Code austauschen in Bibliotheken

===Motivation ===
An einem Beispiel wollen wir zeigen, wie ähnlich das Kopieren eines Containers für verschiedene Datentypen abläuft:

====Code====

def copyArray(a):
r =[]
for k in a:
r.append(k)
return k

class Node :
def__init__(self, data, next)
self.data = data
self.next = next

def copyArrayToList(a) :
if len(a) == 0 : return None
first = last = Node (a[0], None)
for k in a[1:] :
last.next = Node(k, None)
last = last.next
return first

def copyListToArray(l):
r = []
while l is not in None :
r.append(l.data)
l = l.next
return r

==== Beobachtung ====

Für '''N Datenstrukuren''' ist der Implementationsaufwand <math>O(N^2) </math>, wenn man je zwei Datenstrukturen ineinander umwandeln können will.
Alle Funktionen machen das gleiche mit einem uninteressantem Unterschied. Wir wollen daher im Folgenden eine Möglichkeit angeben, das kopieren der Daten zu vereinheitlichen.

====Verbesserungsmöglichkeiten ====
'''Verbesserung durch Verallgemeinerung zweier Aspekte''' :

*Navigieren durch die Quelldaten
*Aufbauen der Zieldatenstruktur

'''Vereinheitlichung der Zieldatenstruktur :'''
*standardisierte Funktion "append"
*Array hat sie schon
*Liste : definiere Klasse DoublyLinkedList

class SentinelTag : pass # keine Daten

class DoublyLinkedNode:
def__init__(self,data = sentinelTag(), next = None)
self.data = data
if next is None :
self.prev = self.next = self
else:
self.next = next
self.prev = next.prev
next.prev.next = self
next.prev = self

def isSentinel(self ) : return isinstance( self.data, sentinelTag)

class DoublyLinkedList : # Realisiert doppelt verbundene kreisförmige Kette mit Sentinel
# als "Anker"
def__init__(self):
self.sentinel = DoublyLinkedNode()
self.size = 0
def__len__(self): return self.size #len(l)
def append(self, value):
DoublyLinkedNode(value, self.sentinel)
self.size += size
def__iter__(self):
return ListIterator(self.sentinel.next)
def reverseIterator(self):
return ListIterator(self.sentinel.prev)

====verbesserter Code ====
Mit diesen Schnittstellen reicht uns nun eine einzige Methode zum Kopieren eines Containers aus.

def genericCopy (quelle, ziele) :
for k in quelle :
ziel.append(k)
return ziel

liste = genericCopy(array, DoublyLinkedList()) # Statt copyArrayToList
array2 = genericCopy(array,[]) # Statt copyArray
array3 = genericCopy(liste,[]) # Statt copyListToArray

=== Iteratoren ===

----

'''Definition Iterator:''' siehe [http://de.wikipedia.org/wiki/Iterator]

Navigation in der Quelldatenstruktur ( Iteratoren ) soll für alle Datenstrukturen funktionieren

Ein Iterator ist ein Objekt,
*das auf ein Element des Containers zeigt
*das zum nächsten Element weiter rücken kann
*das anzeigt, wenn das Ende der Sequenz erreicht ist

'''Beispiel:'''
class ListIterator:
def __init__(self, node):
self.node = node
def next(self):
if self.node.isSentinel():
raise StopIteration() #Python Konvention
v = self.node.data
self.node = self.node.next # zeigt Ende der Sequenz
return v # Pythonkonvention, gebe vorigen Wert zurück

def __iter__(self):
return ListIterator(self.node) # Pythonkonvention, Kopie des Iterators zurückgeben
#oder stattdessen besser:
return self.__class__(self.node) # ist allgemeiner

'''Was tut Python bei " for k in quelle"( in genericCopy ) ?''': 
Will man in Python alle Elemente eines Containers durchlaufen, so tut man dies leicht mit einem Statement der Form <code>for k in quelle</code>. Was passiert dabei eigentlich? 
Das Schlüsselwort <code>for</code> ruft dabei die Methode <code>iter()</code> der entsprechenden Klasse auf, die einen Zeiger auf ein Iterator-Objekt zurückgibt. Dieses Objekt definiert eine Methode <code>next()</code>, womit man das nächste Element der Datenstruktur bekommen kann. Wenn keine weiteren Elemente mehr vorhanden sind, wird eine Exception <code>StopIteration</code> ausgelöst.
iter = quelle.__iter__()
try :
while True :
k = iter.next()
... # Schleifeninhalt
except StopIteration: pass

'''Rückwärts kopieren :'''
Um eine Liste rückwärts zu kopieren, könnten wir also folgenden Iterator verwenden:
class ReverseListIterator(ListIterator)
def next(self):
if self.node.isSentinel(): raise StopIteration()
v = self.node.data
self.node = self.node.prev
return v

revArray = genericCopy(list.reverseIterator(), []), # Liste in ein Array kopieren
revList = genericCopy(reversed(array), DoublyLinkedList()) # Array umdrehen und dann in eine Liste kopieren

===Funktoren===

----

'''Definition eines Funktors :''' siehe [http://de.wikipedia.org/wiki/Funktor]

'''Verallgemeinerung auf Funktionen die " etwas tun":'''

def sumArray(a):
s = 0
for k in a :
s += a # s = add(s,k)
return a

def maxList(l):
m = -1111111111111111
while not l.isSentinel:
m = max(m, l.data) # max ist eingebaute Funktion in Python
l =l.next
return m

''' Verallgemeinerung durch Funktoren :'''

*Funktor muss "callable" sein : falls f Funktor ist, funktioniert v = f(a1, a2,...)
*Funktion, oder Objekt bei dem die Funktion __call___ definiert ist.

def doSomethingGeneric(functor,iterator, initial):
for k in iterator
initial = functor(initial, k)
return initial

'''Statt maxList:'''

m = doSomethingGeneric(max,list, -1111111111111111)

'''Statt sumArray :'''

def add(x,y): return x + y
s = doSomethingGeneric(add, array, 0)

'''Statt genericCopy :'''

def append(x,y):
x.append(y)
return x
array4 = doSomeThingGeneric(append, array, [])

'''doSomethingGeneric''' gibt es in vielen Programmiersprachen :

*in Python : reduce
*in C++ : accumulate
...funktionale Sprachen (Lisp, Haskell...)

'''verwandte generische Funktionen'''

map:

[x1, x2,...] --> [f(x1),f(x2),...] # Funktor mit einem Argument

===Offered Interface versus Required Interface===

----

'''Interface:'''
*standardisierte Schnittstelle zwischen Algorithmen und Datenstruktur

====Offered Interface:====

*Funktionalität, die eine Datenstruktur anbietet.
*Die Datensruktur sollte möglichst vielseitig sein.

'''z.B. PythonList unterstützt Funktionalität von :'''

* Dynamisches Array
* Stack
* Deque
* LinkedList

*standardisiert durch abstrakte Datentypen

====Required Interface:====

*Funktionalität, die von einem Algorithmus benutzt wird
*das '''required Interface''' ist meist weniger als '''das offered Interface'''

z.B.:

'''RI''': lesender Zugriff 
'''OI''' schreibender Zugriff Konstruktor, remove...
* standardisiert durch Konzepte

* ADT sind Sammlungen zusammengehörender Konzepte
* '''RIs''' sollten minimal sein

====Konzepte ( + Hierarchie)====

* copy Constructible ( Python:Klassen, die man auf deepcopy anwenden kann, copy.deepcopy)
(Gegenteil : Singleton)
* Default Constructible (v1 = v.__class__() ist aufrufbar ) # DoublylinkedNode
* EqualityComparable('=='), LessThanComparable('<')
* ThreeWayComparable(__cmp__ ist aufrufbar)
* Indexable("a[k]", k ist Integer)
* Mapping("a[key]", key ist arbitrary)
* Hashable(__hash__ für key)

* Iteratoren :(C++ : ForwardIterator : next, BidirektionalIterator : next, prev , RandomAccessIterator : next[k])

Container : Sequence Array

====Mathematische Konzepte :====

Addable(__add__)
Subtractable(__sub__)
Multiplyable(__mul__)
Dividable(__div__)

'''Ein offered Interface ist mehr als ein required Interface.'''

Generizität

2008-06-26T12:29:55Z

Jschleic: /* Beispiel => Motivation */ Verbesserung der Gliederung

Ziel von generischer Programmierung [http://de.wikipedia.org/wiki/Generische_Programmierung] ist es, Algorithmen und Datenstrukturen so zu entwerfen und zu implementieren, dass sie möglichst vielfältig verwendbar sind.

'''Gemeint sind :'''

*verschiedene Anwendungen
*mit vielen Kombinationsmöglichkeiten
*als wiederverwendbare Bibliothek

--> ''' ohne Neuimplementation '''
*Code austauschen in Bibliotheken

===Motivation ===
An einem Beispiel wollen wir zeigen, wie ähnlich das Kopieren eines Containers für verschiedene Datentypen abläuft:

====Code====

def copyArray(a):
r =[]
for k in a:
r.append(k)
return k

class Node :
def__init__(self, data, next)
self.data = data
self.next = next

def copyArrayToList(a) :
if len(a) == 0 : return None
first = last = Node (a[0], None)
for k in a[1:] :
last.next = Node(k, None)
last = last.next
return first

def copyListToArray(l):
r = []
while l is not in None :
r.append(l.data)
l = l.next
return r

==== Beobachtung ====

Für '''N Datenstrukuren''' ist der Implementationsaufwand <math>O(N^2) </math>, wenn man je zwei Datenstrukturen ineinander umwandeln können will.
Alle Funktionen machen das gleiche mit einem uninteressantem Unterschied. Wir wollen daher im Folgenden eine Möglichkeit angeben, das kopieren der Daten zu vereinheitlichen.

====Verbesserungsmöglichkeiten ====
'''Verbesserung durch Verallgemeinerung zweier Aspekte''' :

*Navigieren durch die Quelldaten
*Aufbauen der Zieldatenstruktur

'''Vereinheitlichung der Zieldatenstruktur :'''
*standardisierte Funktion "append"
*Array hat sie schon
*Liste : definiere Klasse DoublyLinkedList

class SentinelTag : pass # keine Daten

class DoublyLinkedNode:
def__init__(self,data = sentinelTag(), next = None)
self.data = data
if next is None :
self.prev = self.next = self
else:
self.next = next
self.prev = next.prev
next.prev.next = self
next.prev = self

def isSentinel(self ) : return isinstance( self.data, sentinelTag)

class DoublyLinkedList : # Realisiert doppelt verbundene kreisförmige Kette mit Sentinel
# als "Anker"
def__init__(self):
self.sentinel = DoublyLinkedNode()
self.size = 0
def__len__(self): return self.size #len(l)
def append(self, value):
DoublyLinkedNode(value, self.sentinel)
self.size += size
def__iter__(self):
return ListIterator(self.sentinel.next)
def reverseIterator(self):
return ListIterator(self.sentinel.prev)

====verbesserter Code ====
Mit diesen Schnittstellen reicht uns nun eine einzige Methode zum Kopieren eines Containers aus.

def genericCopy (quelle, ziele) :
for k in quelle :
ziel.append(k)
return ziel

liste = genericCopy(array, DoublyLinkedList()) # Statt copyArrayToList
array2 = genericCopy(array,[]) # Statt copyArray
array3 = genericCopy(liste,[]) # Statt copyListToArray

=== Iteratoren ===

----

'''Definition Iterator:''' siehe [http://de.wikipedia.org/wiki/Iterator]

Navigation in der Quelldatenstruktur ( Iteratoren ) soll für alle Datenstrukturen funktionieren

*Objekt, das auf ein Element des Containers zeigt
*Zum nächsten Element weiter rücken kann
*Zeigt an, wenn das Ende der Sequenz erreicht ist

class ListIterator:
def__init__(self, node):
self.node = node
def next(self):
if self.node.isSentinel():
raise StopIteration() #Python Konvention
v = self.node.data
self.node = self.node.next # zeigt Ende der Sequenz
return v # Pythonkonvention, gebe vorigen Wert zurück

def__iter__(self):
return ListIterator(self.node) # Pythonkonvention, Kopie des Iterators zurückgeben

'''besser stattdessen''' :

return self.__class__(self.node) # ist allgemeiner

'''Was tut Python bei''' " for k in quelle"( in genericCopy ) ?:

iter = quelle.__iter__()
try :
while True :
k = iter.next()
... # Schleifeninhalt
except StopIteration: pass

'''Rückwärts kopieren :'''

class ReverseListIterator(ListIterator)
def next(self):
if self.node.isSentinel(): raise StopIteration()
v = self.node.data
self.node = self.node.prev
return v

revArray = genericCopy(list.reverseIterator(), []),
revList = genericCopy(reversed(array), DoublyLinkedList())

===Funktoren===

----

'''Definition eines Funktors :''' siehe [http://de.wikipedia.org/wiki/Funktor]

'''Verallgemeinerung auf Funktionen die " etwas tun":'''

def sumArray(a):
s = 0
for k in a :
s += a # s = add(s,k)
return a

def maxList(l):
m = -1111111111111111
while not l.isSentinel:
m = max(m, l.data) # max ist eingebaute Funktion in Python
l =l.next
return m

''' Verallgemeinerung durch Funktoren :'''

*Funktor muss "callable" sein : falls f Funktor ist, funktioniert v = f(a1, a2,...)
*Funktion, oder Objekt bei dem die Funktion __call___ definiert ist.

def doSomethingGeneric(functor,iterator, initial):
for k in iterator
initial = functor(initial, k)
return initial

'''Statt maxList:'''

m = doSomethingGeneric(max,list, -1111111111111111)

'''Statt sumArray :'''

def add(x,y): return x + y
s = doSomethingGeneric(add, array, 0)

'''Statt genericCopy :'''

def append(x,y):
x.append(y)
return x
array4 = doSomeThingGeneric(append, array, [])

'''doSomethingGeneric''' gibt es in vielen Programmiersprachen :

*in Python : reduce
*in C++ : accumulate
...funktionale Sprachen (Lisp, Haskell...)

'''verwandte generische Funktionen'''

map:

[x1, x2,...] --> [f(x1),f(x2),...] # Funktor mit einem Argument

===Offered Interface versus Required Interface===

----

'''Interface:'''
*standardisierte Schnittstelle zwischen Algorithmen und Datenstruktur

====Offered Interface:====

*Funktionalität, die eine Datenstruktur anbietet.
*Die Datensruktur sollte möglichst vielseitig sein.

'''z.B. PythonList unterstützt Funktionalität von :'''

* Dynamisches Array
* Stack
* Deque
* LinkedList

*standardisiert durch abstrakte Datentypen

====Required Interface:====

*Funktionalität, die von einem Algorithmus benutzt wird
*das '''required Interface''' ist meist weniger als '''das offered Interface'''

z.B.:

'''RI''': lesender Zugriff 
'''OI''' schreibender Zugriff Konstruktor, remove...
* standardisiert durch Konzepte

* ADT sind Sammlungen zusammengehörender Konzepte
* '''RIs''' sollten minimal sein

====Konzepte ( + Hierarchie)====

* copy Constructible ( Python:Klassen, die man auf deepcopy anwenden kann, copy.deepcopy)
(Gegenteil : Singleton)
* Default Constructible (v1 = v.__class__() ist aufrufbar ) # DoublylinkedNode
* EqualityComparable('=='), LessThanComparable('<')
* ThreeWayComparable(__cmp__ ist aufrufbar)
* Indexable("a[k]", k ist Integer)
* Mapping("a[key]", key ist arbitrary)
* Hashable(__hash__ für key)

* Iteratoren :(C++ : ForwardIterator : next, BidirektionalIterator : next, prev , RandomAccessIterator : next[k])

Container : Sequence Array

====Mathematische Konzepte :====

Addable(__add__)
Subtractable(__sub__)
Multiplyable(__mul__)
Dividable(__div__)

'''Ein offered Interface ist mehr als ein required Interface.'''

Graphen und Graphenalgorithmen

2008-06-25T22:44:26Z

Jschleic: /* Minimaler Spannbaum (tree-MST) */ formeln verbessert

== Einführung zu Graphen ==

=== Motivation ===

==== Königsberger - Brückenproblem ====
(1736 Euler)

[[Image:Koenigsberg.jpg]]

Königsberger Brücken:

Spaziergang durch Königsberg, so dass alle Brücken nur einmal überquert werden.

Geometrie:
Topologie

O
|| \
|| \
O O
|| /
|| /
O

* '''Definition: ungerichteter Graph'''

Ein ungerichteter Graph G = ( V, E )

** V ist endliche Menge von Knoten (vertices)
** E c V × V (edges)

Ein Graph heißt ungerichtet, wenn zusätzlich gilt:

(x,y) ∈ E => (y,x) ∈ E (symmetrie)

Bsp:

gerichteter Graph
[[Image:digraph.png|gerichteter Graph]]

ungerichtet

O
|| \
|| \
O O
|| /
|| /
O

Bsp:

* Landkarten:
** Knoten: Länder
** Kanten: gem. Grenzen

* Schaltkreis:
** Knoten: Gatter
** Kanten: Verbindungen

* Chemie (Summenformeln):
** Knoten: Elemente
** Kanten: Bindungen

* Soziologie (StudieVZ)
** Soziogramm
*** Knoten: Personen
*** Kanten: Freund von ...

* '''Definition: Vollständige Graphen'''

Bei vollständigen Graphen ist jeder Knoten mit allen anderen Knoten verbunden.

E = U V (v,w) u (w,v) | v ∈ V, w ∈ V, u != w

{| 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?

== Repräsentation von Graphen ==

Sei G = ( V, E ) geg und liege V in einer lineraren Sortierung vor.
V = { v1, ...., vn }

== Adjazenzmatrix ==

AG = aij = {1 falls (vi, vj) ∈ E ; sonst 0}

Bsp:

v = { a,b,c,d } b d
| \ / |
| \/ |
| /\ |
| / \ |
a c

a b c d
-----------
(0 1 0 1) |a
AG = (1 0 1 0) |b
(0 1 0 1) |c
(1 0 1 0) |d

== Adjezenzlisten ==

al(v) = {v' ∈ V | (u,u') ∈ E}
Lg = ((v1, al(v1)), ...., (vn, al(vn))

Python:

Array von Arrays [[...],[...],...,[...]]
0 1 n

* '''Definition: Teilgraphen'''

Ein Graph G' = (v',E') ist ein Teilgraph, wenn gilt:

** v' c V
** E' c E

Er heißt erzegender Graph, wenn zusätzlich gilt:

** v' = V

* '''Definition: Knotengrade'''
Für G = (v,E)und v ∈ V
grad(v) = |{v' ∈ V | v,v'∈ E}|
out_grad(v) = | -""- |
in_grad(v) = |{v'∈ V| (v',v) ∈ E}|

Bsp:

ungerichtet

c
|| \
|| \
b d grad(a) = | {b,b,d} | = 3
|| /
|| /
a

gerichtet

c←
| \
↓ \
b←--d out_grad(d) = 2 = | {c,b} |
| /→ in_grad(d) = 1 = | {a} |
↓ /
a

* '''Definition: Wege'''

Sei G = (v,E)

** Für v0 ∈ V ist (v0) ein Weg in G
** Für Knoten v1,...vn,vn+1 und eine Kante (vn,vn+1) ∈ E ist mit einem Weg (v0,....vn) in G auch (v0,...,vn,vn+1) ein Weg in G.

Also: Nichtleere Folgen von Knoten die durch eine Kante verbunden sind.

== Eulerweg ==

O
/ \
O----O
| \/ |
| /\ | "Das Haus vom Nikolaus" Alle ''Kanten'' werden nur ''einmal'' passiert
O----O

== Hamiltonweg ==

O
/
O----O
/
/ Alle ''Knoten'' werden nur ''einmal'' passiert
O----O

== Kreis ==

O
/ \
O O
| | v0 = vn
| | vi != vj Für Alle i,j i !=j; i,j >0; i,j < n
O----O

== Zyklen ==

O
/ \
O O
\ |
\ | Wie Kreis nur ohne (vi != vj)
O====O

* '''Definition: planare Graphen'''

Ist ein Graph, der auf einer Ebene gezeichnet werden ''kann'', sodass sich die Kanten nicht schneiden!

Bsp:

1)

O
/|\
/ O \
/ / \ \
O O

2)

O
/ \
O----O
| \/ |
| /\ |
O----O

3)

|----O @
| /@ \
| O----O
| |@ / |
| | / @|
| O----O @ entspricht ''Regionen'' auch ausserhalb der Figur ist eine Region
|@ |
|-------|

1),2) und 3) sind planare Graphen.

Der K5 Graph ist kein planarer Graph da sich zwangsweise Kanten schneiden.

* '''Definition: dualer Graph'''

Der duale Graph eines geg. planaren Graphs G' ist ein Graph mit

** Knoten für jede Region
** Für jede Kante aus E gilt es gibt eine Kante, die die angrenzende Region mit Knoten verbindet.

dualer Graph

O------O
| /| \
|-|-@ / | @\---|
| | |\/ |/| O |
| | |/\ /| |/ |
| | / @ | / |
| O-+--+-O | |
| | | | |
|---|--@---|----|

* '''Definition: erreichbar'''

W ∈ V ist erreichbar von v ∈ G gdw.:
es Existiert Weg(v,...w)

* '''Definition: Zusammenhang'''

G heißt zusammenhängend, wenn für Alle v,w ∈V gilt:
w ist erreichbar von V

== Bäume ==

* '''Definition: Baum'''

Ein Baum ist ein zusammenhängender, kreisfreier Graph.

Bsp.: Binary Search Tree

* '''Definition: erzeugender Baum'''

für G = (v,E) ist ein erzeigender Teilgraph mit Baumeigenschaft

Bsp.:

O O
/ /
O O O
| / /
| / /
O----O----O

== Durchlaufen von Graphen ==

=== Tiefensuche in Graphen ===

Sei der Graph gegeben als Liste von Listen = g

def dfs (g,node,v=0):
if v == 0:
v = [0]*len(g) #visited-Liste
v[node] = 1 #besuche node
for t in g[node]: #gehe zu allen Nachbarn
if v[t] == 0: #falls diese noch nicht besucht
dfs(g,t,v) #Rekursion

[[Image:Tiefens.jpg]]

Aufruf dfs(g,1)

=>Folge 1,2,4,3,6,7,5

=== Breitensuche ===

from Queue import *
def bfs(g,startnode)
v = [0]*len(g)
q = Queue()
v = [startnode] = 1 #besuche
q.put(startnode) #in Schlange
while not q.get()
node = q.get()
for t in q[node]
if v[t] == 0:
v[t] = 1
q.put(t)

[[Image:Breitens.jpg]]

=>Folge 1,2,3,4,5,6,7

== Damenproblem ==

---------------
| | X | | |
|---|---|---|---|
| | | | X |
|---|---|---|---|
| X | | | |
|---|---|---|---|
| | | | X |
---------------

4 Damen auf einem vereinfachten Schachbrett so Positionieren, dass sich keine bedroht.

erster Durchlauf:

[[Image:Suche1.jpg]]

zweiter Durchlauf:

[[Image:Suche2.jpg]]

== Weitere Anwendungen (18.06.08) ==

def dfs(graph):
'''
Diese Tiefensuche tut so noch nichts weiter als zu traversieren
+ graph ist Array,
i-ter Eintrag enthaelt Adjazenzliste (auch Array) des i-ten Knotens,
wobei Knoten nummeriert von 0 ... v-i
'''
def visit(graph, node, visited):
'''
visited ist Array mit Flags fuer besuchte Knoten
'''
if visited[node]: return
visited[node] = True
for neighbor in graph[node]:
visit(graph, neighbor, visited)

visited = [False]*len(graph)
for node in range(len(graph)):
visit(graph, node, visited)

=== Finden von Zusammenhangskomponenten ===

Ein moeglicher Einsatz des Verfahrens ist das Finden von Zusammenhangskomponenten (connected components).

* Beispiel: ...

* Definition: CC_i = {u_k, u_l e V: es gibt einen Pfad von u_k nach u_l ("u_l ist von u_k aus erreichbar")
* fuer ungerichtete Graphen gilt zusaetzlich: es gibt einen Pfad von u_l nach u_k}

Die Relation CC_i, also die Zusammenhangskomponenten (ZK) bilden eine Aequivalenzrelation,
also kann fuer jede ZK ein Repraesentant bestimmt werden (der sog. "Anker"). Kennt jeder
Knoten seinen Anker, so ist das ZK-Problem geloest.

==== Tiefensuchen-Algorithmus ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden, wobei statt
Knotenbesuche Knotennummern fuer die schon gefundenen Anker gesetzt werden. Ein moeglicher
Algorithmus lautet damit wie folgt:

def connectedComponents(graph):
def visit(graph, node, anchors, anchor):
'''
anchor ist Anker der aktuellen ZK
'''
if anchors[node] is not None: return # Anker von <node> schon bekannt
anchors[node] = anchor
for neighbor in graph[node]
visit(graph, neighbor, anchors, anchor)

anchors = [None]*len(graph)
for node in range(len(graph)):
visit(graph, node, anchors, node) # node: Anker der naechste ZK = erster Knoten der ZK
return anchors

* Beispiel: ...

==== Union-Find-Algorithmus ====

Eine Alternative (ohne Tiefensuche) waere z.B. ein Union-Find-Algorithmus. Idee dabei ist, dass eingangs jeder Knoten eine eigene ZK bildet, wobei in einer anschliessenden Rekursion Kanten gesucht werden, die zwischen den ZK bestehen.

Initialisierung: jeder Knoten wird als 1 ZK behandelt
Rekursion: fasse ZK zusammen (Union) falls Kante zwischen ihnen existiert
Ergebnis: Array mit dem Anker jedes Knotens

def unionFindCC(graph):
def findAnchor(anchors, k):
'''
Prueft auf anchors[k]==k
'''
while anchors[k] != k:
k = anchor[k]
return k

def edges(graph):
e = []
for node in range(len(Graph)):
for n in graph[node]:
if node < n:
e.append((node, n))
return e

anchors = range(len(graph) # jeder Knoten ist sein eigener Anker
for edge in edges(graph):
# diese Schleife ordnet die Anker so, dass
# der 1. Anker immer der kleinste ist
a1, a2 = findAnchor(anchors, edge[0]), findAnchor(anchors, edge[1])
if a2 < a1: a2,a1 = a1,a2
if a1 != a2: anchors[a2] = a1
for node in range(len(graph)):
# diese Schleife raeumt mit Indirektionen auf (s. Bsp. (#))
anchor[node] = findAnchor(anchors, node)

* Beispiel (#): ...

Eine verbreitete Anwendung fuer dieses Verfahren gibt es in der Bildverarbeitung:

* Beispiel: ...

== Variationen der Tiefensuche (19.06.2008) ==

=== Wichtige Algorithmen, die in der Vorlesung nicht behandelt werden ===

* Max Flow (zur Bestimmung des maximalen Flusses durch ein Netzwerk, z.B. bei Ölpipelines)
* Matching (auch ''Paarung'' genannt): Teilmenge der Kanten eines Graphen, wobei keine zwei Kanten einen gleichen Knoten besitzen
*:Anwendungsbereiche: Zuordnung von Gruppen, z.B. Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot), Universität (Zuordnung Studenten - Übungsgruppen)

=== Vereinfachte Lösung für den ''acyclic''-Algorithmus ===
Zum Finden von Zyklen, bzw. der Feststellung, ob ein Graph azyklisch ist, verwenden wir
wieder eine modifizierte Version der Tiefensuche: Die Knoten werden wieder nach dem System der Tiefensuche besucht, und alle besuchten Knoten in einem Array visited abgespeichert. Es gibt einen Zyklus genau dann, wenn man zu
einem früheren Knoten (außer zum direkten Vorgaenger) zurückkommt.

<code python>
def acyclic(graph):
def visit(graph, node, fromNode, visited):
if visited[node]: # Zyklus entdeckt
return False
visited[node] = True
for neighbor in graph[node]:
if neighbor == fromNode: # überspringe Nachbar, von dem du gekommen bist
continue
if not visit(graph, neighbor, node, visited):
return False # der Graph ist zyklisch
return True # kein Zyklus
visited = [False]*len(graph)
for node in range(len(graph)):
if visited[node]: # schließt aus, dass Knoten besucht wird, der schon besucht war
continue
if not visit(graph, node, None, visited):
return False
return True
</code>

'''Anmerkungen zum Code:'''

* Wenn ein Knoten bereits besucht ist, dann gehört er zur gleichen Zusammenhangskomponente - dies hat allerdings nichts mit einem Zyklus zu tun.
* Ein Graph der einmal zyklisch war wird nie wieder azyklisch.
* Der obige Algorithmus weist Ähnlichkeiten mit den bereits behandelten Algorithmen auf: '''ein guter Algorithmus zeichnet sich dadurch aus, dass mit kleinen Code-Variationen ganz andere Probleme gelöst werden können'''.

=== Kürzeste Wege (Pfade) ===

* Definition: gewichteter Graph

Jeder Kante e ist eine reelle oder natürliche Zahl we zugeordnet (wird auch als
''Kantengewicht'' bezeichnet).

z.B.
* Abstand der Anfangs- und Endknoten

* Durchflusskapazität eines Rohres (für max-Flussprobleme)

* Wechselkurse (Darstellung in einem gerichteten Graph, da jede Kante auch eine Richtung hat. Die Knoten sind die Währungen, die Kanten sind die Wechselkurse. Auf diese Weise lassen sich unterschiedliche Wechselkurse + Bankgebühren darstellen.)

* '''Definition''': Problem des kürzesten Weges

Sei P die Menge aller Wege von u nach v

Puv = {u_v}

und der Weg gegeben durch

u → x1 → x2 → ... → v

dann sind die Kosten eines Weges definiert durch

Kosten (Puv) = <math>\sum\limits_{l \in Pv}</math> we

* gesucht: Pfad u_v, so dass Kosten (u_v) minimal sind

* Lösung: Algorithmus von Dijkstra

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

<code python>
import heapq # heapq ist ein Modul von Python
def dijkstra(graph, start, ziel): # graph: gewichtete Adjazenzliste
heap = []
visited = [None]*len(graph)
visited[start] = start
for neighbor in graph[start]:
heapq.heappush(heap, (neighbor[1], start, neighbor[0])) # neighbor[1]:Kantengewicht,neighbor[0]:Endpunkt d. K.
while len(heap) > 0: # solange der heap nicht leer ist
w, fromNode, node = heapq.heappop(heap)
if visited[node] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
visited[node] = fromNode # baue Vorgänger-Baum
if node == ziel: # da der heap noch nicht leer ist, wird an dieser Stelle ein break benötigt
break
for neighbor in graph[node]:
if visited[neighbor[0]] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
heapq.heappush(heap, (neighbor[1]+w, node, neighbor[0]))
bestPath = []
t = ziel
while t != visited[t]: # Array wird durchlaufen bis der Anker des Pfades gefunden ist, vgl. Union-Search
bestPath.append(t)
t=visited[t]
bestPath.append(start)
return bestPath # bestPath.reverse()
</code>

'''Anmerkungen zum Code:'''
* der graph ist eine gewichtete Adjazenzliste

{|

|-

| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | Endknoten || → || style="background:silver; color:white" | Endknoten || (Nr. der Nachbarn des Knoten 0)

|-

| || style="background:silver; color:white" | 1 || || style="background:silver; color:white" | Gewicht || || style="background:silver; color:white" | Gewicht || (Gewicht der jeweiligen Kante)

|-

| || style="background:silver; color:white" | 2 ||

|-

| || style="background:silver; color:white" | 3 ||

|}
* Eingabe z.B.:
{|
|-
| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | (1, 0.3) || style="background:silver; color:white" | (3, 0.1) || style="background:silver; color:white" | (5, 1.2) ||
|-
| || style="background:silver; color:white" | 1 || → || style="background:silver; color:white" | || style="background:silver; color:white" | || style="background:silver; color:white" | ||
|-
| || style="background:silver; color:white" | 2 ||
|-
| || style="background:silver; color:white" | 3 ||
|-
| || style="background:silver; color:white" | 4 ||
|-
| || style="background:silver; color:white" | 5 ||
|-
| || style="background:silver; color:white" | 6 ||
|}
* heapq() verwendet den 1. Eintrag des Tupels zum sortieren des heap

==== Prinzip des Dijkstra-Algorithmus ====

* Algorithmus ist Tiefensuche mit Prioritätswarteschlange (Heap) statt eines Stapelspeichers (Stack) → vgl. Übung 8

* Die Prioritätswarteschlange speichert die kürzesten Wege, die bereits gefunden worden sind.

* Wenn man die Prioritätswarteschlange (Heap) durch eine Warteschlange (Queue) ersetzt, erhält man Breitensuche.

* Wenn man die Prioritätswarteschlange (Heap) durch einen Stapelspeicher (Stack) ersetzt, erhält man Tiefensuche.

==== Beispiel ====

[[Image:Bsp.jpg]]

* An der Stelle "neighbor[1]" wird eine Zählvariable ''count'' eingefügt, die hoch (Breitensuche) oder runter (Tiefensuche) zählt.

* Die Gewichte werden hoch- oder runtergezählt, so wie die Kanten gesehen wurden.

* Wenn man rückwärts zählt (von 0 abziehen), werden die zuletzt hinzugefügten Kanten expandiert.

* '''Algorithmus von Dijkstra funktioniert nur für positive Kantengewichte
*:<math>\forall</math> we > 0'''

* Bei negativen Kantengewichten könnte es Zyklen geben, die negative Kosten für den ganzen Zyklus haben:

/\ 1. Durchlauf: Kosten -1
1 / \ 4 2. Durchlauf: Kosten -2
/____\ etc.
2

* Verwendung bei arbitragen Geschäften (Börsengeschäfte, die die Preis-, Kurs- und Zinsunterschiede auf verschiedenen Märkten ausnutzen):
*:EURO wurden in YEN, YEN in DOLLAR gewechselt und das Geld hat sich dadurch vermehrt
* Für negative Kantengewichte verwendet man den Bellman-Ford-Allgorithmus, der allerdings langsamer ist, als der Dijkstra-Algorithmus.

==== Komplexität von Dijkstra ====

* Jeder Knoten wird höchstens 1x expandiert (Iteration über die Nachbarn des Knotens).

* Jeder Knoten kann mehrmals im Heap enthalten sein.

* Es sind aber höchstens E (Anzahl der Kanten) Heap-Einträge möglich, da jede Kante höchstens 1 Heap-Eintrag generiert (ein Knoten ist nur dann im Heap, wenn man ihn über eine Kante erreicht hat, die man vorher noch nicht besucht hatte). Deshalb können nie mehr Einträge im Heap sein, als es Kanten gibt. Die Komplexität von heappush(), heappop() ist
O(log E) = O(2 log v) = O(log v)
wenn alle Kanten einen Heap-Eintrag generiert haben.
* Die while-Schleife wird im schlimmsten Fall E mal durchlaufen, deshalb ist die Komplexität von Dijkstra O(E log v).

==== Korrektheit von Dijkstra ====

* Falls
visited[node] (Schleifen-Invariante von while) != None
ist, dann liefert Zurückverfolgen des Pfades von node nach start den kürzesten Pfad von start nach node (gilt für alle Knoten, für die das visited-Feld gesetzt ist).
* Induktionsanfang: visited[start] ist einziger not-None-Fall → Bedingung erfüllt
* Induktionsschritt: wenn visited[node] gesetzt wird, ist es ein kürzester Pfad

==== Indirekter Beweis ====

Set S = {node | visited[node] != None} (alle Knoten, von denen wir den kürzesten Pfad schon kennen)

* u ist der Knoten an der Spitze des Heaps
* fromNode <math>\in</math> S (ein Nachbar von node kommt erst dann in den Heap, wenn visited[node] vorher gesetzt wurde)
* falls u → fromNode &rarr start kein kürzester Pfad wäre, müsste u's Vorgänger in V\S sein
* sei dieser Vorgänger x <math>\notin</math> S, x <math>\not=</math> u
* sei wx das Gewicht der Kante x → u, dann sind die Kosten für start nach u gleich

Kosten(start_u) = Kosten(start_x) + wx

* Annahme des indirekten Beweises:

Kosten(start_fromNode) + wfromNode

* Behauptung des indirekten Beweises:
Es gibt einen anderen Pfad x, so dass die Kosten von start nach x geringer sind

* Da aber gilt:
fromNode <math>\in</math> S und x <math>\notin</math> S

* gilt (Induktionsvoraussetzung):
Kosten(start_fromNode) < Kosten(start_x)

* Falls Kosten(start_x) < Kosten(start_u) müsste x im Heap vor u kommen; daraus folgt, dass u nicht an der Spitze des Heaps sein kann

→ Widerspruch!

→ Die Behauptung, der Weg über x ist besser, kann nicht stimmen.

→ Korrektheit von Dijkstra ist somit bewiesen.

==== Wie kann man Dijkstra noch verbessern? ====

===== A*-Algorithmus =====

* Verbesserung von Dijkstra im typischen Fall, aber die Komplexität ist immer noch =(Elog v) im schlechtesten Fall (die Komplexität kann man nicht verbessern, aber die Laufzeit im typischen Fall).
* Schätzung für jeden Knoten für den restlichen Weg:
geschätzte Gesamtkosten: Kosten(start_node) + Restschätzung(node_ziel)
(exakte Kosten werden durch Dijkstra ermittelt)

'''Idee:'''
* Sortiere den Heap nach geschätzten Gesamtkosten.
* Satz:
Falls jede Schätzung den exakten Weg unterschätzt, werden die gleichen Pfade gefunden, wie
bei Dijkstra (also die korrekten kürzesten Pfade).
(Die Schätzung für den restlichen Weg muss man immer so einrichten, dass der tatsächliche Weg unterschätzt wird. Da keine Straße kürzer sein kann als die Luftlinie, ist die Luftlinie eine geeignete Annahme für A*.)
* Falls der falsche Pfad im Heap eher an die Spitze kommt als der richtige Pfad, findet der A*-Algorithmus den falschen Pfad.
* Wenn der Pfad zum Ziel an der Spitze des Heap ist, dann wird keine Restschätzung mehr benötigt, denn wenn der Zielknoten aus dem Heap herrauskommt, dann hat man die exakte Berechnung. Die Restschätzung ist in diesem Fall 0. Wenn die Schätzung zu klein ist, wird der exakte Weg immer größer sein und zuerst aus dem Heap herauskommen.

===Minimaler Spannbaum (tree-MST)===
gegeben: gewichteter, zusammenhängender Graph G 
gesucht: Untermenge <math>E'\subseteq E</math>, so dass <math>\sum_{e\in E} w_e</math> minimal und G' zusammenhängend ist. 
G' definiert dann einen Baum, denn andernfalls könnte man \sum verringern (eine Kante weglassen)
Anwendungen: Wie verbindet man n Punkte mit möglichst wenigen kurzen Straßen

====Algorithmus von Prim====

def prim(graph):
heap = []
visited = [False]*len(graph)
sum = 0
r = []
for neighbor in graph[0]:
heapq.heappush(heap, (neighbor[1], 0, neighbor[0]))
while len(heap):
wn, start, ziel = heapq.heappop(heap)
if visited[ziel]: continue
visited[ziel] = True
sum += wn
r.append([start, ziel])
for neighbor in graph[ziel]:
if visited[neighbor[0]]: continue
heapq.heappush(heap, (neighbor[1], ziel, neighbor[0]))
return sum, r

====Algorithmus von Krushal====
Idee: wie beim Union-Find-Algorithmus für Zusammenhangskomponenten
# Behandle jeden Knoten als Baum für sich
# Fasse zwei Bäume zu neuem Baum zusammen
für MST: betrachte dazu die Kanten in aufsteigender Reihenfolge der Gewichte
(ignoriere Kanten zw. Knoten in gleichem Baum)
=> geeignet für Übungsaufgabe

=== Problem des Handlungsreisenden (travelling salesman problem - TSP)===
gegeben: zusammenhängender, gewichteter Graph (oft vollständiger Graph)

gesucht: kürzester Weg, der alle Knoten genau einmal besucht (und zum Ausgangsknoten zurückkehrt)

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

naive Lösung: brute force (Durchprobieren aller möglichen Pfade)

'''Systematisches Erzeugen aller Permutationen'''
Trick: erzeuge jede Permutation in lexikographischer Ordnung

def next_permutation(a):
i = len(a) -1
while True:
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexicogr. Nachfolger hat groß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, also
<math>O(v!) = O(v^v)</math>

Graphen und Graphenalgorithmen

2008-06-25T22:42:56Z

Jschleic: /* Algorithmus von Krushal */ nummerierung

== Einführung zu Graphen ==

=== Motivation ===

==== Königsberger - Brückenproblem ====
(1736 Euler)

[[Image:Koenigsberg.jpg]]

Königsberger Brücken:

Spaziergang durch Königsberg, so dass alle Brücken nur einmal überquert werden.

Geometrie:
Topologie

O
|| \
|| \
O O
|| /
|| /
O

* '''Definition: ungerichteter Graph'''

Ein ungerichteter Graph G = ( V, E )

** V ist endliche Menge von Knoten (vertices)
** E c V × V (edges)

Ein Graph heißt ungerichtet, wenn zusätzlich gilt:

(x,y) ∈ E => (y,x) ∈ E (symmetrie)

Bsp:

gerichteter Graph
[[Image:digraph.png|gerichteter Graph]]

ungerichtet

O
|| \
|| \
O O
|| /
|| /
O

Bsp:

* Landkarten:
** Knoten: Länder
** Kanten: gem. Grenzen

* Schaltkreis:
** Knoten: Gatter
** Kanten: Verbindungen

* Chemie (Summenformeln):
** Knoten: Elemente
** Kanten: Bindungen

* Soziologie (StudieVZ)
** Soziogramm
*** Knoten: Personen
*** Kanten: Freund von ...

* '''Definition: Vollständige Graphen'''

Bei vollständigen Graphen ist jeder Knoten mit allen anderen Knoten verbunden.

E = U V (v,w) u (w,v) | v ∈ V, w ∈ V, u != w

{| 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?

== Repräsentation von Graphen ==

Sei G = ( V, E ) geg und liege V in einer lineraren Sortierung vor.
V = { v1, ...., vn }

== Adjazenzmatrix ==

AG = aij = {1 falls (vi, vj) ∈ E ; sonst 0}

Bsp:

v = { a,b,c,d } b d
| \ / |
| \/ |
| /\ |
| / \ |
a c

a b c d
-----------
(0 1 0 1) |a
AG = (1 0 1 0) |b
(0 1 0 1) |c
(1 0 1 0) |d

== Adjezenzlisten ==

al(v) = {v' ∈ V | (u,u') ∈ E}
Lg = ((v1, al(v1)), ...., (vn, al(vn))

Python:

Array von Arrays [[...],[...],...,[...]]
0 1 n

* '''Definition: Teilgraphen'''

Ein Graph G' = (v',E') ist ein Teilgraph, wenn gilt:

** v' c V
** E' c E

Er heißt erzegender Graph, wenn zusätzlich gilt:

** v' = V

* '''Definition: Knotengrade'''
Für G = (v,E)und v ∈ V
grad(v) = |{v' ∈ V | v,v'∈ E}|
out_grad(v) = | -""- |
in_grad(v) = |{v'∈ V| (v',v) ∈ E}|

Bsp:

ungerichtet

c
|| \
|| \
b d grad(a) = | {b,b,d} | = 3
|| /
|| /
a

gerichtet

c←
| \
↓ \
b←--d out_grad(d) = 2 = | {c,b} |
| /→ in_grad(d) = 1 = | {a} |
↓ /
a

* '''Definition: Wege'''

Sei G = (v,E)

** Für v0 ∈ V ist (v0) ein Weg in G
** Für Knoten v1,...vn,vn+1 und eine Kante (vn,vn+1) ∈ E ist mit einem Weg (v0,....vn) in G auch (v0,...,vn,vn+1) ein Weg in G.

Also: Nichtleere Folgen von Knoten die durch eine Kante verbunden sind.

== Eulerweg ==

O
/ \
O----O
| \/ |
| /\ | "Das Haus vom Nikolaus" Alle ''Kanten'' werden nur ''einmal'' passiert
O----O

== Hamiltonweg ==

O
/
O----O
/
/ Alle ''Knoten'' werden nur ''einmal'' passiert
O----O

== Kreis ==

O
/ \
O O
| | v0 = vn
| | vi != vj Für Alle i,j i !=j; i,j >0; i,j < n
O----O

== Zyklen ==

O
/ \
O O
\ |
\ | Wie Kreis nur ohne (vi != vj)
O====O

* '''Definition: planare Graphen'''

Ist ein Graph, der auf einer Ebene gezeichnet werden ''kann'', sodass sich die Kanten nicht schneiden!

Bsp:

1)

O
/|\
/ O \
/ / \ \
O O

2)

O
/ \
O----O
| \/ |
| /\ |
O----O

3)

|----O @
| /@ \
| O----O
| |@ / |
| | / @|
| O----O @ entspricht ''Regionen'' auch ausserhalb der Figur ist eine Region
|@ |
|-------|

1),2) und 3) sind planare Graphen.

Der K5 Graph ist kein planarer Graph da sich zwangsweise Kanten schneiden.

* '''Definition: dualer Graph'''

Der duale Graph eines geg. planaren Graphs G' ist ein Graph mit

** Knoten für jede Region
** Für jede Kante aus E gilt es gibt eine Kante, die die angrenzende Region mit Knoten verbindet.

dualer Graph

O------O
| /| \
|-|-@ / | @\---|
| | |\/ |/| O |
| | |/\ /| |/ |
| | / @ | / |
| O-+--+-O | |
| | | | |
|---|--@---|----|

* '''Definition: erreichbar'''

W ∈ V ist erreichbar von v ∈ G gdw.:
es Existiert Weg(v,...w)

* '''Definition: Zusammenhang'''

G heißt zusammenhängend, wenn für Alle v,w ∈V gilt:
w ist erreichbar von V

== Bäume ==

* '''Definition: Baum'''

Ein Baum ist ein zusammenhängender, kreisfreier Graph.

Bsp.: Binary Search Tree

* '''Definition: erzeugender Baum'''

für G = (v,E) ist ein erzeigender Teilgraph mit Baumeigenschaft

Bsp.:

O O
/ /
O O O
| / /
| / /
O----O----O

== Durchlaufen von Graphen ==

=== Tiefensuche in Graphen ===

Sei der Graph gegeben als Liste von Listen = g

def dfs (g,node,v=0):
if v == 0:
v = [0]*len(g) #visited-Liste
v[node] = 1 #besuche node
for t in g[node]: #gehe zu allen Nachbarn
if v[t] == 0: #falls diese noch nicht besucht
dfs(g,t,v) #Rekursion

[[Image:Tiefens.jpg]]

Aufruf dfs(g,1)

=>Folge 1,2,4,3,6,7,5

=== Breitensuche ===

from Queue import *
def bfs(g,startnode)
v = [0]*len(g)
q = Queue()
v = [startnode] = 1 #besuche
q.put(startnode) #in Schlange
while not q.get()
node = q.get()
for t in q[node]
if v[t] == 0:
v[t] = 1
q.put(t)

[[Image:Breitens.jpg]]

=>Folge 1,2,3,4,5,6,7

== Damenproblem ==

---------------
| | X | | |
|---|---|---|---|
| | | | X |
|---|---|---|---|
| X | | | |
|---|---|---|---|
| | | | X |
---------------

4 Damen auf einem vereinfachten Schachbrett so Positionieren, dass sich keine bedroht.

erster Durchlauf:

[[Image:Suche1.jpg]]

zweiter Durchlauf:

[[Image:Suche2.jpg]]

== Weitere Anwendungen (18.06.08) ==

def dfs(graph):
'''
Diese Tiefensuche tut so noch nichts weiter als zu traversieren
+ graph ist Array,
i-ter Eintrag enthaelt Adjazenzliste (auch Array) des i-ten Knotens,
wobei Knoten nummeriert von 0 ... v-i
'''
def visit(graph, node, visited):
'''
visited ist Array mit Flags fuer besuchte Knoten
'''
if visited[node]: return
visited[node] = True
for neighbor in graph[node]:
visit(graph, neighbor, visited)

visited = [False]*len(graph)
for node in range(len(graph)):
visit(graph, node, visited)

=== Finden von Zusammenhangskomponenten ===

Ein moeglicher Einsatz des Verfahrens ist das Finden von Zusammenhangskomponenten (connected components).

* Beispiel: ...

* Definition: CC_i = {u_k, u_l e V: es gibt einen Pfad von u_k nach u_l ("u_l ist von u_k aus erreichbar")
* fuer ungerichtete Graphen gilt zusaetzlich: es gibt einen Pfad von u_l nach u_k}

Die Relation CC_i, also die Zusammenhangskomponenten (ZK) bilden eine Aequivalenzrelation,
also kann fuer jede ZK ein Repraesentant bestimmt werden (der sog. "Anker"). Kennt jeder
Knoten seinen Anker, so ist das ZK-Problem geloest.

==== Tiefensuchen-Algorithmus ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden, wobei statt
Knotenbesuche Knotennummern fuer die schon gefundenen Anker gesetzt werden. Ein moeglicher
Algorithmus lautet damit wie folgt:

def connectedComponents(graph):
def visit(graph, node, anchors, anchor):
'''
anchor ist Anker der aktuellen ZK
'''
if anchors[node] is not None: return # Anker von <node> schon bekannt
anchors[node] = anchor
for neighbor in graph[node]
visit(graph, neighbor, anchors, anchor)

anchors = [None]*len(graph)
for node in range(len(graph)):
visit(graph, node, anchors, node) # node: Anker der naechste ZK = erster Knoten der ZK
return anchors

* Beispiel: ...

==== Union-Find-Algorithmus ====

Eine Alternative (ohne Tiefensuche) waere z.B. ein Union-Find-Algorithmus. Idee dabei ist, dass eingangs jeder Knoten eine eigene ZK bildet, wobei in einer anschliessenden Rekursion Kanten gesucht werden, die zwischen den ZK bestehen.

Initialisierung: jeder Knoten wird als 1 ZK behandelt
Rekursion: fasse ZK zusammen (Union) falls Kante zwischen ihnen existiert
Ergebnis: Array mit dem Anker jedes Knotens

def unionFindCC(graph):
def findAnchor(anchors, k):
'''
Prueft auf anchors[k]==k
'''
while anchors[k] != k:
k = anchor[k]
return k

def edges(graph):
e = []
for node in range(len(Graph)):
for n in graph[node]:
if node < n:
e.append((node, n))
return e

anchors = range(len(graph) # jeder Knoten ist sein eigener Anker
for edge in edges(graph):
# diese Schleife ordnet die Anker so, dass
# der 1. Anker immer der kleinste ist
a1, a2 = findAnchor(anchors, edge[0]), findAnchor(anchors, edge[1])
if a2 < a1: a2,a1 = a1,a2
if a1 != a2: anchors[a2] = a1
for node in range(len(graph)):
# diese Schleife raeumt mit Indirektionen auf (s. Bsp. (#))
anchor[node] = findAnchor(anchors, node)

* Beispiel (#): ...

Eine verbreitete Anwendung fuer dieses Verfahren gibt es in der Bildverarbeitung:

* Beispiel: ...

== Variationen der Tiefensuche (19.06.2008) ==

=== Wichtige Algorithmen, die in der Vorlesung nicht behandelt werden ===

* Max Flow (zur Bestimmung des maximalen Flusses durch ein Netzwerk, z.B. bei Ölpipelines)
* Matching (auch ''Paarung'' genannt): Teilmenge der Kanten eines Graphen, wobei keine zwei Kanten einen gleichen Knoten besitzen
*:Anwendungsbereiche: Zuordnung von Gruppen, z.B. Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot), Universität (Zuordnung Studenten - Übungsgruppen)

=== Vereinfachte Lösung für den ''acyclic''-Algorithmus ===
Zum Finden von Zyklen, bzw. der Feststellung, ob ein Graph azyklisch ist, verwenden wir
wieder eine modifizierte Version der Tiefensuche: Die Knoten werden wieder nach dem System der Tiefensuche besucht, und alle besuchten Knoten in einem Array visited abgespeichert. Es gibt einen Zyklus genau dann, wenn man zu
einem früheren Knoten (außer zum direkten Vorgaenger) zurückkommt.

<code python>
def acyclic(graph):
def visit(graph, node, fromNode, visited):
if visited[node]: # Zyklus entdeckt
return False
visited[node] = True
for neighbor in graph[node]:
if neighbor == fromNode: # überspringe Nachbar, von dem du gekommen bist
continue
if not visit(graph, neighbor, node, visited):
return False # der Graph ist zyklisch
return True # kein Zyklus
visited = [False]*len(graph)
for node in range(len(graph)):
if visited[node]: # schließt aus, dass Knoten besucht wird, der schon besucht war
continue
if not visit(graph, node, None, visited):
return False
return True
</code>

'''Anmerkungen zum Code:'''

* Wenn ein Knoten bereits besucht ist, dann gehört er zur gleichen Zusammenhangskomponente - dies hat allerdings nichts mit einem Zyklus zu tun.
* Ein Graph der einmal zyklisch war wird nie wieder azyklisch.
* Der obige Algorithmus weist Ähnlichkeiten mit den bereits behandelten Algorithmen auf: '''ein guter Algorithmus zeichnet sich dadurch aus, dass mit kleinen Code-Variationen ganz andere Probleme gelöst werden können'''.

=== Kürzeste Wege (Pfade) ===

* Definition: gewichteter Graph

Jeder Kante e ist eine reelle oder natürliche Zahl we zugeordnet (wird auch als
''Kantengewicht'' bezeichnet).

z.B.
* Abstand der Anfangs- und Endknoten

* Durchflusskapazität eines Rohres (für max-Flussprobleme)

* Wechselkurse (Darstellung in einem gerichteten Graph, da jede Kante auch eine Richtung hat. Die Knoten sind die Währungen, die Kanten sind die Wechselkurse. Auf diese Weise lassen sich unterschiedliche Wechselkurse + Bankgebühren darstellen.)

* '''Definition''': Problem des kürzesten Weges

Sei P die Menge aller Wege von u nach v

Puv = {u_v}

und der Weg gegeben durch

u → x1 → x2 → ... → v

dann sind die Kosten eines Weges definiert durch

Kosten (Puv) = <math>\sum\limits_{l \in Pv}</math> we

* gesucht: Pfad u_v, so dass Kosten (u_v) minimal sind

* Lösung: Algorithmus von Dijkstra

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

<code python>
import heapq # heapq ist ein Modul von Python
def dijkstra(graph, start, ziel): # graph: gewichtete Adjazenzliste
heap = []
visited = [None]*len(graph)
visited[start] = start
for neighbor in graph[start]:
heapq.heappush(heap, (neighbor[1], start, neighbor[0])) # neighbor[1]:Kantengewicht,neighbor[0]:Endpunkt d. K.
while len(heap) > 0: # solange der heap nicht leer ist
w, fromNode, node = heapq.heappop(heap)
if visited[node] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
visited[node] = fromNode # baue Vorgänger-Baum
if node == ziel: # da der heap noch nicht leer ist, wird an dieser Stelle ein break benötigt
break
for neighbor in graph[node]:
if visited[neighbor[0]] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
heapq.heappush(heap, (neighbor[1]+w, node, neighbor[0]))
bestPath = []
t = ziel
while t != visited[t]: # Array wird durchlaufen bis der Anker des Pfades gefunden ist, vgl. Union-Search
bestPath.append(t)
t=visited[t]
bestPath.append(start)
return bestPath # bestPath.reverse()
</code>

'''Anmerkungen zum Code:'''
* der graph ist eine gewichtete Adjazenzliste

{|

|-

| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | Endknoten || → || style="background:silver; color:white" | Endknoten || (Nr. der Nachbarn des Knoten 0)

|-

| || style="background:silver; color:white" | 1 || || style="background:silver; color:white" | Gewicht || || style="background:silver; color:white" | Gewicht || (Gewicht der jeweiligen Kante)

|-

| || style="background:silver; color:white" | 2 ||

|-

| || style="background:silver; color:white" | 3 ||

|}
* Eingabe z.B.:
{|
|-
| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | (1, 0.3) || style="background:silver; color:white" | (3, 0.1) || style="background:silver; color:white" | (5, 1.2) ||
|-
| || style="background:silver; color:white" | 1 || → || style="background:silver; color:white" | || style="background:silver; color:white" | || style="background:silver; color:white" | ||
|-
| || style="background:silver; color:white" | 2 ||
|-
| || style="background:silver; color:white" | 3 ||
|-
| || style="background:silver; color:white" | 4 ||
|-
| || style="background:silver; color:white" | 5 ||
|-
| || style="background:silver; color:white" | 6 ||
|}
* heapq() verwendet den 1. Eintrag des Tupels zum sortieren des heap

==== Prinzip des Dijkstra-Algorithmus ====

* Algorithmus ist Tiefensuche mit Prioritätswarteschlange (Heap) statt eines Stapelspeichers (Stack) → vgl. Übung 8

* Die Prioritätswarteschlange speichert die kürzesten Wege, die bereits gefunden worden sind.

* Wenn man die Prioritätswarteschlange (Heap) durch eine Warteschlange (Queue) ersetzt, erhält man Breitensuche.

* Wenn man die Prioritätswarteschlange (Heap) durch einen Stapelspeicher (Stack) ersetzt, erhält man Tiefensuche.

==== Beispiel ====

[[Image:Bsp.jpg]]

* An der Stelle "neighbor[1]" wird eine Zählvariable ''count'' eingefügt, die hoch (Breitensuche) oder runter (Tiefensuche) zählt.

* Die Gewichte werden hoch- oder runtergezählt, so wie die Kanten gesehen wurden.

* Wenn man rückwärts zählt (von 0 abziehen), werden die zuletzt hinzugefügten Kanten expandiert.

* '''Algorithmus von Dijkstra funktioniert nur für positive Kantengewichte
*:<math>\forall</math> we > 0'''

* Bei negativen Kantengewichten könnte es Zyklen geben, die negative Kosten für den ganzen Zyklus haben:

/\ 1. Durchlauf: Kosten -1
1 / \ 4 2. Durchlauf: Kosten -2
/____\ etc.
2

* Verwendung bei arbitragen Geschäften (Börsengeschäfte, die die Preis-, Kurs- und Zinsunterschiede auf verschiedenen Märkten ausnutzen):
*:EURO wurden in YEN, YEN in DOLLAR gewechselt und das Geld hat sich dadurch vermehrt
* Für negative Kantengewichte verwendet man den Bellman-Ford-Allgorithmus, der allerdings langsamer ist, als der Dijkstra-Algorithmus.

==== Komplexität von Dijkstra ====

* Jeder Knoten wird höchstens 1x expandiert (Iteration über die Nachbarn des Knotens).

* Jeder Knoten kann mehrmals im Heap enthalten sein.

* Es sind aber höchstens E (Anzahl der Kanten) Heap-Einträge möglich, da jede Kante höchstens 1 Heap-Eintrag generiert (ein Knoten ist nur dann im Heap, wenn man ihn über eine Kante erreicht hat, die man vorher noch nicht besucht hatte). Deshalb können nie mehr Einträge im Heap sein, als es Kanten gibt. Die Komplexität von heappush(), heappop() ist
O(log E) = O(2 log v) = O(log v)
wenn alle Kanten einen Heap-Eintrag generiert haben.
* Die while-Schleife wird im schlimmsten Fall E mal durchlaufen, deshalb ist die Komplexität von Dijkstra O(E log v).

==== Korrektheit von Dijkstra ====

* Falls
visited[node] (Schleifen-Invariante von while) != None
ist, dann liefert Zurückverfolgen des Pfades von node nach start den kürzesten Pfad von start nach node (gilt für alle Knoten, für die das visited-Feld gesetzt ist).
* Induktionsanfang: visited[start] ist einziger not-None-Fall → Bedingung erfüllt
* Induktionsschritt: wenn visited[node] gesetzt wird, ist es ein kürzester Pfad

==== Indirekter Beweis ====

Set S = {node | visited[node] != None} (alle Knoten, von denen wir den kürzesten Pfad schon kennen)

* u ist der Knoten an der Spitze des Heaps
* fromNode <math>\in</math> S (ein Nachbar von node kommt erst dann in den Heap, wenn visited[node] vorher gesetzt wurde)
* falls u → fromNode &rarr start kein kürzester Pfad wäre, müsste u's Vorgänger in V\S sein
* sei dieser Vorgänger x <math>\notin</math> S, x <math>\not=</math> u
* sei wx das Gewicht der Kante x → u, dann sind die Kosten für start nach u gleich

Kosten(start_u) = Kosten(start_x) + wx

* Annahme des indirekten Beweises:

Kosten(start_fromNode) + wfromNode

* Behauptung des indirekten Beweises:
Es gibt einen anderen Pfad x, so dass die Kosten von start nach x geringer sind

* Da aber gilt:
fromNode <math>\in</math> S und x <math>\notin</math> S

* gilt (Induktionsvoraussetzung):
Kosten(start_fromNode) < Kosten(start_x)

* Falls Kosten(start_x) < Kosten(start_u) müsste x im Heap vor u kommen; daraus folgt, dass u nicht an der Spitze des Heaps sein kann

→ Widerspruch!

→ Die Behauptung, der Weg über x ist besser, kann nicht stimmen.

→ Korrektheit von Dijkstra ist somit bewiesen.

==== Wie kann man Dijkstra noch verbessern? ====

===== A*-Algorithmus =====

* Verbesserung von Dijkstra im typischen Fall, aber die Komplexität ist immer noch =(Elog v) im schlechtesten Fall (die Komplexität kann man nicht verbessern, aber die Laufzeit im typischen Fall).
* Schätzung für jeden Knoten für den restlichen Weg:
geschätzte Gesamtkosten: Kosten(start_node) + Restschätzung(node_ziel)
(exakte Kosten werden durch Dijkstra ermittelt)

'''Idee:'''
* Sortiere den Heap nach geschätzten Gesamtkosten.
* Satz:
Falls jede Schätzung den exakten Weg unterschätzt, werden die gleichen Pfade gefunden, wie
bei Dijkstra (also die korrekten kürzesten Pfade).
(Die Schätzung für den restlichen Weg muss man immer so einrichten, dass der tatsächliche Weg unterschätzt wird. Da keine Straße kürzer sein kann als die Luftlinie, ist die Luftlinie eine geeignete Annahme für A*.)
* Falls der falsche Pfad im Heap eher an die Spitze kommt als der richtige Pfad, findet der A*-Algorithmus den falschen Pfad.
* Wenn der Pfad zum Ziel an der Spitze des Heap ist, dann wird keine Restschätzung mehr benötigt, denn wenn der Zielknoten aus dem Heap herrauskommt, dann hat man die exakte Berechnung. Die Restschätzung ist in diesem Fall 0. Wenn die Schätzung zu klein ist, wird der exakte Weg immer größer sein und zuerst aus dem Heap herauskommen.

===Minimaler Spannbaum (tree-MST)===
gegeben: gewichteter, zusammenhängender Graph G
gesucht: Untermenge E'\subseteq E, so dass \sum_{e\in E} w_e minimal und G' zusammenhängend
G' definiert dann einen Baum, denn andernfalls könnte man \sum verringern (eine Kante weglassen)
Anwendungen: Wie verbindet man n Punkte mit möglichst wenigen kurzen Straßen"""

====Algorithmus von Prim====

def prim(graph):
heap = []
visited = [False]*len(graph)
sum = 0
r = []
for neighbor in graph[0]:
heapq.heappush(heap, (neighbor[1], 0, neighbor[0]))
while len(heap):
wn, start, ziel = heapq.heappop(heap)
if visited[ziel]: continue
visited[ziel] = True
sum += wn
r.append([start, ziel])
for neighbor in graph[ziel]:
if visited[neighbor[0]]: continue
heapq.heappush(heap, (neighbor[1], ziel, neighbor[0]))
return sum, r

====Algorithmus von Krushal====
Idee: wie beim Union-Find-Algorithmus für Zusammenhangskomponenten
# Behandle jeden Knoten als Baum für sich
# Fasse zwei Bäume zu neuem Baum zusammen
für MST: betrachte dazu die Kanten in aufsteigender Reihenfolge der Gewichte
(ignoriere Kanten zw. Knoten in gleichem Baum)
=> geeignet für Übungsaufgabe

=== Problem des Handlungsreisenden (travelling salesman problem - TSP)===
gegeben: zusammenhängender, gewichteter Graph (oft vollständiger Graph)

gesucht: kürzester Weg, der alle Knoten genau einmal besucht (und zum Ausgangsknoten zurückkehrt)

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

naive Lösung: brute force (Durchprobieren aller möglichen Pfade)

'''Systematisches Erzeugen aller Permutationen'''
Trick: erzeuge jede Permutation in lexikographischer Ordnung

def next_permutation(a):
i = len(a) -1
while True:
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexicogr. Nachfolger hat groß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, also
<math>O(v!) = O(v^v)</math>

Graphen und Graphenalgorithmen

2008-06-25T22:41:56Z

Jschleic: /* Problem des Handlungsreisenden (travelling salesman problem - TSP) */ typo

== Einführung zu Graphen ==

=== Motivation ===

==== Königsberger - Brückenproblem ====
(1736 Euler)

[[Image:Koenigsberg.jpg]]

Königsberger Brücken:

Spaziergang durch Königsberg, so dass alle Brücken nur einmal überquert werden.

Geometrie:
Topologie

O
|| \
|| \
O O
|| /
|| /
O

* '''Definition: ungerichteter Graph'''

Ein ungerichteter Graph G = ( V, E )

** V ist endliche Menge von Knoten (vertices)
** E c V × V (edges)

Ein Graph heißt ungerichtet, wenn zusätzlich gilt:

(x,y) ∈ E => (y,x) ∈ E (symmetrie)

Bsp:

gerichteter Graph
[[Image:digraph.png|gerichteter Graph]]

ungerichtet

O
|| \
|| \
O O
|| /
|| /
O

Bsp:

* Landkarten:
** Knoten: Länder
** Kanten: gem. Grenzen

* Schaltkreis:
** Knoten: Gatter
** Kanten: Verbindungen

* Chemie (Summenformeln):
** Knoten: Elemente
** Kanten: Bindungen

* Soziologie (StudieVZ)
** Soziogramm
*** Knoten: Personen
*** Kanten: Freund von ...

* '''Definition: Vollständige Graphen'''

Bei vollständigen Graphen ist jeder Knoten mit allen anderen Knoten verbunden.

E = U V (v,w) u (w,v) | v ∈ V, w ∈ V, u != w

{| 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?

== Repräsentation von Graphen ==

Sei G = ( V, E ) geg und liege V in einer lineraren Sortierung vor.
V = { v1, ...., vn }

== Adjazenzmatrix ==

AG = aij = {1 falls (vi, vj) ∈ E ; sonst 0}

Bsp:

v = { a,b,c,d } b d
| \ / |
| \/ |
| /\ |
| / \ |
a c

a b c d
-----------
(0 1 0 1) |a
AG = (1 0 1 0) |b
(0 1 0 1) |c
(1 0 1 0) |d

== Adjezenzlisten ==

al(v) = {v' ∈ V | (u,u') ∈ E}
Lg = ((v1, al(v1)), ...., (vn, al(vn))

Python:

Array von Arrays [[...],[...],...,[...]]
0 1 n

* '''Definition: Teilgraphen'''

Ein Graph G' = (v',E') ist ein Teilgraph, wenn gilt:

** v' c V
** E' c E

Er heißt erzegender Graph, wenn zusätzlich gilt:

** v' = V

* '''Definition: Knotengrade'''
Für G = (v,E)und v ∈ V
grad(v) = |{v' ∈ V | v,v'∈ E}|
out_grad(v) = | -""- |
in_grad(v) = |{v'∈ V| (v',v) ∈ E}|

Bsp:

ungerichtet

c
|| \
|| \
b d grad(a) = | {b,b,d} | = 3
|| /
|| /
a

gerichtet

c←
| \
↓ \
b←--d out_grad(d) = 2 = | {c,b} |
| /→ in_grad(d) = 1 = | {a} |
↓ /
a

* '''Definition: Wege'''

Sei G = (v,E)

** Für v0 ∈ V ist (v0) ein Weg in G
** Für Knoten v1,...vn,vn+1 und eine Kante (vn,vn+1) ∈ E ist mit einem Weg (v0,....vn) in G auch (v0,...,vn,vn+1) ein Weg in G.

Also: Nichtleere Folgen von Knoten die durch eine Kante verbunden sind.

== Eulerweg ==

O
/ \
O----O
| \/ |
| /\ | "Das Haus vom Nikolaus" Alle ''Kanten'' werden nur ''einmal'' passiert
O----O

== Hamiltonweg ==

O
/
O----O
/
/ Alle ''Knoten'' werden nur ''einmal'' passiert
O----O

== Kreis ==

O
/ \
O O
| | v0 = vn
| | vi != vj Für Alle i,j i !=j; i,j >0; i,j < n
O----O

== Zyklen ==

O
/ \
O O
\ |
\ | Wie Kreis nur ohne (vi != vj)
O====O

* '''Definition: planare Graphen'''

Ist ein Graph, der auf einer Ebene gezeichnet werden ''kann'', sodass sich die Kanten nicht schneiden!

Bsp:

1)

O
/|\
/ O \
/ / \ \
O O

2)

O
/ \
O----O
| \/ |
| /\ |
O----O

3)

|----O @
| /@ \
| O----O
| |@ / |
| | / @|
| O----O @ entspricht ''Regionen'' auch ausserhalb der Figur ist eine Region
|@ |
|-------|

1),2) und 3) sind planare Graphen.

Der K5 Graph ist kein planarer Graph da sich zwangsweise Kanten schneiden.

* '''Definition: dualer Graph'''

Der duale Graph eines geg. planaren Graphs G' ist ein Graph mit

** Knoten für jede Region
** Für jede Kante aus E gilt es gibt eine Kante, die die angrenzende Region mit Knoten verbindet.

dualer Graph

O------O
| /| \
|-|-@ / | @\---|
| | |\/ |/| O |
| | |/\ /| |/ |
| | / @ | / |
| O-+--+-O | |
| | | | |
|---|--@---|----|

* '''Definition: erreichbar'''

W ∈ V ist erreichbar von v ∈ G gdw.:
es Existiert Weg(v,...w)

* '''Definition: Zusammenhang'''

G heißt zusammenhängend, wenn für Alle v,w ∈V gilt:
w ist erreichbar von V

== Bäume ==

* '''Definition: Baum'''

Ein Baum ist ein zusammenhängender, kreisfreier Graph.

Bsp.: Binary Search Tree

* '''Definition: erzeugender Baum'''

für G = (v,E) ist ein erzeigender Teilgraph mit Baumeigenschaft

Bsp.:

O O
/ /
O O O
| / /
| / /
O----O----O

== Durchlaufen von Graphen ==

=== Tiefensuche in Graphen ===

Sei der Graph gegeben als Liste von Listen = g

def dfs (g,node,v=0):
if v == 0:
v = [0]*len(g) #visited-Liste
v[node] = 1 #besuche node
for t in g[node]: #gehe zu allen Nachbarn
if v[t] == 0: #falls diese noch nicht besucht
dfs(g,t,v) #Rekursion

[[Image:Tiefens.jpg]]

Aufruf dfs(g,1)

=>Folge 1,2,4,3,6,7,5

=== Breitensuche ===

from Queue import *
def bfs(g,startnode)
v = [0]*len(g)
q = Queue()
v = [startnode] = 1 #besuche
q.put(startnode) #in Schlange
while not q.get()
node = q.get()
for t in q[node]
if v[t] == 0:
v[t] = 1
q.put(t)

[[Image:Breitens.jpg]]

=>Folge 1,2,3,4,5,6,7

== Damenproblem ==

---------------
| | X | | |
|---|---|---|---|
| | | | X |
|---|---|---|---|
| X | | | |
|---|---|---|---|
| | | | X |
---------------

4 Damen auf einem vereinfachten Schachbrett so Positionieren, dass sich keine bedroht.

erster Durchlauf:

[[Image:Suche1.jpg]]

zweiter Durchlauf:

[[Image:Suche2.jpg]]

== Weitere Anwendungen (18.06.08) ==

def dfs(graph):
'''
Diese Tiefensuche tut so noch nichts weiter als zu traversieren
+ graph ist Array,
i-ter Eintrag enthaelt Adjazenzliste (auch Array) des i-ten Knotens,
wobei Knoten nummeriert von 0 ... v-i
'''
def visit(graph, node, visited):
'''
visited ist Array mit Flags fuer besuchte Knoten
'''
if visited[node]: return
visited[node] = True
for neighbor in graph[node]:
visit(graph, neighbor, visited)

visited = [False]*len(graph)
for node in range(len(graph)):
visit(graph, node, visited)

=== Finden von Zusammenhangskomponenten ===

Ein moeglicher Einsatz des Verfahrens ist das Finden von Zusammenhangskomponenten (connected components).

* Beispiel: ...

* Definition: CC_i = {u_k, u_l e V: es gibt einen Pfad von u_k nach u_l ("u_l ist von u_k aus erreichbar")
* fuer ungerichtete Graphen gilt zusaetzlich: es gibt einen Pfad von u_l nach u_k}

Die Relation CC_i, also die Zusammenhangskomponenten (ZK) bilden eine Aequivalenzrelation,
also kann fuer jede ZK ein Repraesentant bestimmt werden (der sog. "Anker"). Kennt jeder
Knoten seinen Anker, so ist das ZK-Problem geloest.

==== Tiefensuchen-Algorithmus ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden, wobei statt
Knotenbesuche Knotennummern fuer die schon gefundenen Anker gesetzt werden. Ein moeglicher
Algorithmus lautet damit wie folgt:

def connectedComponents(graph):
def visit(graph, node, anchors, anchor):
'''
anchor ist Anker der aktuellen ZK
'''
if anchors[node] is not None: return # Anker von <node> schon bekannt
anchors[node] = anchor
for neighbor in graph[node]
visit(graph, neighbor, anchors, anchor)

anchors = [None]*len(graph)
for node in range(len(graph)):
visit(graph, node, anchors, node) # node: Anker der naechste ZK = erster Knoten der ZK
return anchors

* Beispiel: ...

==== Union-Find-Algorithmus ====

Eine Alternative (ohne Tiefensuche) waere z.B. ein Union-Find-Algorithmus. Idee dabei ist, dass eingangs jeder Knoten eine eigene ZK bildet, wobei in einer anschliessenden Rekursion Kanten gesucht werden, die zwischen den ZK bestehen.

Initialisierung: jeder Knoten wird als 1 ZK behandelt
Rekursion: fasse ZK zusammen (Union) falls Kante zwischen ihnen existiert
Ergebnis: Array mit dem Anker jedes Knotens

def unionFindCC(graph):
def findAnchor(anchors, k):
'''
Prueft auf anchors[k]==k
'''
while anchors[k] != k:
k = anchor[k]
return k

def edges(graph):
e = []
for node in range(len(Graph)):
for n in graph[node]:
if node < n:
e.append((node, n))
return e

anchors = range(len(graph) # jeder Knoten ist sein eigener Anker
for edge in edges(graph):
# diese Schleife ordnet die Anker so, dass
# der 1. Anker immer der kleinste ist
a1, a2 = findAnchor(anchors, edge[0]), findAnchor(anchors, edge[1])
if a2 < a1: a2,a1 = a1,a2
if a1 != a2: anchors[a2] = a1
for node in range(len(graph)):
# diese Schleife raeumt mit Indirektionen auf (s. Bsp. (#))
anchor[node] = findAnchor(anchors, node)

* Beispiel (#): ...

Eine verbreitete Anwendung fuer dieses Verfahren gibt es in der Bildverarbeitung:

* Beispiel: ...

== Variationen der Tiefensuche (19.06.2008) ==

=== Wichtige Algorithmen, die in der Vorlesung nicht behandelt werden ===

* Max Flow (zur Bestimmung des maximalen Flusses durch ein Netzwerk, z.B. bei Ölpipelines)
* Matching (auch ''Paarung'' genannt): Teilmenge der Kanten eines Graphen, wobei keine zwei Kanten einen gleichen Knoten besitzen
*:Anwendungsbereiche: Zuordnung von Gruppen, z.B. Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot), Universität (Zuordnung Studenten - Übungsgruppen)

=== Vereinfachte Lösung für den ''acyclic''-Algorithmus ===
Zum Finden von Zyklen, bzw. der Feststellung, ob ein Graph azyklisch ist, verwenden wir
wieder eine modifizierte Version der Tiefensuche: Die Knoten werden wieder nach dem System der Tiefensuche besucht, und alle besuchten Knoten in einem Array visited abgespeichert. Es gibt einen Zyklus genau dann, wenn man zu
einem früheren Knoten (außer zum direkten Vorgaenger) zurückkommt.

<code python>
def acyclic(graph):
def visit(graph, node, fromNode, visited):
if visited[node]: # Zyklus entdeckt
return False
visited[node] = True
for neighbor in graph[node]:
if neighbor == fromNode: # überspringe Nachbar, von dem du gekommen bist
continue
if not visit(graph, neighbor, node, visited):
return False # der Graph ist zyklisch
return True # kein Zyklus
visited = [False]*len(graph)
for node in range(len(graph)):
if visited[node]: # schließt aus, dass Knoten besucht wird, der schon besucht war
continue
if not visit(graph, node, None, visited):
return False
return True
</code>

'''Anmerkungen zum Code:'''

* Wenn ein Knoten bereits besucht ist, dann gehört er zur gleichen Zusammenhangskomponente - dies hat allerdings nichts mit einem Zyklus zu tun.
* Ein Graph der einmal zyklisch war wird nie wieder azyklisch.
* Der obige Algorithmus weist Ähnlichkeiten mit den bereits behandelten Algorithmen auf: '''ein guter Algorithmus zeichnet sich dadurch aus, dass mit kleinen Code-Variationen ganz andere Probleme gelöst werden können'''.

=== Kürzeste Wege (Pfade) ===

* Definition: gewichteter Graph

Jeder Kante e ist eine reelle oder natürliche Zahl we zugeordnet (wird auch als
''Kantengewicht'' bezeichnet).

z.B.
* Abstand der Anfangs- und Endknoten

* Durchflusskapazität eines Rohres (für max-Flussprobleme)

* Wechselkurse (Darstellung in einem gerichteten Graph, da jede Kante auch eine Richtung hat. Die Knoten sind die Währungen, die Kanten sind die Wechselkurse. Auf diese Weise lassen sich unterschiedliche Wechselkurse + Bankgebühren darstellen.)

* '''Definition''': Problem des kürzesten Weges

Sei P die Menge aller Wege von u nach v

Puv = {u_v}

und der Weg gegeben durch

u → x1 → x2 → ... → v

dann sind die Kosten eines Weges definiert durch

Kosten (Puv) = <math>\sum\limits_{l \in Pv}</math> we

* gesucht: Pfad u_v, so dass Kosten (u_v) minimal sind

* Lösung: Algorithmus von Dijkstra

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

<code python>
import heapq # heapq ist ein Modul von Python
def dijkstra(graph, start, ziel): # graph: gewichtete Adjazenzliste
heap = []
visited = [None]*len(graph)
visited[start] = start
for neighbor in graph[start]:
heapq.heappush(heap, (neighbor[1], start, neighbor[0])) # neighbor[1]:Kantengewicht,neighbor[0]:Endpunkt d. K.
while len(heap) > 0: # solange der heap nicht leer ist
w, fromNode, node = heapq.heappop(heap)
if visited[node] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
visited[node] = fromNode # baue Vorgänger-Baum
if node == ziel: # da der heap noch nicht leer ist, wird an dieser Stelle ein break benötigt
break
for neighbor in graph[node]:
if visited[neighbor[0]] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
heapq.heappush(heap, (neighbor[1]+w, node, neighbor[0]))
bestPath = []
t = ziel
while t != visited[t]: # Array wird durchlaufen bis der Anker des Pfades gefunden ist, vgl. Union-Search
bestPath.append(t)
t=visited[t]
bestPath.append(start)
return bestPath # bestPath.reverse()
</code>

'''Anmerkungen zum Code:'''
* der graph ist eine gewichtete Adjazenzliste

{|

|-

| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | Endknoten || → || style="background:silver; color:white" | Endknoten || (Nr. der Nachbarn des Knoten 0)

|-

| || style="background:silver; color:white" | 1 || || style="background:silver; color:white" | Gewicht || || style="background:silver; color:white" | Gewicht || (Gewicht der jeweiligen Kante)

|-

| || style="background:silver; color:white" | 2 ||

|-

| || style="background:silver; color:white" | 3 ||

|}
* Eingabe z.B.:
{|
|-
| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | (1, 0.3) || style="background:silver; color:white" | (3, 0.1) || style="background:silver; color:white" | (5, 1.2) ||
|-
| || style="background:silver; color:white" | 1 || → || style="background:silver; color:white" | || style="background:silver; color:white" | || style="background:silver; color:white" | ||
|-
| || style="background:silver; color:white" | 2 ||
|-
| || style="background:silver; color:white" | 3 ||
|-
| || style="background:silver; color:white" | 4 ||
|-
| || style="background:silver; color:white" | 5 ||
|-
| || style="background:silver; color:white" | 6 ||
|}
* heapq() verwendet den 1. Eintrag des Tupels zum sortieren des heap

==== Prinzip des Dijkstra-Algorithmus ====

* Algorithmus ist Tiefensuche mit Prioritätswarteschlange (Heap) statt eines Stapelspeichers (Stack) → vgl. Übung 8

* Die Prioritätswarteschlange speichert die kürzesten Wege, die bereits gefunden worden sind.

* Wenn man die Prioritätswarteschlange (Heap) durch eine Warteschlange (Queue) ersetzt, erhält man Breitensuche.

* Wenn man die Prioritätswarteschlange (Heap) durch einen Stapelspeicher (Stack) ersetzt, erhält man Tiefensuche.

==== Beispiel ====

[[Image:Bsp.jpg]]

* An der Stelle "neighbor[1]" wird eine Zählvariable ''count'' eingefügt, die hoch (Breitensuche) oder runter (Tiefensuche) zählt.

* Die Gewichte werden hoch- oder runtergezählt, so wie die Kanten gesehen wurden.

* Wenn man rückwärts zählt (von 0 abziehen), werden die zuletzt hinzugefügten Kanten expandiert.

* '''Algorithmus von Dijkstra funktioniert nur für positive Kantengewichte
*:<math>\forall</math> we > 0'''

* Bei negativen Kantengewichten könnte es Zyklen geben, die negative Kosten für den ganzen Zyklus haben:

/\ 1. Durchlauf: Kosten -1
1 / \ 4 2. Durchlauf: Kosten -2
/____\ etc.
2

* Verwendung bei arbitragen Geschäften (Börsengeschäfte, die die Preis-, Kurs- und Zinsunterschiede auf verschiedenen Märkten ausnutzen):
*:EURO wurden in YEN, YEN in DOLLAR gewechselt und das Geld hat sich dadurch vermehrt
* Für negative Kantengewichte verwendet man den Bellman-Ford-Allgorithmus, der allerdings langsamer ist, als der Dijkstra-Algorithmus.

==== Komplexität von Dijkstra ====

* Jeder Knoten wird höchstens 1x expandiert (Iteration über die Nachbarn des Knotens).

* Jeder Knoten kann mehrmals im Heap enthalten sein.

* Es sind aber höchstens E (Anzahl der Kanten) Heap-Einträge möglich, da jede Kante höchstens 1 Heap-Eintrag generiert (ein Knoten ist nur dann im Heap, wenn man ihn über eine Kante erreicht hat, die man vorher noch nicht besucht hatte). Deshalb können nie mehr Einträge im Heap sein, als es Kanten gibt. Die Komplexität von heappush(), heappop() ist
O(log E) = O(2 log v) = O(log v)
wenn alle Kanten einen Heap-Eintrag generiert haben.
* Die while-Schleife wird im schlimmsten Fall E mal durchlaufen, deshalb ist die Komplexität von Dijkstra O(E log v).

==== Korrektheit von Dijkstra ====

* Falls
visited[node] (Schleifen-Invariante von while) != None
ist, dann liefert Zurückverfolgen des Pfades von node nach start den kürzesten Pfad von start nach node (gilt für alle Knoten, für die das visited-Feld gesetzt ist).
* Induktionsanfang: visited[start] ist einziger not-None-Fall → Bedingung erfüllt
* Induktionsschritt: wenn visited[node] gesetzt wird, ist es ein kürzester Pfad

==== Indirekter Beweis ====

Set S = {node | visited[node] != None} (alle Knoten, von denen wir den kürzesten Pfad schon kennen)

* u ist der Knoten an der Spitze des Heaps
* fromNode <math>\in</math> S (ein Nachbar von node kommt erst dann in den Heap, wenn visited[node] vorher gesetzt wurde)
* falls u → fromNode &rarr start kein kürzester Pfad wäre, müsste u's Vorgänger in V\S sein
* sei dieser Vorgänger x <math>\notin</math> S, x <math>\not=</math> u
* sei wx das Gewicht der Kante x → u, dann sind die Kosten für start nach u gleich

Kosten(start_u) = Kosten(start_x) + wx

* Annahme des indirekten Beweises:

Kosten(start_fromNode) + wfromNode

* Behauptung des indirekten Beweises:
Es gibt einen anderen Pfad x, so dass die Kosten von start nach x geringer sind

* Da aber gilt:
fromNode <math>\in</math> S und x <math>\notin</math> S

* gilt (Induktionsvoraussetzung):
Kosten(start_fromNode) < Kosten(start_x)

* Falls Kosten(start_x) < Kosten(start_u) müsste x im Heap vor u kommen; daraus folgt, dass u nicht an der Spitze des Heaps sein kann

→ Widerspruch!

→ Die Behauptung, der Weg über x ist besser, kann nicht stimmen.

→ Korrektheit von Dijkstra ist somit bewiesen.

==== Wie kann man Dijkstra noch verbessern? ====

===== A*-Algorithmus =====

* Verbesserung von Dijkstra im typischen Fall, aber die Komplexität ist immer noch =(Elog v) im schlechtesten Fall (die Komplexität kann man nicht verbessern, aber die Laufzeit im typischen Fall).
* Schätzung für jeden Knoten für den restlichen Weg:
geschätzte Gesamtkosten: Kosten(start_node) + Restschätzung(node_ziel)
(exakte Kosten werden durch Dijkstra ermittelt)

'''Idee:'''
* Sortiere den Heap nach geschätzten Gesamtkosten.
* Satz:
Falls jede Schätzung den exakten Weg unterschätzt, werden die gleichen Pfade gefunden, wie
bei Dijkstra (also die korrekten kürzesten Pfade).
(Die Schätzung für den restlichen Weg muss man immer so einrichten, dass der tatsächliche Weg unterschätzt wird. Da keine Straße kürzer sein kann als die Luftlinie, ist die Luftlinie eine geeignete Annahme für A*.)
* Falls der falsche Pfad im Heap eher an die Spitze kommt als der richtige Pfad, findet der A*-Algorithmus den falschen Pfad.
* Wenn der Pfad zum Ziel an der Spitze des Heap ist, dann wird keine Restschätzung mehr benötigt, denn wenn der Zielknoten aus dem Heap herrauskommt, dann hat man die exakte Berechnung. Die Restschätzung ist in diesem Fall 0. Wenn die Schätzung zu klein ist, wird der exakte Weg immer größer sein und zuerst aus dem Heap herauskommen.

===Minimaler Spannbaum (tree-MST)===
gegeben: gewichteter, zusammenhängender Graph G
gesucht: Untermenge E'\subseteq E, so dass \sum_{e\in E} w_e minimal und G' zusammenhängend
G' definiert dann einen Baum, denn andernfalls könnte man \sum verringern (eine Kante weglassen)
Anwendungen: Wie verbindet man n Punkte mit möglichst wenigen kurzen Straßen"""

====Algorithmus von Prim====

def prim(graph):
heap = []
visited = [False]*len(graph)
sum = 0
r = []
for neighbor in graph[0]:
heapq.heappush(heap, (neighbor[1], 0, neighbor[0]))
while len(heap):
wn, start, ziel = heapq.heappop(heap)
if visited[ziel]: continue
visited[ziel] = True
sum += wn
r.append([start, ziel])
for neighbor in graph[ziel]:
if visited[neighbor[0]]: continue
heapq.heappush(heap, (neighbor[1], ziel, neighbor[0]))
return sum, r

====Algorithmus von Krushal====
Idee: wie beim Union-Find-Algorithmus für Zusammenhangskomponenten
1. Behandle jeden Knoten als Baum für sich
2. Fasse zwei Bäume zu neuem Baum zusammen
für MST: betrachte dazu die Kanten in aufsteigender Reihenfolge der Gewichte
(ignoriere Kanten zw. Knoten in gleichem Baum)
=> geeignet für Übungsaufgabe

=== Problem des Handlungsreisenden (travelling salesman problem - TSP)===
gegeben: zusammenhängender, gewichteter Graph (oft vollständiger Graph)

gesucht: kürzester Weg, der alle Knoten genau einmal besucht (und zum Ausgangsknoten zurückkehrt)

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

naive Lösung: brute force (Durchprobieren aller möglichen Pfade)

'''Systematisches Erzeugen aller Permutationen'''
Trick: erzeuge jede Permutation in lexikographischer Ordnung

def next_permutation(a):
i = len(a) -1
while True:
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexicogr. Nachfolger hat groß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, also
<math>O(v!) = O(v^v)</math>

Prioritätswarteschlangen

2008-06-25T22:40:26Z

Jschleic: /* Prioritätswarteschlangen */ typo

==Prioritätswarteschlangen==

* Max Priority Queue : insert(x)
x = largest()
removeLargest()

* Min Priority Queue: smallest()
removeSmallets()
===Prioritätswarteschlange als Suchproblem===

*Sequentielle Suche - Array mit Prioritäten : insert(x)<=> a.append(x) ( <math>\mathcal{O}(1)</math>(amortisierte Komplexität))

def largest(a): 
if len (a) == 0: 
raise RuntimeError("...") 
''' max = a[0]''' 
'''k = 0 '''
'''for n in range(1, len(a):''' ''(innere Schleife von SelectionSort)'' 
''' if a[n] > max''' (Das ganze hat die Komplexität:''' N = len(a) =>''' <math>\mathcal{O}(N)</math> 
''' max = a[n]''' 
''' k = n''' 
''' return k''' 
Bei kleine Array ist dies die schnellste Methode

===Binärer (balancierter)Suchbaum===
insert => z.B. wie beim Anderson Baum [http://hci.iwr.uni-heidelberg.de/alda/index.php/Suchen#Anderson-B.C3.A4ume] <math>\mathcal{O}(logN)</math> 
def largest(node): # Wurzel 
'''if node.right is not None:''' #rechts stehen immer die großen 
'''return largest(node.right)''' 
'''return node''' #wenn es nicht mehr nach rechts geht, dann haben wir den größten Knoten gefunden 

Das ganze hat <math>\mathcal{O}(logN)</math> Komplexität 
Ergebnis: gute Komplexität aber komplizierte Datenstruktur
===Heap===
*Datenstruktur optimiert für Prioritätssuche - man sucht nicht effizient alle Knoten, sondern nur einen bestimmten z.B. Heap max 
*Definition: ein linkslastiger Binärbaum ist ein Baum mit <math>d(node.left) \geq d(node.right)</math>

Ein Heap ist ein linkslastiger, perfekt balancierter Baum.
(lässt sich max. um 1 unterscheiden)

Man kann einen Heap leicht als Array implementieren, wie folgende Grafik veranschaulicht:
[[Image:heapArray.png|400px]]

'''index[parent] = [(indexChild - 1)/2]''' #[] heißt abgerundet 
'''index[left] = index[parent]2 + 1''' 
'''index[right] = index[parent]2 + 2 

'''=>''' linkslastiger perfect balancierter Binärbaum kann effizient als Array abgespeichert werden 
'''=>'''verwende Indizes wie oben
====Heap - Bedingung====
* die Wurzel hat höhere Prioriät als die Kinder(gilt für jeden Teilbaum) 
'''=>'''Wurzel = array[0] hat die größte Priorität 
def largest(h): 
return h[0] <math>\mathcal{O}(N)</math> 

====Einfügen in einem Heap====

h - Array #speichrt Haep 
def insert(h,x): 
h.append(x) # wir speichern den Wurzel am Ende, so wird glecih zu einem linkslastigen perfect balancierten Baum (die Haep - Bedingung ist erfüllt) 
upheap(h, len(h) - 1): 

def upheap(h, k): 
"""k-tes Element evtl. an der falsche Stelle 
""" 
v = h[k] 
while True #endlose Schleife 
if k == 0: 
break 
parent = (k - 1)/2 
if h[parent]>v: 
break 
h[k] = h[parent] 
k = parent 
h[k] = v 

def removeLargest(h):
'''h[0] = h[len(h) - 1]''' 
'''del h[len(n) - 1]''' <math>\mathcal{O}(1)</math> 
downHeap(h, 0) <math>\mathcal{O}(logN)</math> 

def downHeap(h, k): 
v = h[k] 
while True 
child = 2k + 1 #linke Kind 
if child <math>\ge</math>len(h): 
break 
if child < h[child] < h[child + 1] #rechtes Kind 
child = child + 1
if v <math>\ge</math> h[child]: 
break 
h[k] = h[child] 
k = child 
h[k] = v

====Beispiel am Wort "SORTING"====

(Grafiken folgen)

====weitere Heapvarianten====
*Min-Max-Priority Queue ("Deap", Double Ended Heap)
*Binomialer Heap, effiziente Operation "merege Heap" <math>\mathcal{O}(n * log N (i*N_1 + N_2)</math>
(Beweis durch binomiale Koeffizienten, Zusammenführen zweier Prioritätslisten)
*Fibonacci-Heap, einfügen in amortisierter Zeit <math>\mathcal{O}(1)</math>
(Beweis durch Fibonacci Zahlen)

Main Page

2008-06-25T21:43:31Z

Jschleic: /* Übungsaufgaben */

== Getting started ==

* [http://meta.wikimedia.org/wiki/Help:Editing Wiki Editierhilfe] (Wiki-Syntax usw.)
* [http://www.mediawiki.org/wiki/Manual MediaWiki Manual] (für Administratoren)
* [[Sandbox]] (zum ungefährlichen Ausprobieren von Änderungen)

== Vorlesung Algorithmen und Datenstrukturen ==

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

Die Vorlesung findet '''mittwochs''' um 11:15 Uhr in INF 227, HS 2 und '''donnerstags''' um 11:15 Uhr in INF 308, HS 2 statt. Die '''Abschlussklausur''' findet am Mittwoch, dem 23.7.2008 von 10:00 bis ca. 13:00 Uhr im HS1, INF 227 (KIP) statt. (Die genaue Klausurdauer wird noch bekannt gegeben. Hinweis: Sie benötigen einen Lichtbildausweis, um sich bei der Klausur zu indentifizieren!)

=== Leistungsnachweise ===
Für alle Leistungsnachweise ist die erfolgreiche Teilnahme an den Übungen erforderlich. Für Leistungspunkte bzw. den Klausurschein muss außerdem die schriftliche Prüfung bestanden werden. Im einzelnen können erworben werden:
* ein benoteter Übungsschein (Magister mit Computerlinguistik im ''Nebenfach'', Physik Diplom)
* ein Klausurschein (Magister mit Computerlinguistik im ''Hauptfach'')
* ein Leistungsnachweis über 9 Leistungspunkte (B.A. Computerlinguistik - alte Studienordnung)
* ein Leistungsnachweis über 8 Leistungspunkte (B.Sc. Informatik, B.A. Computerlinguistik - neue Studienordnung)
* ein Leistungsnachweis über 7 Leistungspunkte (B.Sc. Physik).

=== Übungsbetrieb ===
* Termine der Übungsgruppen:
** Mo 11:00 - 13:00 Uhr, INF 350 (Otto-Meyerhof-Zentrum, Seiteneingang), Raum 014 (Tutor: Rahul Nair, [mailto:rnair(at)gmx(punkt)de rnair (at) gmx (punkt) de])
** Di 11:00 - 13:00 Uhr, INF 350 (Otto-Meyerhof-Zentrum, Seiteneingang), Raum 014 (Tutor: Thomas Gerlach, [mailto:gerlach@kip.uni-heidelberg.de gerlach@kip.uni-heidelberg.de])
** Mi 14:00 - 16:00 Uhr, '''neu: INF 327, Raum SR 5''' (Tutor: Christoph Sommer, [mailto:christoph.sommer@iwr.uni-heidelberg.de christoph.sommer@iwr.uni-heidelberg.de])
** Do 14:00 - 16:00 Uhr, INF 294, Raum -113 (im Untergeschoss, Tutor: Daniel Kondermann, [mailto:daniel.kondermann@iwr.uni-heidelberg.de daniel.kondermann@iwr.uni-heidelberg.de])
* [[Main Page#Übungsaufgaben|Übungsaufgaben]] (Übungszettel mit Abgabetermin, Musterlösungen)
* [[Media:Punktestand.pdf|aktueller Punktestand]] (PDF, anonymisiert -- '''Immatrikulationsnummer 0 bedeutet, dass wir Ihre Nummer noch nicht haben, bitte nachreichen!''')
* Zur Klausur wird zugelassen, wer mindestens 60% der Übungspunkte erreicht. Außerdem muss jeder Teilnehmer eine Lösung (bzw. einen Teil davon) in der Übungsgruppe vorrechnen. Es gibt verschiedene Möglichkeiten, Zusatzpunkte zu erlangen (Bonusaufgaben, Anfertigung der Wiki-Seiten, gute Mitarbeit in den Übungen).

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

([[Media:VL-Algorithmen-und-Datenstrukturen-ss08-Overview.pdf|Übersicht als PDF]] mit Übungsthemen)

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

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

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

# [[Korrektheit]] (23. - 30.4.2008)
#* 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]] (30.4. - 14.5.2008)
#* 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]] (14. - 21.5.2008)
#* Lineare Suche
#* Binäre Suche in sortierten Arrays, Medianproblem
#* Suchbäume, balancierte Bäume
#* selbst-balancierende Bäume, Rotationen
#* Komplexität der Suche

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

# [[Hashing und assoziative Arrays]] (29.5.und 4.6.2008)
#* 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]] (5.6.2008)
#* Typen der Rekursion und ihre Umwandlung in Iteration
#* Auflösung rekursiver Formeln mittels Master-Methode und Substitutionsmethode

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

# [[Graphen und Graphenalgorithmen]] (12. bis 19.6.2008)
#* Einführung
#* Graphendatenstrukturen, Adjazenzlisten und Adjazenzmatrizen
#* Gerichtete und ungerichtete Graphen
#* Vollständige Graphen
#* Planare Graphen, duale Graphen
#* Pfade, Zyklen
#* Tiefensuche und Breitensuche
#* Zusammenhang, mehrfacher Zusammenhang, Komponenten
#* Gewichtete Graphen
#* Minimaler Spannbaum
#* Kürzeste Wege, Best-first search (Dijkstra)
#* Most-Promising-first search (A*)

# [[Prinzipien des Algorithmenentwurfs]] (25.6.2008)
#* Repetition
#* Orthogonale Zerlegung des Problems
#* Hierarchische Zerlegung der Daten (Divide and Conquer)
#* Randomisierung
#* Optimierung, Zielfunktionen
#* Systematisierung von Algorithmen aus der bisherigen Vorlesung

# [[Analytische Optimierung]] (25.6.2008)
#* Methode der kleinsten Quadrate
#* Approximation von Geraden

# [[Randomisierte Algorithmen]] (26.6. und 2.7.2008)
#* Zufallszahlen, Zyklenlänge, Pitfalls
#* Zufallsverteilungen, Box-Muller Transformation
#* Randomisierte vs. deterministische Algorithmen
#* Las Vegas vs. Monte Carlo Algorithmen
#* Beispiel für Las Vegas: Randomisiertes Quicksort
#* Beispiele für Monte Carlo: randomisierte Integration, randomisierter Primzahltest
#* RANSAC-Algorithmus, Erfolgswahrscheinlichkeit

# [[Greedy-Algorithmen]] (3.7.2008)
#* Prinzip
#* Bedingung für Optimalität
#* Beispiele für Greedy-Algorithmen

# [[Dynamische Programmierung]] (9.7.2008)
#* Prinzip
#* Beispiele für Dynamische Programmierung

# [[Erschöpfende Suche]] (10. und 16.7.2008)
#* Beispiele: u.a. Problem des Handlungsreisenden
#* Exponentielle Komplexität, NP-Vollständigkeit
#* Approximation bei NP-vollständigen Problemen

# [[Quantum computing]] (17.7.2008)

== Übungsaufgaben ==

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

# [[Media:Übung-1.pdf|Übung]] (Abgabe 17.4.2008) und [[Media:Übung-1-Musterlösung.pdf|Musterlösung]]
#* Python-Tutorial
#* Sieb des Eratosthenes
#* Wert- und Referenzsemantik

# [[Media:Übung-2.pdf|Übung]] (Abgabe 24.4.2008) sowie Musterlösungen für [[Media:muster_blatt2-aufgabe1.pdf|Aufgabe 1]] und [[Media:muster_blatt2-aufgabe2.pdf|Aufgabe 2]]
#* Sortieren: Implementation und Geschwindigkeitsvergleich (Diagramme in Abhängigkeit von Problemgröße)
#* Entwicklung eines effizienten Algorithmus: Bruchfestigkeit von Gläsern

# [[Media:Übung-3.pdf|Übung]] ('''neuer Abgabetermin''' 7.5.2008) und [[Media:Übung-3-Musterlösung.pdf|Musterlösung]]
#* Experimente zur Effektivität von Unit Tests
#* Deque-Datenstruktur: Vor- und Nachbedingungen der Operationen, Implementation und Unit Tests

# [[Media:Übung-4.pdf|Übung]] (Abgabe 15.5.2008) und [[Media:Musterloesung_4.pdf|Musterlösung]]
#* Theoretische Aufgaben zur Komplexität
#* Amortisierte Komplexität von array.append()
#* Optimierung der Matrizenmultiplikation

# [[Media:Übung-5.pdf|Übung]] ('''neuer Abgabetermin''' 29.5.2008) und [[Media:muster_blatt5.pdf|Musterlösung]]
#* Implementation und Analyse eines Binärbaumes
#* Anwendung: einfacher Taschenrechner

# [[Media:Übung-6.pdf|Übung]] (Abgabe 5.6.2008) und [[Media:muster_blatt6.pdf|Musterlösung]]
#* Treap-Datenstruktur: Verbindung von Suchbaum und Heap
#* Anwendung: Worthäufigkeiten (Dazu benötigen Sie das File [http://klimt.iwr.uni-heidelberg.de/mip/people/ukoethe/download/die-drei-musketiere.txt die-drei-musketiere.txt]. Die Zeichenkodierung in diesem File ist Latin-1.)
#* Suche mit linearer Komplexität

# [[Media:Übung-7.pdf|Übung]] (Abgabe 12.6.2008) und [[Media:muster_blatt7.pdf|Musterlösung]]
#* Übungen zu Rekursion und Iteration: Fakultät, Koch-Schneeflocke, Komplexität rekursiver Algorithmen, Umwandlung von Rekursion in Iteration

# [[Media:Übung-8.pdf|Übung]] (Abgabe 19.6.2008)
#* Elementare Graphenaufgaben: Aufstellen von Adjazenzmatrizen und Adjazenzlisten, planare Graphen
#* Übungen zur Generizität: Sortieren mit veränderter Ordnung, Iterator für Tiefensuche

# [[Media:Übung-9.pdf|Übung]] (Abgabe 26.6.2008)
#* Fortgeschrittene Graphenaufgaben: Erzeugen einer perfekten Hashfunktion, Routenplaner (Dazu benötigen Sie das File [http://klimt.iwr.uni-heidelberg.de/mip/people/ukoethe/download/entfernungen.txt entfernungen.txt]. Die Zeichenkodierung in diesem File ist Latin-1.)
#* '''Achtung: geänderte Version''' in der Originaldatei haben sich einige Fehler eingeschlichen. Hier ist eine neue Version der Entfernungen verfügbar: [http://www.rzuser.uni-heidelberg.de/~jschleic/entfernungen_neu.txt entfernungen_neu.txt]

# Übung (Abgabe 3.7.2008)
#* Beispiele für Divide and Conquer: pow-Funktion
#* Beispiel für Methode der kleinsten Quadrate: Approximation von Kreisen

# Übung (Abgabe 10.7.2008)
#* Randomisierte Algorithmen: Laufzeitvergleich deterministischer und randomisierter Primzahltest, RANSAC für Kreise

# Übung (Abgabe 17.7.2008)
#* Theoretische und praktische Aufgaben zur dynamische Programmierung

Main Page

2008-06-25T21:41:28Z

Jschleic: /* Übungsaufgaben */ Neue entfernungen.txt - im Original waren falsche Koordinaten bei Pforzheim und Oldenburg drin

== Getting started ==

* [http://meta.wikimedia.org/wiki/Help:Editing Wiki Editierhilfe] (Wiki-Syntax usw.)
* [http://www.mediawiki.org/wiki/Manual MediaWiki Manual] (für Administratoren)
* [[Sandbox]] (zum ungefährlichen Ausprobieren von Änderungen)

== Vorlesung Algorithmen und Datenstrukturen ==

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

Die Vorlesung findet '''mittwochs''' um 11:15 Uhr in INF 227, HS 2 und '''donnerstags''' um 11:15 Uhr in INF 308, HS 2 statt. Die '''Abschlussklausur''' findet am Mittwoch, dem 23.7.2008 von 10:00 bis ca. 13:00 Uhr im HS1, INF 227 (KIP) statt. (Die genaue Klausurdauer wird noch bekannt gegeben. Hinweis: Sie benötigen einen Lichtbildausweis, um sich bei der Klausur zu indentifizieren!)

=== Leistungsnachweise ===
Für alle Leistungsnachweise ist die erfolgreiche Teilnahme an den Übungen erforderlich. Für Leistungspunkte bzw. den Klausurschein muss außerdem die schriftliche Prüfung bestanden werden. Im einzelnen können erworben werden:
* ein benoteter Übungsschein (Magister mit Computerlinguistik im ''Nebenfach'', Physik Diplom)
* ein Klausurschein (Magister mit Computerlinguistik im ''Hauptfach'')
* ein Leistungsnachweis über 9 Leistungspunkte (B.A. Computerlinguistik - alte Studienordnung)
* ein Leistungsnachweis über 8 Leistungspunkte (B.Sc. Informatik, B.A. Computerlinguistik - neue Studienordnung)
* ein Leistungsnachweis über 7 Leistungspunkte (B.Sc. Physik).

=== Übungsbetrieb ===
* Termine der Übungsgruppen:
** Mo 11:00 - 13:00 Uhr, INF 350 (Otto-Meyerhof-Zentrum, Seiteneingang), Raum 014 (Tutor: Rahul Nair, [mailto:rnair(at)gmx(punkt)de rnair (at) gmx (punkt) de])
** Di 11:00 - 13:00 Uhr, INF 350 (Otto-Meyerhof-Zentrum, Seiteneingang), Raum 014 (Tutor: Thomas Gerlach, [mailto:gerlach@kip.uni-heidelberg.de gerlach@kip.uni-heidelberg.de])
** Mi 14:00 - 16:00 Uhr, '''neu: INF 327, Raum SR 5''' (Tutor: Christoph Sommer, [mailto:christoph.sommer@iwr.uni-heidelberg.de christoph.sommer@iwr.uni-heidelberg.de])
** Do 14:00 - 16:00 Uhr, INF 294, Raum -113 (im Untergeschoss, Tutor: Daniel Kondermann, [mailto:daniel.kondermann@iwr.uni-heidelberg.de daniel.kondermann@iwr.uni-heidelberg.de])
* [[Main Page#Übungsaufgaben|Übungsaufgaben]] (Übungszettel mit Abgabetermin, Musterlösungen)
* [[Media:Punktestand.pdf|aktueller Punktestand]] (PDF, anonymisiert -- '''Immatrikulationsnummer 0 bedeutet, dass wir Ihre Nummer noch nicht haben, bitte nachreichen!''')
* Zur Klausur wird zugelassen, wer mindestens 60% der Übungspunkte erreicht. Außerdem muss jeder Teilnehmer eine Lösung (bzw. einen Teil davon) in der Übungsgruppe vorrechnen. Es gibt verschiedene Möglichkeiten, Zusatzpunkte zu erlangen (Bonusaufgaben, Anfertigung der Wiki-Seiten, gute Mitarbeit in den Übungen).

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

([[Media:VL-Algorithmen-und-Datenstrukturen-ss08-Overview.pdf|Übersicht als PDF]] mit Übungsthemen)

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

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

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

# [[Korrektheit]] (23. - 30.4.2008)
#* 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]] (30.4. - 14.5.2008)
#* 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]] (14. - 21.5.2008)
#* Lineare Suche
#* Binäre Suche in sortierten Arrays, Medianproblem
#* Suchbäume, balancierte Bäume
#* selbst-balancierende Bäume, Rotationen
#* Komplexität der Suche

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

# [[Hashing und assoziative Arrays]] (29.5.und 4.6.2008)
#* 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]] (5.6.2008)
#* Typen der Rekursion und ihre Umwandlung in Iteration
#* Auflösung rekursiver Formeln mittels Master-Methode und Substitutionsmethode

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

# [[Graphen und Graphenalgorithmen]] (12. bis 19.6.2008)
#* Einführung
#* Graphendatenstrukturen, Adjazenzlisten und Adjazenzmatrizen
#* Gerichtete und ungerichtete Graphen
#* Vollständige Graphen
#* Planare Graphen, duale Graphen
#* Pfade, Zyklen
#* Tiefensuche und Breitensuche
#* Zusammenhang, mehrfacher Zusammenhang, Komponenten
#* Gewichtete Graphen
#* Minimaler Spannbaum
#* Kürzeste Wege, Best-first search (Dijkstra)
#* Most-Promising-first search (A*)

# [[Prinzipien des Algorithmenentwurfs]] (25.6.2008)
#* Repetition
#* Orthogonale Zerlegung des Problems
#* Hierarchische Zerlegung der Daten (Divide and Conquer)
#* Randomisierung
#* Optimierung, Zielfunktionen
#* Systematisierung von Algorithmen aus der bisherigen Vorlesung

# [[Analytische Optimierung]] (25.6.2008)
#* Methode der kleinsten Quadrate
#* Approximation von Geraden

# [[Randomisierte Algorithmen]] (26.6. und 2.7.2008)
#* Zufallszahlen, Zyklenlänge, Pitfalls
#* Zufallsverteilungen, Box-Muller Transformation
#* Randomisierte vs. deterministische Algorithmen
#* Las Vegas vs. Monte Carlo Algorithmen
#* Beispiel für Las Vegas: Randomisiertes Quicksort
#* Beispiele für Monte Carlo: randomisierte Integration, randomisierter Primzahltest
#* RANSAC-Algorithmus, Erfolgswahrscheinlichkeit

# [[Greedy-Algorithmen]] (3.7.2008)
#* Prinzip
#* Bedingung für Optimalität
#* Beispiele für Greedy-Algorithmen

# [[Dynamische Programmierung]] (9.7.2008)
#* Prinzip
#* Beispiele für Dynamische Programmierung

# [[Erschöpfende Suche]] (10. und 16.7.2008)
#* Beispiele: u.a. Problem des Handlungsreisenden
#* Exponentielle Komplexität, NP-Vollständigkeit
#* Approximation bei NP-vollständigen Problemen

# [[Quantum computing]] (17.7.2008)

== Übungsaufgaben ==

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

# [[Media:Übung-1.pdf|Übung]] (Abgabe 17.4.2008) und [[Media:Übung-1-Musterlösung.pdf|Musterlösung]]
#* Python-Tutorial
#* Sieb des Eratosthenes
#* Wert- und Referenzsemantik

# [[Media:Übung-2.pdf|Übung]] (Abgabe 24.4.2008) sowie Musterlösungen für [[Media:muster_blatt2-aufgabe1.pdf|Aufgabe 1]] und [[Media:muster_blatt2-aufgabe2.pdf|Aufgabe 2]]
#* Sortieren: Implementation und Geschwindigkeitsvergleich (Diagramme in Abhängigkeit von Problemgröße)
#* Entwicklung eines effizienten Algorithmus: Bruchfestigkeit von Gläsern

# [[Media:Übung-3.pdf|Übung]] ('''neuer Abgabetermin''' 7.5.2008) und [[Media:Übung-3-Musterlösung.pdf|Musterlösung]]
#* Experimente zur Effektivität von Unit Tests
#* Deque-Datenstruktur: Vor- und Nachbedingungen der Operationen, Implementation und Unit Tests

# [[Media:Übung-4.pdf|Übung]] (Abgabe 15.5.2008) und [[Media:Musterloesung_4.pdf|Musterlösung]]
#* Theoretische Aufgaben zur Komplexität
#* Amortisierte Komplexität von array.append()
#* Optimierung der Matrizenmultiplikation

# [[Media:Übung-5.pdf|Übung]] ('''neuer Abgabetermin''' 29.5.2008) und [[Media:muster_blatt5.pdf|Musterlösung]]
#* Implementation und Analyse eines Binärbaumes
#* Anwendung: einfacher Taschenrechner

# [[Media:Übung-6.pdf|Übung]] (Abgabe 5.6.2008) und [[Media:muster_blatt6.pdf|Musterlösung]]
#* Treap-Datenstruktur: Verbindung von Suchbaum und Heap
#* Anwendung: Worthäufigkeiten (Dazu benötigen Sie das File [http://klimt.iwr.uni-heidelberg.de/mip/people/ukoethe/download/die-drei-musketiere.txt die-drei-musketiere.txt]. Die Zeichenkodierung in diesem File ist Latin-1.)
#* Suche mit linearer Komplexität

# [[Media:Übung-7.pdf|Übung]] (Abgabe 12.6.2008) und [[Media:muster_blatt7.pdf|Musterlösung]]
#* Übungen zu Rekursion und Iteration: Fakultät, Koch-Schneeflocke, Komplexität rekursiver Algorithmen, Umwandlung von Rekursion in Iteration

# [[Media:Übung-8.pdf|Übung]] (Abgabe 19.6.2008)
#* Elementare Graphenaufgaben: Aufstellen von Adjazenzmatrizen und Adjazenzlisten, planare Graphen
#* Übungen zur Generizität: Sortieren mit veränderter Ordnung, Iterator für Tiefensuche

# [[Media:Übung-9.pdf|Übung]] (Abgabe 26.6.2008)
#* Fortgeschrittene Graphenaufgaben: Erzeugen einer perfekten Hashfunktion, Routenplaner (Dazu benötigen Sie das File [http://klimt.iwr.uni-heidelberg.de/mip/people/ukoethe/download/entfernungen.txt entfernungen.txt]. Die Zeichenkodierung in diesem File ist Latin-1.)
#* '''Achtung: geänderte Version''' in der Originaldatei haben sich einige Fehler eingeschlichen. Hier ist eine neue Version der Entfernungen verfügbar: [http://www.rzuser.uni-heidelberg.de/~jschleic/entfernungen_neu.txt entfernungen_neu.txt]

# Übung (Abgabe 3.7.2008)
#* Beispiele für Divide and Conquer: pow-Funktion
#* Beispiel für Methode der kleinsten Quadrate: Approximation von Kreisen

# Übung (Abgabe 10.7.2008)
#* Randomisierte Algorithmen: Laufzeitvergleich deterministischer und randomisierter Primzahltest, RANSAC für Kreise

# Übung (Abgabe 17.7.2008)
#* Theoretische und praktische Aufgaben zur dynamische Programmierung

Graphen und Graphenalgorithmen

2008-06-25T21:33:26Z

Jschleic: heutige Vorlesung (25.06.) vorläufig nicht-autorisiert hinzugefügt - Bitte vom Wiki-Beauftragten ergänzen / ersetzen!

== Einführung zu Graphen ==

=== Motivation ===

==== Königsberger - Brückenproblem ====
(1736 Euler)

[[Image:Koenigsberg.jpg]]

Königsberger Brücken:

Spaziergang durch Königsberg, so dass alle Brücken nur einmal überquert werden.

Geometrie:
Topologie

O
|| \
|| \
O O
|| /
|| /
O

* '''Definition: ungerichteter Graph'''

Ein ungerichteter Graph G = ( V, E )

** V ist endliche Menge von Knoten (vertices)
** E c V × V (edges)

Ein Graph heißt ungerichtet, wenn zusätzlich gilt:

(x,y) ∈ E => (y,x) ∈ E (symmetrie)

Bsp:

gerichteter Graph
[[Image:digraph.png|gerichteter Graph]]

ungerichtet

O
|| \
|| \
O O
|| /
|| /
O

Bsp:

* Landkarten:
** Knoten: Länder
** Kanten: gem. Grenzen

* Schaltkreis:
** Knoten: Gatter
** Kanten: Verbindungen

* Chemie (Summenformeln):
** Knoten: Elemente
** Kanten: Bindungen

* Soziologie (StudieVZ)
** Soziogramm
*** Knoten: Personen
*** Kanten: Freund von ...

* '''Definition: Vollständige Graphen'''

Bei vollständigen Graphen ist jeder Knoten mit allen anderen Knoten verbunden.

E = U V (v,w) u (w,v) | v ∈ V, w ∈ V, u != w

{| 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?

== Repräsentation von Graphen ==

Sei G = ( V, E ) geg und liege V in einer lineraren Sortierung vor.
V = { v1, ...., vn }

== Adjazenzmatrix ==

AG = aij = {1 falls (vi, vj) ∈ E ; sonst 0}

Bsp:

v = { a,b,c,d } b d
| \ / |
| \/ |
| /\ |
| / \ |
a c

a b c d
-----------
(0 1 0 1) |a
AG = (1 0 1 0) |b
(0 1 0 1) |c
(1 0 1 0) |d

== Adjezenzlisten ==

al(v) = {v' ∈ V | (u,u') ∈ E}
Lg = ((v1, al(v1)), ...., (vn, al(vn))

Python:

Array von Arrays [[...],[...],...,[...]]
0 1 n

* '''Definition: Teilgraphen'''

Ein Graph G' = (v',E') ist ein Teilgraph, wenn gilt:

** v' c V
** E' c E

Er heißt erzegender Graph, wenn zusätzlich gilt:

** v' = V

* '''Definition: Knotengrade'''
Für G = (v,E)und v ∈ V
grad(v) = |{v' ∈ V | v,v'∈ E}|
out_grad(v) = | -""- |
in_grad(v) = |{v'∈ V| (v',v) ∈ E}|

Bsp:

ungerichtet

c
|| \
|| \
b d grad(a) = | {b,b,d} | = 3
|| /
|| /
a

gerichtet

c←
| \
↓ \
b←--d out_grad(d) = 2 = | {c,b} |
| /→ in_grad(d) = 1 = | {a} |
↓ /
a

* '''Definition: Wege'''

Sei G = (v,E)

** Für v0 ∈ V ist (v0) ein Weg in G
** Für Knoten v1,...vn,vn+1 und eine Kante (vn,vn+1) ∈ E ist mit einem Weg (v0,....vn) in G auch (v0,...,vn,vn+1) ein Weg in G.

Also: Nichtleere Folgen von Knoten die durch eine Kante verbunden sind.

== Eulerweg ==

O
/ \
O----O
| \/ |
| /\ | "Das Haus vom Nikolaus" Alle ''Kanten'' werden nur ''einmal'' passiert
O----O

== Hamiltonweg ==

O
/
O----O
/
/ Alle ''Knoten'' werden nur ''einmal'' passiert
O----O

== Kreis ==

O
/ \
O O
| | v0 = vn
| | vi != vj Für Alle i,j i !=j; i,j >0; i,j < n
O----O

== Zyklen ==

O
/ \
O O
\ |
\ | Wie Kreis nur ohne (vi != vj)
O====O

* '''Definition: planare Graphen'''

Ist ein Graph, der auf einer Ebene gezeichnet werden ''kann'', sodass sich die Kanten nicht schneiden!

Bsp:

1)

O
/|\
/ O \
/ / \ \
O O

2)

O
/ \
O----O
| \/ |
| /\ |
O----O

3)

|----O @
| /@ \
| O----O
| |@ / |
| | / @|
| O----O @ entspricht ''Regionen'' auch ausserhalb der Figur ist eine Region
|@ |
|-------|

1),2) und 3) sind planare Graphen.

Der K5 Graph ist kein planarer Graph da sich zwangsweise Kanten schneiden.

* '''Definition: dualer Graph'''

Der duale Graph eines geg. planaren Graphs G' ist ein Graph mit

** Knoten für jede Region
** Für jede Kante aus E gilt es gibt eine Kante, die die angrenzende Region mit Knoten verbindet.

dualer Graph

O------O
| /| \
|-|-@ / | @\---|
| | |\/ |/| O |
| | |/\ /| |/ |
| | / @ | / |
| O-+--+-O | |
| | | | |
|---|--@---|----|

* '''Definition: erreichbar'''

W ∈ V ist erreichbar von v ∈ G gdw.:
es Existiert Weg(v,...w)

* '''Definition: Zusammenhang'''

G heißt zusammenhängend, wenn für Alle v,w ∈V gilt:
w ist erreichbar von V

== Bäume ==

* '''Definition: Baum'''

Ein Baum ist ein zusammenhängender, kreisfreier Graph.

Bsp.: Binary Search Tree

* '''Definition: erzeugender Baum'''

für G = (v,E) ist ein erzeigender Teilgraph mit Baumeigenschaft

Bsp.:

O O
/ /
O O O
| / /
| / /
O----O----O

== Durchlaufen von Graphen ==

=== Tiefensuche in Graphen ===

Sei der Graph gegeben als Liste von Listen = g

def dfs (g,node,v=0):
if v == 0:
v = [0]*len(g) #visited-Liste
v[node] = 1 #besuche node
for t in g[node]: #gehe zu allen Nachbarn
if v[t] == 0: #falls diese noch nicht besucht
dfs(g,t,v) #Rekursion

[[Image:Tiefens.jpg]]

Aufruf dfs(g,1)

=>Folge 1,2,4,3,6,7,5

=== Breitensuche ===

from Queue import *
def bfs(g,startnode)
v = [0]*len(g)
q = Queue()
v = [startnode] = 1 #besuche
q.put(startnode) #in Schlange
while not q.get()
node = q.get()
for t in q[node]
if v[t] == 0:
v[t] = 1
q.put(t)

[[Image:Breitens.jpg]]

=>Folge 1,2,3,4,5,6,7

== Damenproblem ==

---------------
| | X | | |
|---|---|---|---|
| | | | X |
|---|---|---|---|
| X | | | |
|---|---|---|---|
| | | | X |
---------------

4 Damen auf einem vereinfachten Schachbrett so Positionieren, dass sich keine bedroht.

erster Durchlauf:

[[Image:Suche1.jpg]]

zweiter Durchlauf:

[[Image:Suche2.jpg]]

== Weitere Anwendungen (18.06.08) ==

def dfs(graph):
'''
Diese Tiefensuche tut so noch nichts weiter als zu traversieren
+ graph ist Array,
i-ter Eintrag enthaelt Adjazenzliste (auch Array) des i-ten Knotens,
wobei Knoten nummeriert von 0 ... v-i
'''
def visit(graph, node, visited):
'''
visited ist Array mit Flags fuer besuchte Knoten
'''
if visited[node]: return
visited[node] = True
for neighbor in graph[node]:
visit(graph, neighbor, visited)

visited = [False]*len(graph)
for node in range(len(graph)):
visit(graph, node, visited)

=== Finden von Zusammenhangskomponenten ===

Ein moeglicher Einsatz des Verfahrens ist das Finden von Zusammenhangskomponenten (connected components).

* Beispiel: ...

* Definition: CC_i = {u_k, u_l e V: es gibt einen Pfad von u_k nach u_l ("u_l ist von u_k aus erreichbar")
* fuer ungerichtete Graphen gilt zusaetzlich: es gibt einen Pfad von u_l nach u_k}

Die Relation CC_i, also die Zusammenhangskomponenten (ZK) bilden eine Aequivalenzrelation,
also kann fuer jede ZK ein Repraesentant bestimmt werden (der sog. "Anker"). Kennt jeder
Knoten seinen Anker, so ist das ZK-Problem geloest.

==== Tiefensuchen-Algorithmus ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden, wobei statt
Knotenbesuche Knotennummern fuer die schon gefundenen Anker gesetzt werden. Ein moeglicher
Algorithmus lautet damit wie folgt:

def connectedComponents(graph):
def visit(graph, node, anchors, anchor):
'''
anchor ist Anker der aktuellen ZK
'''
if anchors[node] is not None: return # Anker von <node> schon bekannt
anchors[node] = anchor
for neighbor in graph[node]
visit(graph, neighbor, anchors, anchor)

anchors = [None]*len(graph)
for node in range(len(graph)):
visit(graph, node, anchors, node) # node: Anker der naechste ZK = erster Knoten der ZK
return anchors

* Beispiel: ...

==== Union-Find-Algorithmus ====

Eine Alternative (ohne Tiefensuche) waere z.B. ein Union-Find-Algorithmus. Idee dabei ist, dass eingangs jeder Knoten eine eigene ZK bildet, wobei in einer anschliessenden Rekursion Kanten gesucht werden, die zwischen den ZK bestehen.

Initialisierung: jeder Knoten wird als 1 ZK behandelt
Rekursion: fasse ZK zusammen (Union) falls Kante zwischen ihnen existiert
Ergebnis: Array mit dem Anker jedes Knotens

def unionFindCC(graph):
def findAnchor(anchors, k):
'''
Prueft auf anchors[k]==k
'''
while anchors[k] != k:
k = anchor[k]
return k

def edges(graph):
e = []
for node in range(len(Graph)):
for n in graph[node]:
if node < n:
e.append((node, n))
return e

anchors = range(len(graph) # jeder Knoten ist sein eigener Anker
for edge in edges(graph):
# diese Schleife ordnet die Anker so, dass
# der 1. Anker immer der kleinste ist
a1, a2 = findAnchor(anchors, edge[0]), findAnchor(anchors, edge[1])
if a2 < a1: a2,a1 = a1,a2
if a1 != a2: anchors[a2] = a1
for node in range(len(graph)):
# diese Schleife raeumt mit Indirektionen auf (s. Bsp. (#))
anchor[node] = findAnchor(anchors, node)

* Beispiel (#): ...

Eine verbreitete Anwendung fuer dieses Verfahren gibt es in der Bildverarbeitung:

* Beispiel: ...

== Variationen der Tiefensuche (19.06.2008) ==

=== Wichtige Algorithmen, die in der Vorlesung nicht behandelt werden ===

* Max Flow (zur Bestimmung des maximalen Flusses durch ein Netzwerk, z.B. bei Ölpipelines)
* Matching (auch ''Paarung'' genannt): Teilmenge der Kanten eines Graphen, wobei keine zwei Kanten einen gleichen Knoten besitzen
*:Anwendungsbereiche: Zuordnung von Gruppen, z.B. Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot), Universität (Zuordnung Studenten - Übungsgruppen)

=== Vereinfachte Lösung für den ''acyclic''-Algorithmus ===
Zum Finden von Zyklen, bzw. der Feststellung, ob ein Graph azyklisch ist, verwenden wir
wieder eine modifizierte Version der Tiefensuche: Die Knoten werden wieder nach dem System der Tiefensuche besucht, und alle besuchten Knoten in einem Array visited abgespeichert. Es gibt einen Zyklus genau dann, wenn man zu
einem früheren Knoten (außer zum direkten Vorgaenger) zurückkommt.

<code python>
def acyclic(graph):
def visit(graph, node, fromNode, visited):
if visited[node]: # Zyklus entdeckt
return False
visited[node] = True
for neighbor in graph[node]:
if neighbor == fromNode: # überspringe Nachbar, von dem du gekommen bist
continue
if not visit(graph, neighbor, node, visited):
return False # der Graph ist zyklisch
return True # kein Zyklus
visited = [False]*len(graph)
for node in range(len(graph)):
if visited[node]: # schließt aus, dass Knoten besucht wird, der schon besucht war
continue
if not visit(graph, node, None, visited):
return False
return True
</code>

'''Anmerkungen zum Code:'''

* Wenn ein Knoten bereits besucht ist, dann gehört er zur gleichen Zusammenhangskomponente - dies hat allerdings nichts mit einem Zyklus zu tun.
* Ein Graph der einmal zyklisch war wird nie wieder azyklisch.
* Der obige Algorithmus weist Ähnlichkeiten mit den bereits behandelten Algorithmen auf: '''ein guter Algorithmus zeichnet sich dadurch aus, dass mit kleinen Code-Variationen ganz andere Probleme gelöst werden können'''.

=== Kürzeste Wege (Pfade) ===

* Definition: gewichteter Graph

Jeder Kante e ist eine reelle oder natürliche Zahl we zugeordnet (wird auch als
''Kantengewicht'' bezeichnet).

z.B.
* Abstand der Anfangs- und Endknoten

* Durchflusskapazität eines Rohres (für max-Flussprobleme)

* Wechselkurse (Darstellung in einem gerichteten Graph, da jede Kante auch eine Richtung hat. Die Knoten sind die Währungen, die Kanten sind die Wechselkurse. Auf diese Weise lassen sich unterschiedliche Wechselkurse + Bankgebühren darstellen.)

* '''Definition''': Problem des kürzesten Weges

Sei P die Menge aller Wege von u nach v

Puv = {u_v}

und der Weg gegeben durch

u → x1 → x2 → ... → v

dann sind die Kosten eines Weges definiert durch

Kosten (Puv) = <math>\sum\limits_{l \in Pv}</math> we

* gesucht: Pfad u_v, so dass Kosten (u_v) minimal sind

* Lösung: Algorithmus von Dijkstra

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

<code python>
import heapq # heapq ist ein Modul von Python
def dijkstra(graph, start, ziel): # graph: gewichtete Adjazenzliste
heap = []
visited = [None]*len(graph)
visited[start] = start
for neighbor in graph[start]:
heapq.heappush(heap, (neighbor[1], start, neighbor[0])) # neighbor[1]:Kantengewicht,neighbor[0]:Endpunkt d. K.
while len(heap) > 0: # solange der heap nicht leer ist
w, fromNode, node = heapq.heappop(heap)
if visited[node] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
visited[node] = fromNode # baue Vorgänger-Baum
if node == ziel: # da der heap noch nicht leer ist, wird an dieser Stelle ein break benötigt
break
for neighbor in graph[node]:
if visited[neighbor[0]] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
heapq.heappush(heap, (neighbor[1]+w, node, neighbor[0]))
bestPath = []
t = ziel
while t != visited[t]: # Array wird durchlaufen bis der Anker des Pfades gefunden ist, vgl. Union-Search
bestPath.append(t)
t=visited[t]
bestPath.append(start)
return bestPath # bestPath.reverse()
</code>

'''Anmerkungen zum Code:'''
* der graph ist eine gewichtete Adjazenzliste

{|

|-

| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | Endknoten || → || style="background:silver; color:white" | Endknoten || (Nr. der Nachbarn des Knoten 0)

|-

| || style="background:silver; color:white" | 1 || || style="background:silver; color:white" | Gewicht || || style="background:silver; color:white" | Gewicht || (Gewicht der jeweiligen Kante)

|-

| || style="background:silver; color:white" | 2 ||

|-

| || style="background:silver; color:white" | 3 ||

|}
* Eingabe z.B.:
{|
|-
| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | (1, 0.3) || style="background:silver; color:white" | (3, 0.1) || style="background:silver; color:white" | (5, 1.2) ||
|-
| || style="background:silver; color:white" | 1 || → || style="background:silver; color:white" | || style="background:silver; color:white" | || style="background:silver; color:white" | ||
|-
| || style="background:silver; color:white" | 2 ||
|-
| || style="background:silver; color:white" | 3 ||
|-
| || style="background:silver; color:white" | 4 ||
|-
| || style="background:silver; color:white" | 5 ||
|-
| || style="background:silver; color:white" | 6 ||
|}
* heapq() verwendet den 1. Eintrag des Tupels zum sortieren des heap

==== Prinzip des Dijkstra-Algorithmus ====

* Algorithmus ist Tiefensuche mit Prioritätswarteschlange (Heap) statt eines Stapelspeichers (Stack) → vgl. Übung 8

* Die Prioritätswarteschlange speichert die kürzesten Wege, die bereits gefunden worden sind.

* Wenn man die Prioritätswarteschlange (Heap) durch eine Warteschlange (Queue) ersetzt, erhält man Breitensuche.

* Wenn man die Prioritätswarteschlange (Heap) durch einen Stapelspeicher (Stack) ersetzt, erhält man Tiefensuche.

==== Beispiel ====

[[Image:Bsp.jpg]]

* An der Stelle "neighbor[1]" wird eine Zählvariable ''count'' eingefügt, die hoch (Breitensuche) oder runter (Tiefensuche) zählt.

* Die Gewichte werden hoch- oder runtergezählt, so wie die Kanten gesehen wurden.

* Wenn man rückwärts zählt (von 0 abziehen), werden die zuletzt hinzugefügten Kanten expandiert.

* '''Algorithmus von Dijkstra funktioniert nur für positive Kantengewichte
*:<math>\forall</math> we > 0'''

* Bei negativen Kantengewichten könnte es Zyklen geben, die negative Kosten für den ganzen Zyklus haben:

/\ 1. Durchlauf: Kosten -1
1 / \ 4 2. Durchlauf: Kosten -2
/____\ etc.
2

* Verwendung bei arbitragen Geschäften (Börsengeschäfte, die die Preis-, Kurs- und Zinsunterschiede auf verschiedenen Märkten ausnutzen):
*:EURO wurden in YEN, YEN in DOLLAR gewechselt und das Geld hat sich dadurch vermehrt
* Für negative Kantengewichte verwendet man den Bellman-Ford-Allgorithmus, der allerdings langsamer ist, als der Dijkstra-Algorithmus.

==== Komplexität von Dijkstra ====

* Jeder Knoten wird höchstens 1x expandiert (Iteration über die Nachbarn des Knotens).

* Jeder Knoten kann mehrmals im Heap enthalten sein.

* Es sind aber höchstens E (Anzahl der Kanten) Heap-Einträge möglich, da jede Kante höchstens 1 Heap-Eintrag generiert (ein Knoten ist nur dann im Heap, wenn man ihn über eine Kante erreicht hat, die man vorher noch nicht besucht hatte). Deshalb können nie mehr Einträge im Heap sein, als es Kanten gibt. Die Komplexität von heappush(), heappop() ist
O(log E) = O(2 log v) = O(log v)
wenn alle Kanten einen Heap-Eintrag generiert haben.
* Die while-Schleife wird im schlimmsten Fall E mal durchlaufen, deshalb ist die Komplexität von Dijkstra O(E log v).

==== Korrektheit von Dijkstra ====

* Falls
visited[node] (Schleifen-Invariante von while) != None
ist, dann liefert Zurückverfolgen des Pfades von node nach start den kürzesten Pfad von start nach node (gilt für alle Knoten, für die das visited-Feld gesetzt ist).
* Induktionsanfang: visited[start] ist einziger not-None-Fall → Bedingung erfüllt
* Induktionsschritt: wenn visited[node] gesetzt wird, ist es ein kürzester Pfad

==== Indirekter Beweis ====

Set S = {node | visited[node] != None} (alle Knoten, von denen wir den kürzesten Pfad schon kennen)

* u ist der Knoten an der Spitze des Heaps
* fromNode <math>\in</math> S (ein Nachbar von node kommt erst dann in den Heap, wenn visited[node] vorher gesetzt wurde)
* falls u → fromNode &rarr start kein kürzester Pfad wäre, müsste u's Vorgänger in V\S sein
* sei dieser Vorgänger x <math>\notin</math> S, x <math>\not=</math> u
* sei wx das Gewicht der Kante x → u, dann sind die Kosten für start nach u gleich

Kosten(start_u) = Kosten(start_x) + wx

* Annahme des indirekten Beweises:

Kosten(start_fromNode) + wfromNode

* Behauptung des indirekten Beweises:
Es gibt einen anderen Pfad x, so dass die Kosten von start nach x geringer sind

* Da aber gilt:
fromNode <math>\in</math> S und x <math>\notin</math> S

* gilt (Induktionsvoraussetzung):
Kosten(start_fromNode) < Kosten(start_x)

* Falls Kosten(start_x) < Kosten(start_u) müsste x im Heap vor u kommen; daraus folgt, dass u nicht an der Spitze des Heaps sein kann

→ Widerspruch!

→ Die Behauptung, der Weg über x ist besser, kann nicht stimmen.

→ Korrektheit von Dijkstra ist somit bewiesen.

==== Wie kann man Dijkstra noch verbessern? ====

===== A*-Algorithmus =====

* Verbesserung von Dijkstra im typischen Fall, aber die Komplexität ist immer noch =(Elog v) im schlechtesten Fall (die Komplexität kann man nicht verbessern, aber die Laufzeit im typischen Fall).
* Schätzung für jeden Knoten für den restlichen Weg:
geschätzte Gesamtkosten: Kosten(start_node) + Restschätzung(node_ziel)
(exakte Kosten werden durch Dijkstra ermittelt)

'''Idee:'''
* Sortiere den Heap nach geschätzten Gesamtkosten.
* Satz:
Falls jede Schätzung den exakten Weg unterschätzt, werden die gleichen Pfade gefunden, wie
bei Dijkstra (also die korrekten kürzesten Pfade).
(Die Schätzung für den restlichen Weg muss man immer so einrichten, dass der tatsächliche Weg unterschätzt wird. Da keine Straße kürzer sein kann als die Luftlinie, ist die Luftlinie eine geeignete Annahme für A*.)
* Falls der falsche Pfad im Heap eher an die Spitze kommt als der richtige Pfad, findet der A*-Algorithmus den falschen Pfad.
* Wenn der Pfad zum Ziel an der Spitze des Heap ist, dann wird keine Restschätzung mehr benötigt, denn wenn der Zielknoten aus dem Heap herrauskommt, dann hat man die exakte Berechnung. Die Restschätzung ist in diesem Fall 0. Wenn die Schätzung zu klein ist, wird der exakte Weg immer größer sein und zuerst aus dem Heap herauskommen.

===Minimaler Spannbaum (tree-MST)===
gegeben: gewichteter, zusammenhängender Graph G
gesucht: Untermenge E'\subseteq E, so dass \sum_{e\in E} w_e minimal und G' zusammenhängend
G' definiert dann einen Baum, denn andernfalls könnte man \sum verringern (eine Kante weglassen)
Anwendungen: Wie verbindet man n Punkte mit möglichst wenigen kurzen Straßen"""

====Algorithmus von Prim====

def prim(graph):
heap = []
visited = [False]*len(graph)
sum = 0
r = []
for neighbor in graph[0]:
heapq.heappush(heap, (neighbor[1], 0, neighbor[0]))
while len(heap):
wn, start, ziel = heapq.heappop(heap)
if visited[ziel]: continue
visited[ziel] = True
sum += wn
r.append([start, ziel])
for neighbor in graph[ziel]:
if visited[neighbor[0]]: continue
heapq.heappush(heap, (neighbor[1], ziel, neighbor[0]))
return sum, r

====Algorithmus von Krushal====
Idee: wie beim Union-Find-Algorithmus für Zusammenhangskomponenten
1. Behandle jeden Knoten als Baum für sich
2. Fasse zwei Bäume zu neuem Baum zusammen
für MST: betrachte dazu die Kanten in aufsteigender Reihenfolge der Gewichte
(ignoriere Kanten zw. Knoten in gleichem Baum)
=> geeignet für Übungsaufgabe

=== Problem des Handlungsreisenden (travelling salesman problem - TSP)===
gegeben: zusammenhängender, gewichteter Graph (oft vollständiger Graph)
gesucht: kürzester Weg, der alle Knoten genau einmal besucht (und zum Ausgangsknoten zurückkehrt)
vorgegeben: Startknoten => v-1 Möglichkeiten => je v-2 Möglichkeiten
also (v-1)!/2 mögliche Wege in einem vollständigen Graphen

naive Lösung: brute force (Durchprobieren aller möglichen Pfade)

'''Systematisches Erzeugen aller Permutationen'''
Trick: erzeuge jede Permutation in lexikographischer Ordnung

def next_permutation(a):
i = len(a) -1
while True:
if i <= 0: return False # a ist letzte Permutation
i -= 1
if a[i]<a[i+1]: break
#lexicogr. Nachfolger hat groß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, also
O(v!) = O(v^v)

Graphen und Graphenalgorithmen

2008-06-25T21:06:33Z

Jschleic: /* Vereinfachte Lösung für den acyclic-Algorithmus */

Graphen und Graphenalgorithmen

2008-06-25T21:03:32Z

Jschleic: /* Detektion von Zyklen */ fehlerhafter Code entfernt, funktionierender acyclic(graph) siehe unten

== Einführung zu Graphen ==

=== Motivation ===

==== Königsberger - Brückenproblem ====
(1736 Euler)

[[Image:Koenigsberg.jpg]]

Königsberger Brücken:

Spaziergang durch Königsberg, so dass alle Brücken nur einmal überquert werden.

Geometrie:
Topologie

O
|| \
|| \
O O
|| /
|| /
O

* '''Definition: ungerichteter Graph'''

Ein ungerichteter Graph G = ( V, E )

** V ist endliche Menge von Knoten (vertices)
** E c V × V (edges)

Ein Graph heißt ungerichtet, wenn zusätzlich gilt:

(x,y) ∈ E => (y,x) ∈ E (symmetrie)

Bsp:

gerichteter Graph
[[Image:digraph.png|gerichteter Graph]]

ungerichtet

O
|| \
|| \
O O
|| /
|| /
O

Bsp:

* Landkarten:
** Knoten: Länder
** Kanten: gem. Grenzen

* Schaltkreis:
** Knoten: Gatter
** Kanten: Verbindungen

* Chemie (Summenformeln):
** Knoten: Elemente
** Kanten: Bindungen

* Soziologie (StudieVZ)
** Soziogramm
*** Knoten: Personen
*** Kanten: Freund von ...

* '''Definition: Vollständige Graphen'''

Bei vollständigen Graphen ist jeder Knoten mit allen anderen Knoten verbunden.

E = U V (v,w) u (w,v) | v ∈ V, w ∈ V, u != w

{| 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?

== Repräsentation von Graphen ==

Sei G = ( V, E ) geg und liege V in einer lineraren Sortierung vor.
V = { v1, ...., vn }

== Adjazenzmatrix ==

AG = aij = {1 falls (vi, vj) ∈ E ; sonst 0}

Bsp:

v = { a,b,c,d } b d
| \ / |
| \/ |
| /\ |
| / \ |
a c

a b c d
-----------
(0 1 0 1) |a
AG = (1 0 1 0) |b
(0 1 0 1) |c
(1 0 1 0) |d

== Adjezenzlisten ==

al(v) = {v' ∈ V | (u,u') ∈ E}
Lg = ((v1, al(v1)), ...., (vn, al(vn))

Python:

Array von Arrays [[...],[...],...,[...]]
0 1 n

* '''Definition: Teilgraphen'''

Ein Graph G' = (v',E') ist ein Teilgraph, wenn gilt:

** v' c V
** E' c E

Er heißt erzegender Graph, wenn zusätzlich gilt:

** v' = V

* '''Definition: Knotengrade'''
Für G = (v,E)und v ∈ V
grad(v) = |{v' ∈ V | v,v'∈ E}|
out_grad(v) = | -""- |
in_grad(v) = |{v'∈ V| (v',v) ∈ E}|

Bsp:

ungerichtet

c
|| \
|| \
b d grad(a) = | {b,b,d} | = 3
|| /
|| /
a

gerichtet

c←
| \
↓ \
b←--d out_grad(d) = 2 = | {c,b} |
| /→ in_grad(d) = 1 = | {a} |
↓ /
a

* '''Definition: Wege'''

Sei G = (v,E)

** Für v0 ∈ V ist (v0) ein Weg in G
** Für Knoten v1,...vn,vn+1 und eine Kante (vn,vn+1) ∈ E ist mit einem Weg (v0,....vn) in G auch (v0,...,vn,vn+1) ein Weg in G.

Also: Nichtleere Folgen von Knoten die durch eine Kante verbunden sind.

== Eulerweg ==

O
/ \
O----O
| \/ |
| /\ | "Das Haus vom Nikolaus" Alle ''Kanten'' werden nur ''einmal'' passiert
O----O

== Hamiltonweg ==

O
/
O----O
/
/ Alle ''Knoten'' werden nur ''einmal'' passiert
O----O

== Kreis ==

O
/ \
O O
| | v0 = vn
| | vi != vj Für Alle i,j i !=j; i,j >0; i,j < n
O----O

== Zyklen ==

O
/ \
O O
\ |
\ | Wie Kreis nur ohne (vi != vj)
O====O

* '''Definition: planare Graphen'''

Ist ein Graph, der auf einer Ebene gezeichnet werden ''kann'', sodass sich die Kanten nicht schneiden!

Bsp:

1)

O
/|\
/ O \
/ / \ \
O O

2)

O
/ \
O----O
| \/ |
| /\ |
O----O

3)

|----O @
| /@ \
| O----O
| |@ / |
| | / @|
| O----O @ entspricht ''Regionen'' auch ausserhalb der Figur ist eine Region
|@ |
|-------|

1),2) und 3) sind planare Graphen.

Der K5 Graph ist kein planarer Graph da sich zwangsweise Kanten schneiden.

* '''Definition: dualer Graph'''

Der duale Graph eines geg. planaren Graphs G' ist ein Graph mit

** Knoten für jede Region
** Für jede Kante aus E gilt es gibt eine Kante, die die angrenzende Region mit Knoten verbindet.

dualer Graph

O------O
| /| \
|-|-@ / | @\---|
| | |\/ |/| O |
| | |/\ /| |/ |
| | / @ | / |
| O-+--+-O | |
| | | | |
|---|--@---|----|

* '''Definition: erreichbar'''

W ∈ V ist erreichbar von v ∈ G gdw.:
es Existiert Weg(v,...w)

* '''Definition: Zusammenhang'''

G heißt zusammenhängend, wenn für Alle v,w ∈V gilt:
w ist erreichbar von V

== Bäume ==

* '''Definition: Baum'''

Ein Baum ist ein zusammenhängender, kreisfreier Graph.

Bsp.: Binary Search Tree

* '''Definition: erzeugender Baum'''

für G = (v,E) ist ein erzeigender Teilgraph mit Baumeigenschaft

Bsp.:

O O
/ /
O O O
| / /
| / /
O----O----O

== Durchlaufen von Graphen ==

=== Tiefensuche in Graphen ===

Sei der Graph gegeben als Liste von Listen = g

def dfs (g,node,v=0):
if v == 0:
v = [0]*len(g) #visited-Liste
v[node] = 1 #besuche node
for t in g[node]: #gehe zu allen Nachbarn
if v[t] == 0: #falls diese noch nicht besucht
dfs(g,t,v) #Rekursion

[[Image:Tiefens.jpg]]

Aufruf dfs(g,1)

=>Folge 1,2,4,3,6,7,5

=== Breitensuche ===

from Queue import *
def bfs(g,startnode)
v = [0]*len(g)
q = Queue()
v = [startnode] = 1 #besuche
q.put(startnode) #in Schlange
while not q.get()
node = q.get()
for t in q[node]
if v[t] == 0:
v[t] = 1
q.put(t)

[[Image:Breitens.jpg]]

=>Folge 1,2,3,4,5,6,7

== Damenproblem ==

---------------
| | X | | |
|---|---|---|---|
| | | | X |
|---|---|---|---|
| X | | | |
|---|---|---|---|
| | | | X |
---------------

4 Damen auf einem vereinfachten Schachbrett so Positionieren, dass sich keine bedroht.

erster Durchlauf:

[[Image:Suche1.jpg]]

zweiter Durchlauf:

[[Image:Suche2.jpg]]

== Weitere Anwendungen (18.06.08) ==

def dfs(graph):
'''
Diese Tiefensuche tut so noch nichts weiter als zu traversieren
+ graph ist Array,
i-ter Eintrag enthaelt Adjazenzliste (auch Array) des i-ten Knotens,
wobei Knoten nummeriert von 0 ... v-i
'''
def visit(graph, node, visited):
'''
visited ist Array mit Flags fuer besuchte Knoten
'''
if visited[node]: return
visited[node] = True
for neighbor in graph[node]:
visit(graph, neighbor, visited)

visited = [False]*len(graph)
for node in range(len(graph)):
visit(graph, node, visited)

=== Finden von Zusammenhangskomponenten ===

Ein moeglicher Einsatz des Verfahrens ist das Finden von Zusammenhangskomponenten (connected components).

* Beispiel: ...

* Definition: CC_i = {u_k, u_l e V: es gibt einen Pfad von u_k nach u_l ("u_l ist von u_k aus erreichbar")
* fuer ungerichtete Graphen gilt zusaetzlich: es gibt einen Pfad von u_l nach u_k}

Die Relation CC_i, also die Zusammenhangskomponenten (ZK) bilden eine Aequivalenzrelation,
also kann fuer jede ZK ein Repraesentant bestimmt werden (der sog. "Anker"). Kennt jeder
Knoten seinen Anker, so ist das ZK-Problem geloest.

==== Tiefensuchen-Algorithmus ====

Unser erster Ansatz ist, den Anker mit Hilfe der Tiefensuche zu finden, wobei statt
Knotenbesuche Knotennummern fuer die schon gefundenen Anker gesetzt werden. Ein moeglicher
Algorithmus lautet damit wie folgt:

def connectedComponents(graph):
def visit(graph, node, anchors, anchor):
'''
anchor ist Anker der aktuellen ZK
'''
if anchors[node] is not None: return # Anker von <node> schon bekannt
anchors[node] = anchor
for neighbor in graph[node]
visit(graph, neighbor, anchors, anchor)

anchors = [None]*len(graph)
for node in range(len(graph)):
visit(graph, node, anchors, node) # node: Anker der naechste ZK = erster Knoten der ZK
return anchors

* Beispiel: ...

==== Union-Find-Algorithmus ====

Eine Alternative (ohne Tiefensuche) waere z.B. ein Union-Find-Algorithmus. Idee dabei ist, dass eingangs jeder Knoten eine eigene ZK bildet, wobei in einer anschliessenden Rekursion Kanten gesucht werden, die zwischen den ZK bestehen.

Initialisierung: jeder Knoten wird als 1 ZK behandelt
Rekursion: fasse ZK zusammen (Union) falls Kante zwischen ihnen existiert
Ergebnis: Array mit dem Anker jedes Knotens

def unionFindCC(graph):
def findAnchor(anchors, k):
'''
Prueft auf anchors[k]==k
'''
while anchors[k] != k:
k = anchor[k]
return k

def edges(graph):
e = []
for node in range(len(Graph)):
for n in graph[node]:
if node < n:
e.append((node, n))
return e

anchors = range(len(graph) # jeder Knoten ist sein eigener Anker
for edge in edges(graph):
# diese Schleife ordnet die Anker so, dass
# der 1. Anker immer der kleinste ist
a1, a2 = findAnchor(anchors, edge[0]), findAnchor(anchors, edge[1])
if a2 < a1: a2,a1 = a1,a2
if a1 != a2: anchors[a2] = a1
for node in range(len(graph)):
# diese Schleife raeumt mit Indirektionen auf (s. Bsp. (#))
anchor[node] = findAnchor(anchors, node)

* Beispiel (#): ...

Eine verbreitete Anwendung fuer dieses Verfahren gibt es in der Bildverarbeitung:

* Beispiel: ...

== Variationen der Tiefensuche (19.06.2008) ==

=== Wichtige Algorithmen, die in der Vorlesung nicht behandelt werden ===

* Max Flow (zur Bestimmung des maximalen Flusses durch ein Netzwerk, z.B. bei Ölpipelines)
* Matching (auch ''Paarung'' genannt): Teilmenge der Kanten eines Graphen, wobei keine zwei Kanten einen gleichen Knoten besitzen
*:Anwendungsbereiche: Zuordnung von Gruppen, z.B. Arbeitsamt (Zuordnung Arbeitssuchender - Stellenangebot), Universität (Zuordnung Studenten - Übungsgruppen)

=== Vereinfachte Lösung für den ''acyclic''-Algorithmus ===

<code python>
def acyclic(graph):
def visit(graph, node, fromNode, visited):
if visited[node]: # Zyklus entdeckt
return False
visited[node] = True
for neighbor in graph[node]:
if neighbor == fromNode: # überspringe Nachbar, von dem du gekommen bist
continue
if not visit(graph, neighbor, node, visited):
return False # der Graph ist zyklisch
return True # kein Zyklus
visited = [False]*len(graph)
for node in range(len(graph)):
if visited[node]: # schließt aus, dass Knoten besucht wird, der schon besucht war
continue
if not visit(graph, node, None, visited):
return False
return True
</code>

'''Anmerkungen zum Code:'''

* Wenn ein Knoten bereits besucht ist, dann gehört er zur gleichen Zusammenhangskomponente - dies hat allerdings nichts mit einem Zyklus zu tun.
* Ein Graph der einmal zyklisch war wird nie wieder azyklisch.
* Der obige Algorithmus weist Ähnlichkeiten mit den bereits behandelten Algorithmen auf: '''ein guter Algorithmus zeichnet sich dadurch aus, dass mit kleinen Code-Variationen ganz andere Probleme gelöst werden können'''.

=== Kürzeste Wege (Pfade) ===

* Definition: gewichteter Graph

Jeder Kante e ist eine reelle oder natürliche Zahl we zugeordnet (wird auch als
''Kantengewicht'' bezeichnet).

z.B.
* Abstand der Anfangs- und Endknoten

* Durchflusskapazität eines Rohres (für max-Flussprobleme)

* Wechselkurse (Darstellung in einem gerichteten Graph, da jede Kante auch eine Richtung hat. Die Knoten sind die Währungen, die Kanten sind die Wechselkurse. Auf diese Weise lassen sich unterschiedliche Wechselkurse + Bankgebühren darstellen.)

* '''Definition''': Problem des kürzesten Weges

Sei P die Menge aller Wege von u nach v

Puv = {u_v}

und der Weg gegeben durch

u → x1 → x2 → ... → v

dann sind die Kosten eines Weges definiert durch

Kosten (Puv) = <math>\sum\limits_{l \in Pv}</math> we

* gesucht: Pfad u_v, so dass Kosten (u_v) minimal sind

* Lösung: Algorithmus von Dijkstra

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

<code python>
import heapq # heapq ist ein Modul von Python
def dijkstra(graph, start, ziel): # graph: gewichtete Adjazenzliste
heap = []
visited = [None]*len(graph)
visited[start] = start
for neighbor in graph[start]:
heapq.heappush(heap, (neighbor[1], start, neighbor[0])) # neighbor[1]:Kantengewicht,neighbor[0]:Endpunkt d. K.
while len(heap) > 0: # solange der heap nicht leer ist
w, fromNode, node = heapq.heappop(heap)
if visited[node] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
visited[node] = fromNode # baue Vorgänger-Baum
if node == ziel: # da der heap noch nicht leer ist, wird an dieser Stelle ein break benötigt
break
for neighbor in graph[node]:
if visited[neighbor[0]] is not None: # wenn der kürzeste Pfad bereits bekannt ist, überspringe ihn
continue
heapq.heappush(heap, (neighbor[1]+w, node, neighbor[0]))
bestPath = []
t = ziel
while t != visited[t]: # Array wird durchlaufen bis der Anker des Pfades gefunden ist, vgl. Union-Search
bestPath.append(t)
t=visited[t]
bestPath.append(start)
return bestPath # bestPath.reverse()
</code>

'''Anmerkungen zum Code:'''
* der graph ist eine gewichtete Adjazenzliste

{|

|-

| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | Endknoten || → || style="background:silver; color:white" | Endknoten || (Nr. der Nachbarn des Knoten 0)

|-

| || style="background:silver; color:white" | 1 || || style="background:silver; color:white" | Gewicht || || style="background:silver; color:white" | Gewicht || (Gewicht der jeweiligen Kante)

|-

| || style="background:silver; color:white" | 2 ||

|-

| || style="background:silver; color:white" | 3 ||

|}
* Eingabe z.B.:
{|
|-
| Knoten || style="background:silver; color:white" | 0 || → || style="background:silver; color:white" | (1, 0.3) || style="background:silver; color:white" | (3, 0.1) || style="background:silver; color:white" | (5, 1.2) ||
|-
| || style="background:silver; color:white" | 1 || → || style="background:silver; color:white" | || style="background:silver; color:white" | || style="background:silver; color:white" | ||
|-
| || style="background:silver; color:white" | 2 ||
|-
| || style="background:silver; color:white" | 3 ||
|-
| || style="background:silver; color:white" | 4 ||
|-
| || style="background:silver; color:white" | 5 ||
|-
| || style="background:silver; color:white" | 6 ||
|}
* heapq() verwendet den 1. Eintrag des Tupels zum sortieren des heap

==== Prinzip des Dijkstra-Algorithmus ====

* Algorithmus ist Tiefensuche mit Prioritätswarteschlange (Heap) statt eines Stapelspeichers (Stack) → vgl. Übung 8

* Die Prioritätswarteschlange speichert die kürzesten Wege, die bereits gefunden worden sind.

* Wenn man die Prioritätswarteschlange (Heap) durch eine Warteschlange (Queue) ersetzt, erhält man Breitensuche.

* Wenn man die Prioritätswarteschlange (Heap) durch einen Stapelspeicher (Stack) ersetzt, erhält man Tiefensuche.

==== Beispiel ====

[[Image:Bsp.jpg]]

* An der Stelle "neighbor[1]" wird eine Zählvariable ''count'' eingefügt, die hoch (Breitensuche) oder runter (Tiefensuche) zählt.

* Die Gewichte werden hoch- oder runtergezählt, so wie die Kanten gesehen wurden.

* Wenn man rückwärts zählt (von 0 abziehen), werden die zuletzt hinzugefügten Kanten expandiert.

* '''Algorithmus von Dijkstra funktioniert nur für positive Kantengewichte
*:<math>\forall</math> we > 0'''

* Bei negativen Kantengewichten könnte es Zyklen geben, die negative Kosten für den ganzen Zyklus haben:

/\ 1. Durchlauf: Kosten -1
1 / \ 4 2. Durchlauf: Kosten -2
/____\ etc.
2

* Verwendung bei arbitragen Geschäften (Börsengeschäfte, die die Preis-, Kurs- und Zinsunterschiede auf verschiedenen Märkten ausnutzen):
*:EURO wurden in YEN, YEN in DOLLAR gewechselt und das Geld hat sich dadurch vermehrt
* Für negative Kantengewichte verwendet man den Bellman-Ford-Allgorithmus, der allerdings langsamer ist, als der Dijkstra-Algorithmus.

==== Komplexität von Dijkstra ====

* Jeder Knoten wird höchstens 1x expandiert (Iteration über die Nachbarn des Knotens).

* Jeder Knoten kann mehrmals im Heap enthalten sein.

* Es sind aber höchstens E (Anzahl der Kanten) Heap-Einträge möglich, da jede Kante höchstens 1 Heap-Eintrag generiert (ein Knoten ist nur dann im Heap, wenn man ihn über eine Kante erreicht hat, die man vorher noch nicht besucht hatte). Deshalb können nie mehr Einträge im Heap sein, als es Kanten gibt. Die Komplexität von heappush(), heappop() ist
O(log E) = O(2 log v) = O(log v)
wenn alle Kanten einen Heap-Eintrag generiert haben.
* Die while-Schleife wird im schlimmsten Fall E mal durchlaufen, deshalb ist die Komplexität von Dijkstra O(E log v).

==== Korrektheit von Dijkstra ====

* Falls
visited[node] (Schleifen-Invariante von while) != None
ist, dann liefert Zurückverfolgen des Pfades von node nach start den kürzesten Pfad von start nach node (gilt für alle Knoten, für die das visited-Feld gesetzt ist).
* Induktionsanfang: visited[start] ist einziger not-None-Fall → Bedingung erfüllt
* Induktionsschritt: wenn visited[node] gesetzt wird, ist es ein kürzester Pfad

==== Indirekter Beweis ====

Set S = {node | visited[node] != None} (alle Knoten, von denen wir den kürzesten Pfad schon kennen)

* u ist der Knoten an der Spitze des Heaps
* fromNode <math>\in</math> S (ein Nachbar von node kommt erst dann in den Heap, wenn visited[node] vorher gesetzt wurde)
* falls u → fromNode &rarr start kein kürzester Pfad wäre, müsste u's Vorgänger in V\S sein
* sei dieser Vorgänger x <math>\notin</math> S, x <math>\not=</math> u
* sei wx das Gewicht der Kante x → u, dann sind die Kosten für start nach u gleich

Kosten(start_u) = Kosten(start_x) + wx

* Annahme des indirekten Beweises:

Kosten(start_fromNode) + wfromNode

* Behauptung des indirekten Beweises:
Es gibt einen anderen Pfad x, so dass die Kosten von start nach x geringer sind

* Da aber gilt:
fromNode <math>\in</math> S und x <math>\notin</math> S

* gilt (Induktionsvoraussetzung):
Kosten(start_fromNode) < Kosten(start_x)

* Falls Kosten(start_x) < Kosten(start_u) müsste x im Heap vor u kommen; daraus folgt, dass u nicht an der Spitze des Heaps sein kann

→ Widerspruch!

→ Die Behauptung, der Weg über x ist besser, kann nicht stimmen.

→ Korrektheit von Dijkstra ist somit bewiesen.

==== Wie kann man Dijkstra noch verbessern? ====

===== A*-Algorithmus =====

* Verbesserung von Dijkstra im typischen Fall, aber die Komplexität ist immer noch =(Elog v) im schlechtesten Fall (die Komplexität kann man nicht verbessern, aber die Laufzeit im typischen Fall).
* Schätzung für jeden Knoten für den restlichen Weg:
geschätzte Gesamtkosten: Kosten(start_node) + Restschätzung(node_ziel)
(exakte Kosten werden durch Dijkstra ermittelt)

'''Idee:'''
* Sortiere den Heap nach geschätzten Gesamtkosten.
* Satz:
Falls jede Schätzung den exakten Weg unterschätzt, werden die gleichen Pfade gefunden, wie
bei Dijkstra (also die korrekten kürzesten Pfade).
(Die Schätzung für den restlichen Weg muss man immer so einrichten, dass der tatsächliche Weg unterschätzt wird. Da keine Straße kürzer sein kann als die Luftlinie, ist die Luftlinie eine geeignete Annahme für A*.)
* Falls der falsche Pfad im Heap eher an die Spitze kommt als der richtige Pfad, findet der A*-Algorithmus den falschen Pfad.
* Wenn der Pfad zum Ziel an der Spitze des Heap ist, dann wird keine Restschätzung mehr benötigt, denn wenn der Zielknoten aus dem Heap herrauskommt, dann hat man die exakte Berechnung. Die Restschätzung ist in diesem Fall 0. Wenn die Schätzung zu klein ist, wird der exakte Weg immer größer sein und zuerst aus dem Heap herauskommen.

Graphen und Graphenalgorithmen

2008-06-25T09:08:24Z

Jschleic: /* Detektion von Zyklen */ acyclic2

Sandbox

2008-06-23T21:08:37Z

Jschleic: test TeX

Formel:
<math>
\Delta L_{sum} = \frac{\sqrt{L_R^4 \cdot \Delta L_B^2 + L_B^4 \cdot \Delta L_R^2}}{(L_B + L_R)^2}
</math>
---
<math>f(x)=\sqrt[4]{x}</math>

<math>f(x)=\frac{y}{x}</math> 
'''
hallo'''

There was a young lady from Riga,

who smiled as she rode on a tiger.

they returned from the ride

with the lady inside

and the smile on the face of the tiger.

{| border="1" cellspacing="0" cellpadding="9" align="center"
! hello
! is
|-
| a
| table
|-
|}
5

/ \

2 8

/ \ / \

1 4 7 9

This is a sentence.

Sortieren

2008-06-20T13:16:25Z

Jschleic: /* a.1) Algorithmus c ← merge(a,b) */ Code als ein block

----
== Laufzeitmesung in Python ==

Verwendung der '''timeit-Bibliothek''' für die Hausaufgabe.

* Importiere das timeit-Modul: <tt>import timeit</tt>
* Teile den Algorithmus in die Initialisierungen und den Teil, dessen Geschwindigkeit gemessen werden soll. Beide Teile werden in jeweils einen (mehrzeiligen) String eingeschlossen:

+--------+ +----+ setup = """ prog = """
| algo | --> |init| +----+ +----+
| | +----+ |init| |prog|
| | +----+ +----+
| | +----+ """ """
| | --> |prog|
+--------+ +----+

* aus den beiden Strings wird ein Timeit-Objekt erzeugt: <tt>t = timeit.Timer(prog, setup)</tt>
* Frage: Wie oft soll die Algorithmik wiederholt werden
:z.B. N = 1000
* Zeit in Sekunden für N Durchläufe: <tt>K = t.timeit(N)</tt>
:Zeit für 1 Durchlauf: K/N

----
3.Stunde am 16.04.2008

==Sortierverfahren==

=== 1.Motivation ===
'''Def:'''
Ein Sortierverfahren ist ein Algorithmus, der dazu dient, eine Liste von Elementen zu sortieren.
* Literatur, ride Sortierverfahren; Bubblesort 1956, Quicksort 1962. Librarysort 2004

'''Anwendungen'''
* Sortierte Daten sind häufig Vorbedingungen für Suchverfahren (Speziell für Algorithmen mit Log(N) Komplexität)
* Darstellung von Daten gemäß menschlicher Wahrnehmung
* Bemerkung: aus programmiertechnischer Anwendungssicht hat das Sortierproblem an Relevanz verloren da
** Festplatten / Hauptspeicher heute weniger limitierenden Charakter haben, so dass komplizierte, speicher-sparende Sortieralgorithmen nur noch in wenigen Fällen benötigt werden.
** gängige Programmiersprachen heute typunabhängige Algorithmen zur Verfügung stellen. Der Programmierer braucht sich deshalb in den meisten Fällen nicht mehr um die Implementierung von Sortieralgorithmen zu kümmern. In C/C++ sorgen dafür beispielsweise Methoden aus der [http://de.wikipedia.org/wiki/Standard_Template_Library STL]

=== 2. Vorraussetzungen/ Spielregeln ===
- Mengentheoretische Anforderungen a Elemente
- Datenspeicherung Array / Liste
- Charakterisierung von Algorithmen
-- Komplexität (Speicher/ Laufzeit)
-- Stabilität
-- allg. Eigenschaften (Rekursivität/ Vergleich/ Methoden)

==== 2.1 Mengentheoretische Anforderungen====
Definition Totale Ordnung/ Total gordnete Menge:
Eine Totale Ordnung / Total geordnete Menge ist eine binäre Relation
<math>R \subseteq M \times M</math> über einer Menge <math>M</math>, die transitiv, antisymmetrisch und total ist. 

<math>R</math> sei dargestellt als infix Notation <math>\le </math> dann, falls M total geordnet, gilt
<math> \forall a,b,c \ \epsilon M </math> 
(1) <math>a \le b \bigwedge b \le a \Rightarrow a=b </math> (antisymmetrisch) 
(2) <math>a \le b \bigwedge b \le c \Rightarrow a \le c </math> (transitiv) 
(3) <math>a \le b \bigvee b \le a </math> (total) 
Bemerkung: aus (3) folgt <math> a \le a </math> (reflexiv) 

''Hab in der Wiki eine gute Seite dazu gefunden [http://de.wikipedia.org/wiki/Ordnungsrelation'' Ordnungsrelation]

==== 2.2 Datenspeicherung ====
a) Array ---
+---+---+---+---+---+---+---+---+---+
|///| | | | | | | |///| Einfügen oder Löschen
+---+---+---+---+---+---+---+---+---+
\________________ ____________________/
\/
N
b) Vekettete Liste
+---+ +---+ +---+
| |-> | |-> | |-> Z
+---+ +---+ +---+

Datenelement zeigt auf das Nächste
Nachteil: lineares array (Adressierung bsp: 10 > 9)

==== Charakterisierung der Effizienz von Algorithmen ====

:(a) Komplexität O( 1), O(n), etc. wird in Kapitel [[Effizienz]] erklärt.
:(b) Zählen der notwendigen Vergleiche
:(c) Messen der Laufzeit mit 'timeit' (auf identischen Daten)

'''Rekursive Beziehungen'''
zerlegt die ursprünglichen Probleme in kleinere Probleme und wendet den Algorithmus auf die kleineren Probleme an; daraufhin werden die Teilprobleme zur Lösung des Gesamtproblems verwendet.
d.h. Laufzeit (operativer Vergleich) für N Eingaben hängt von der Laufzeit der Eingaben für die Teilprobleme

'''Aufwand'''

(i) rekursives/ lineares Durchlaufen der Eingabedaten, Bearbeitung einzelner Elemente

C(N)= C(N-1)+ N ; N>1, C(1)= 1 +---+---+---+---+---+---+---+---+---+
= C(N-2) +(N-1)+ N | 7 | 3 | 2 | 5 | 6 | 8 | 1 | 4 | 2 |
= C(N-3) + (N-2) + (N-1) + N +---+---+---+---+---+---+---+---+---+
= ... ________________________/
= C(1) + 2+...+(N-1) +N /
+---+---+---+---+---+---+---+---+---+
N(N+1) N² | 1 | 3 | 2 | 5 | 6 | 8 | 7 | 4 | 2 |
= ----- ~ -- +---+---+---+---+---+---+---+---+---+
2 2

(ii) rekursives halbieren der Menge der Eingabedaten

C(N)= C(N/2)+1 ; N>1, C(1)=0
Aus Gründen der Einfachheit sei N = 2n

C(N)= C(2^n)= C(<math>2^{n-1}</math>) + 1

= C(<math>2^{n-1}</math>) + 1 + 1
= ...

= C(<math>2^0</math>) + n
= n
= <math>log_2 N</math>
+---+---+---+---+-|-+---+---+---+---+
| | | | | | | | | |
+---+---+---+---+-|-+---+---+---+---+
+---+---+---+---+
| | | | |
+---+---+---+---+
+---+---+ +---+
| | | -> | |
+---+---+ +---+

(iii) rekursives halbieren, lineare Bearbeitung, jedes Elements

C(N)= 2C(N/2)+ N; N>1, C(1)= 0
Sei N= <math>2^n</math>
C(N)= C(<math>2^n</math>)= 2C (<math>2^{n-1}</math>)+ <math>2^n</math>
<=> <math> \cfrac{C(2^n)}{2^n}</math> = <math> \cfrac{2C(2^{n-1})}{2^{n-1}}</math>

= <math> \cfrac{2C(2^{n-2})+2^{n-1}}{2^{n-1}}+1</math>
= <math> \cfrac{2C(2^{n-2})}{2^{n-2}}+1 +1</math>
=...
= n
<=> C(<math>2^n</math>)= <math>2^n</math> * n
<=> C= N log<math>_2</math>N

'''(b) Stabilität'''
Definition: stabiles Sortierverfahren
Ein Sortierverfahren heißt stabil falls die relative Reihenfolge gleicher Schlüssel M der Ausgangsdaten beibehält.

Beispiel:

(3,7) / (1,8)
(4,2) /stabil (2,2)
(4,1) / (3,7)
(4,2)
(2,2) \ ....
(1,8) \ nicht stabil (4,1)
\ (4,2)

==3. Sortierverfahren==

insertion sort N²
selection sort N²
Bubblesort N log N
Quicksort N log N

'''3.1 Selection Sort'''

a) Algorithmus

for i= 1 to N-1
min <- 1;
for j= i+1 to N
if a[j]< a min
min <- j
swap(a[min], a[i]) //Elemente links von i befinden sich an endgültiger Position

<math> \downarrow</math>
+---+---+---+---+---+---+---+
| S | O | R | T | I | N | G |
+---+---+---+---+---+---+---+
i
+---|---+---+---+---+---+---+
| G | O | R | T | I | N | S |
+---|---+---+---+---+---+---+
i
+---+---|---+---+---+---+---+
| G | I | R | T | O | N | S |
+---+---|---+---+---+---+---+
i
+---+---+---|---+---+---+---+
| G | I | N | T | O | R | S |
+---+---+---|---+---+---+---+
i
+---+---+---+---+---+---+---+
| G | I | N | O | T | R | S |
+---+---+---+---+---+---+---+
..

'''b) Komplexität'''
- Anzahl Vergleiche

C(N)= C(N-1)+ (N-1)
= C(N-2)+ (N-2)+ (N-1)
...
= 1+2 + ...+ (N-2)+ (N-1)
= <math>\cfrac{(N-1)N}{2}</math> <math>\approx \cfrac{(N^2)}{2}</math>
- Anzahl Austauschoperationen

C(N)= C(N-1)+1; C(1)= 0; n>1
= N-1

'''c) Stabilität'''

Im Allg. zur Prüfung a[j]<a[min] ist Selection Sort stabil
falls <math>\le</math> nicht.

'''3.2 Insertion Sort'''
- Teil der Übung
- Erweiteung: Shell sort

----
4. Stunde, am 17.04.2008
 
(Fortsetzung der Stunde vom 16.04.2008)
 

=== Mergesort ===
==== a) Algorithmus ====

Zugrunde liegende Idee:
* "Teile und herrsche"-Prinzip (divide and conquer) zur Zerlegung des Problems in Teilprobleme.
* Zusammenführen der Lösungen über Mischen (merging): "two-way" oder "multi-way".

==== a.1) Algorithmus <tt>c ← merge(a,b)</tt> ====

c = merge(a,b) ← { # Kombination zweier sortierter Listen a[i] und b[j]
# zu einer sortierten Ausgabeliste c[k]
a[M+1] ← maxint
b[N+1] ← maxint

for k ← 1 to M+N
if a[i] < b[j]
c[k] > a[i]
i ← i+1
else
c[k] ← b[j]
j ← j+1
}

==== a.2) '''rekursiver Mergesort''' ====

mergesort(m) ← { #m ist ein Array
if |m| > 1 #True, wenn m mehr als 1 Element hat.
a ← mergesort(m[1:<|m|/2])
b ← mergesort(m[(|m|/2)+1:|m|])
c ← merge(a,b)
return(c)
else
return(m)
}

(Eine In-place-Implementierung siehe bei Sedgewick.)

Bei der Sortierung mit Mergesort wird das Array immer in zwei Teile geteilt. → Es entsteht ein Binärbaum der Tiefe <math>lgN</math>.

Gegebene unsortierte Liste: [S,O,R,T,I,N,G]
Die Teile werden bei jedem Schritt paarweise gemischt.

Schritt 0:
S 0 R T I N G S O R T I N G #Arraylänge: N/8
Schritt 1: \ / \ / \ / /
OS RT IN G OS RT IN / #Arraylänge: N/4 Vergleiche: N/4 * 4
Schritt 2: \ / \ /
ORST GIN ORST GIN #Arraylänge: N/2 Vergleiche: N/2 * 2
\ /
Schritt3: \ /
GINORST GINORST #Arraylänge: N Vergleiche: N

Zeitkomplexität: <math>C(N) - N \cdot lgN</math>

==== b) Komplexität ====
Komplexität: <math>C(N) = 2 \cdot C \left( \frac{N}{2} \right) + N = N \cdot log_2 N </math> (für N = <math>2^n</math> )

Erklärungen zur Formel:
* <math> C \left(\frac{N}{2}\right) </math>: "für jede Hälfte des Arrays"
* <math> +N </math>: für das Zusammenführen
* N Vergleiche pro Ebene
* Insgesamt gibt es <math> log_2 N </math> Ebenen.

==== c) Weitere Eigenschaften von MergeSort ====

* Mergesort ist '''stabil''', weil die Position gleicher Schlüssel im Algorithmus <tt>merge(a,b)</tt> nicht verändert wird - wegen <tt>„<”</tt> hat das linke Element Vorrang.
* Mergesort ist '''unempfindlich gegenüber der ursprünglichen Reihenfolge der Eingabedaten'''. Grund dafür ist
** die vollständige Aufteilung des Ausgangsarrays in Arrays der Länge 1 und
** dass <tt>merge(a,b)</tt> die Vorsortierung nicht ausnutzt, d.h. die Komplexität von <tt>merge(a,b)</tt> ist sortierungsunabhängig.
* Diese Eigenschaft ist dann unerwünscht, wenn ein Teil des Arrays oder gar das ganze Array schon sortiert ist. Es wird nämlich in jedem Fall das ganze Array neu sortiert.
 

=== Quicksort ===

* Quicksort wurde in den 60er Jahren von Charles Antony Richard Hoare [http://de.wikipedia.org/wiki/C._A._R._Hoare] entwickelt. Es gibt viele Implementierungen von Quicksort, vgl. [http://de.wikipedia.org/wiki/Quicksort].
* Dieser Algorithmus gehört zu den "Teile und herrsche"-Algorithmen (divide-and-conquer) und ist der Standardalgorithmus für Sortieren.

==== a) Algorithmus für <tt>quicksort</tt> ====

quicksort(l,r) ← { #l: linke Grenze, r: rechte Grenze des Arrays
#Das Array läuft also von l bis r (a[l:r])
if r > l
i ← partition(l,r) #i ist das Pivot-Element
quicksort(l,i-1) #quicksort auf beide Hälfte des Arrays anwenden
quicksort(i+1,r)
}

Dieser Algorithmus wird rekursiv für zwei Teilstücke links und rechts des Pivot-Elements aufgerufen. Das Pivot-Element ist nach diesem Schritt an der richtigen Position (d.h. links von der Stelle <tt>i</tt> stehen nur kleinere, rechts von <tt>i</tt> nur größere Elemente als das Pivot-Element).
Die Methode <tt>partition</tt> sorgt dafür, dass diese Bedingung erfüllt ist.

==== b) Algorithmus für <tt>partition</tt> ====
Aufgabe: Ordne <tt>a</tt> so um, dass nach der Wahl von <tt>i</tt> (Pivot-Element) gilt:
# <math>a[i]</math> ist sortiert, d.h. dieses Element ist am endgültigen Platz.
# <math>\forall x \in \left\{ a \left[ l \right] , ... a \left[ i-1 \right] \right\} : x \leq a \left[ i \right]</math>
# <math>\forall x \in \left\{ a \left[ i+1 \right], ... a \left[ r \right] \right\} : x \geq a \left[ i \right]</math>

* a[i] heißt Pivot-Element (p)

l r
+---+---+---+---+---+---+---+---+---+
Array: | | | | |\\\| | | | |
+---+---+---+---+---+---+---+---+---+
\______ _____/ i \______ _____/
\/ \/
<=a[i] >=a[i] (a[i] ist das Pivot-Element)

i ← partition(l,r) ← {
p ← a[r] #p: Pivot-Element. Hier wird willkürlich das rechteste
# Element als Pivot-Element genommen.
i ← l-1 #i und j sind Laufvariablen
j ← r

repeat
repeat
i ← i+1 #Finde von links den ersten Eintrag >= p
until a[i] >= r

repeat
j ← j-1 #Finde von rechts den ersten Eintrag < p
until a[j] <= r
swap(a[i], a[j])
until j <= i #Nachteile: p steht noch rechts
swap(a[i], a[j]) #Letzter Austausch zwischen i und j muss
#zurückgenommen werden
swap(a[i], a[r]) #Das Pivot-Element wird an die korrekte Position gesetzt.
return(i)
}

p
+---+---+---+---+---+---+---+---+---+
Array: | | | | |\\\| | | | |
+---+---+---+---+---+---+---+---+---+
-------> i>p j <-----------------

"repeat" bis sich die Zeiger treffen oder einander überholt haben.

l,i --> <-- j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | S | O | R | T | I | N | G | E | X | A | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | S | O | R | T | I | N | G | E | X | A | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i j r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | O | R | T | I | N | G | E | X | S | M | P | L | E |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

j i r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | R | E | T | I | N | G | O | X | S | M | P | L | E | --> Hier wird die
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Schleife verlassen.

j i r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | R | T | I | N | G | O | X | S | M | P | L | E | 1.swap
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

i r
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A | A | E | E | T | I | N | G | O | X | S | M | P | L | R | 2.swap
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

* Bemerkungen zur gegebenen Implementierung:
# Die gegebene Implementierung benötigt ein Dummy-Minimalelement (für den Fall <tt>i=1</tt>).
#* Dieses Element ist durch zusätzliche <tt>if</tt>-Abfrage vermeidbar, aber die <tt>if</tt>-Abfrage erhöht die Komplexität des Algorithmus (schlechte Performanz).
# Sie ist uneffizient für (weitgehend) sortierte Arrays, da sich folgende Aufteilung für die Partitionen ergibt:
#* Erste Partition: <tt>[l,i-1]</tt>, zweite Partition: <tt>[i+1,r]</tt>
#* Die erste Partition umfasst <tt>N-1</tt> Elemente. Die zweite Partition ist leer (bzw. sie existiert nicht), weil das Pivot-Element <tt>p = r</tt> gewählt wurde.
#* Das Array wird elementweise abgearbeitet. → <tt>N</tt> einzelne Aufrufe ⇒ Zeitkomplexität: <math>\approx\frac{N^2}{2}</math>.
# Für identische Schlüssel sollten beide Laufvariablen stehen bleiben (daher "<tt><math>\leq</math></tt>"), um ausgeglichene Zerlegungen bei vielen identischen Schlüsseln zu gewährleisten.
# Bei der gegebenen Implementierung tauscht auch gleiche Elemente aus.
# Für identische Schlüssel können die Abbruchbedingungen verbessert werden (siehe Sedgewick, Seite 150).

==== c) Komplexität ====

<math>C(N) = (N+1) + \frac{1}{N} \sum_{k=1}^{N} \left[ C(k-1) + C(N-k) \right]</math> für <math> N>1;\, C_1 = C_0 =0 </math>

Anmerkungen zur Formel:
# <math>(N+1)</math>: Vergleiche für jeden Aufruf
# <math>k</math>: Teilungspunkt
# <math> \frac{1}{N} \sum_{k=1}^{N} \left[ C(k-1) + C(N-k) \right] = 2 \frac{1}{N} \sum_{k=1}^{N} C(k-1) </math> ist der mittlere Aufwand über alle möglichen Zerlegungen.

 

<math>
C(N) = (N+1) + \frac{2}{N} \sum_{k=1}^{N} C(k-1) </math> <math>\overset{\cdot N}{\longleftrightarrow} </math>
 

<math>
N \cdot C(N) = N \left[ (N+1) + \frac{2}{N} \sum_{k=1}^{N} C(k-1) \right] \overset{-\, (N-1) \cdot C(N-1)}{\longleftrightarrow} </math>
 

<math>
N \cdot C(N) - (N-1) \cdot C(N-1) = N(N+1) - (N-1) N + 2 \sum_{k=1}^{N} C(k-1) - 2 \sum_{k=1}^{N} C(k-1) </math>
 

<math>
= N(N+1) - (N-1) N + 2 \cdot C(N-1) \longleftrightarrow </math>
 

<math>
N \cdot C(N) = N(N+1) - (N-1) N + 2 \cdot C(N-1) + (N-1) \cdot

C(N-1) = 2N + (N+1) \cdot C(N-1) \overset{/N(N+1)}{\longleftrightarrow} </math>
 

<math>
\frac{C(N)}{N+1} = \frac{C(N-1)}{N} + \frac{2}{N+1} </math>
 

<math>
= \frac{C(N-2)}{N-1} + \frac{2}{N} + \frac{2}{N+1} </math>
 

<math>
= \frac{C(N-3)}{N-2} + \frac{2}{N-1} + \frac{2}{N} + \frac{2}{N+1} </math>
 

<math>
= ... = </math>
 

<math>
= \frac{C(2)}{3} + 2 \sum_{k=3}^{N} \frac{1}{k+1} \approx 2 \sum_{k=3}^{N} \frac{1}{k+1} \approx 2 \int_1^N \frac{1}{k} dk = 2 \cdot ln N
</math>
 
Für sehr große N gilt:
<math>\approx 2 \sum_{k=1}^{N} \frac{1}{k}</math> beziehungsweise <math> \geq 2

\sum_{k=1}^{N} \frac{1}{k}</math>
 
Mittlere Komplexität:
<math>C(N) = 2(N+1) \cdot lnN \approx 2N \cdot lnN </math>
 

==== d) Verbesserungen des Quicksort-Algorithmus ====

===== Beseitigung der Rekursion =====
* Eine Verbesserung beseitigt die Rekursion durch Verwendung eines Stacks. Nach jeder Partitionierung wird das größere Teilintervall auf dem Stack abgelegt und das kleinere Teilintervall direkt weiterverarbeitet.

quickSort(l,r) ← {
#initialize stack
push([l,r])
repeat
if r > l:
i ← partition(l,r)
if (i-l) > (r-i):
push([l,i-1])
l ← i+1
else:
push([i+1,r])
r ← i-1
else:
[l,r] ← pop()
until stackempty()
}

+---+---+---+---+---+---+---+
| Q | U | I | C | K | S | O |
+---+---+---+---+---+---+---+

+---+---+---+===+---+---+---+
| K | C | I |=O=| Q | S | U |
+---+---+---+===+---+---+---+
\_________/
push

+---+===+---+
| C |=I=| K |
+---+===+---+
\_/
push

+===+
|=C=|
+===+

+===+
|=K=|
+===+

+---+---+===+
| Q | S |=U=|
+---+---+===+

+---+===+
| Q |=S=|
+---+===+

+===+
|=Q=|
+===+

+---+---+---+---+---+---+---+
| C | I | K | O | Q | S | U |
+---+---+---+---+---+---+---+

===== Alternatives Sortieren kleiner Intervalle =====
* Für kleine Intervalle ist Insertion Sort effizienter als "Teile und herrsche"
* Modifikation:
if (r-l) <= K:
insertion(l,r)
else:
#wie bisher
* für <tt>M = 3</tt>: explizites Sortieren von 3 Elementen. - Sortieren von 3 Datensätzen. Idee:
# Stelle sicher, dass <tt>a[1]</tt> und <tt>a[2]</tt> relativ zueinander sortiert sind.
# Falls <tt>a[1]</tt> jetzt noch größer als <tt>a[3]</tt> ist, so ist <tt>a[3]</tt> das kleinste Element und muss nach vorne geschrieben werden. Das heißt: <tt>swap(a[i], a[3])</tt>. Danach steht das kleinste Element in <tt>a[1]</tt>.
# Jetzt kann es entweder sein, dass
#* in 2. kein swap durchgeführt wurde und <tt>a[3]</tt> eventuell zwischen <tt>a[1]</tt> und <tt>a[2]</tt> liegen könnte, oder
#* der <tt>swap</tt> durchgeführt wurde und die Reihenfolge von <tt>a[2]</tt> und <tt>a[3]</tt> jetzt falsch ist.
# Falls <tt>a[2] > a[3]</tt>, dann <tt>swap(a[2], a[3])</tt>. Das löst beide in 3. genannten Probleme.

* Der Algorithmus zum Sortieren von drei Datensätzen:
a = sort2(a) ← {
if a[1] > a[2]:
swap(a[1], a[2])
if a[1] > a[3]:
swap(a[1], a[3])
# Man könnte hier
# swap(a[2],a[3])
# return
# einfügen und eine if-Abfrage sparen.
if a[2] > a[3]:
swap(a[2], a[3])
}

===== Günstige Selektion des Pivot-Elements =====
* Das Pivot-Element könnte geschickter gewählt werden. Methode: Median von drei Elementen: Bestimme den Median der ersten, mittleren und letzten Elements eines Arrays und verwende der Median als Pivot-Element
* Diese Methode minimiert die Häufigkeit des Auftetens des ungünstigsten Falles.
 
[[Special:Contributions/147.142.207.188|147.142.207.188]] 19:31, 23 April 2008 (UTC)

Generizität

2008-06-17T08:56:57Z

Jschleic: Gliederung des Artikels

Ziel von generischer Programmierung ist es, Algorithmen und Datenstrukturen so zu entwerfen und zu implementieren, dass sie möglichst vielvältig verwendbar sind.

'''Gemeint sind :'''

*verschiedene Anwendungen
*mit vielen Kombinationsmöglichkeiten
*als wiederverwendbare Bibliothek

--> ''' ohne Neuimplemenation '''
*Code austauschen in Bibliotheken

===Beispiel : ===
Kopieren eines Containers

def copyArray(a):
r =[]
for k in a
r.append(k)
return k

class Node :
def__init__(self,data,next)
self.data = data
self.next = next
return k

def copyArrayToList(a) :
if len(a) == 0 : return None
first = last = Node (a[0], None)
for k in a[1:] :
last.next = Node(k, None)
last = last.next

def copyListToArray(l):
r = []
while l is not in None :
r.append(l.data)
l = l.next
return r

==== '''Beobachtung''' : ====

Für '''N Datenstrukuren''' ist der Implementaionsaufwand <math>O({N^2})</math>.
Alle Funktionen machen das gleiche mit uninteressanten Unterschied

'''Verbesserung durch Verallgemeinerung zweier Aspekte''' :

*Navigation durch die Quelldaten
*Aufbauen der Zieldatenstruktur

'''Vereinheitlichung der Zieldatenstruktur :'''
*standardisierte Funktion "append"
*Array hat sie schon
*Liste : definiere Klasse DoublyLinkedList

class SentinelTag : pass # keine Daten

class DoublyLinkedNode:
def__init__(self,data = sentinelTag(), next = None)
self.data =data
if next is None:
self.prev = self.next = self
else:
self.next = next
self.prev = next.prev
next.prev.next = self
next.prev = self

def isSentinel(self) : return isinstance(self.data, SentinelTag)

class DoublyLinkedList : # Realisiert doppelt verbundene kreisförmige Kette mit Seninel als Anker

def__init__(self):
self.sentinel = DoublyLinkedNode()
self.size = 0

def__len__(self): return self.size #len(l)

def append(self, value):
DoublyLinkedNode(value, self.sentinel)
self.size += size

def__iter__(self):
return ListIterator(self.sentinel.next)

def reverseIterator(self):
return ListIterator(self.sentinel.prev)

===Iteratoren===
Navigation in der Quelldatenstruktur(Iteratoren) soll für alle Datenstrukturen funktionieren

*Objekt, das auf ein Element des Containers zeigt
*Zum nächsten Element weiter rücken kann
*anzeigt, wenn das Ende der Sequenz erreicht ist

def genericCopy(quelle, ziele) :
for k in quelle :
ziel.append(k)
return ziel

liste = genericCopy(array, DoublyLinkedList()) # Statt copyArrayToList
array2 = genericCopy(array,[]) # Statt copyArray
array3 = genericCopy(liste,[]) # Statt copyListToArray

class ListIterator:
def__init__(self, node):
self.node = node
def next(self):
if self.node.isSentinel():
raise StopIteraion() #Python Konvention
v = self.node.data
self.node = self.node.next # zeigt Ende der Sequenz
return v # Pythonkonvention, gebe vorigen Wert zurück

def__iter__(self):
return ListIterator(self.node) # Pythonkonvention, Kopie des Iterators erzeugen

'''besser stattdessen''' :

self__class__(self.node)

'''Was tut Python bei''' " for k in quelle":

iter = quelle__iter__()
try :
while True :
k = iter.next()
... # Schleifeninhalt
except StopIteration: pass

'''Rückwärts kopieren :'''

class ReverseListIterator(ListIterator)
def next(self):
if self.node isSentinel(): raise StopIteration()
v = self.node.data
self.node = self.node.prev
return v

revArray = genericCopy(list, reverseIter(), []),
revList = genericCopy(reversed(array), DoublyLinkedList())

===Funktoren===
'''Verallgemeinerung auf Funktionen die " etwas tun":'''

<code>def sumArray(a):
s = 0
for k in a :
s+=a # s = add(s,k)
return s </code>

def maxList(l):
m = -1111111111111111
while not l isSentinel:
m = max(m, l.data) # max ist eingebaute Funkion in Python
l =l.next

'''Zur Verallgemeinerung werden Funktoren eingerichtet:'''

*Funktor muss "callable" sein : falls f Funktor ist, funktioniert v = f(a1, a2,...)
*Funktion, oder Objekt bei dem die Funktion __call___ definiert ist.

def doSomethingGeneric(functor,iterator, intial):
for k in iterator
initial = functor(initial, k)
return initial

'''Statt maxList:'''

m = doSomethingGeneric(max,list -11111111111)

'''Statt sumArray :'''

def add(x,y): return x + y
s = doSomethingGeneric(add, array,o)

'''Statt genericCopy :'''

def append(x,y):
x.append(y)
return x

array4 = doSomethingGeneric(append, array[])

'''doSomethingGeneric'''() gibt es in vielen Programmiersprachen

*in Python : reduce
*in C++ : accumulate
...funktionale Sprachen (Lisp, Haskell...)

'''verwandte generische Funktionen'''

map:

[x1, x2,...] --> [f(x1),f(x2),...] # Funktor mit einem Argument

===Offered Interface versus Required Interface===

'''Interface:'''
*standardisierte Schnittstelle zwischen Algorithmen und Datenstruktur

====Offered Interface:====

*Funktionalität, die eine Datenstruktur anbietet.
*Die Datensruktur sollte möglichst vielseitig sein.

'''z.B. PythonList:'''

* dynamisches Array
* stack
* deque
* linkedList

*standardisiert durch abstrakte Datentypen

====Required Interface:====

*Funktionalität, die Algorihmus benutzt
*das '''required Interface''' ist meist weniger als '''das offered Interface'''

z.B.:

'''RI''' lesender Zugriff
'''OI''' lesender Zugriff schreibender Zugriff Konstruktor remove...

* standardisiert über Konzepte
* ADT sind Sammlungen zusammengehörender Konzepte
* RI sollten minimal sein

====Konzepte ( + Hierarchie)====

* copy Constructible ( P: copy.deepcopy)
* Default Constructible (v1 = v.__class__() ist aufrufbar ) # DoublylinkedNode
* EqualityComparable('=='), LessThanComparable('<')
* ThreeWayComparable(__cmp__ ist aufrufbar)
* Indexable("a[k]", k ist Integer)
* Mapping("a[key]", key ist arbitrary)
* Hashable(__hash__ für key)

* Iteratoren : Forward(next), BidirektionalIterator(next, prev), RandomAccessIterator(nex(k))

* Container : Sequence # Array

====Mathematische Konzepte :====

Addable(__add__)
Subtractable(__sub__)
Multiplyable(__mul__)
Dividable(__div__)

'''Ein offered Interface is mehr als ein required Interface.'''

Prioritätswarteschlangen

2008-05-28T10:44:11Z

Jschleic: /* Heap */ Größe der Grafik geändert

==Prioritätswarteschlangen==
===Heap===
*Datenstruktur optimiert für Prioritätssuche
*Def: ein linkslastiger Binärbaum ist ein Baum mit <math>d(node.left) \geq d(node.right)</math>

Ein Heap ist ein linkslastiger, perfekt balancierter Baum.

Man kann einen Heap leicht als Array implementieren, wie folgende Grafik veranschaulicht:
[[Image:heapArray.png|left|400px]]

Prioritätswarteschlangen

2008-05-28T10:40:02Z

Jschleic: heap - first edit

File:HeapArray.png

2008-05-28T10:34:42Z

Jschleic: Man kann einen Heap-Baum als Array abspeichern, indem man die Elemente wie gezeigt durchnummeriert.

Man kann einen Heap-Baum als Array abspeichern, indem man die Elemente wie gezeigt durchnummeriert.