Zufallsbit

Vielleicht erinnert sich noch jemand, dass ich in grauer Vorzeit mal eine Serie über Automatentheorie gestartet habe, mit dem Ziel, irgendwann zur Entscheidbarkeitstheorie zu gelangen. Der Grund, warum ich das nie weitergeführt habe ist, dass ich Automatentheorie nicht besonders spannend finde. Also überspringe ich den langweiligen Teil, komme direkt wieder zu Turingmaschinen und schreibe vielleicht später einen Beitrag über Automatentheorie mit einem eher zusammenfassenderen Charakter.

Entscheidbarkeitstheorie also. Die meisten Probleme sind ja irgendwie durch eine konkrete Fragestellung motiviert. Hier ist diese Frage, welche Funktionen entschieden werden können und welche nicht. Ich werde noch darauf kommen was das im Detail bedeutet. Erstmal führen wir eine neue Art Turingmaschine ein, die wir später brauchen.

Eine Turingmaschine, nennen wir sie M, ist ja folgendermaßen definiert:

Dabei ist Q die Menge der Zustände und q₀ identifiziert den Startzustand. ist das Bandalphabet und umfasst alle Buchstaben, die auf dem Band auftreten können. Dazu gehört insbesondere das "Blank" B, das nur als Platzhalter für "leer" steht. Für die bessere Lesbarkeit. ist das Eingabealphabet, was im wesentlichen mit dem Bandalphabet identisch ist, nur ohne das B. Außerdem können spezielle "Trennungssymbole" im Bandalphabet vorkommen, die man beim Entwurf des Algorithmus zur Vereinfachung verwenden kann. Genau wie man bei C++ Programmen vielleicht eine temporäre Variable zur Zwischenberechnung von Ergebnissen verwenden würde. Bleibt das , was die Zustandsübergangsfunktion darstellt. Wir erinnern uns: Eine Turingmaschine liest in jedem Schritt genau ein Zeichen, wechselt den Zustand, schreibt ein Zeichen zurück und bewegt den Kopf. Die Zustandsübergangsfunktion beschreibt, abhängig von gelesenen Zeichen und dem aktuellen Zustand, welche Aktionen passieren sollen. Oder anders gesagt: , wobei "0" für "keine Kopfbewegung" und -1 oder +1 für "links" bzw. "rechts" steht.

So eine gewöhnliche Turingmaschine hat einen gewaltigen Nachteil. Sie ist mit der formalen Definition bereits vollständig programmiert. Und zwar endgültig. Viel schöner und vertrauter wäre es doch, wenn eine Turingmaschine nur die "Hardware" zur Verfügung stellen würde und wir das Programm auf das Band schreiben könnten, genau wie wir das bei normalen Computern tun. Da schreiben wir das Programm auf die Festplatte (genauer gesagt in den Bootsektor) und von da aus guckt unser Computer nur, welches Programm an der richtigen Stelle der Festplatte zur Ausführung bereit liegt. Man stelle sich vor, wir würden für jeden auszuführenden Algorithmus einen neuen Prozessor kaufen und dem nur die Instanzen füttern. Ein Sortierprozessor zum Beispiel, dem wir nur Ganzzahlen zum Sortieren geben könnten, oder ein "Fülle-den-Cache-mit-Daten-Prozessor". Im echten Leben mutet das absurd an, aber so machen es klassische Turingmaschinen und für die Theorie kann man das auch tun.

Aber es geht eben auch anders, und das nennt man eine "universelle Turingmaschine", kurz UTM, noch kürzer U. Diese kann ein beliebiges Programm (bzw. eine andere, normale Turingmaschine M) ausführen. Die Eingabe besteht jetzt nicht mehr aus einem Wort w, sondern aus (<M>w). Dabei ist w nach wie vor das zu bearbeitende Wort, neu ist <M>, die so genannte Gödelnummer der zu simulierenden Turingmaschine M.

Man kann jede normale TM in eine lange Zahl codieren, die dann wiederum eindeutig ist. Zu jeder Gödelnummer gehört genau eine Turingmaschine. Diese Nummer wiederum gibt man dann als Eingabe an die UTM, die dann die zur Gödelnummer zugehörige TM simuliert. Diese Codierung funktioniert so:

, dann und Kopfbewegungen , dann

Keine Erklärung nötig soweit? Doch? Na gut. 

Zuerst transferieren wir das Bandalphabet (hier oBdA {0,1,B}) in . Jetzt gibt es also für jeden möglichen Bandbuchstaben ein entsprechendes X mit einem Index dran. Das gleiche passiert mit den Kopfbewegungen. Statt {-1,0+1} benutzen wir jetzt die Ds mit jeweils einem Index. Warum wir diese scheinbar sinnlose Transformation machen wird erst gleich klar, erstmal müssen wir uns einig sein, dass man den Zustandsübergang jetzt auch schreiben kann wie . Der Vorteil ist, dass jetzt alle Zustandsübergänge bis auf die Indizes gleich aussehen (bitte nochmal genau hinschauen wenn das nicht klar ist). Wenn man also wollte, könnte man die Übergänge also auch nur mit Zahlen aufschreiben.

Und das ist ja schließlich unser Ziel gewesen. Nun, die universelle TM hat allerdings auch nur ein {0,1} Alphabet, deshalb notiert man einen einzelnen Zustandsübergang so:

Jetzt dienen die Einsen als "Trenner" für eine Anzahl von Nullen, die mit dem ursprünglichen Zustandsübergang korrespondiert. Ein alter Übergang würde mit X₀=0, X₁=1 und D₁=-1 aussehen wie 001100001010. Wenn ich ab jetzt code(x) schreibe, meine ich abkürzend eine solche Zahl, einen Zustandsübergang repräsentierend.

