4XLFNVRUW. Geschichte:

4XLFNVRUW Geschichte: - Sortieren ist wegen seines Gebrauches in vielen Anwendungen das meist studierte Problem in der Informatik - grundlegendes Sortierproblem: Prozess der Neuordnung einer gegebenen Ansammlung von Größen in eine auf- oder absteigende Folge Æ Daten werden also auf eine vorher festgelegte Ordnung sortiert; kann z.b. nach Zahlenwerten (z.b. PLZ) oder Alphabet geschehen Æ Ziel des Sortierens: Daten nach geschicktem Sortieren schneller und einfacher wiederfinden - mathematische Darstellung des Sortierproblems: Geg.: Folge s 1,s,,s n ; s i Schlüssel Ges.: Permutation, so dass gilt s V ) «V - erste Betätigungen im Sortieren: Amerika, 1. Jahrhundert; schon damals war es üblich, alle 10 Jahre eine Volkszählung durchzuführen Æ mit gewonnenen Daten wuchs Interesse an verschiedenen Statistiken Æ für diese Erhebungen musste Datenmaterial nach verschiedenen Gesichtspunkten sortiert werden, was in mühevoller Handarbeit geschah - Hermann Hollerith erfand 180 erste Sortiermaschine, die batteriebetrieben war Æ dank ihr wurde es möglich, Daten der Volkszählung, die auf Lochkarten gestanzt wurden, zu sortieren (Nadeln tasteten Löcher ab, traf Nadel auf ein Loch HOHNWULVFKHU.RWDNWKHUJHVWHOOW IIHWH.ODSSH VRUWLHUWH Dateikarte fiel auf den jeweiligen Stapel), erleichterte Arbeit, verkürzte Zeit - kamen immer mehr Datenmassen einher ZXUGHGD6RUWLHUPDVFKLH mit automatischer Papierzuführung verwendet - Durchbruch gelang 130 HUVWHUSURJUDPPLHUEDUHU&RPSXWHU - schon hatte man Interesse, Sortierproblem damit zu lösen; man wusste, dass Computer aufgrund ihrer Arbeitsweise geradezu dafür geschaffen sind, Daten zu sortieren - mittlerweile gibt es viele Sortieralgorithmen; betrachten zuerst uicksort, vergleichen später noch mit anderen Sortieralgorithmen - uicksort-algorithmus von Charles Antony Richard Hoare, kurz C.A.R. Hoare oder Tony Hoare, britischer Informatiker, erfand Grundform des Algorithmus 16; wie kam er darauf?

- Algorithmus wurde entdeckt, als Hoare als Austauschstudent nach Moskau kam - erhielt dort Möglichkeit, bei einem neuen Projekt für automatische Übersetzung vom Russischen ins Englische mitzuarbeiten, damals wurden Wörterbücher auf Magnetband gespeichert : UWHUHLHV6DW]HVPXVVWHDOSKDEHWLVFKVRUWLHUW werden, um Übersetzung vom Band abrufen zu können; Hoare ging vom Fakt aus, dass es effizient ist, bei einem Sortieralgorithmus die Elemente über große Distanzen zu tauschen uicksort war geboren - da Hoare Algorithmus 16 entwickelte, musste er das Verfahren noch Entrekursivieren, da sich zu dieser Zeit keine Rekursion in Programmiersprachen ausdrücken ließ - Hoare verfasste 16 seinen Artikel über uicksort; dort beschrieb er nicht nur seinen Algorithmus, sondern analysierte ihn auch - seine Vorhersagen über die Effizienz seines Verfahrens bestätigten sich später in der Praxis - obwohl es Algorithmus schon seit 16 gibt, ist uicksort noch der meist verwendete Sortieralgorithmus; ist überraschend, weil in den letzten Jahren viele Forscher daran arbeiten, einen schnelleren Sortieralgorithmus zu finden

