Effizienz von Algorithmen - Technische Fakultät - Universität Bielefeld

Effizienz von Algorithmen Asymptotische Effizienz-Analyse Exkurs Beispiel zur Effizienanalyse Ausn 

Algorithmen und Datenstrukturen I 

- Effizienz von Algorithmen - 

Alexander Sczyrba 

Technische Fakultät 

asczyrba@TechFak.Uni-Bielefeld.DE 

Vorlesung, Universität Bielefeld, Winter 2013/2014 

1 / 130 


Kapitel 5 - Effizienz von Algorithmen 

1 Effizienz von Algorithmen 

2 Asymptotische Effizienz-Analyse 

3 Exkurs 

4 Beispiel zur Effizienanalyse 

5 Ausnutzen von erwarteten Daten-Eigenschaften 

2 / 130


Kapitel 5: Effizienz von Algorithmen 

Ziele des Kapitels 

Einführung in asymptotische Notationen 

asymptotische Effizienzanalyse (worst/average case) 

Wie erfasst man die Problemkomplexität? 

Was sind sinnvolle Programmoptimierungen? 

asympt. Klasse versus 

konstante Faktoren 

Analyse diverser Sortierverfahren (insertion-sort, 

tree-sort, merge-sort, smooth-sort, 

counting-sort)) 

Einfluss der Laziness auf die Effizienz 

3 / 130 


Asymptotische Notationen 


Wir betrachten das Polynom 

p(x) = 2x 3 + 1000x 2 − 5x + 12 

Für große x gilt: 

der Beitrag 2x 3 dominiert die anderen Beiträge, 

irgendwann auch 1000x 2 . 

Für das weitere Wachstum gilt: 

p(2 · x) ≈ 8 · p(x) 

dafür spielt der Faktor 2 bei x 3 keine Rolle. 

4 / 130



Oft interessiert in der Mathematik nur das grobe Wachstumsverhalten 

einer Funktion 

z.B. bei der Abschätzung von Fehlern 

(Approximation, fehlerbehaftete Eingaben) 

z.B. bei der Effizienzanalyse von Algorithmen – siehe Folien zu 

Strategien des Problemlösens. 

Das “grobe” Verhalten muss natürlich exakt definiert sein . . . 

5 / 130 



Dazu werden asymptotische Notationen O(n), Ω(n) (Omega), Θ(n) 

(Theta) eingeführt. 

Sie beschreiben asymptotische Effizienzklassen. 

(Sie haben aber nicht per se etwas mit Algorithmen zu tun, sondern 

sind mathematisch definierte Klassen von Funktionen mit ähnlichem 

Wachstum für n → ∞.) 

Die O-Notation wurde von Paul Bachmann 1892 eingeführt und 

später von Edmund Landau weiter bekannt gemacht. Daher wird sie 

auch manchmal als Landau-Notation bezeichnet. 

Seien f , g : N −→ R + . 

6 / 130



O(g) = {f | ∃C > 0, ∃n 0 ≥ 0, ∀n ≥ n 0 : 0 ≤ f (n) ≤ Cg(n)} 

d.h. f gehört zur Klasse O(g), wenn es ab n 0 durch C · g(n) nach 

oben beschränkt ist. g(n) soll dabei möglichst einfach beschrieben 

sein. 

Beispiel: 

f (n) = 3n 4 + 5n 3 + 7 log 2 n 

f (n) ∈ O(n 4 ), denn 

3n 4 + 5n 3 + 7 log 2 n ≤ 3n 4 + 5n 4 + 7n 4 = 15n 4 

für n ≥ 1 

Wir können C = 15 und n 0 = 1 wählen. 

7 / 130 



Ebenso gilt: 

f (n) ∈ O(n 5 ), schon weil 15n 4 ≤ 15n 5 gilt. 

Dagegen gilt: 

f (n) /∈ O(n 3 ), denn es gibt keine Konstante C, so dass 

3n 4 ≤ C · n 3 für alle n ab irgendeinem n 0 . 

Es müsste ja C ≥ 3n gelten. 

8 / 130



Aus dem Obigen folgt: 

O(1) O(n) O(n 2 ) O(n 3 ) . . . 

Die Aussage f ∈ O(n 3 ) ist möglicherweise ausreichend für den 

gegebenen Anlass, aber nicht unbedingt genau. 

Es könnte ja sein, dass auch f ∈ O(n 2 ) gilt, und das wäre dann 

genauer. 

9 / 130 



Die Theta-Klassen 

Die Θ-Klassen begrenzen das Wachstumsverhalten nach oben und 

nach unten. 

Θ(g) = { f | (∃n 0 , c, C)(∀n ≥ n 0 ) cg(n) ≤ f (n) ≤ Cg(n) } 

Ist f ∈ Θ(g), so heißt g asymptotische Schranke von f . 

Wir finden für f (n) = 3n 4 + 5n 3 + 7 log 2 n 

f (n) ∈ Θ(n 4 ) mit den Konstanten C = 15, c = 3 und n 0 = 1 

10 / 130



Im Unterschied zu den O-Klassen gilt bei den Θ-Klassen keine 

Inklusion. 

f (n) /∈ Θ(n 5 ), denn es gibt kein c, n 0 mit c · n 5 ≤ 3n 4 + 5n 3 + 7 log 2 n 

für alle n ≥ n 0 

Aufgepasst: 

Zu gegebenem n 0 lässt sich immer ein c finden mit c · n 5 0 ≤ n4 0 (etwa 

c = 1 n 0 

), aber dies gilt eben nie für alle n ≥ n 0 . 

11 / 130 



Asymptotisch gesehen, betrachten wir 

f (n) = 3n 4 + 5n 3 + 7 log 2 n als gleichwertig mit n 4 . 

Die asymtotischen Effizienklassen haben ungeheuer praktische 

Eigenschaften. 

12 / 130



Eigenschaften der asymptotischen Klassen 

f ∈ Θ(f ) (Reflexivität) (1) 