Wo wir uns jetzt diese ganze Arbeit gemacht haben, können wir damit endlich wieder auf die Gödelnummer zurück kommen. Die sieht jetzt nämlich so aus:

111 code(1) 11 code(2) 11 ... 11 code(n-1) 11 code(n) 111

Drei Einsen markieren also Start und Ende der Gödelnummer, zwei Einsen trennen zwei Codierungen für die Übergänge. Das Ziel ist erreicht, die Turingmaschine wird in einer langen, langen Nummer notiert, die offensichtlich auch wieder in die entsprechende Maschine zurück rechnen lässt. Wenn wir jetzt eine solche Gödelnummer, zusammen mit dem zu entscheidenden Wort an die UTM übergeben, kann diese Schritt für Schritt die Gödelnummer lesen, den neuen Zustand (und damit die neue Position in der Gödelnummer) berechnen und am Ende entscheiden, ob das Wort akzeptiert wird oder nicht. Wie das genau funktioniert wollt ihr nicht wissen, die Gödelnummerkonstruktion war ja schon etwas unheimlich. Nur so viel: Man kann Turingmaschinen auch mit mehreren Speicherbändern definieren. Davon nehmen wir uns in diesem Fall drei, schreiben die zu simulierende Gödelnummer auf das erste, das Wort auf das zweite und auf das dritte kommt der aktuelle Zustand der zu simulierenden TM. Dann wird die Programmierung der UTM zwar weniger hässlich, aber nicht viel.

Bleibt die Frage nach der Rechenzeit. Wenn man sich die Rechenoperationen der UTM allerdings genau anschaut, wird schnell klar, dass die aufwändigste Operation die Suche nach der neuen Position in der Gödelnummer ist. Die UTM ist damit nur konstant langsamer als die ursprüngliche TM, hier droht also keine exponentielle Gefahr, außer die ursprüngliche TM war eh schon exponentiell langsam.

So weit, so gut. Wir haben gesehen, dass man eine TM auch als lange Nummer schreiben kann. Außerdem gibt es offensichtliche eine universelle Turingmaschine, die mit dieser Nummer und dem zu entscheidenden Wort diese TM simulieren kann. Benutzen kann man das für... ääh... eigentlich kann man das nicht benutzen. Man braucht es lediglich später für einen wichtigen Beweis. Ist theoretische Informatik nicht schön?

Wer hier aber dringend eine "Auflösung" braucht, der kann sich ja damit behelfen, dass die UTM offenbar eine praxisnähere Version von Turingmaschinen darstellt, denn man kann sie (auf aufwändige Art und weise) programmieren und muss sich nicht für jeden Algorithmus eine neue Turingmaschine kaufen. Gott sei dank.

Update: Übrigens..

Ich bin eher der Typ, der einmal liegengelassene Sachen nie, nie, NIE wieder anpackt. Deshalb habe ich den Comic vom letzten Beitrag wenigstens soweit fertig gemalt, dass man wenigstens etwas erkennen kann. Ich kann es wirklich besser, aber irgendwie habe ich den Ehrgeiz gerade nicht. (Creative Commons by-nc)

Ein spezieller Typ formaler Sprachen sind die so genannten kontextfreien Sprachen. Sie sind auch die praxisrelevantesten und deren Konstruktion sieht irgendwie am natürlichsten aus, deshalb fange ich mit ihnen an.

Um kontextfreie Sprachen zu beschreiben benutzt man oft die Backus-Naur Form. Das ist im Grunde nur eine spezielle Syntax um die Produktionsregeln übersichtlich hinzuschreiben. Es gibt allerdings auch ein paar neue Begriffe. Da sind zum einen die Terminale. Das sind "finale" Buchstaben, wenn ein Terminal in einer Regel generiert wurde, kann es nicht mehr verändert werden. Nichtterminale hingegen sind die "Variablen" aus dem letzten Beitrag. Das sind Hilfssymbole, die wiederum als Ausgangspunkt für weitere Produktionen verwendet werden. Beispiel-Time!

Z ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

Der vertikale Strich ist als "oder" zu verstehen. Ein "Z" kann nachher in den Regeln mit einer dieser Terminale ersetzt werden. Dann fehlt da formal noch folgendes:

(G steht für Grammatik, T für Terminale, N für Nichtterminale, S für Startsymbol und P für Produktionsregeln)

T= {Z}

N= {A}

P= { S->ASA, S->, A->Z}

G = {S,P,N,T}

Damit hätten wir eine Grammatik definiert, die eine Sprache generieren kann. Diese Sprache kann ein leeres Wort generieren, denn wir starten bei S und kommen von da aus direkt zum epsilon. Das epsilon ist ein Terminal, von hier aus ginge es also nicht weiter.

Die andere S-Regel generiert ASA. Ein A lässt sich nur ins Terminal aus Z transferieren, also steht da in Wirklichkeit <Zahl>S<Zahl>. Das S in der Mitte wiederum kann man wieder in ein epsilon produzieren (und damit das Wort abbrechen) oder wieder ASA generieren. Die Sprache besteht also aus beliebigen Zahlen, die eine gerade Anazhl von Stellen hat, oder aus dem leeren Wort.

Schön, aber noch nicht perfekt, denn ich könnte damit Zahlen mit führenden Nullen generieren. Wenn ich das nicht wollte, müsste ich ein paar Regeln umschreiben:

Z::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

Y::= Z  | "0"

N= {A,B,C}

P= { S->, S-> ACB, A-> Z, B-> Y, C-> BCB C->}

Es wird also etwas komplizierter, aber nicht viel. Wir füren ein paar mehr Regeln und Nichtterminale ein und stellen so sicher, dass gleich nach dem S eine nicht-Null generiert wird. Danach verlassen wir das S und generieren in C weiter. 141592 generiert sich so:

