Architectures of Model Elimination Implementations
Werbung
Seminar: Inferenzmethoden – SS 2005 Universität Potsdam Thomas Rabenalt Architectures of Model Elimination Implementations UNIVERSITÄT POTSDAM – SEMINAR: INFERENZMETHODEN SOMMERSEMESTER 2005 THOMAS RABENALT Architectures of Model Elimination Implementations Seite 1 Seminar: Inferenzmethoden – SS 2005 Universität Potsdam Thomas Rabenalt Einleitung Diese Ausarbeitung beschäftigt sich mit grundsätzlichen Ansätzen für die Implemetation von Modelleliminationen. Dabei werden im Folgenden der Prolog Technologie Theorem Prover (PTTP) genauer vorgestellt. Seitdem hocheffiziente Implementierungstechniken für Prolog entwickelt wurden, ist es möglich, darauf aufzubauen und einen Theorem-Beweiser zu bauen, der auf Prolog aufsetzt. Dieser Ansatz wird mit PTTP umgesetzt. Dabei bedient man sich der Tatsache, das die SLD-Resolution auf welcher Prolog basiert, der Modellelimination sehr ähnlich ist. Es gibt nun verschiedene Möglichkeiten sich den Vorteilen von Prolog anzunehmen. Einerseits ist es möglich, auf den hocheffizienten Implementierungstechniken aufzubauen und diese mit den notwendigen Mechanismen für eine korrekte und vollständige Modellelimination anzureichern. Anderseits ist es auch möglich, Prolog selbst als Implementationssprache zu verstehen, mit der Hoffnung, das seine Anlehnung an die Modellelimination eine kurze und effiziente Möglichkeit für eine entsprechende Beweisprozedur ermöglicht. Datenstrukturen Bevor wir jedoch zum Prolog Technology Theorem Prover kommen, soll zunächst ein kurzer Blick auf die zugrundeliegende Datenstruktur geworfen werden. Obwohl die Datenstrukturen nicht zwingend notwendig für das Verständnis von Modellelimination sind, ist es dennoch sinnvoll, zumindest ein grobes Verständnis davon zu erlangen. Betrachten wir zunächst die Repräsentation von Formeln. Im Prinzip werden Terme, Literale, Variablen und Klauseln durch einen Baum repräsentiert. Interne Variablen werden dabei typischer Weise als Struktur, bestehend aus ihren Namen und ihrem aktuellem Wert, gehalten. Dabei symbolisiert nil, dass die Variable derzeit ungebunden ist. Die Identifikation und Unterscheidung der Variablen geschieht dabei nicht über ihre Namen, sondern über die Adressen der Strukturen. Die folgende Abbildung zeigt die Repräsentation der Klausel P a , f x , x∨¬Q b , g g x Abbildung 1 - Repräsentation einer Klausel Anmerkung: a, b sind Konstanten, x ist eine Variable, f und g sind Funktionen Architectures of Model Elimination Implementations Seite 2 Seminar: Inferenzmethoden – SS 2005 Universität Potsdam Thomas Rabenalt Die zweite Datenstruktur, die beleuchtet werden soll, ist der so genannte Konnexionsgraph (connection graph). Die Konnexionsbedingung ist eine elementare Bedingung für den Extensionsschritt der Modellelimination. Deshalb ist es von Vorteil, wenn man in der Lage ist, sehr schnell die komplementären Literale zu einem speziellen Teilziel finden zu können. Dies wird durch den einen ungerichteten Graphen, dem Konnexionsgraphen, geleistet. Betrachten wir hierzu die folgenden Klauseln ¬P g x∨¬Q f x∨¬Q g x , P f a Q x∨P f x und Q g y∨P f y . Die Abbildung 2 zeigt den zugehörigen Konnexionsgraphen. Dabei repräsentieren die blauen Linien die Konnexion zwischen den Literalen. Die gestrichelten grauen Linien hingegen markieren Literale, die trotz gleichem Prädikatensymbol und komplementären Vorzeichen nicht unifizierbar sind und deswegen nicht miteinander verbunden werden können. Diese Markierung hat den Vorteil, dass wenn man beispielsweise das Literal ¬P g x für einen Extensionsschritt auswählt, man sofort erkennt, dass man die Klausel Q g y∨P f y nicht mehr berücksichtigen muss. Abbildung 2 - Konnexionsgraph Prolog Technology Theorem Prover (PTTP) Die Prolog Technology Theorem Prover benutzen Prolog als Grundlage und stellen eine Erweiterung dieser Technologie dar. Ein Problem, welches Prolog besitzt (und somit als allgemeinen Theorem-Beweiser ausschließt) ist, dass die zugrunde liegende SLD-Resolution nicht Vollständig für Prädikatenlogik erster Stufe ist. Weiterhin muss der nicht korrekte Unifikationsalgorithmus als auch die verwendete unbegrenzte Tiefensuche verbessert werden. Trotzdem bildet Prolog eine sehr interessante Grundlage für Theorem-Beweiser, da es im Vergleich zu konventionellen Beweisern sehr schnell arbeitet. Aus diesem Grund unterscheidet sich PTTP von Prolog durch die Verwendung von korrekter Unifikation unter Zuhilfenahme eines occurs check, einer vollständigen Inferenzregel für Modellelimination anstelle der Prolog-Inferenz und einer iterativen Tiefensuche anstelle einer unbegrenzten Tiefensuche. Eine derartige Umsetzung hat den Vorteil, dass man die selben Implementationsideen wie die des zugrundeliegenden Prologsystems verwenden kann. Damit ist man in der Lage, die gute Prolog Performance beizubehalten. Architectures of Model Elimination Implementations Seite 3 Seminar: Inferenzmethoden – SS 2005 Universität Potsdam Thomas Rabenalt Die typische Arbeitsweise eines PTTP erfolgt in zwei wesentlichen Schritten. Formeln (Prädikatenlogik erster Stufe) werden durch den PTTP-Compiler in Prolog-Klausen übersetzt. Das heißt, es wird durch diesen PTTP-to-Prolog Compiler reiner Prolog Code erzeugt. Die so erzeugten Klauseln werden dann durch den Prolog-Compiler typischer Weise in eine Mashinencode übersetzt. Es gibt auch Ansätze, die anstelle eines PTTP-to-Prolog Compilers einen PTTP-to-LISP Compiler verwenden. Diese Möglichkeit hat jedoch den Nachteil, dass der dadurch entstandene LISP Code deutlich größer ist und die weitere Kompilation deutlich mehr Zeit in Anspruch nimmt. Weitere Vorteile für den Prolog Ansatz sind zum Beispiel, dass das Backtracking bereits eine StandardFähigkeit von Prolog ist oder die einfachere Modifizierbarkeit gegenüber LISP. Im Folgenden sollen nun kurz die Ideen erläutert werden, wie Formeln (Prätikatenlogik erster Stufe) in Prolog-Klausel überführt werden können, sodass man anschließend, bei Ausführung des Prolog-Codes, eine korrekte Methode für das Theorem-Beweisen auf Basis der Modellelimination hat. Dazu sind die folgenden drei Schritt notwendig: (1) Liniarisieren aller Klauselköpfe und Einfügen von Unifikationsopeationen in den Body der Klausel, um eine korrekte Unifikation inklusive occurs check zu erhalten (2) Einfügen notwendiger Elemente für eine schrittweise begrenzte Tiefensuche (3) Ergänzung von Elementen, die eine komplette Inferenzregel für Modellelimination erlauben Weiterhin werden für die korrekte Umsetzung auch noch weitere neue Prolog build-in Prädikate benötigt. Zusätzlich zu den o.g. Punkten sind auch noch weitere Schritte denkbar, die es erlauben einen Beweis optisch darzustellen nachdem er gefunden wurde. Hierauf wird aber im weiteren Verlauf nicht weiter eingegangen. Unifikation Die meisten Implementation von Prolog benutzen einen sehr effizienten Unifikationalgorithmus, der jedoch unkorrekte Ergebnisse liefern kann. Beispielsweise kann mit dem folgenden Programm bewiesen werden, dass es eine Zahl gibt, deren Nachfolger kleiner ist als sie selbst bzw. das eine Person gleichzeitig auch eines seiner Elternteile ist. X < ( X +1 ). :- ( Y + 1) < Y. parent( X , mother(X) ). :- parent( Y, Y ). Der Grund hierfür ist in einem fehlenden occurs check zu suchen, welcher aus Gründen der Effizienz weggelassen wurde. Für eine korrekte Unifikation gibt es verschiedenste Ansätze. Ein interessanter ist folgender. Alle Wiederholungen von Variablen werden durch neue Variablen ersetzt, sodass der Klauselkopf linear wird (d.h. keine Variable tritt doppelt auf). Offensichtlich kann die Unifikation nun ohne occurs check erfolgen und man ist in der Lage, die hohe Effizienz von Prolog auszunutzen. Für die obigen Beispiele ergibt sich somit folgende Änderung: X < ( X1 + 1 ) <- unify( X, X1 ) parent( X, mother(X1) ) <- unify( X, X1 ) Der occurs check muss nun lediglich während der Unifikation von X und X1 durchgeführt werden. Dies wird durch ein neues build-in Prädikat unify erreicht, welches eine korrekte Unifikation gewährleistet. Architectures of Model Elimination Implementations Seite 4 Seminar: Inferenzmethoden – SS 2005 Universität Potsdam Thomas Rabenalt Diese Methode zeigt, dass es sehr leicht möglich ist, Prolog mit einer korrekten Unifikation anzureichern ohne zwingend Änderung am Befehlssatz der virtuelle Maschine von Prolog vornehmen zu müssen. Suchstrategie Prolog scheitert als Theorem-Beweiser, mit Ausnahme von Horn-Klauseln, da viele Probleme nicht mit der in Prolog implementierten unbegrenzten Tiefensuche gelöst werden können. Um die Vollständigkeit auch für Nicht-Horn-Klausel gewährleistet zu können, ist es notwendig die Suchstrategie zu ändern. Eine einfache Möglichkeit ist die schrittweise begrenzte Tiefensuche (depth-first iterative-deepening seach). Das heißt, die Tiefensuche arbeitet zunächst nur bis zu einer vorgegebenen Tiefe, wodurch der Suchraum bis zu dieser Tiefe komplett abgearbeitet wird. Die Vollständigkeit kann nun durch ein schrittweises Erhöhen der Tiefe erreicht werden, solange bis ein Beweis gefunden wurde. Betrachten wir folgendes Beispiel: p(e, X, X). p(U, Z, W) :- p(X,Y,U), p(Y,Z,V), p(X,V,W). Um die neue Suchstrategie umzusetzen ist es notwendig, zwei extra Argumente einzufügen, welche die Tiefe, die bei jedem Inferenzschritt verkleinert wird, vor und nach der Anwendung eines Literals festhält. Erlangt der Wert der Tiefe den Wert Null, so kann kein weiter Inferenzschritt mehr ausgeführt werden. Eine mögliche Erweiterung der Regeln sieht also wie folgt aus. p(e, X, X, DepthIn, DepthOut) :- DepthIn >=1, DepthOut is DepthIn - 1. p(U, Z, W, DepthIn, DepthOut) :- DepthIn >=1, Depth1 is DepthIn – 1, p(X,Y,U,Depth1, Depth2), p(Y,Z,V,Depth2, Depth3), p(X,V,W,Depth4, DepthOut). Obwohl dies so noch nicht der effizienteste Weg ist, demonstriert er jedoch gut die Art und Weise der Umsetzung. Für die komplette Umsetzung der Suchstrategie ist es notwendig, ein weiteres Prädikat, beispielsweise search(Goal, Max, Min, Inc), einzufügen, welches die Suchtiefe schrittweise anpasst. Hierbei wird versucht Goal mit einem Minimum von Min aber maximal mit Max Teilzielen zu beweisen. Inc gibt das Wachstum der Suchtiefe an. Komplettes Inferenzsystem Das Inferenzsystem von Prolog arbeiten in der Form, dass in jedem Schritt versucht wird: • das am weitest links stehende Literal im Body mit Kopf der Regel zu unifizieren • entfernen des am weitest links stehendem Literal aus dem Body • einfügen des Bodys einer Regel, die zu dem Literal passt Kann durch diese Resolution der Body einer Anfrage in eine leere Liste verwandelt werden, so kann kann die Anfrage bewiesen werden. Architectures of Model Elimination Implementations Seite 5 Seminar: Inferenzmethoden – SS 2005 Universität Potsdam Thomas Rabenalt Beispiel: Sei :- q1, q2... , qn der Body einer Anfrage (Liste von Literalen). Dann wird sie mittels Resolution durch p1, ... ,pm,q2, ... ,qn ersetzt, wenn es eine Regel der Form q1 :- p1, ... , pm gibt. Hier stellt sich auch noch ein weiterer wesentlicher Unterschied zu Prolog heraus. Eine Klausel mit n Literalen wird in n verschiedenen Regeln gespeichert. Dies ist notwendig, da man sich leicht vorstellen kann, das eine Klausel in jedem Literal betreten werden kann. Dementsprechend muss man alle so genannten contrapositives einer Klausel L1∨...∨L n beachten. Also alle Li ≤¬L1∧...∧¬Li­1∧¬Li1∧...∧¬L n . (bzw. im Prolog-Stil: Li :­¬Li , ... ,¬Li­1 ,¬Li1 , ... ,¬L n. ). Prologs Unvollständigkeit für Nicht-Horn-Klauseln kann man sich sehr leicht durch folgendes Beispiel vor Augen führen. Man versuche Q mittels P∨Q∧¬P∨Q zu beweisen. Die contrapositives dieser Formel sehen wie folgt aus: q :- not_p. p :- not_q. q :- p. not_p :- not_q. Mittels dieser Wissensbasis ist es Prolog nicht möglich :-q zu beweisen, da die Resolution nie eine leere Liste erzeugen kann. Die Inferenz von Prolog wird nun vollständig gemacht (auch für nicht-Horn-Klauseln) indem die „linear input resolution“-Regel hinzugenommen wird. Die model elimination procedure (ME) ist eine einfache Möglichkeit linear input resolution zu implementieren. Das heißt, wenn das aktuelle goal mit der Negation eines der goals aus dem stack unifiziert werden kann, können wir es als bewiesen betrachten. Anders als das Prolog Inferenzsystem wird dabei das aktuelle Literal nicht aus dem Body der Clausel gelöscht, sondern fügt es zusätzlich als framed literal ein. Das heißt, die als framed markierten Literale, die rechts von Literalen stehen bilden nur die Vorfahren eines Teilziels ab. Somit gehen diese Informationen nicht verloren. Betrachten wir wiederum die Liste der Literale :- q1, q2... , qn. Führen wir nun die äquivalente Inferenzregel zum obigen Beispiel aus so ergibt sich folgendes: :- p1, ..., pm, [q1], q2... , qn Wobei nun p1 bis pm nicht als framed markiert sind und q1 framed ist. Die als framed markierten Literale kann ME nun dazu verwenden, komplementäre Literale zu entfernen (Reduktrions-Regel). Als Besonderheit gilt zusätzlich, dass Literale die als framed markiert sind sofort gelöscht werden, wenn sie in der Liste der Literale ganz links stehen. Architectures of Model Elimination Implementations Seite 6 Seminar: Inferenzmethoden – SS 2005 Universität Potsdam Thomas Rabenalt Betrachten wir nun noch einmal das Beispiel für den Beweis von Q aus P∨Q∧¬P∨Q : :::::- q p, [q] not_q, [p],[q] [p], [q] % % % % % % % Startanfrage Resolente aus q :- p Resolvente aus p :- not_q ME Reduktions-Regel Entfernen aller Literale, die als framed markiert sind, da sie am weitesten links stehen Damit ist die Anfrage :-q bewiesen. Die so implementierte ME Reduktionsregel erlaubt nun also Beweisen durch Widerspruch. Dies sollte einen kurzen Einblick in die Ideen geben, wie man Prolog zu einem vollständigen Theorembeweiser für Prädikatenlogik erster Stufe macht. Gezeigt wurden drei wesentliche Veränderungen, die dafür notwendig sind. Obwohl die PTTP Ansätze die Entwicklung auf diesem Gebiet in den letzten Jahren bestimmt haben, hat die Benutzung von Prolog doch einen entscheidenden Nachteil. D.h. das zugrunde liegende Framework ist einfach nicht flexibel genug und erlaubt somit keine einfache Integration von neuen Techniken und Inferenzregeln. Insbesondere behinderte dies die Integration von effizienten Inferenzmechanismen für das Gleichheitsproblem. Warren Abstract Machine (WAM) Wie bereits angesprochen, arbeiten PTTP-Systeme in zwei wesentlichen Phasen. Zuerst werden die Eingabeformeln in Prolog-Code übersetzt und diese in der zweiten Phase in Maschinencode überführt. Ein Problem welches hierbei auftreten kann ist, dass der zweite Compilierungsvorgang sehr lange dauert. Im Hinblick auf typische Anwendungen ist dies kritisch, da diese kurze Antwortzeiten benötigen. Um dies zu beschleunigen wurde eine sehr restriktive und abstrakte Sprache geschaffen, die speziell auf die Bedürfnisse von Prolog oder Modellelimination zugeschnitten wurde. In den achtiziger Jahren entwickelte D.H.D. Warren eine solche virtuelle Maschine, die für die Ausführung von Prologprogrammen optimiert war. Die Warren Abstract Machine kombiniert dabei eine sehr hohe Effizienz mit guter Portabilität und der Möglichkeit zur Kompilierung von Prolog-Programmen. Dieses System ist heute sehr verbreitet und bildet die Grundlage für viele Prolog-Systeme. Das Architekturmodell ähnelt dabei der, der random access machine RAM. D.h. die WAM wurde als register-based mulit-memory Maschine entworfen. Eine grobes Layout Abbildung 3 - Warren Abstract Machine stellt die Abbildung 3 dar. Zusätzliche zu einigen AssemblerBefehlen verfügt die WAM über spezielle Mechanismen, zum Beispiel zur Unifikation, Backtracking oder Abarbeitung von Prolog-Programmen. Neben einem Registersatz enthält die WAM Speicher zur Verwaltung der Stacks und zum WAMCode. Das heißt, Programme müssen zunächst in diesen Code übersetzt werden, bevor sie ausgeführt werden können. Architectures of Model Elimination Implementations Seite 7 Seminar: Inferenzmethoden – SS 2005 Universität Potsdam Thomas Rabenalt Die Architektur der WAM beinhaltet drei Stacks - den local stack, den global stack und den trail stack. Um die Aufrufe von Prolog-Prädikaten ineinander verschachteln zu können, wird der local stack benötigt, auf dem die Verweise auf Prädikate gespeichert werden. Für das Backtracking, also das Ausprobieren von mehreren Alternativen für ein Teilziel, muss es möglich sein, den gegenwärtigen Zustand der Prolog-Abarbeitung (choice points) zu speichern, um in diesen Zustand zurückkehren zu können und mit einer Alternative fortzufahren. Die Hierfür nötigen Daten werden ebenfalls auf dem local stack abgelegt. Das Zurückkehren in frühere Zustände erfolgt jedoch nicht ausschließlich mit Hilfe des local stack sonder auch mittels dem trail stack, welcher für das Zurücksetzen von Variablenbindungen benötigt wird. Dazu werden hier die Adressen der Variablen, die seit Speicherung des ersten choice points auf dem Stack gebunden worden sind, abgelegt. Auf dem global stack liegen globale Prolog-Strukturen (global gültige Terme), die also nach Abarbeitung eines Prädikats noch nicht gelöscht werden dürfen. Auf eine genauere Beschreibung der Warren Abstract Machine oder die Überführung von PrologCode in den WAM-Maschinencode soll an dieser Stelle jedoch verzichtet werden. Weitere Ansätze SETHEO Ein weiterer Ansatz für einen Theorem-Prover stellt SETHEO dar. Der automatische Hochleistungsbeweiser SETHEO von der Automated Reasoning Research Group der TU München ist ein auf dem Modelleliminationskalkül basierendes Beweissystem für volle Klausellogik erster Stufe. SETHEO ist zur Zeit als dreistufiges System implementiert. Dem Präprozessor stexposu, der die momentan verwendete Gleichheitsbehandlung enthält und in dem verschiedene Filterfunktionen für die Eingabe-Klauselmenge realisiert sind, folgt der Formelcompiler inwasm, der die vervollständigte Klauselmenge in ein Programm für die abstrakte Maschine übersetzt. Diese abstrakte Maschine sam (SETHEO abstract machine), eine Erweiterung der Prolog-WAM auf nicht-Horn-Logik, führt dann den eigentlichen Beweis durch. Prolog als Implementationssprache Wie bereits besprochen, gibt es die Möglichkeit, Prolog durch Mechanismen zu erweitern, um eine korrekte und vollständige Modellelimination zu erhalten. Nachdem die SLD-Resolution sehr ähnlich zur Modellelimination ist, verfolgen viele neue Implementationen auch den Weg Modellelimination direkt in Prolog umzusetzen, dass heißt Prolog als Programmiersprache zu verwenden. Architectures of Model Elimination Implementations Seite 8 Seminar: Inferenzmethoden – SS 2005 Universität Potsdam Thomas Rabenalt Zusammenfassung In dieser Ausarbeitung wurde ein kurzer Einblick in die Grundlagen der Prolog Technology Theorem Prover gegeben. Es wurde auf grundsätzliche Prolog-Probleme verwiesen, die dieses System als vollständigen Beweiser für Prädikatenlogik erster Stufe ausschließen und Ideen für die notwendigen Erweiterungen erläutert. Weiterhin wurden kurz weitere Ansätze für Modelleliminationssysteme angesprochen. Quellen • Logische Schlußfolgerungssysteme, O. Herzog, U. Visser, nach Russell/Norvig Artificial Intelligence, 1995 www.tzi.de/~visser/lectures/ki-1_WS99-00/slides/kap_10_logreas.pdf • A Prolog Technology Theorem Prover - Implementation by an Extended Prolog Compiler Mark E. Stickel, Artificial Intelligence Center, SRI International, Menlo Park, California 94025 http://www.ai.sri.com/~stickel/pttp.html • A Prolog Technology Theorem Prover - A New Exposition and Implementation in Prolog Mark E. Stickel, Artificial Intelligence Center, SRI International, Menlo Park, California 94025 http://www.ai.sri.com/~stickel/pttp.html • Post-mortem-Analyse von WAM-compilierten Prolog-Programmen Friedrich-Schiller-Universität Jena, Institut für Informatik, Arbeitsgruppe Künstliche Intelligenz http://www.minet.uni-jena.de/www/fakultaet/beckstein/stud-und-da/debug.html • Neudesign von SETHEO in Scheme, Reinhold Letz, Gernot Stenz, TU München - Fakultät für Informatik http://www4.informatik.tu-muenchen.de/~stenzg/stenz-abstract.html Architectures of Model Elimination Implementations Seite 9