f ∈ Θ(g) ∧ g ∈ Θ(h) ⇒ f ∈ Θ(h) (Transitivität) (2) 

f ∈ Θ(g) ⇒ g ∈ Θ(f ) (Symmetrie) (3) 

cf ∈ Θ(f ) (4) 

n a + n b ∈ Θ(n a ) für a > b (5) 

log a n ∈ Θ(log b n) (6) 

13 / 130 



Zur Übung sollte man einiger dieser Eigenschaften beweisen. 

Später geht man ganz routinemäßig damit um – man nutzt 

“Rechenregeln” der Form 

anstelle der Aussage 

O(f ) · O(g) = O(f · g) 

h 1 ∈ O(f ) ∧ h 2 ∈ O(g) ⇒ h 1 · h 2 ∈ O(f · g) 

(Natürlich meint (f · g)(n) = f (n) · g(n)) 

14 / 130



In vielen Büchern wird kaum Θ, sondern hauptsächlich O-Notation 

verwendet. 

Man sucht die kleinste mögliche O-Klasse anzugeben, das heißt 

f ∈ O(g) meint f ∈ Θ(g), 

verzichtet aber auf den expliziten Nachweis der unteren Schranke. 

15 / 130 



Untere und obere asymptotische Schranken 

Manchmal gibt man untere und obere Schranken getrennt an, d.h. die 

O-Notation wird ergänzt durch Ω: 

Ω(g) = { f | (∃n 0 , c)(∀n ≥ n 0 ) cg(n) ≤ f (n) } (7) 

In f ∈ O(g) nennt man g obere asymptotische Schranke von f . 

Bei f ∈ Ω(g) heißt g untere asymptotische Schranke von f . 

Klar: Θ(g) = Ω(g) ∩ O(g). 

16 / 130


Effizienzanalyse 

Vorüberlegungen zur Effizienzanalyse 

Nicht für jedes mathematische Problem gibt es einen 

Algorithmus. 

Wenn es einen gibt, gibt es in der Regel beliebig viele. 

Alle (korrekten) Algorithmen für das Problem sind mathematisch 

äquivalent. 

Aus der Sicht der Informatik unterscheiden sie sich erheblich. 

17 / 130 



Algorithmen sind immaterielle Produkte. 

Wenn sie arbeiten, brauchen sie Rechenzeit und belegen 

Speicherplatz im Rechner. 


Die Effizienzanalyse betrachtet den Zeit- und Platzbedarf von 

Algorithmen und liefert analytische Qualitätsurteile (im Unterschied 

zu Messungen). 

18 / 130



Was sind geeignete Maßeinheiten? 

für Speicherplatz: 

Bits, Bytes, MB, Datenblöcke fester 

Größe 

für Rechenzeit: Befehlszyklen, Sekunden, Tage, . . . , 

Rechenschritte fester Dauer 

Das Maß sollte auf den Algorithmus bezogen sein, nicht einen 

bestimmten Rechner voraussetzen. 

Daher: 

Platz in Datenblöcken 

Zeit in (abstrakten) Rechenschritten messen 

19 / 130 



Datenblöcke und Rechenschritte sind jeweils vernünftig zu wählen: 

Länge einer Liste (z.B. beim Sortieren) 

Größe einer Zahl (z.B. beim Wurzel ziehen oder einer 

Primzahlzerlegung) 

Abhängigkeit von Größe der Eingabe: 

Es ist klar, dass der gleiche Algorithmus “kleinere” Eingaben 

schneller verarbeitet als große. 

Wir setzen n als Größe der Eingabe gemessen in Datenblöcken und 

berechnen Platz und Zeit in Abhängigkeit von n. 

20 / 130


Average Case und Worst Case 


Die tatsächliche Laufzeit ist auch manchmal auch abhängig von den 

genauen Daten. Das haben wir z.B. bei manchen Sortierverfahren 

festgestellt. 

Auch bei gegebener Eingabe-Größe kann also ein Algorithmus 

unterschiedlich lange rechnen oder Platz brauchen. 

Worst case Analyse: 

längstmögliche Rechenzeit für 

Eingabe der Größe n 

Average case Analyse: durchschnittliche Rechenzeit 

über alle Eingaben der Größe n 

21 / 130 



Worst case 

garantiert, dass der Bedarf nie höher ist als angegeben. 

Average case nimmt an, dass alle Eingaben gegebener Größe gleich 

wahrscheinlich sind, und kann daher täuschen. 

22 / 130


Formalisierung 

Zusammenfassung und Formalisierung 

Gegeben Problem P, Algorithmus A, der P löst. 

Sei x die Eingabe für A, und |x| die Größe der Eingabe. 

Sei time A (x) Anzahl der Rechenschritte, 

space A (x) Anzahl der Datenblöcke 

die A zur Berechnung x benötigt. 

Effizienzaussagen hängen statt von x von n = |x| ab. 

23 / 130 



Worst-case Zeitkomplexität von A 

wc-time A (n) = 

max 

{x| n=|x|} 

time A (x) 

Average-case Zeitkomplexität von A 

av-time A (n) = 

1 

|{x| n = |x|}| · 

{x| 

∑ 

n=|x|} 

time A (x) 

Expected-time Zeitkomplexität von A 

∑ 

exp-time A (n) = 

{x| n=|x|} 

time A (x) · Prob(x) 

Dabei ist Prob(x) die Wahrscheinlichkeit der Eingabe x. 

24 / 130



Analog dazu die Platz- oder Speicherkomplexität: 

Worst-case Platzkomplexität von A 

wc-space A (n) = 

max 

{x| n=|x|} 

space A (x) 

Average-case Platzkomplexität von A 

av-space A (n) = 

1 

|{x| n = |x|}| · 

{x| 

∑ 

n=|x|} 

space A (x) 

25 / 130 


Beispiele 

Beispiel: Funktion insert 

insert a [ ] = [a] 

insert a (x : xs) = if a ≤ x then a : x : xs 