S->ACB->ZCY->ZBCBY->ZYBCBYY->ZYYYYY->ZYYYYY->141592

Das ist also eine kontextreie Sprache, und jetzt kann ich auch erklären, woher das "kontextfrei" kommt. Die Produktionsregeln sind unabhängig davon, welches Terminal vor oder hinter einem Nichtterminal steht. Grundsätzlich kann für ein Nichtterminal jede entsprechende Produktionsregel verwendet werden, ganz unabhängig vom Kontext in dem es steht.

Ich habe noch nicht erklärt, was "entscheidbar" bedeutet, deshalb kann ich im Moment auch noch nicht erklären, welches Automatenmodell kontextfreie Sprachen entschieden kann. Im nächsten Beitrag geht es um deterministische finite Automaten und welche Art Sprache davon entschieden werden können. Das mag etwas seltsam anmuten, aber diese Reihenfolge macht schon Sinn. Sowohl Automaten als auch Sprachen fühlen sich zu Anfang etwas weit hergeholt an. Dennoch besteht ein so starker Zusammenhang zwischen den beiden, dass es meiner Meinung nach Sinn macht, erst einfache Sprachen zu beschreiben, dann einfache Automaten einzuführen und dann den Zusammenhang herzustellen.

Dies ist der Eröffnungsbeitrag zur nächsten Serie in diesem Blog. Es wird um formale Sprachen und dem Zusammenhang zwischen Automatenmodellen und diesen Sprachen gehen. Leider gibt es hier kein "Ziel" in dem Sinne wie es eines bei P vs. NP gab, aber der lose Plan ist, früher oder später in die Entscheidbarkeitstheorie abzuschweifen. Da steht dann das Halteproblem an, was ich jetzt einfach mal als vorläufiges Ziel definiere. Aber keine Angst, diese Serie wird etwas praxisrelevanter sein als die P vs. NP-Serie. Und wie immer versuche ich natürlich, möglichst plastische Beispiele zu benutzen.

Schauen wir uns zu diesem Zweck erstmal natürliche Sprachen an. Nehmen wir den Satz "Ich esse Pizza". Wir erinnern uns an die Regel "Subjekt Prädikat Objekt" aus der Schulzeit. So könnte man diesen Satz formal konstruieren. Das Subjekt wäre "Ich", also substituiere ich "Ich" mit "Subjekt". Dann steht da "Ich Prädikat Objekt". Dann substituiere ich noch Prädikat mit "esse" und Objekt mit "Pizza" und schon steht da "Ich esse Pizza". Natürlich macht unsere menschliche Intuition das ganze automatisch und viel schneller. Aber ich würde einfach mal ohne Beweis behaupten, dass das Gehirn diese Prozedur trotzdem durchläuft, wenn auch fast unmerklich.

Gut, wir haben also gesehen dass natürliche Sprachen nach gewissen Regeln generiert werden, das ganze kann man natürlich auch formalisieren. Es sei aber vorher erwähnt, dass natürliche Sprachen in der Regel weitaus komplizierter als formale Sprachen sind. Es gibt so viele Sonderregeln und Abweichungen, dass die entsprechende formale Sprache riesig groß und kompliziert wäre. Das ändert aber nichts an der Tatsache, dass natürliche Sprachen im Grunde nur ein Spezialfall einer formalen Sprache ist.

Wie definiert man aber eine Sprache formal? Nun, zunächst brauchen wir ein Alphabet. In Deutsch wäre das vielleicht so etwas wie A = {a,b,...,y,z,A,B,...,Y,Z,ä,ü,ö,Ä,Ü,Ö,ß}. Es gehören außerdem Satzzeichen dazu, denn alles was so allgemein in einem Satz vorkommen kann, muss auch im Alphabet auftauchen.

Machen wir es uns aber etwas einfacher, ohne dabei an Bedeutung zu verlieren. Unser Alphabet ist {A,B,C}. Dann ist ein "Wort" eine Aneinanderreihung von validen Buchstaben, zum Beispiel ABBAC. Der nächste Begriff den wir benötigen ist "Sprache". Das ist eine Menge von Wörtern, z.B. {AB, AABB,CCC}. Auch das ist analog zu natürlichen Sprachen. Wir könnten auch im deutschen Alphabet z.B. "hudZ8,," generieren, aber das würde nicht zu unserer Sprache gehören. Genauso könnten wir in der formalen Sprache "ABCCA" generieren, aber das gehört ebenfalls nicht zur Sprache.

Sprachen bezeichnet man in der Regel mit L = {..}, man könnte aber auch unendlich große Sprachen definieren, zum Beispiel als L2={w| w beginnt mit A und endet mit C}. Da steht in Worten: "L2 besteht aus allen Wörtern w, die der Bedingung hinter dem vertikalen Strich genügen". Diese Sprache wäre also {AC, AAC, ABC ACC, AABC,...}

Das letzte was ich noch ansprechen möchte sind die so genannten Produktionsregeln. Diese sind ein bischen abhängig vom Typ der Sprache, allgemein kann man aber sagen, dass wir formale Sprachen immer irgendwie generieren wollen. Bisher haben wir das intuitiv gemacht, aber das funktioniert nur begrenzt oft. Nehmen wir L2 und defineren ein paar Hilfssymbole. Zum Beispiel brauchen wir ein Startsymbol, das nicht zur Sprache gehören darf. In der Regel nennt man das "S". Wenn wir jetzt ein Wort aus der Sprache generieren wollen, fangen wir beim Startsymbol an und schreiben das auf ein Blatt Papier.