Zu uicksort: - uicksort meist erste Wahl bei Sortierprogrammen, außer man hat detailliertere Informationen über den Input, in diesem Fall: andere Sortieralgorithmen können uicksort übertreffen - andere Besonderheit von uicksort: Reichtum der Komplexitätsanalyse - obwohl worst-case-komplexität von uicksort schlecht ist, kann man beweisen, dass seine durchschnittliche Komplexität ziemlich gut ist; tatsächlich ist uicksorts durchschnittliche Komplexität die bestmögliche unter bestimmten Komplexitätsmodellen für das Sortieren Konkreter: uicksort funktioniert schlecht für fast sortierte Inputs, aber sehr gut für zufällige Inputs - uicksort folgt der Divide-&-Conquer-Strategie (Teile und Herrsche) - Divide-&-Conquer-Strategie hat drei Phasen: 1. Man teilt Problem in mehrere Teilprobleme von fast gleicher Größe (Aufteilungsphase). Man löst die sich ergebenen Teilprobleme unabhängig voneinander 3. Man legt die Lösungen der Teilprobleme in eine Lösung für das ursprüngliche Problem zusammen (Verschmelzungsphase) - Beschreibung von uicksort, angewandt auf ein Feld A[0:n-1] 1. Man wählt ein Pivotelement aus A[0:n-1] aus. Man ordnet die Elemente von A, teilt A in ein linkes und rechtes Teilfeld, so dass kein Element im linken Teilfeld größer und kein Element im rechten Teilfeld kleiner als das Pivotelement ist 3. Man sortiert linkes und rechtes Teilfeld rekursiv Æ Divide-&-Conquer-Strategie: Schritt 1 und entsprechen der Aufteilungsphase, Schritt 3 läuft aus das unabhängige Lösen der herbeigeführten Teilprobleme hinaus (da sich die Teilfelder nicht überlappen, können sie unabhängig voneinander sortiert werden), welches das gesamte Feld sortiert, die Verschmelzungsphase ist also nicht mehr notwendig - zwei entscheidende Ausführungsprobleme: Methode für das Auswählen des Pivotelements und Methode für das Aufteilen des Inputs, wenn Pivotelement ausgewählt ist

Pivotelement auswählen: - entscheidende Voraussetzung für einen effizienten Divide-&-Conquer- Algorithmus: Aufteilen des Inputs in zwei fast gleichgroße Felder Æ Pivotelement so wählen, dass es fast gleichgroße Aufteilungen des Feldes A herbeiführt - Annahme: A enthält verschiedene Elemente; beste Wahl des Pivotelements: Median von A (so dass zwei fast gleichgroße Teilfelder entstehen); obwohl einige gute Algorithmen den Median finden können, ohne das Feld zu sortieren, laden sie alle zu viele Unkosten auf sich, um für eine praktische Ausführung von uicksort nützlich zu sein Möglichkeit fällt weg - 3 Möglichkeiten für die Wahl des Pivotelements: erste und einfachste ist das Auswählen eines Elements von einer fixierten Position von A; im allg. funktioniert diese Wahl nicht so gut, außer wenn der Input zufällig ist; wenn Input fast sortiert, würde er äußerst ungleich bei jeder Iteration aufgeteilt werden, was in eine sehr schlechte Durchführung des gesamten Algorithmus enden würde versuchen, den Median von A zu approximieren, indem man den Median von einer kleinen Teilmenge von A berechnet hier verbreitet benutzte Methode: Mittelwert vom ersten, mittleren und letzten Element von A wird Pivotelement; solch eine Methode funktioniert gut, obwohl es für bestimmte Inputs immer noch in sehr ungleiche Aufteilungen während jeder Iteration enden könnte mittels Zufallszahlengenerator kann man zufällig ein Element von A als Pivotelement auswählen; man kann zeigen, dass ohne Rücksicht auf die anfängliche Input-Verteilung jeder Schritt mit hoher Wahrscheinlichkeit in fast gleichgroße Aufteilungen enden wird Æ wählt man Pivotelement zufällig aus, spricht man vom randomisierten uicksort äquivalent dazu: Input wird in eine zufällige Reihenfolge permutiert

