Algorithmen und Datenstrukturen 1 Kapitel 5

Transkript

1 Algorithmen und Datenstrukturen 1 Kapitel 5 Robert Giegerich Technische Fakultät Universität Bielefeld robert@techfak.uni-bielefeld.de Vorlesung, U. Bielefeld, Winter 2011/ / 121

2 Kapitel 5: Effizienz von Algorithmen Ziele des Kapitels: Einführung in asymptotische Notationen asymptotische Effizienzanalyse (worst/average case) Problemkomplexität sinnvolle Programmoptimierung (asympt. Klasse versus konstante Faktoren) Analyse diverser Sortierverfahren (insertion-sort, tree-sort, merge-sort, smooth-sort, counting-sort)) Einfluss der Laziness auf die Effizienz 2 / 121

3 5.1 Asymptotische Notationen Wir betrachten das Polynom p(x) = 2x x 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. 3 / 121

4 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 4.2 ff. Das grobe Verhalten muss natürlich exakt definiert sein... 4 / 121

5 Dazu werden asymptotische Notationen O(n), Ω(n), Θ(n) 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.) Seien f, g : N R +. 5 / 121

6 O(g) = {f C > 0, n 0 0, n n 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. Beispiel: f (n) = 3n 4 + 5n log 2 n f (n) O(n 4 ), denn 3n 4 + 5n 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. 6 / 121

7 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. 7 / 121

8 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. 8 / 121

9 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 log 2 n f (n) Θ(n 4 ) mit den Konstanten C = 15, c = 1 und n 0 = 1 9 / 121

10 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 log 2 n für alle n n 0 10 / 121

11 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 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 / 121

12 Asymptotisch gesehen, betrachten wir f (n) = 3n 4 + 5n log 2 n als gleichwertig mit n 4. Die asymtotischen Effizienklassen haben ungeheuer praktische Eigenschaften. 12 / 121

13 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 / 121

14 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 / 121

15 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 / 121

16 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) = O(g) Ω(g). 16 / 121

17 5.2 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 / 121

18 Algorithmen sind immaterielle Produkte. Wenn sie arbeiten, brauchen sie Rechenzeit und belegen Speicherplatz im Rechner. Effizienzanalyse betrachtet den Zeit- und Platzbedarf von Algorithmen und liefert analytische Qualitätsurteile (im Unterschied zu Messungen). 18 / 121

19 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 / 121

20 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 / 121

21 5.3 Average Case und Worst Case Abhängigkeit von den genauen Daten Auch bei gegebener Eingabe-Größe kann 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 / 121

22 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 / 121

23 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 / 121

24 Worst-case Zeitkomplexität von A wc-time A (n) = max time A(x) {x n= 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) = time A (x) Prob(x) {x n= x } Dabei ist Prob(x) die Wahrscheinlichkeit der Eingabe x. 24 / 121

25 Analog dazu die Platz- oder Speicherkomplexität: Worst-case Platzkomplexität von A wc-space A (n) = max space A(x) {x n= x } Average-case Platzkomplexität von A av-space A (n) = 1 {x n = x } {x n= x } space A (x) 25 / 121

26 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 insert a x in Abhängigkeit von n = length x. 26 / 121

27 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 / 121

28 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 / 121

29 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 gegebenen Position ist Aufwand exakt berechenbar. 29 / 121

30 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 / 121

31 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 ( c1 + n + 1 i=1 n 1 ) (i c 3 + c 2 ) + n c 3 + c 1 i=1 1 ( 2c1 + (n 1) c 2 + n n + 1 c 1 + n 1 n + 1 c 2 + n 2 c 3 n ) i c 3 i=1 31 / 121

32 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 / 121

33 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 / 121