Und jetzt kommen die Produktionsregeln ist Spiel. Wir müssen uns ein paar einfach Regeln ausdenken, wie jedes Wort aus L2 zu erzielen ist. Wir wissen schon einmal, dass jedes Wort ein A am Anfang und ein C am Ende haben muss. Was läge also näher als S-> AYC? Wenn man das S auf dem Blatt stehen hat, kann man mit dieser Regel das S in AYC umwandeln. Dabei ist wichtig zu beachten, dass A und C Buchstaben aus dem Alpabet sind und das Y eine Variable. Für diese Variable definieren wir weitere Regeln, denn in der Mitte des Wortes ist es uns egal was da steht. Nehmen wir also Y->AY, Y->BY, Y->CY und . Die ersten drei Regeln generieren einen Buchstaben und packen wieder ein Y mit rein, so dass wir  wieder irgendeinen Buchstaben generieren können. Die letzte Regel ist eine Spezialregel, denn das epsilon steht für das leere Wort, also ein Wort ohne Buchstaben. Wenn man diese Regeln anwendet endet die Generierung, denn das Y fällt dann raus.

Fassen wir also zusammen:

A= {A,B,C}, L2={w| w beginnt mit A und endet mit C}

Produktionsregeln P= { S-> AYC, Y->AY, Y->BY, Y->CY, }

Man kann leicht sehen dass die Produktionregeln die Sprache erzeugen, aber hier noch ein Beispiel: Generieren wir mal ABAC.

S-> AYC ->ABYC -> ABAYC -> ABAC. Man beachte, dass bei der letzten Regel das Epsilon einfach wegfällt. Es ist das leere Wort, das taucht nur symbolisch in den Regeln auf, aber nicht im Wort.

Ein Beispiel habe ich noch, diesmal etwas "praxisnäheres". Das Alphabet A ist A={0,1,} und L3={w| w hat 8 Buchstaben}. Die validen Wörter sind also beliebige Bitstrings mit immer 8 Bits. Das mag nicht spekakulär aussehen, ist aber ganz schön verzwickt. Die Produktionsregeln {S->0S, S->1S, S->} funktionieren offensichtlich nicht, denn sie erzeugen Bitstrings beliebiger Länge. Es stellt sich mit ein wenig Nachdenken heraus, dass die einzig möglichen Produktionsregeln aussehen wie {S->00000000, S->00000001, ... ,S->11111111}. Das ist natürlich sehr unschön, denn das sind natürlich 2⁸ Regeln. Ein Computer allerdings (oder sein theoretischer Gegenpart, die Turingmaschine) kann das ganze in einer simpler Schleife in Millisekunden abarbeiten. Hier ist offensichtlich eine einfach aussehende Sprache strukturell schwieriger als die bisherigen. Und das soll der Cliffhanger für die nächsten Folgen bleiben ;)

Jetzt wo wir also wissen wie man formale Sprachen definiert und generiert, schauen wir uns in einem späteren Posting mal an, was es bedeutet wenn eine Sprache entscheidbar ist und welche Sprachen von Turingmaschinen entscheidbar sind. Später beschäftigen wir uns dann mit anderen Automatenmodellen, Chomsky-Hierachien und vielleicht noch mit Beweismethoden wie dem Pumping-Lemma.

Eigentlich hatte ich das P vs. NP Problem bereits abgeschlossen, aber es gibt da so eine Sache, die gehört zum Thema einfach dazu. Außerdem ist es eine großartige Sache um damit auf Cocktailpartys Wissen raushängen zu lassen.

Also, wir hatten ja festgestellt, dass Probleme aus NP in polynomieller Zeit auf nichtdeterministischen Turingmaschinen entschieden werden können. Die P vs. NP Frage ist jetzt, ob die Problemklassen P und NP gleich sind oder nicht. Essentiell heißt das, dass wir nicht wissen, ob es für heutzutage praktisch nicht effizient lösbare Probleme wirklich keinen effizienten Algorithmus gibt, oder ob wir ihn nur einfach noch nicht gefunden haben. Nun ist es ziemlich schwierig, untere Schranken zu finden. Ich nehme da immer gerne das Beispiel mit der Orangenkiste. Man stelle sich vor, man will möglichst effizient Orangen in eine Kiste packen. Dabei kommt es natürlich zu Luft zwischen den einzelnen Kugeln. Was ist die optimale Packstrategie? Einfach zufällig reinwerfen, die Orangen wie Blöcke übereinander stapeln oder die Orangen leicht versetzt anordnen, so dass sie gegenseitig die Hohlräume füllen? Intuitiv würden wir natürlich die letztere Möglichkeit wählen, aber können wir denn sicher sein, dass nicht in 2000 Jahren irgendein schlauer Mensch daher kommt und eine revolutionäre Idee hat? Hierzu braucht man untere Schranken, man will mathematisch beweisen, dass es kein besseres Verfahren geben kann. Das ist natürlich eine ganze Ecke schwieriger, denn man muss ja auch alle Fälle ausschließen können, die man noch nicht kennt.

Das ist auch im Grunde das Problem bei P vs. NP. Beide Komplexitätsklassen beinhalten eine Menge Probleme, aber wir können nicht erwarten, wirklich alle Probleme bereits identifiziert zu haben. Wie können wir also z.B. P=NP behaupten, wenn wir vielleicht morgen ein Problem entdecken, das in NP aber nicht in P ist? Anders herum: Wir können auch nicht einfach P!=NP sagen wenn wir ein Problem haben, das in NP, aber nicht in P ist. Es könnte ja einen Algorithmus geben, den wir nur noch nicht entdeckt haben.

Der Ausweg sind so genannte Reduktionen. Wenn man Problem A auf Problem B reduziert, bedeutet das, dass man die Eingabe für Problem A so umbasteln kann, dass man sie in einen Algorithmus für Problem B füttern kann, der das Problem löst und dabei die Antwort für A liefert. Ein Beispiel hilft wie immer:

Problem A ist "Ist die Zahl x gerade?". Problem B ist "Ist x mod 2=1?". Nun, für uns mit unserer menschlichen Intuition sehen die Probleme gleich aus, denn eine gerade Zahl modulo 2 ist eben immer null. Aber unsere Intuition macht nichts anderes als eine Reduktion. Wenn wir Problem A lösen wollen, rechnen wir eigentlich x mod 2 und entscheiden Aufgrund dieser Rechnung (des Problems B!) das Problem A. Und damit (und hier kommt der Knackpunkt), ist das Problem A in der gleichen Zeit entscheidbar wie B. Wenn B einen O(n) Algorithmus hat, dann ist auch A in dieser Zeit entscheidbar. Nicht für alle Probleme allerdings ist das so offensichtlich wie hier, es gibt teilweise die abenteuerlichsten Reduktionen. Wer hätte z.B. gedacht dass Tetris komplexitätstechnisch so schwer ist, wie die optimale Anordnung von Sicherheitskameras zu finden?

Zurück zu den unteren Schranken. Sicher wäre es doch äußerst praktisch, wenn man sagen könnte, dass ein Problem das schwerste aus NP ist. Dann könnte wir nämlich sagen, dass wir nur noch einen P-Algorithmus für dieses schwerste Problem finden müssten. Wenn sich dieses allerschwerste Problem nämlich effizient lösen ließe, müssten einfachere Probleme aus NP ja wohl auch effizient lösbar sein. Und interessanterweise hat Stephen A. Cook bewiesen, dass es ein Problem gibt, das das schwerste in NP ist. Das ist natürlich überraschend, denn auch hier muss man ja über potentiell noch nicht entdeckte Probleme argumentieren, trotzdem schafft dieser großartige Beweis genau das.

Wie immer reiße ich die Beweisidee nur kurz an, denn die Details dürften nur sehr wenige interessieren. Wer näheres Wissen will schreibt mir eine Mail oder kauft sich ein Buch über theoretische Informatik ;)

Das schwerste Problem aus NP heisst "SAT" und hat nichts mit deutschen Fernsehsendern zu tun. Das Kürzel steht viel mehr für "satisfiability". Stellen wir uns eine Klausel aus boolschen Variablen vor. "x₁" wäre so eine Klausel mit nur einer Variablen. x1 AND x2 wäre eine andere, auch (x₁ AND x₃) OR (x₅ AND x₁ AND NOT(x₃)) ist so eine. Die Frage die das SAT-Problem stellt ist: Ist diese Klausel erfüllbar? D.h. gibt es eine Belegung von Variablen, wo die ganze Klausel "true" wird? x₁ AND NOT(x₁) zum Beispiel ist trivialerweise nicht erfüllbar. Es gibt nur eine Variable, und wenn diese 1 wäre, wäre der NOT(..) Teil nicht mehr erfüllbar und umgekehrt. Dieses Problem ist aus NP, wir kennen keine bessere Idee als "Belegungen ausprobieren". Im schlechtesten Fall müssen wir deshalb alle möglichen Belegungen ausprobieren und das sind exponentiell viele. Deshalb ist es auf TMs nicht effizient lösbar.

Warum ist SAT jetzt das schwerste Problem im NP? Ganz einfach, Turingmaschinen lassen sich auf trickreiche Weise in Boolschen Ausdrücken codieren. Dabei stellt man durch allerlei Kniffe sicher, dass eine sehr lange Klausel entsteht, die genau und ausschließlich dann erfüllbar ist, wenn die Turingmaschine terminiert und ein Ergebnis liefert. Dann löst man diese Klausel auf und sieht: Wenn die Klausel erfüllbar ist, dann liefert die codierte TM "true", sonst "false". Und diese Idee ist geradezu genial, denn wer würde schon darauf kommen, ein so umfangreiches Modell wie eine TM in eine lange boolsche Formel umzusetzen um das Ergebnis der SAT Berechnung als Ergebnis der TM zu nehmen?

Aber warum ist damit SAT das schwerste Problem aus NP? Nun, man stelle sich ein schwereres Problem als SAT vor, so ein richtig scheiße schweres Problem. Der Michael Moore unter den Problemen. Nun könnte man doch einfach die entsprechende TM in eine Klausel umbasteln (und der Satz von Cook stellt sicher dass das in poynomieller Zeit passiert). Wenn man diese Klausel hat, kann man sie in den SAT Problemlöser füttern, der dann das Ergebnis berechnet. D.h. also, dass jedes noch so schweres NP-Problem nicht schwerer zu lösen sein kann als SAT. Und das ist genial, denn wir haben damit das schwerste Problem aus NP identifiziert.

Und die Implikationen sind enorm, denn jetzt können wir die oben angesprochene Reduktion anwenden und wiederum SAT-Eingaben in Eingaben von anderen Problemen umbasteln. Z.B. gibt es ein Problem, das DHC heisst. Wenn wir ein DHC-Probleminstanz so bauen können, dass ein DHC-Algorithmus genau dann "wahr" entscheidet, wenn die Klausel vom SAT "wahr" entscheiden würde, könnten wir auch DHC als "schwerstes" Problem identifizieren. Nun, schwerer als SAT kann es aber auch nicht sein, also müssen beide Probleme gleich schwer sein. Solche Probleme heißen NP-Vollständig. Sie gehören einer Unterklasse von NP an, die die schwersten Probleme aus NP umfasst. Tausende Probleme sind NP Vollständig und wenn man auch nur für ein einiziges von diesen einen P-Algorithmus finden würde, hätte man automatisch P=NP bewiesen. Denn wenn ein schwerstes Problem aus NP effizient lösbar wäre, wären es auch alle einfacheren. Der Fakt allerdings, dass für kein einziges dieser tausenden Probleme ein guter Algorithmus existiert, lässt wenig Hoffnung übrig, dass es einen solchen gibt