Input aufteilen - Aufteilungsphase startet mit dem Initialisieren der Zeiger L und R und dem Auswählen des z.b. rechtesten Elements als Pivotelement - haben Teilfeld A[Begin,End], Begin < End; zwei Zeiger L und R; L bewegt sich von links nach rechts, beginnend auf Position Begin; R bewegt sich von rechts nach links, fängst bei Position End an - Zeiger L wachsend, bis ein Element A[L] größer als das Pivotelement ist; ähnlich: R fallend, bis es auf ein Element A[R] stößt, dass kleiner als das Pivotelement ist; dann tauscht man A[L] und A[R] - Ablauf setzt sich fort, bis sich beide Zeiger kreuzen, was auf den Abschluss der Aufteilungsphase hindeutet - letzten Zuweisungen stellen sicher, dass das Pivotelement an seine korrekte Position in der letzten sortierten Folge von A platziert wird - uicksort ruft Anfang des Aufteilungsverfahrens mit den Werten Begin = 0 und End = n-1 auf, gefolgt von einem rekursiven Aufruf, um die Teilfelder A[Begin,j-1] und A[j+1,End] (j Stelle des Pivotelements) zu sortieren - lassen Teilfelder ihrerseits wieder mit neuem Pivotelement zerlegen, bis die rekursiv gewonnenen Partitionen nur noch jeweils ein Element enthalten - Aufteilungsverfahren benötigt lineare Zeit O(n)