else x : insert a xs 

Wir bestimmen Zeitbedarf für 

in Abhängigkeit von n = length x. 

insert a x 

26 / 130


Beispiele 

Nur der Aufruf von insert hängt von n ab, die Anzahl der sonstigen 

Rechenschritte ist konstant. Wir annotieren das Programm 

insert a [ ] = [a] {c 1 } 

insert a (x : xs) = if a ≤ x then a : x : xs {c 2 } 

else x : insert a xs {c 3 } 

27 / 130 


Beispiele 

wc-time insert (n) = c 1 für n = 0 

wc-time insert (n) = c 3 + wc-time insert (n − 1) 

da der else-Fall hier der worst case ist. 

Daraus erhalten wir 

wc-time insert (n) = c 1 + nc 3 

28 / 130


Beispiele 

Für den average case kommt es darauf an, an welcher Position 

eingefügt wird. 

Wir nehmen an, alle Positionen sind gleich wahrscheinlich. 

Für gegebene Position ist Aufwand exakt berechenbar. 

29 / 130 


Beispiele 

Wir bestimmen 

time(n|i) = a wird in Liste der Länge n 

nach Position i eingefügt, 

i = 0, . . . , n 

i = 0 time(n, 0) = c 1 

1 ≤ i < n time(n, i) = i · c 3 + c 2 

time(n, n) = n · c 3 + c 1 

30 / 130


Beispiele 

Für den Durchschnitt betrachten wir die n + 1 gleich wahrscheinlichen 

Fälle 

av-time insert (n) = 

= 

= 

= 

1 ( ∑n−1 

time(n, 0) + time(n, i) + time(n, n) ) 

n + 1 

i=1 

1 ( ∑n−1 

) 

c1 + (i · c 3 + c 2 ) + n · c 3 + c 1 

n + 1 

i=1 

1 ( 

n∑ ) 

2c1 + (n − 1) · c 2 + i · c 3 

n + 1 

i=1 

2 

n + 1 c 1 + n − 1 

n + 1 c 2 + n 2 c 3 

31 / 130 


Beispiele 

Betrachtung für große n: 

lim 

n→∞ wc-time insert(n) ≈ n · c 3 

lim 

n→∞ av-time insert(n) ≈ n 2 · c 3 

Hieran sieht man (besser als an der genauen Laufzeitformel): 

Aufwand wächst linear mit Größe der Eingabe. 

c 3 ist der wesentliche konstante Faktor, der die Laufzeit 

bestimmt. 

32 / 130


Beispiele 

Worst-case für insertion-sort: 

isort [ ] = [ ] {k 1 } 

isort (a : x) = insert a (isort x) {k 2 } 

wc-time isort (0) = k 1 

wc-time isort (n + 1) = k 2 + wc-time insert (n) + wc-time isort (n) 

= n · k 2 + k 1 + 

= n · k 2 + k 1 + 

n∑ 

i=1 

wc-time insert (i) 

n∑ 

(c 1 + i · c 3 ) 

i=1 

= n · k 2 + k 1 + n · c 1 + 

n(n + 1) 

c 3 

2 

33 / 130 


Beispiele 

wc-time isort (n) = n2 

2 c 3 + n(c 1 + 1 2 c 3 + k 2 ) + k 1 

Also gilt hier 

wc-time isort (n) ≈ n2 

2 · c 3 für n → ∞ 

Beachte: c 3 aus insert ist die einzige zeitkritische Konstante. 

34 / 130


Beispiele 

Die genauen Konstanten c 1 , c 2 , . . . hängen ab von 

der konkreten Rechenmaschine, 

der Programmiersprache, 

dem Übersetzer. 

Sie sind aber jeweils konstant und daher durch 

Proportionalitätsfaktoren verknüpft. 

Z.B. 1 Funktionsaufruf in Haskell −→ 30 Maschinenbefehle im 1 GHz 

Takt 

c Aufruf ˆ= 30 · c Maschine ˆ= 30 · 10 −9 sec 

35 / 130 


Beispiele 

Platzbedarf für insert 

Hier gibt es keinen Unterschied im worst/average case. Wir setzen 

den Platzbedarf für ein Listenelement gleich c. 

space insert (0) = c 

space insert (n + 1) = (n + 2) · c 

also 

space insert (n) = (n + 1) · c für n ≥ 0 

36 / 130


Beispiele 

Platzbedarf für isort 

space isort (0) = 0 

space isort (n + 1) = space insert (n) + space isort (n) 

wäre falsch, denn die Speicherblöcke für insert und isort werden nicht 

gleichzeitig benötigt. 

Daher: 

space isort (n + 1) = max{space insert (n), space isort (n)} 

Also: 

space isort (n) = space insert (n − 1) = n · c 

37 / 130 


Asymptotische Effizienz-Analyse 

Die Komplexität eines Algorithmus A wird häufig nur bis auf konstante 

Faktoren bestimmt. 

Es interessiert (nur), ob 

wc-time A (n) ≈ n 

≈ n · log n 

≈ n 2 

≈ 2 n 

und so weiter 

Ebenso bei av-time A (n), wc-space A (n), av-space A (n). 

38 / 130


Rückblick 

Betrachten wir die bisherigen Ergebnisse asymptotisch, so erhalten 

wir: 

wc-time insert 

av-time insert 

space insert 

∈ Θ(n) 

∈ Θ(n) 

∈ Θ(n) 

wc-time isort ∈ Θ(n 2 ) 

space isort 

∈ Θ(n) 

39 / 130 


Exakte vs. asymptotische Analyse 

Exakte versus asymptotische Analyse 

Die bisherige Effizienzanalyse war exakt – wir konnten genau die 

Rolle der Komponenten c 1 , c 2 , c 3 , k 1 , k 2 bestimmen. 

Erst am Ende haben wir das asymptotische Verhalten von 

wc-time insert etc. betrachtet. 

Die Analyse läßt sich aber auch von vornherein asymptotisch 