Viele meiner Suchanfragen lassen vermuten, dass einige Informatikstudenten im ersten Semester händeringend nach Beispielen suchen, wie man mit der O-Notation umgeht. Ich werde hier ein Beispiel durchrechnen, in der Hoffnung dass es jemandem hilft. Lasst doch ein Kommentar da wenn das der Fall ist ;)

Also, neben der informellen Beschreibung der O-Notation gibt es natürlich auch den streng formalen Weg. Zunächst nehme ich mir mal den Bubble-Sort heraus und kopiere den Pseudocode von Wikipedia:

prozedur bubbleSort( A : Liste sortierbarer Elemente ) definiert als:
  n := Länge( A ) - 1
  wiederhole
    vertauscht := falsch
    für jedes i in 0 bis n wiederhole:
      falls A[ i ] > A[ i + 1 ] dann
        vertausche( A[ i ], A[ i + 1 ] )
        vertauscht := wahr
      falls ende
    für ende
    n := n - 1
  während vertauscht
prozedur ende

Jetzt analysieren wir, wie man diesen Algorithmus bezüglich der O-Notation klassifizieren muss. Zunächst einigen wir uns darauf, dass wir nur Zuweisungen, Additionen und Vertauschungen (was ja auch nur Zuweisungen sind) als Rechenschritt zählen. Alles andere kostet natürlich auch Zeit, macht aber verhältnismäßig wenig aus.

Also los: Zeile zwei ist eine Zuweisung, das ist ein Rechenschritt. Alles was zwischen Zeile drei und  zwölf steht  wird wiederholt, und zwar so lange bis das Array sortiert ist. Wann ist das im schlimmsten Fall passiert? Natürlich wenn das Array umgekehrt sortiert ist. Denn dann muss das vorderste Element nach hinten und umgekehrt. Da Bubble-Sort immer nur direkte Nachbarn vertauscht, muss jedes Element also ganz durchgeschoben werden. Also weiter, das erste Element muss also ganz nach hinten, braucht dafür n Durchläufe der "für"-Schleife. Pro einen solchen Durchlauf brauchen wir einen Vergleich, eine Vertauschung und eine Zuweisung. Wir sind also im Moment bei . Dann wird noch das n heruntergezählt und dann wird die "wiederhole"-Schleife durchlaufen. Das passiert auch n-Mal in unserem worst-case.

Da bekommen wir also und damit . Gut, wie erwartet ist das eine quadratische Laufzeit, bleibt nur noch formal zu zeigen dass das auch wirklich ist. Dafür ist natürlich zunächst die formale Definition nötig, die sieht so aus:

Da steht also folgendes: Es gibt eine Funktion g, die schneller oder gleich schnell als unsere Funktion f wächst. Dazu multiplizieren wir noch eine Konstante c dran, die wir uns für den Beweis wählen können. Plastischer wirds erst, wenn ich das mal eben für das Beispiel durchführe.

Jetzt muss ich nur noch ein c und ein finden, für das die obige Gleichung gilt, dann gilt es auch für alle größeren n und der Beweis ist geführt. Dafür dividiere ich aber erst durch , dann wird es einfacher:

Ich wähle und c=5, die Gleichung ist erfüllt und es ist leicht zu sehen, dass sie auch erfüllt bleibt, wenn das n größer wird. Ab dem bleibt die Bubble-Sort Funktion also immer im -Bereich, Beweisende.

Im Gegensatz zu den bisher betrachteten deterministischen Algorithmen gibt es die so genannten randomisierten Algorithmen. Dazu wird ein Zufallsgenerator benutzt und der weiter Verlauf des Algorithmus von diesem abhängig gemacht. In der Realität gibt es natürlich Zufallsgeneratoren beliebiger Qualität, aber in der Theorie beschränken wir uns mal wieder auf das kleinste Vorstellbare: Unser Zufallgsgenerator produziert perfekt zufällige Bits. In jedem Rechenschritt genau eins.

Aber vielleicht ist dem ein oder anderen noch nicht einsichtig, warum wir eigentlich randomisierte Algorithmen brauchen, schließlich produzieren sie Fehlerquellen und nehmen uns doch eine große Portion der Sicherheit, dass der Algorithmus das macht was er soll. Am Besten hilft auch hier ein Beispiel. Wenn beim Quicksort-Algorithmus immer deterministisch das letzte Element als Pivot-Element nimmt und die Eingabe vorsortiert ist, ist die Laufzeit O(n²). Und das wo doch gerade Quicksort normalerweise O(n*log(n)) macht. Da der Speziallfall der sortierten Liste nicht gerade selten vorkommt, ist das Verhalten natürlich sehr ungünstig. Und einfach das erste Element als Pivot zu nehmen verschiebt das Problem auch nur. Die Lösung ist, einfach ein zufälliges Element zu wählen. Auch da kann es natürlich ganz blöd laufen und O(n²) brauchen, aber die Wahrscheinlichkeit ist doch sehr gering, denn dazu müsste immer zufällig genau das Element gewählt werden, das im unsortierten Teil am größten ist. Hier trägt randomisierung also dazu bei, dass es in den meisten Fällen eine gute durschnittliche Laufzeit gibt.

Ein anderes prominentes Beispiel ist der Primzahltest von Solovay-Strassen. Hier wird am Anfang eine zufällige Zahl gewählt und die zu prüfende Zahl damit "bearbeitet". Die genauen Schritte wären hier jetzt zu schwierig, aber auch hier ist es praktisch unmöglich, eine "fest einprogrammierte" Zahl zu finden die man benutzen kann, denn es würde Primzahlen geben, bei denen der Algorithmus immer "dies ist keine Primzahl" sagen würde. Der Algorithmus würde ohne Randomisierung also nichtmal korrekt funktionieren.