34 wc-time isort (n) = n2 2 c 3 + n(c 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 / 121

35 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 ˆ= sec 35 / 121

36 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 / 121

37 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 / 121

38 5.4 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 / 121

39 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 / 121

40 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 von vornherein asymptotisch durchführen. 40 / 121

41 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 n wc-time isort (n + 1) = n k 2 + k 1 + wc-time insert (i) i=1 n wc-time isort (n + 1) = n + i Θ(n 2 ) i=1 41 / 121

42 Zu den gleichen asymptotischen Ergebnissen kommen wir, wenn wir in der Analyse nur die Vergleichsoperationen auf Listenelementen zählen warum? 42 / 121

43 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 / 121

44 Beispiel: In einem Sortierprogramm kommen (:)- und (<)-Operationen vor. Ab n > n 0 gilt: Anzahl(:) 10 Anzahl(<). Also genügt es, die Anzahl der (<)-Operationen zu analysieren. 44 / 121

45 Zwischen-Fazit Die Effizienzanalyse wird durch die asymptotische Betrachtungsweise stark vereinfacht. Das wesentliche Problem ist das folgende: Wir können die Definition von f (x) in Rekurrenzgleichungen für wc-time( x ) übersetzen: 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 / 121

46 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 (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 (a:as) [] = a:as merge (a:as) (b:bs) a <= b = a:merge as (b:bs) otherwise = b:merge (a:as) bs 46 / 121

47 Seien m und n die Längen der Eingabelisten. Wir betrachten zuerst wc-time merge. ist die charakteristische Operation. Im worst case werden beide Listen wie ein Reißverschluss zusammengeführt. Also wc-time merge (m, n) = m + n 1 Θ(m + n) 47 / 121

48 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. 48 / 121

49 Nun folgt die Analyse von sorttree. Wir betrachten nun einen Baum mit n Blättern: 49 / 121

50 Die Aufrufe von merge ergeben sich aus der Baumstruktur 50 / 121

51 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. 51 / 121

52 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? 52 / 121

53 Betrachtet man den Rechenaufwand für die merge-phase ergibt sich: bzw. Resultat: = = 5 Wir müssen davon ausgehen, dass wc-time sorttree von der Form des Baumes abhängt. 53 / 121

54 Die Größe der Daten 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 t liegen) die Tiefe des Baumes t (die Anzahl der Blätter ist damit beschränkt durch 2 depth(t) ) Wir untersuchen beide Varianten. 54 / 121

55 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 < i < n } Wie kommen wir weiter? 55 / 121

56 Wir programmieren wc-time sorttree in Haskell und tabellieren: n wc-time sorttree (n) Das sieht aus wie 1 2n(n 1). 56 / 121

57 In der Tat der schlechteste Fall tritt auf für i = 1 und i = n 1 das ist der entartete Baum, etwa wc-time sorttree (n) = 1 2 n(n 1) Θ(n2 ) 57 / 121

58 Untersuchung ausgehend von depth(t): Sei d = depth(t) wc-time sorttree (0) = 0 wc-time sorttree (d + 1) = 2 d wc-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. 58 / 121

59 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 in worst-case n = 2 d. Beide Analysen zusammengenommen: wc-time sorttree (n, d) Θ(n d) 59 / 121

60 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), erhalten wir durch sorttree(build(l)) ein schnelleres Sortierverfahren in Θ(n log n). 60 / 121

61 Ziel: Aufbau eines ausgeglichenen Baums build :: [a] -> Tree a build [] = Nil build [a] = Leaf a build as = Br (build (take k as))(build (drop k as)) where k = length as div 2 61 / 121

62 Asymptotische Effizienz von build Zählen wir (wie bisher) nur die Vergleichsoperationen, so gilt: wc-time build (m) = 0 Was stimmt hier nicht? 62 / 121

63 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. 63 / 121

64 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 n + 2 wc-time build (n/2) = 3n (n/ n/2 +2 wc-time build (n/4)) 64 / 121

65 Insgesamt kann (log 2 n)-mal halbiert werden, jedesmal kommt ein Beitrag in Θ(n) hinzu, also wc-time build (n) Θ(n log n) 65 / 121

66 Ergebnis: Ein schnelles Sortierverfahren mergesort :: [a] OrdList a mergesort = sorttree.build wc-time mergesort (n) Θ(n log n) 66 / 121

67 Vergleich des asymptotischen Wachstums: n n log 2 n n , , , , mergesort ist also wesentlich effizienter als insertionsort. 67 / 121

68 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))? 68 / 121

69 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. 69 / 121

70 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. 70 / 121

71 Satz: Sortieren durch Vergleichen (wir hatten (<) als charakteristische Operation) hat Problemkomplexität Θ(n log n). Beweis: Wir müssen zeigen: Jeder Algorithmus braucht mindestens Θ(n log n) Vergleiche. 71 / 121

72 Was leistet eigentlich ein Vergleich, gegeben n ungeordnete Daten? Entscheidungsbäume a1<=a2 a1<=a2 [a1,a2] [a2,a1] a1<=a3 a2<=a3 a2<=a3 [a3,a1,a2] a1<=a3 [a3,a2,a1] [a1,a2,a3] [a1,a3,a2] [a2,a1,a3] [a2,a3,a1] Ein Vergleich scheidet die möglichen Permutationen der Eingabedaten in zwei Hälften. 72 / 121

73 Eine Liste mit n Elementen hat n! Permutationen. Wir kennen daher die Mindest-Tiefe des Entscheidungsbaums. Also gilt: Time sort (n) log 2 (n!) 73 / 121

74 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 ) n 2πn. e 74 / 121