durchführen. 

40 / 130



wc-time insert ∈ Θ(n) – also setzen wir 

wc-time insert (n) = n 

Wir setzen k 1 = 0 durch Wahl von n. 

Wir setzen k 2 = 1 durch Wahl von c und C. 

Damit vereinfacht sich die Gleichung 

zu 

wc-time isort (n + 1) = n · k 2 + k 1 + 

n∑ 

i=1 

wc-time isort (n + 1) = n + 

wc-time isort (n + 1) = n + 

wc-time insert (i) 

n∑ 

i 

i=1 

n(n + 1) 

2 

∈ Θ(n 2 ) 

41 / 130 



Überlegung 

Zu den gleichen asymptotischen Ergebnissen kommen wir, wenn wir 

in der Analyse nur die Vergleichsoperationen auf Listenelementen 

zählen. 

→ Warum? 

42 / 130


Charakteristische Operation 

Definition. Eine Operation p eines Algorithmus A ist 

charakteristisch für die asymptotische Laufzeit, wenn 

wc-time p_in_A (n) ∈ Θ(wc-time A (n)). 

(Beachte: dann gilt auch die Umkehrung.) 

Lemma. Eine Operation p in A ist charakteristisch, genau dann, 

wenn für alle anderen Operationen q gilt 

wc-time q_in_A (n) ∈ O(wc-time p_in_A (n)). 

43 / 130 



Beispiel: 

