Algorithmen und Datenstrukturen I. 1 Effizienz von Algorithmen

Transkript

1 Algorithmen und Datenstrukturen I - Effizienz von Algorithmen - Alexander Sczyrba Technische Fakultät asczyrba@techfak.uni-bielefeld.de Vorlesung, Universität Bielefeld, Winter 2013/ / 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

2 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 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. 4 / 130

3 Asymptotische Notationen 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 Asymptotische Notationen 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

4 Asymptotische Notationen 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 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. 7 / 130 Asymptotische Notationen 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

5 Asymptotische Notationen 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 Asymptotische Notationen 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 log 2 n f (n) Θ(n 4 ) mit den Konstanten C = 15, c = 3 und n 0 = 1 10 / 130

6 Asymptotische Notationen 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 / 130 Asymptotische Notationen 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 / 130

7 Asymptotische Notationen 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 Asymptotische Notationen 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

8 Asymptotische Notationen 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 Asymptotische Notationen 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

9 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 Effizienzanalyse Algorithmen sind immaterielle Produkte. Wenn sie arbeiten, brauchen sie Rechenzeit und belegen Speicherplatz im Rechner. Effizienzanalyse Die Effizienzanalyse betrachtet den Zeit- und Platzbedarf von Algorithmen und liefert analytische Qualitätsurteile (im Unterschied zu Messungen). 18 / 130

10 Effizienzanalyse 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 Effizienzanalyse 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

11 Average Case und Worst Case 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 Average Case und Worst Case 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

12 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 Formalisierung 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

13 Formalisierung 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

14 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

15 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

16 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

17 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 / 130 Beispiele 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 / 130

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

19 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

20 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

21 Exakte vs. asymptotische Analyse 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 Exakte vs. asymptotische Analyse Überlegung Zu den gleichen asymptotischen Ergebnissen kommen wir, wenn wir in der Analyse nur die Vergleichsoperationen auf Listenelementen zählen. Warum? 42 / 130

22 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 Charakteristische Operation 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 / 130

23 Charakteristische Operation 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

24 Effizienz von Algorithmen Asymptotische Effizienz-Analyse Exkurs Beispiel zur Effizienanalyse Ausn Binärer Baum Ja/Nein Fragen führen zu binären Entscheidungen <128 <32 <64 <96 <160 <192 <224 Für eine optimale Strategie, muss der Problemraum systematisch aufgeteilt werden Die Fragen verästeln sich wie in einem Baum (hier auf dem Kopf) Der Pfad im Baum kann binär kodiert werden (0 = links, 1 = rechts). Im Beispiel entspricht er der binären Repräsentation der Zahl 47 / 130 Effizienz von Algorithmen Asymptotische Effizienz-Analyse Exkurs Beispiel zur Effizienanalyse Ausn Überlegungen Die Länge des Pfades nennen wir Tiefe. Die Länge des längsten Pfades ist die maximale Tiefe des Baumes. Der Startpunkt (Kreis ohne Vorgänger) heißt Wurzel. Dass die Werte kontinuierlich sind, spielt eigentlich keine Rolle. Wichtig für die Entscheidungsfindung ist, dass wir eine totale Ordnung haben (siehe Kapitel zur Wohlfundierten Rekursion). Bäume könnten auch eine interessante Datenstruktur abgeben / 130

25 Effizienz von Algorithmen Asymptotische Effizienz-Analyse Exkurs Beispiel zur Effizienanalyse Ausn Eine Datenstruktur für binäre Bäume Die Fragen stellen wir uns an den Verzeigungen (hier Kreise) <128 <32 00 <64 <96 < <192 <224 Die Zahlen, unsere Daten, stehen an den Blättern (hier Kästen) Theoretisch sollte es auch unbeschriftete Blätter geben (kommt hier nicht vor). Warum? Antwort: man möchte z.b. auch ungerade Anzahlen an Blättern repräsentieren können. 49 / 130 Effizienz von Algorithmen Asymptotische Effizienz-Analyse Exkurs Beispiel zur Effizienanalyse Ausn Bäume in Haskell data Tree a = Nil Leaf a Br (Tree a) (Tree a) deriving Show Der Typ Tree umfasst binäre Bäume über dem Grundtyp a. Ein Baum ist entweder leer (unbeschriftetes Blatt Nil), enthält ein Blatt mit Daten (Leaf a), oder verzweigt sich in zwei Teilbäume (Br). 50 / 130

26 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

27 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

28 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

29 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 <= b = a:merge as (b:bs) otherwise = b:merge (a:as) bs 57 / 130 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) 58 / 130

30 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

31 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

32 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: = = 5 Wir müssen also davon ausgehen, dass wc-time sorttree von der Form des Baumes abhängt. 64 / 130

33 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 < i < n } Wie kommen wir weiter? 66 / 130

34 Untersuchung basierend auf size Wir programmieren wc-time sorttree in Haskell und tabellieren: n wc-time sorttree (n) Das sieht aus wie 1 2n(n 1). 67 / 130 Untersuchung basierend auf size 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

35 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 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. 69 / 130 Untersuchung ausgehend von depth 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

36 Untersuchung ausgehend von depth 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 :: [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 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

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

38 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

39 build Vergleich des asymptotischen Wachstums: n n log 2 n n , , , , 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

40 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

41 Beispiel Satz: Sortieren durch Vergleichen (wir hatten (<) als charakteristische Operation) hat Problemkomplexität Θ(n log n). Zu beweisen: Wir müssen zeigen: Jeder Algorithmus braucht mindestens Θ(n log n) Vergleiche. 81 / 130 Beispiel 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. 82 / 130

42 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 ) n 2πn. e 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π) log 2 n + n log 2 n n log 2 e Θ(n log n) 84 / 130

43 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 Zusammenfassung 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

44 Zusammenfassung 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! 87 / 130 Zusammenfassung 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

45 Zusammenfassung Ü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 Zusammenfassung 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

46 Zusammenfassung 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 Zusammenfassung 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 / 130

47 Zusammenfassung 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 Zusammenfassung 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 94 / 130

48 Zusammenfassung Ü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. 95 / 130 Zusammenfassung Vergleicht einmal den Effekt: mtest = mergesort [ ] für die alte und neue Version von mergesort. 96 / 130

49 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

50 Läufe sind auf- oder absteigende Folgen. Über die Richtung entscheidet das zweite Element / 130 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 100 / 130

51 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

52 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

53 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

54 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) <- assocs t, i <- [1..n]] where t = accumarray (+) 0 bs [(a,1) a <- x, inrange bs a] 107 / 130 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. 108 / 130

55 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

56 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

57 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

58 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 / 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

59 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

60 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

61 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 = worin durch die Nebenrechnung nur einmal berechnet wird. 122 / 130

62 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<=b then min a x else min b x Offensichtlich ist wc-time minimum (n) Θ(n) 124 / 130

63 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<=b then a:b:as else b:(insert a as) 126 / 130

64 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

65 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