Wir sollten uns also darüber einig sein, dass Algorithmen mit einem Zufallselement sinnvoll sind. Wir erweitern unsere Turingmaschine also dahingehend, dass die Zustandsübergangsfunktion nicht nur davon abhängt in welchem Zustand wir sind und welches Zeichen wir lesen, es wird jetzt auch noch in jedem Rechenschritt ein Zufallsbit generiert. Damit verdoppelt sich zwar die Zahl der Übergänge, aber dass Turingmaschinen in der Praxis eh untauglich sind wissen wir ja auch.

Jetzt habe ich ja im letzten Beitrag mit den Komplexitätsklassen sozusagen die letzte Abstraktionsstufe erreicht und da passt es natürlich nicht, dass wir wieder in die Tiefen der Turingmaschine gehen. Deshalb gibt es natürlich auch randomisierte Komplexitätsklassen und eine davon besprechen wir jetzt noch kurz, nur um zu sehen wie man Beziehungen zwischen den Klassen herstellt.

Wir definieren: Die Komplexitätsklasse ZPP(f(n)) umfasst alle Algorithmen, die auf einer randomisierten TM ausgeführt werden können und wo die Fehlerwahrscheinlichkeit durch f(n) beschränkt ist. Algorithmen in ZPP können entweder das richtige Ergebnis oder "?" ausgeben.

Das klingt jetzt vielleicht etwas hölzern, eigentlich geht es nur darum, dass ZPP-Algorithmen vielleicht nicht zu einem Ergebnis kommen und dann "keine Ahnung" ausgeben. Wenn es aber ein Ergebnis gibt, ist es sicher richtig. Die Wahrscheinlichkeit dass ein ? ausgegeben wird, ist dabei durch f(n) angegeben und damit gibt es im Prinzip unendlich viele ZPP-Klassen. Es gibt ZPP(1/4), ZPP(1), ZPP(1/2) usw. Dabei ist ZPP(1/4) natürlich eine Untermenge von ZPP(1/2), denn wir hatten ja gesagt, dass die Fehlerwahrscheinlichkeit durch f(n) beschränkt ist, es geht also darum, dass f(n) ausdrückt was der schlechteste mögliche Fall ist.

Denken wir kurz darüber nach, was ist denn ZPP(0)? Ein randomisierter Algorithmus, der nie einen Fehler macht, also immer das richtige Ergebnis liefert. Klingt nach der Definition von P. Damit ist P=ZPP(0) und damit eine Untermenge von ZPP(f(n)). Was ist ZPP(1)? Komplett sinnlos, denn diese Algorithmen geben immer "?" aus.

Wenn man jetzt noch weiter nachdenken wollte, könnte man darauf kommen, dass man einen ZPP(1/4)-Algorithmus ja auch einfach zweimal laufen lassen kann, dann wäre die Wahrscheinlichkeit für ein ? nur noch 1/16. Was würde uns denn daran hindern, den Algorithmus einfach so oft auszuführen bis wir kein ? mehr bekommen? Doch nur die exponentielle Grenze, denn irgendwann müssen wir den Algorithmus im Wesentlichen exponentiell oft laufen lassen um ein Ergebnis erwarten zu können. Das ist der Fall wenn f(n) > 1/2, also können wir mit dieser Technik sagen, dass eigentlich alls Algorithmen mit ZPP(1/2) gleich sind. ZPP(1/4), ZPP(1/3) und ZPP(1/2) unterscheiden sich nur dadurch, dass man hier und da eventuell mehrere Durchläufe braucht. Da aber die Laufzeit je Durchlauf polynomiell ist, bleibt die Laufzeit insgesamt auch polynomiell. Nur wenn wir eine exponentielle Anzahl von Durchläufen brauchen, kommen wir insgesamt auf exponentielle Laufzeit (das ist dann bei f(n)>1/2 der Fall).

Mit diesem Wissen kürzen wir ZPP(1/2)=ZPP ab und erkennen P als kleine Unterklasse von ZPP. ZPP mit Fehlerwahrscheinlichkeit >1/2 nennt man ZPP*, aber diese Klasse ist relativ uninteressant. Im nächsten Eintrag wird es dann um andere Komplexitätsklassen gehen, die tatsächlich Fehler machen können (im Sinne von: Das Ergebnis kann falsch sein). Und wenn wir diese Klassen kennen und die Verbindung zu Nichtdeterminismus hergestellt haben, können wir die P vs. NP-Frage endlich verstehen.

Noch ein letzter Satz, mit dem man auf Partys wunderbar angeben kann: Diese Technik des "mehrfachen Ausführens" nennt man probability amplification. Wenn man das in einen Satz mit "Komplexitätstheorie", "polynomielle Laufzeit" und "randomisierte Turingmaschine" bringt, kann man sicher sein, dass man von allen anderen Partygästen bis auf weiteres gemieden wird.

Im letzten Beitrag hatte ich ja erklärt, dass man Algorithmen äußerst weit abstrahiert um sie vergleichen zu können. Das lag daran, dass man bestimmte Faktoren einfach nicht einbeziehen darf, weil sonst nicht mehr Algorithmen verglichen werden würden, sondern CPU-Power oder Betriebssysteme. Wir haben das gemacht, um später überhaupt eine Argumentationsbasis zu haben. Wenn wir sowas sagen wie "Das Problem A lösen wir mit Algorithmus B in O(log(n))", dann geht das nur weil wir uns überhaupt auf die O-Notation und deren Vergleichbarkeit geeinigt haben. Jetzt liegt es natürlich nahe ein möglichst allgemeingültiges Computermodell zu entwickeln, um eben diese Vergleichbarkeit zu erreichen.