In einem Sortierprogramm kommen (:)- und ( n 0 gilt: 

Anzahl(:) ≤ 10 · Anzahl(



Zwischenfazit 

Die Effizienzanalyse wird durch die asymptotische Betrachtungsweise 

stark vereinfacht. Das wesentliche Problem ist das folgende: 

Wir müssen die Definition von f (x) in Rekurrenzgleichungen für 

wc-time(|x|) übersetzen können: 

wc-time A (n) = Ausdruck, der wc-time A enthält. 

Diese müssen nach wc-time A aufgelöst werden, was nicht immer 

einfach ist. 

45 / 130 


Aufgabe 

Zahlenspiel 

Das Spiel wird paarweise gespielt. Suche Dir bitte einen 

Sitznachbarn, mit dem Du das Spiel spielen kannst. 

Einer von euch denkt sich jetzt eine Zahl zwischen 0 und 255. 

Der andere muss versuchen, die Zahl zu erraten. Er darf aber nur 

Ja/Nein-Fragen stellen. Versucht, so wenig Fragen wie möglich zu 

stellen. 

Wie viele Fragen musstet ihr stellen? 

46 / 130


Binärer Baum 


Eine Datenstruktur für binäre Bäume 


Fragen 

Wie viele Blätter n gibt es maximal bis Tiefe t? 

Wenn ein Baum n Blätter hat, wie tief kann er dann maximal 

sein? 

Wie ist das Verhältnis von Br zu Leaf Knoten? 

51 / 130 


Überlegungen 

Listen sind sehr kompakte Repräsentationen im Speicher und 

wir haben interessante Funktionen auf Listen bereits definiert. 

Für bestimmte Fragestellungen scheinen sich Bäume besonders 

gut zu eignen. 

Kann man die beiden Datentypen ineinander überführen? 

52 / 130


Tree and back again. . . 

Für die Überführung von Listen in Bäume brauchen wir eine Funktion 

build :: [a] -> Tree a 

Und für die Überführung von Bäumen in Listen etwa 

leaves :: Tree a -> [a] 

53 / 130 


Naiver Ansatz für leaves, ganz entlang einer Strukturellen Rekursion 

auf Bäumen: 

leaves :: Tree a -> [a] 

leaves Nil = [] 

leaves (Leaf a) = [a] 

leaves (Br l r) = leaves l ++ leaves r 

Betrachten wir einmal die Zahl der Rechenschritte unserer 

naiven Implementierung. 

wc-time leaves (n) = n 2 

Diese Funktion leaves ist also sehr teuer bezüglich der 

Rechenzeit. 

54 / 130


Ansatz unter Vermeidung der Listenkonkatenation: 

leaves’ :: Tree a -> [a] 

leaves’ Nil = [] 

leaves’ (Leaf a) = [a] 

leaves’ (Br Nil r) = leaves’ r 

leaves’ (Br (Leaf a) r) = a:leaves’ r 

Was machen wir, wenn links ebenfalls ein Branch hängt? 

Idee: wir wandeln den Branch um in ein einfacheres Problem! 

leaves’ (Br (Br l’ r’) r) = leaves’ (Br l’ (Br r’ r)) 

55 / 130 


Exkurs Bäume Ende 

. . . und nun zurück zum Thema 

56 / 130


Als nächstes (interessanteres) Beispiel betrachten wir das 

Programm sortTree. Es berechnet die sortierte Liste der Blätter eines 

Baumes: 

sortTree :: Tree Integer -> [Integer] 

sortTree Nil = [] 

sortTree (Leaf a) = [a] 

sortTree (Br l r) = merge (sortTree l) (sortTree r) 

merge :: (Ord a) => OrdList a -> OrdList a -> OrdList a 

merge [] bs = bs 

merge as [] = as 

merge (a:as) (b:bs) 

| a


Wie beschreibt man den worst-case genau? 

merge (as, bs) [· · · , a m , b n ] 

oder [· · · , b n , a m ] 

Alle Elemente (bis auf das letzte) werden vor dem Einbau verglichen. 

59 / 130 


Nun folgt die Analyse von sortTree. Wir betrachten nun Bäume mit n 

Blättern: 

60 / 130


Die Aufrufe von merge ergeben sich aus der Baumstruktur 

61 / 130 


Zwischenbeobachtung: 

In der Tat kann man so rechnen, dass die “merge-Bäume” als 

Zwischenergebnisse auftreten. Man wendet überall die Gleichungen 

von sortTree an – und keine anderen. 

Damit ist auch der Aufwand bis zu diesem Punkt bekannt – n − 1 

innere Knoten (Br) erfordern genau n − 1 Gleichungsanwendungen, 

unabhängig von der Form des Baums. 

62 / 130


Die gleiche Betrachtung an isort[4, 2, 3, 1] ergibt das 

Zwischenergebnis: 

insert 

4 

insert 

2 

insert 

3 

insert 

1 

[ ] 

Worin liegt noch der Unterschied zwischen isort und sortTree bei 

Listen-ähnlichem Baum? 

63 / 130 


Betrachtet man den Rechenaufwand für die merge-Phase ergibt sich: 

bzw. 

Resultat: 3 + 2 + 1 = 6 1 + 1 + 3 = 5 

Wir müssen also davon ausgehen, dass wc-time sortTree von der Form 

des Baumes abhängt. 

64 / 130


Die Größe der Daten n für sortTree(t) können wir beschreiben durch 

die Anzahl size(t) der Blätter von t (Form unbeschränkt, aber die 

Tiefe muss dann zwischen log 2 n und size(t) liegen) 

die Tiefe depth(t) des Baumes t (die Anzahl der Blätter ist damit 

beschränkt durch 2 depth(t) ) 

Wir untersuchen beide Varianten. 

65 / 130 


Untersuchung basierend auf size 

Untersuchung ausgehend von size(t) 

Sei n = size (t) 

wc-time sortTree (1) = 0 

wc-time sortTree (n) = n − 1 + max { wc-time sortTree (i)+ 

wc-time sortTree (n − i)| 

0 

Wie kommen wir weiter? 

66 / 130



Wir programmieren wc-time sortTree in Haskell und tabellieren: 

n 1 2 3 4 5 6 7 8 9 

wc-time sortTree (n) 0 1 3 6 10 15 21 28 36 

Das sieht aus wie 1 2 n(n − 1). 67 / 130 



In der Tat – der schlechteste Fall tritt auf für i = 1 und i = n − 1 – das 

sind “entartete” Baum, etwa 

wc-time sortTree (n) = 1 2 n(n − 1) ∈ Θ(n2 ) 

68 / 130


Untersuchung ausgehend von depth 

Untersuchung ausgehend von depth(t) 

Sei d = depth(t) 

wc-time sortTree (0) = 0 

wc-time sortTree (d + 1) = 2 d+1 − 1 + 2wc-time sortTree (d) 

wc-time sortTree (d) = ∑ d 

i=1 2d−i (2 i − 1) 

= ∑ d 

i=1 (2d − 2 d−i ) = d2 d − 2 d + 1 ∈ Θ(d2 d ) 

Schlechtester Fall: ausgeglichener Baum. Dieser hat n = 2 d Blätter, 

wir haben also wc-time sortTree (n) ∈ Θ(n · log 2 n) 

– das ist besser als Θ(n 2 ) wie zuvor ermittelt. 

69 / 130 



Sei n Anzahl der Blätter, d die Tiefe von t. 

Wir haben erhalten: 

wc-time sortTree (n) ∈ Θ(n 2 ) 

wc-time sortTree (d) ∈ Θ(2 d · d) 

Im ersten Fall ist im worst-case d = n. 

Im zweiten Fall ist im worst-case n = 2 d . 

Beide Analysen zusammengenommen: 

wc-time sortTree (n, d) ∈ Θ(n · d) 

70 / 130



Konsequenz: 

sortTree ist asymptotisch schneller als insertion sort, sofern 

der Baum ausgeglichen ist: Dann ist d = ⌈log 2 n⌉. 

Können wir aus einer (unsortierten) Liste l in Θ(n · log n) Zeit oder 

schneller einen ausgeglichenen Baum aufbauen (⇒ Funktion 

build)? Dann erhalten wir durch 

sortTree(build(l)) 

ein schnelleres Sortierverfahren in Θ(n · log n). 

71 / 130 


build 

Aufbau eines ausgeglichenen Baums 


build [] = Nil 

build [a] = Leaf a 

build as = Br (build (take k as))(build (drop k as)) 

where k = length as ‘div‘ 2 

Auch dieser naive Ansatz (wie bei leaves) ist recht 

teuer. . . warum? 

In der letzten Definition werden die as mehrfach durchlaufen 

(length, take, drop). 

72 / 130


build 

Asymptotische Effizienz von build 

Zählen wir (wie bisher) nur die Vergleichsoperationen, so gilt: 

Was stimmt hier nicht? 

wc-time build (m) = 0 

Der Vergleich ist nicht charakteristische Operation für build. 

Also zählen wir die Schritte für take, drop, length, build. 

73 / 130 


build 

wc-time take (k, n) = k ∈ Θ(n) 

wc-time drop (k, n) = k ∈ Θ(n) 

wc-time length (n) = n + 1 ∈ Θ(n) 

wc-time build (0) = 1 

wc-time build (n) = n + 1 + 2n + 2 · wc-time build (n/2) 

= 3n + 1 + 2 · (n/2 + 1 + 2n/2 

+2 · wc-time build (n/4)) 

74 / 130


build 

Insgesamt kann (log 2 n)-mal halbiert werden, jedesmal kommt ein 

Beitrag in Θ(n) hinzu, also 

wc-time build (n) ∈ Θ(n · log n) 

75 / 130 


build 

Ergebnis: Ein schnelles Sortierverfahren 

mergeSort :: [a] → OrdList a 

mergeSort = sortTree.build 

wc-time mergeSort (n) ∈ Θ(n · log n) 

76 / 130


build 

Vergleich des asymptotischen Wachstums: 

n n log 2 n n 2 

10 3 ≈ 10, 0 · 10 3 10 6 

10 4 ≈ 13, 3 · 10 4 10 8 

10 5 ≈ 16, 6 · 10 5 10 10 

10 6 ≈ 19, 9 · 10 6 10 12 

mergeSort ist also wesentlich effizienter als insertionSort. 

77 / 130 


build 

Lässt sich mergeSort weiter verbessern? 

Aber worauf sollen wir abzielen – 

bessere konstante Faktoren bei Laufzeit Θ(n · log n)? 

bessere asymptotische Laufzeit, etwa Θ(n) oder 

Θ(n · log(log n))? 

78 / 130


build 

Problemkomplexität 

Definition 

Die algorithmische Komplexität eines Problems P ist die 

Effizienzklasse des besten Algorithmus, der P löst. 

“Beste” meint hier: niedrigste asymptotische worst-case-Laufzeit. Das 

ist in der Regel eine Klasse von Algorithmen mit unterschiedlichen 

konstanten Faktoren. 

79 / 130 


build 

Kochrezept zum Nachweis von: 

P hat Komplexität Θ(f ) 

1 Angabe eines Algorithmus A für P mit wc-time A ∈ Θ(f ) 

2 Zeigen, dass jeder Algorithmus für P mindestens Θ(f ) Schritte 

rechnen muss. 

80 / 130


Beispiel 

Satz: 

Sortieren durch Vergleichen (wir hatten (


Beispiel 

Eine Liste mit n Elementen hat n! Permutationen. Wir kennen daher 

die Mindest-Tiefe des Entscheidungsbaums. Also gilt: 

Time sort (n) ≥ log 2 (n!) 

Die Fakultätsfunktion lässt sich mit der Stirlingschen Formel 

abschätzen: 

n! ≥ √ ( n 

2πn 

e 

) n 

. 

83 / 130 


Beispiel 

Insgesamt erhalten wir: 

(√ ( 

Time sort (n) ≥ log 2 2πn n 

) ) n 

e 

= log 2 

√ 

2πn + log2 

( n 

e 

) n 

= log 2 (2πn) 1/2 + log 2 

( n 

e 

) n 

= 1 2 log 2 (2πn) + n log 2 n e 

= 1 2 log 2 (2π) + 1 2 log 2 n + n log 2 n − n log 2 e 

∈ Θ(n log n) 

84 / 130


Zusammenfassung 

Der Weg zu einer guten Problemlösung 

1 Man verschafft sich Klarheit über die Komplexität des zu 

lösenden Problems. 

2 Man entwickelt einen Algorithmus, dessen Effizienz in der Klasse 

der Problemkomplexität liegt. Asymptotisch gesehen, ist dieser 

bereits “optimal”. 

3 Man analysiert die konstanten Faktoren des Algorithmus und 

sucht diese zu verbessern. 

85 / 130 



Programmoptimierung am Beispiel mergeSort 

Unter Optimierung von Programmen versteht man im Allgemeinen 

die Verbesserung der konstanten Faktoren. (Verbessert sich die 

asymptotische Effizienzklasse, spricht man eher von einem Redesign 

des Algorithmus.) 

Wir bilden Varianten von build und vergleichen die konstanten 

Faktoren. 

86 / 130




build [] = Nil 

build [a] = Leaf a 

build (as) = Br (build (take k as)) (build (drop k as)) 

where k = length as ’div’ 2 

Die Neuberechnung der Listenlänge (length) kostet Θ(n log n) 

Schritte! 

87 / 130 



Eine Funktion mit zusätzlichem Parameter (⇒ Einbettung) hilft, die 

Neuberechnung der Länge vermeiden: 

build’’ :: [a] -> Tree a 

build’’ as = buildn (length as) as 

where buildn :: Int -> [a] -> Tree a 

buildn 1 (a:as) = Leaf a 

buildn n as = Br (buildn k (take k as)) 

(buildn (n-k) (drop k as)) 

where k = n ‘div‘ 2 

Jedoch: auch take und drop erzeugen Aufwand der Ordnung 

Θ(n · log n). 

88 / 130



Überlegung: Die n Elemente der Eingabe werden dauernd in immer 

kleinere Listen gepackt, um am Ende in den Baum gehängt zu 

werden. 

Können wir diese Listen vermeiden, und jedes Element der Eingabe 

nur einmal “anfassen”, wenn es in den Baum gehängt wird? 

89 / 130 



Idee: Jeder Aufruf von build nimmt von der Liste was er braucht, 

und reicht den Rest unbesehen weiter: 

build’ :: [a] -> Tree a 

build’ as = fst (buildSplit (length as) as) 

buildSplit 1 (a:as) = (Leaf a, as) 

buildSplit n as = (Br l r, as’’) 

where k = n ‘div‘ 2 

(l,as’) = buildSplit k as 

(r,as’’) = buildSplit (n-k) as’ 

90 / 130



Analyse: 

wc-time buildSplit (n) = 6 + wc-time buildSplit (⌊n/2⌋) + wc-time buildSplit (⌈n/2⌉) 

wc-time buildSplit (1) = 6 

(Die zweite 6 ist etwas zu hoch, vereinfacht aber die Rechnung.) 

Für n = 2 k : wc-time buildSplit (2 k ) = 6(2 k+1 − 1) = 12n − 6 ∈ Θ(n) 

91 / 130 



Ergebnis für mergeSort: 

Wir haben die Effizienz der build-Phase von Θ(n log n) nach Θ(n) 

verbessert. 

An der asymptotischen Effizienz von mergeSort ändert sich dadurch 

nichts, da die sortTree-Phase in Θ(n · log n) bleibt. 

Aber besser als Θ(n log n) geht ja auch nicht . . . 

92 / 130



Weitere Vereinfachung: 

Wir brauchen build, um einen ausgeglichenen Baum aus der 

Eingabeliste zu machen. 

Der Baumstruktur entspricht genau die Aufrufstruktur von merge. 

Wir können den Baum ganz eliminieren (Stichwort “Deforestation”). 

Wir nehmen die Definition von mergeSort und rechnen den Baum 

weg: 

93 / 130 



mergeSort [] = sortTree (build []) = sortTree Nil = [] 

mergeSort [a] = sortTree (build [a]) = sortTree (Leaf a) = [a] 

mergeSort (as) = sortTree (build as) 

= sortTree Br (build (take k as)) (build (drop k as))) 


= merge (sortTree (build (take k as)) 

sortTree (build (drop k as))) 


= merge (mergeSort (take k as) 

mergeSort (drop k as)) 


94 / 130



Übrig bleibt also 

mergeSort’ [] = [] 

mergeSort’ [a] = [a] 

mergeSort’ (as) = merge (mergeSort (take k as)) 

(mergeSort (drop k as)) 


Dieser mergeSort baut keinen Baum auf. Die zuvor untersuchten 

Verbesserungen von build sollte man auch hier wieder 

untersuchen. 

95 / 130 



Vergleicht einmal den Effekt: 

mtest = mergeSort [1..10000] 

für die alte und neue Version von mergeSort. 

96 / 130


Ausnutzen von erwarteten Daten-Eigenschaften 

In den obigen Testbeispielen ist die Eingabe-Liste bereits sortiert – 

wovon unser Programm aber wenig mitkriegt. 

Wir suchen eine Variante von mergeSort, die umso schneller wird, je 

mehr die Eingabe vorsortiert ist. 

97 / 130 


Idee: Ausnutzung von “Läufen” (Runs) von vorsortierten 

Elementen (aufsteigend oder absteigend). 

Problem: Top-Down Baumkonstruktion zerstört die Läufe. 

Lösung: Wir bestimmen erst die Läufe und bauen aus ihnen den 

Baum. 

98 / 130


Läufe sind auf- oder absteigende Folgen. Über die Richtung 

entscheidet das zweite Element. 

16 14 13 4 9 10 11 5 1 15 6 2 3 7 8 12 

16 14 13 4 | 9 10 11 | 5 1 | 15 6 2 | 3 7 8 12. 

99 / 130 


runs :: [a] -> [[a]] 

runs [] = [[]] 

runs [a] = [[a]] 

runs (a:b:x) = if a [a] -> [a] -> [[a]] 

ascRun a as [] = [reverse (a:as)] 

ascRun a as (b:y) = if a


Nun wird ein ausgeglichener Baum aufgebaut, an dessen Blättern die 

Läufe stehen. Er hat also den Typ Tree[a] statt Tree a. 

Trotzdem können wir die schon bekannte Θ(n) build-Funktion 

einsetzen – für diese ist n nun die Anzahl der Läufe! 

101 / 130 


Das Programm smoothSort: 

smsort :: Ord a => [a] -> [a] 

smsort = mergeRuns . build’ . runs 

mergeRuns :: Ord a => Tree [a] -> [a] 

mergeRuns (Leaf x) = x 

mergeRuns (Br l r) = merge (mergeRuns l) (mergeRuns r) 

102 / 130


Sortieren in Θ(n) 

Eine Funktion sort :: Ord(a) ⇒ [a] → OrdList a kann es nicht 

geben mit Effizienz Θ(n). 

Einzige vorausgesetzte Operationen auf dem Datentyp a sind ja die 

Vergleichsoperationen der Typklasse Ord. 

Wissen wir mehr über den Typ a, lässt sich dies vielleicht ausnutzen. 

103 / 130 


Dazu brauchen wir aus der Haskell-Vorlesung 

die Typklasse (Ix a) (Index-Typen) 

den Datentyp Array a b (mit Index-Typ a und Elementtyp b 

Das Besondere an Arrays: Elementzugriff 

Array t : t!i ∈ Θ(1) im Unterschied zu 

Liste l : l!!i ∈ Θ(i) 

104 / 130


Idee des Counting-Sort: 

Alle Elemente liegen in einem begrenzten Intervall. 

Wir zählen, wie oft jeder Wert vorkommt. 

Wir reproduzieren alle Werte in aufsteigender Reihenfolge und 

korrekter Anzahl. 

105 / 130 


Beispiel: Eingabe “bacaabfdfabaf” 

Intervall: [a..f] 

Tabelle 

Ausgabe: “aaaaabbbcdfff” 

Anzahl 

a ||||| 

b ||| 

c | 

d | 

e 

f ||| 

106 / 130


Effizienz 

Der Aufbau der Tabelle sowie die Erzeugung der sortierten Ausgabe 

lassen sich in Θ(n) bewerkstelligen. 

CountingSort ist ein lineares Sortierverfahren 

Haskell-Code: 

import Array 

countingSort :: Ix a => (a,a) -> [a] -> [a] 

countingSort bs x = [ a | (a,n)


Effekte der Laziness 

Was wir bisher über Effizienzanalyse und Komplexität gelernt haben, 

gilt für alle Programmiersprachen. Schließlich gibt es 

immer eine geeignete abstrakte Einheit “Rechenschritt”, auf 

der die Analyse aufbaut. 

109 / 130 


Eine Besonderheit gilt für Haskell als eine Programmiersprache, in 

der das Prinzip der “Lazy Evaluation” (verzögerte Auswertung) 

realisiert ist. 

Die bisherige Analyse ging davon aus, dass es bei jedem Aufruf, z.B. 

isort x, stets das ganze Ergebnis berechnet wird. Laziness kann 

dazu führen, dass auch weniger gerechnet wird. 

110 / 130


Grundbegriffe zu Auswertungs-Strategien: 

Rechnen = Anwenden von Gleichungen in Formeln 

Redex = reducible expression: Stelle in einer Formel, an 

der die linke Seite einer Gleichung “passt” 

“passt” = die auf der linken Seite verlangten Konstruktoren 

der Argumente liegen vor 

111 / 130 


Beispiel: 

head (x:xs) = x 

ist anwendbar auf die Formel und ergibt 

head (1:2:2:[]) => 1 

head (1:([3,4]++[5,6])) => 1 

head ((1+4):[5]) => (1+4) 

head (1:ones) where 

ones = 1:ones => 1 

ist (noch) nicht anwendbar auf 

head ([1,3,4] ++ [5,6]) 

head (map (1+) [1,2,3]) 

head ones where 

ones = 1:ones 

Es muss erst eine Gleichung für (++), map oder ones angewandt 

werden. 

112 / 130


Lage von Redexen in einer Formel 

Ein Redex ist 

innermost, wenn er keinen weiteren Redex enthält, 

outermost, wenn er in keinem weiteren Redex enthalten ist, 

“zwischendrin”, sonst. 

113 / 130 


Beispiel 

114 / 130


Auswertungs-Strategien 

leftmost innermost: immer den Redex wählen, der am weitesten 

links steht und innermost ist. 

leftmost outermost: immer den Redex wählen, der am weitesten 

links steht und outermost ist. 

gemischt: man kann sich viele weitere Strategien vorstellen . . . 

115 / 130 


Besonderheit von if_then_else: 

Seine definierenden Gleichungen sind 

Ein Redex 

if True then x else y = x 

if False then x else y = y 

wird in jedem Fall leftmost outermost berechnet. 

Je nach Ergebnis für C wird A oder B nicht berechnet. 

116 / 130


Diese Regel für if_then_else gilt in allen Programmiersprachen. 

Ohne sie könnte man keine terminierende Rekursion programmieren: 

f (x) = if_then_else(x ≤ 0, 42, 2 + f (x − 1)) 

Innermost-Strategie führt zu endloser Berechnung des else-Falles. 

Auch wenn die Bedingung gerne in “mix-fix” Schreibweise 

daherkommt: 

f (x) = if x ≤ 0 then 42 else 2 + f (x − 1) 

sollte man nicht verkennen, dass es sich dabei um eine dreistellige 

Funktion handelt, die NICHT innermost berechnent wird. 

117 / 130 


Eigenschaften der Strategien 

1 Ob eine Rechnung terminiert, hängt i.A. von der Strategie ab. 

2 Wenn zwei verschiedene Strategien, angewandt auf die gleiche 

Formel, terminieren, liefern sie das gleiche Ergebnis. 

3 Im Fall (2) kann sich der Rechenaufwand stark unterscheiden. 

4 Wenn für eine Formel F irgendeine Strategie terminiert, dann 

terminiert für F auch “leftmost outermost”. 

5 “leftmost innermost” terminiert seltener als “leftmost outermost”. 

118 / 130


Anschauliche Bedeutung 

innermost: Alle Argumente einer Funktion werden ganz 

ausgerechnet, bevor die Funktion “aufgerufen” wird. 

outermost: Die Argumente einer Funktion werden immer nur so 

weit ausgerechnet, wie es die Funktion für ihren 

nächsten Schritt braucht. 

119 / 130 


Lazy Evaluation 

Haskell verwendet lazy evaluation (verzögerte Auswertung), das ist 

leftmost outermost + graph reduction 

graph reduction ist eine Zusatzregel, die die Duplikation 

unausgerechneter Formeln vermeidet. 

120 / 130


Beispiel zur graph reduction 

twice x = x ∗ x 

twice (3 + 4) 

↑ 

↑ 

outermost innermost 

würde blindlings outermost reduziert zu 

(3 + 4) ∗ (3 + 4) 

wo nun der Ausdruck (3 + 4) zweimal berechnet werden müsste. 

121 / 130 


Stattdessen wird reduziert 

twice (3 + 4) ⇒ x ∗ x 

where x = 3 + 4 

worin durch die “Nebenrechnung” 3 + 4 nur einmal berechnet wird. 

122 / 130


Einfluss von lazy evaluation auf Effizienz-Analyse 

Es wurde bisher angenommen, dass alle Funktionen ihre Ergebnisse 

ganz berechnen. 

Das muss nicht stimmen. Unter lazy evaluation kann es sein, dass 

eine Funktion in einem bestimmten Kontext nur einen Teil ihres 

Ergebnisses berechnet. Die Laufzeit kann dann besser sein als nach 

der Analyse ohne Berücksichtigung der Laziness. 

123 / 130 


Hier die naheliegende Implementierung von minimum: 

minimum (a:as) = min a as 

min a [] = a 

where 

min a (b:x) = if a


Hier eine alternative Implementierung, die bequemerweise den 

Insertion-Sort benutzt 

minimum (a:as) = head (isort (a:as)) 

Wegen wc-time isort (n) ∈ Θ(n 2 ) könnte man vermuten, dass 

wc-time minimum (n) ∈ Θ(n 2 ). 

Sehen wir genauer hin! 

125 / 130 


Die Definition von isort war: 

isort [] = [] 

isort (a:as) = insert a (isort as) 

insert a [] = [a] 

insert a (b:as) = if a


Lazy Evaluation berechnet in einer Formel immer an der “äußersten” 

Stelle, an der eine Gleichung anwendbar ist: 

Zunächst kann immer nur die Gleichung isort.2 angewandt werden, 

am Ende einmal isort.1 

head 

head 

isort 

insert 

a1 

: 

a 2 

: 

: 

=> 

a 1 

insert 

a2 

insert 

a n 

[ ] 

a n 

[ ] 

127 / 130 


Danach wird n-mal insert angewandt, beginnend bei a n . Nehmen 

wir an, a 5 ist das kleinste Element. Streng “outermost” entsteht nun 

head 

: 

=> 

a 5 

a 1 

insert 

insert 

a2 

insert 

innerhalb des Kastens 

könnte man weiterrechnen, 

aber das wäre nicht 

“outermost”. 

a n−1 

[a n] 

128 / 130


head braucht nicht mehr als den obersten Konstruktur (:), um sein 

Ergebnis zu liefern 

head 

=> a 5 

: 

a 5 

Es werden ≈ 2 · n Gleichungen angewandt. Der Rest der Θ(n 2 ) 

Operationen steckt im Kasten und wird nicht benötigt! 

129 / 130 


Fazit: Durch Lazy Evaluation gilt auch bei dieser Definition 

wc-time minimum (n) ∈ Θ(n). 

130 / 130

Effizienz von Algorithmen - Technische Fakultät - Universität Bielefeld

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?