75 Insgesamt erhalten wir: Time sort (n) log 2 ( 2πn ( n e ) n ) = log 2 2πn + log2 ( n e ) n = log 2 (2πn) 1/2 + log 2 ( n e = 1 2 log 2(2πn) + n log 2 n e = 1 2 log 2(2π) log 2 n + n log 2 n n log 2 e Θ(n log n) ) n 75 / 121

76 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. 76 / 121

77 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. 77 / 121

78 build :: [a] -> Tree a 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! 78 / 121

79 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). 79 / 121

80 Ü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? 80 / 121

81 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 81 / 121

82 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) 82 / 121

83 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 / 121

84 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: 84 / 121

85 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))) where k = length as div 2 = merge (sorttree (build (take k as)) sorttree (build (drop k as))) where k = length as div 2 = merge (mergesort (take k as) mergesort (drop k as)) where k = length as div 2 85 / 121

86 Übrig bleibt also mergesort [] = [] mergesort [a] = [a] mergesort (as) = merge (mergesort (take k as)) (mergesort (drop k as)) where k = length as div 2 Dieser mergesort baut keinen Baum auf. Die zuvor untersuchten Verbesserungen von build sollte man auch hier wieder untersuchen. 86 / 121

87 Man sollte den Effekt vergleichen: mtest = mergesort [ ] für die alte und neue Version von mergesort. 87 / 121

88 5.6 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. 88 / 121

89 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. 89 / 121

90 Läufe sind auf- oder absteigende Folgen. entscheidet das zweite Element. Über die Richtung / 121

91 runs :: [a] -> [[a]] runs [] = [[]] runs [a] = [[a]] runs (a:b:x) = if a<=b then ascrun b [a] x else descrun b [a] x ascrun, descrun :: a -> [a] -> [a] -> [[a]] ascrun a as [] = [reverse (a:as)] ascrun a as (b:y) = if a<=b then ascrun b (a:as) y else reverse (a:as):runs (b:y) descrun a as [] = [a:as] descrun a as (b:y) = if a<=b then (a:as):runs (b:y) else descrun b (a:as) y 91 / 121

92 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! 92 / 121

93 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) 93 / 121

94 5.7 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. 94 / 121

95 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) 95 / 121

96 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. 96 / 121

97 Beispiel: Eingabe bacaabfdfabaf Intervall: [a..f] Tabelle Ausgabe: aaaaabbbcdfff Anzahl a b c d e f 97 / 121

98 Effizienz: Der Aufbau der Tabelle wie 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) <- assocs t, i <- [1..n]] where t = accumarray (+) 0 bs [(a,1) a <- x, inrange bs a] 98 / 121

99 In den Beispielen dieses Kapitels sehen wir ein typisches Vorgehen der Informatik: Der Informatiker analysiert die Komplexität seiner Probleme und der Problemlösungen. Dabei werden auch absolute oder quantitative Grenzen der Lösbarkeit nachgewiesen. Diese werden anschließend durch Modifikation der Problemstellung umgangen. 99 / 121

100 5.8 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. 100 / 121

101 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 dzu führen, dass auch weniger gerechnet wird. 101 / 121

102 Grundbegriffe zu Auswertungs-Strategien: Rechnen = Anwenden von Gleichungen in Formeln Redex = Stelle in einer Formel, an der die linke Seite einer Gleichung passt passt = die auf der linken Seite verlangten Konstruktoren der Argumente liegen vor 102 / 121

103 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. 103 / 121

104 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. 104 / 121

105 Beispiel 105 / 121

106 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 / 121

107 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. 107 / 121

108 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. 108 / 121

109 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. 109 / 121

110 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. 110 / 121

111 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. 111 / 121

112 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. 112 / 121

113 Stattdessen wird reduziert twice (3 + 4) x x where x = worin durch die Nebenrechnung nur einmal berechnet wird. 113 / 121

114 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. 114 / 121

115 Hier die naheliegende Implementierung von minimum: minimum (a:as) = min a as where min a [] = a min a (b:x) = if a<=b then min a x else min b x Offensichtlich ist wc-time minimum (n) Θ(n) 115 / 121

116 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! 116 / 121

117 Die Definition von isort war: isort [] = [] isort (a:as) = insert a (isort as) insert a [] = [a] insert a (b:as) = if a<=b then a:b:as else b:(insert a as) 117 / 121

118 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 [ ] 118 / 121

119 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 insert a 1 insert a2 insert innerhalb des Kastens könnte man weiterrechnen, aber das wäre nicht outermost. a n 1 [a n] 119 / 121

120 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! 120 / 121

121 Fazit: Durch Lazy Evaluation gilt auch bei dieser Definition wc-time minimum (n) Θ(n). 121 / 121