Das was man üblicherweise benutzt ist die sogenannte Turingmaschine (kurz: TM). Diese wurde 1936 von Alan Turing entwickelt, was insofern bemerkenswert ist, als dass es da noch keine echten Rechner gab. Ich nehme mal die "Auflösung" vorweg: Turingmaschinen bilden genau unsere aktuellen Rechner ab, d.h. man kann Algorithmen mit akzeptablem Aufwand von einem Athlon64 zu einer Turingmaschine übertagen. Was ein akzeptabler Aufwand ist, darüber handelt der nächste Beitrag. Und dass sich keiner wirklich die Mühe macht, TM-Programme zu schreiben, soviel sei auch schon gesagt. Das ist auch nicht nötig. Wichtig ist, dass man damit eine gemeinsame Argumentationsbasis hat. Dann schauen wir uns Turingmaschinen also mal konkret an.

Jedes dieser Zellen steht für eine Speichereinheit, die Punkte links und rechts deuten an, dass die Speichergröße unendlich ist (den Speicher nennt man "das Band"). Das macht für uns erstmal keine Probleme, auch wenn es natürlich möglicherweise nicht komplett realistisch ist. Die TM hat eine Startposition, auf der hier der Lese/Schreibkopf steht. Dieser kann sich in jedem Rechenschritt entweder nach links oder rechts bewegen, oder dort bleiben wo er gerade ist. Der Rechenschritt läuft so ab: Der Kopf liest die aktuelle Zelle, berechnet die Ausgabe, schreibt etwas in die aktuelle Zelle und bewegt sich.

Aber wie berechnet die TM die Ausgabe? Dafür gibt es die Menge der Zustände . Für jedes mögliche Symbol, das auf dem Band steht, definiert man jetzt einen Zustandsübergang. Am Anfang ist man im Zustand , und für jedes Symbol (üblicherweise 0 oder 1) sagt man sowas wie "wenn 0 gelesen wird, schreibe ein Leerzeichen (auch "B" für "Blank" genannt) und bewege dich nach rechts". Oder "wenn 1 gelesen wird, schreibe die 1 zurück und bewege dich nach links". Die Bewegung wird gerne mit -1 (links), 0 (stehen bleiben) und 1 (rechts) bezeichnet. Aber auch L,0,R ist üblich.

Vielleicht macht ein Beispiel das etwas klarer. Sagen wir, auf dem Band steht "010011" und wir wollen alle nullen löschen. Wir sind ja im Zustand , wenn wir hier eine null lesen, löschen wir sie und gehen weiter. Also In der ersten Klammer stehen der Zustand in dem wir uns befinden und das gelesene Zeichen. Der Pfeil deutet den Zustandsübergang an, man kann das so lesen: "Wenn wir uns in befinden und 0 lesen, gehe nach , schreibe ein Blank und gehe 1 weiter". Was passiert aber wenn 1 gelesen wird? Nun, das müssen wir auch definieren, nämlich so: . Wenn eine 1 gelesen wird, schreiben wir sie zurück und gehen weiter. Der letzte Zeichen das gelesen werden kann ist das Leerzeichen B: . Wenn das B gelesen wird sind wir logischerweise am Ende angekommen, also schreiben wir das B zurück und bleiben wo wir sind. Jetzt würde die TM unendlich weiter rechnen, diesen Umstand interpretieren wir als "wir haben zu Ende gerechnet". Diese drei Regeln sind sozusagen die Programmierung der Turingmaschine. Wichtig ist, dass man für jedes Zeichen, das auf dem Band vorkommen kann auch einen Zustandsübergang definiert.

Das war jetzt kein Entscheidungsproblem, wenn man ein solches hat, wird normalerweise gefordert, dass man die Eingabe komplett löscht und eine 0 oder 1 (wahr oder falsch) an die erste Position schreibt. Im obigen Beispiel kamen wir mit einem Zustand aus, normalerweise hat man mehrere. Man kann sich z.B. leicht vorstellen, dass man zählen will, ob auf dem Band genau so viele einsen wie nullen stehen. Dann würde man z.B. eine null lesen, in Zustand gehen, so lange weiter gehen bis man eine 1 findet, wieder in gehen und so weiter. Der Fakt, dass man in ist, würde anzeigen, dass man eine null gelesen hat und nach einer eins sucht. Zugegeben, es wäre ein bisschen komplizierter als das, denn wir müssten natürlich auch noch zurück laufen, weil man potentiell ein paar Zahlen überspringt beim "nach einer 1 suchen". Jetzt sollte auch klar sein, warum kaum einer Algorithmen auf TMs schreibt. Man stelle sich einen Sortieralgorithmus vor und die wahnsinnige Anzahl der Zustände die man bräuchte. Man kann aber zeigen, dass alle Algorithmen auf normalen Computern prinzipiell auch auf TMs berechnen könnte, man kann also ohne Probleme TMs als Argumentationsbasis nehmen, denn hier gibt es keine Variablen wie CPU-Geschwindigkeit.

Formal ist eine TM ein Tupel:

Hierbei steht Q für die Menge der Zustände, das Sigma für das Eingabealphabet. Das Gamma steht für das Bandalphabet (normalerweise ist das das Eingabealphabet plus das B). Das delta ist die Zustandsübergangsfunktion, beschreibt also mathematisch, was die TM macht. Zuletzt muss noch der Startzustand angegeben werden.



Turingmaschinen sind für das P vs. NP Problem zugegebenermaßen nicht wahnsinnig wichtig. Später definieren wir noch eine nichtdeterministische TM, aber eigentlich muss man sich nur einig sein, dass man ein Computermodell hat, dass Vergleichbarkeit sicherstellt. Wer sich wirklich mit TMs auseinandersetzen will, dem seien die Stichworte Automatentheorie und Chomsky-0 ans Herz gelegt.