Algorithmus: (in C++) void uicksort (Element *Array, int Begin, int End) { int L = Begin, R = End; Element Temp; keytype Pivot; if (End - Begin > 0) { Pivot = Array[End].key; while (L < R) { while (L < R && Array[L].key <= Pivot) L++; while (L < R && Array[R].key >= Pivot) R--; if (L < R ) { Temp = Array[L]; Array[L] = Array[R]; Array[R] = Temp; Temp = Array[End]; Array[End] = Array[L]; Array[L] = Temp; uicksort (Array, Begin, L-1); uicksort (Array, L+1, End);

- Beispiel: rot Pivotelement, grün sortiert LÆ L R ÅR 5 8 6 1 3 7 LÆ LÆ L R ÅR 5 3 6 1 8 7 LÆ LR 5 3 6 1 8 7 5 3 6 1 7 8 LR ÅR ÅR ÅR LÆ LR 5 3 6 1 7 8 LÆ LR ÅR 1 3 6 5 7 8 1 3 5 6 7 8 - Algorithmus hat den Vorteil, dass er über eine sehr kurze innere Schleife verfügt (was die Ausführungsgeschwindigkeit stark erhöht) - 6WDELOLWlW beim Sortieren einer Datenmenge bleibt die Reihenfolge gleicher Schlüssel erhalten - UGXJVYHUWUlJOLFKNHLW gibt Auskunft, ob Sortierverfahren bereits bestehende Teilordnungen beim Sortieren ausnutzt - uicksort ist kein stabiles Verfahren und nicht ordnungsverträglich - ist ein in-place-sortierverfahren; kommt ohne zusätzlichen Speicherplatz aus (abgesehen von dem Zwischenspeicher für die Tauschoperationen und von dem für die Rekursionsaufrufe zusätzlich benötigten Platz auf dem Stack) Æ 6WDFN in der Informatik eine häufig (aber meist unbewusst) eingesetzte, spezielle Datenstruktur; kann eine beliebige Menge von Objekten aufnehmen und gibt diese entgegengesetzt zur Reihenfolge der Aufnahme wieder zurück; LIFO (Last In First Out)

Komplexität: - Definitionen: J( )) = { I ( ) : F > 0, 1 : I ( ) F J( ) > Θ ( 0 0 ( J ( )) = { I ( ) : F1 > 0, F > 0, 0 1 : F1 J( ) I ( ) F J( ) > 0 - man kann verschiedene Maßstäbe verwenden, um Durchführung des Sortieralgorithmus zu analysieren Æ man kann die Anzahl der Vergleiche zählen, weil die Vergleiche, die vom Sortieralgorithmus durchgeführt werden, die Hauptoperation zu sein scheinen Æ anderer wichtiger Parameter: Anzahl der Vertauschungen - hier: konzentrieren uns auf die Anzahl der Vergleiche worst-case - bestimmen Anzahl der Vergleiche, die beim worst-case benötigt werden - sei () die Anzahl der Vergleiche, die beim uicksort-algorithmus benötigt werden - der schlechteste Fall tritt ein, wenn das Pivotelement das größte oder kleinste Element des Feldes ist; bedeutet folgendes für die Anzahl der Vergleiche: ( 1) ( ) = ( 1) + ( ) +... + 1 = Æ worst-case-komplexität: (²) best-case: - im günstigsten Fall ist das Pivotelement i jedesmal gerade der Median; das Feld wird in zwei gleich große Teilfelder aufgeteilt; die Anzahl der Vergleiche ist minimal - in diesem Fall haben die zwei Teilfelder A[0:i-1] und A[i+1:n-1] die Größe ( ) = 1 + - Rekursionsgleichung hat die Lösung ( ) = log + Θ( ) Æ best-case-komplexität: ( log )

average-case: - () sei hier die mittlere Anzahl von Vergleichsoperationen auf Felder der Länge - nehmen an, dass alle! Permutationen von Elementen mit der gleichen Wahrscheinlichkeit auftreten; die Wahl des Pivotelements ist gleichwahrscheinlich, somit haben wir folgende Rekursionsformel für den average-case 1 ( ) = 1+ = 1 ( ( L 1) + ( L)) - wobei 1 die Anzahl der Vergleiche mit dem Pivotelement sind - L ist die Position des Pivotelements, jede dieser Positionen hat die Wahrscheinlichkeit 1 - die Teilfelder der Längen L 1 und L sind dann zu sortieren, hierbei haben wieder alle ( L 1)! und ( L)! Permutationen gleiche Wahrscheinlichkeit - Vereinfachung ergibt sich aus der Beobachtung, dass auf der rechten Seite der Rekursion zweimal die gleiche Summe (mit unterschiedlicher Summationsrichtung) steht, also: (0) = 0 ( ) = 1 + 1 = 0 ( L)

- will zwei Richtungen vorstellen, wie man das berechnen kann: :HJ - beide Seiten mit n multipliziert ( ) = - auch bei ( 1) + 1 = 0 ( 1) ( 1) = ( 1) ( L) - Subtrahiert ( 1) von () ( 1) + = 0 ( L) ( ) ( 1) ( 1) = 1 1+ ( 1) ( ) = + ( + 1) ( 1) - dividiert durch ( +1) Æ ( ) 1 ( 1) = + + 1 ( + 1) ( 1) ( ) = + ( 1) 1 ( ) 1 (1) = + 3 3 - addiert man die obigen Gleichungen, erhält man folgende Gleichung 1 ( ) = ( + 1) + 4 mit + = ln( + 1) + γ = 1 L γ 0,577 Eulersche Konstante Æ ( ) 1,386 log Æ average-case-komplexität: ( log )

. Weg: - Frage ist nun, wie sich die Lösung () dieser Rekursion für verhält. Experimentell wird rasch klar, dass () stärker als linear wächst (1) = 0 () = 1 (3),66 (4) 4,83 (5) = 7,4 (10) 4,43 (100) 647,85 (1000) 1086 - interessant ist, dass sich die Lösung der Rekursion explizit angeben lässt ( ) = ( + 1) + 4 mit + = = 1 1 ln( + 1) + γ L - damit kann man leicht auch den Funktionsverlauf für größere verfolgen 4 (10 ) 15577 5 ( 10 ) 0,018 6 ( 10 ) 0,478 7 ( 10 ) 0,3 8 ( 10 ) 0,33 ( 10 ) 0,3860 10 ( 10 ) 0,430 10 10 10 10 10 7 8 10 11 10 - insgesamt ergibt das: ( ) 1,386 log Æ average-case-komplexität: ( log ) 1

(a) best-case (b) average-case (c) worst-case

Wie kann man Komplexität verbessern? - in Praxis kann worst-case vorkommen (²) uicksort fällt wieder weit zurück - kann man verhindern, indem man drei Elemente aus Input herausgreift und die Mitte als Pivotelement wählt gewährleistet, dass Pivotelement nicht Minimum oder Maximum ist worst-case vermieden - weiterer Geschwindigkeitsvorteil, wenn man uicksort mit anderen Verfahren kombiniert, z.b. Insertsort Æ Praxis zeigt, dass uicksort bei Datenmengen < 10 schlechter abschneidet als mancher Konkurrent, Nachteil kann wettgemacht werden, indem man Segmente mit weniger als 10 Elementen nicht weiter partitioniert, sondern z.b. mit Insertsort sortiert

Vergleich mit anderen Sortieralgorithmen: %XEEOHVRUW Algorithmus: (in C++) void Bubblesort (Element *Array, int N) { int i,j; Element Temp; for (i = 1; i < N; i++) { for (j = 1; j < N i + 1; j++) { if (Array[j - 1].key > Array[j].key) { Temp = Array[j - 1]; Array[j - 1] = Array[j]; Array[j] = Temp;

Komplexität (average-case) von Bubblesort: - am Anfang n-1 Vergleiche, dann n-,, bis 1 ( 1) Æ ( ) = ( 1) + ( ) +... + 1 = ( 1) für große : Æ ( ) - Tausch findet nur statt, wenn erstes Element > zweites, Tausch T besteht aus 3 Zuweisungen = ; wenn Datenverteilung zufällig, dann können wir annehmen, dass ein Tausch ungefähr in der Hälfte aller Fälle notwendig ist 3 Æ 7 ( ) Æ = ( ) 4 4 Anzahl Operationen in Bubblesort: ca. Bubblesort hat Komplexität ( ) 3 + 4 5 = 4 - Fazit: leicht zu implementieren, für große sehr langsam

Insertsort Algorithmus: (in C++) void Insertsort (Element *Array, int N) { int i,j; Element Temp; for (i=0; i < N - 1; i++) { j = i + 1; Temp = Array[j]; while (j > 0 && Array[j 1].key > Temp.key) { Array[j] = Array[j-1]; j--; Array[j] = Temp; Komplexität (average-case) von Insertsort: - im ersten Schleifendurchlauf ein Vergleich, im zweiten höchstens zwei usw. Æ ( ) 1+ +... + 1 - im Durchschnitt werden höchstens die Hälfte der Elemente in jedem Schleifendurchlauf verglichen Æ ( ) 4 - Anzahl der Kopien (sind hier nicht wirklich Tauschoperationen) ist ungefähr gleich der Anzahl der Vergleiche Æ = ( ) 4 Anzahl Operationen in Insertsort: ca. + = 4 4 Insertsort hat Komplexität ( ) - Fazit: deutlich schneller als Bubblesort

Æ Bubblesort schneidet im Vergleich immer am schlechtesten ab; Insertsort ist im Gegensatz zu uicksort ein stabiles und ordnungsverträgliches Sortierverfahren und somit bei vorsortierten Datenmengen schneller als uicksort (best-case bei Insertsort ist () ) Æ folgende Tabelle zeigt die Laufzeiten einiger Sortierverfahren für zufällig sortierte Datenmengen (P IV; 3,0 GHz) 50k 100k 500k 1M 5M 10M Bubblesort,31 1:1 - - - - Insertsort 4,6 31,15 17:06 - - - Shellsort 0,01 0,05 0,36 0,3 6,76 16,1 uicksort 0,01 0,0 0,16 0,35,67 6,80 (Shellsort funktioniert wie Insertsort, nur dass man hier erst jeden h-ten Schlüssel im Input vergleicht und sortiert, h wird dann immer kleiner gesetzt bis h = 1 ist) - bei allen Vorzügen nicht vergessen: Æ uicksort nicht stabil und nicht ordnungsverträglich Æ entfaltet Optimum erst bei großen Datenmengen