Schachregeln in Datalog Deduktive Datenbanken WS 2000/01 Schachregeln in Datalog modelliert © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

"Schachspielen in Datalog"? in diesem zweiten Einschub: ausführliche Diskussion eines weiteren Modellierungs- beispiels einer "realen" Anwendung unter Verwendung von Datalog und DDB Wieso sind die Regeln des Schachspiels ein (deduktives) DB-Thema ? Schach ist seit langem ein aktives Anwendungsgebiet verschiedenster Informatik-Techniken vorwiegend populär geworden: Schachspielprogramme ("Deep Blue") Forschungsthema u.a. in der KI, Spieltheorie und Algorithmik zentrale Rolle spielen Datenbanken mit Partien (z.B. von Großmeistern auf internationalen Turnieren) Stellungen (mit Fortsetzungsmöglichkeiten), insbesondere Eröffnungen und Endspiele (z.B. alle 5-Steiner: ca. 2 Giga-Byte!) Schachdatenbanken erheblichen Umfangs (z.B. 1,6 Mill. Partien) kommer- ziell über Internet oder auf CD-ROMs verfügbar bisher: "Schach-DB" als reine Faktensammlungen (oft komprimiert) mit speziellen Schnittstellen; selten Verwendung eines DBMS; nie regelbasierte Techniken © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Regeln in Schach-DB: Ideen und Spekulationen am naheliegendsten: Spielregeln als DB-Regeln normativ: zulässige Zugfolgen (dynamische IB) und Stellungen (statische IB) deduktiv: Definitionen von Schach-Begriffen (z.B. matt, remis, gedeckt, gefesselt) und der legalen Zugmöglichkeiten aktiv: Lehr- und Trainingssysteme, Überprüfung "dynamischer" Spiel- regeln (Remisreklamation nach 50 Zügen, Bauernumwandlung) weitere Einsatzmöglichkeiten deduktiver Regeln: Bewertung und Analyse von Stellungen Herleiten von Stellungen aus Zugfolgen Empfehlungen für aussichtsreiche Folgezüge (Strategien) ebenfalls aussichtsreich: "Data Mining" in Schach-DB (zur Gewinnung strategischen Wissens: Assoziationsregeln) all diese Möglichkeiten: bisher (meines Wissens) praktisch nicht genutzt folgende Beispielmodellierung diente als Grundlage für entsprechende Fallstudie (einschlägige Diplomarbeit Uni Bonn 1999) © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Schachbrett mit Koordinatensystem Feld mit Koordinaten (d,4) Y 8 7 6 5 4 3 2 1 reihe(a). reihe(b). . . . reihe(h). zeile(1). zeile(2). . . . zeile(8). a b c d e f g h feld (X,Y)  reihe(X), zeile(Y). X © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Datalog-Erweiterung um geklammerte Terme Koordinatenpaarangabe für Felder motiviert geringfügige Erweiterung von Datalog: Zulassen von geklammerten (u.U. auch geschachtelten) Termen auf Parameterposition in Literalen damit möglich: Auffassen von Feldkoordinaten als Einzelterme: z.B.: p(X, (X, Y, (a, b))) feld( (X,Y) )  reihe(X), zeile(Y). erweitertes Matching ("Unifikation") von Variablen gegen Klammerterme bzw. von Klammertermen untereinander: feld(F) feld( (X, 3) ) feld( (a,3) ) F = (a,3) X = a © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Topologie des Schachbretts Y zunächst: aufbauend auf Grund- relationen reihe zeile feld Modellierung von Nach- barschaftsbeziehungen zwischen Feldern "Topologie" des Schachbretts 8 7 6 5 4 3 2 1 a b c d e f g h X © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Topologie des Schachbretts (2) rechts_von(a,b). rechts_von(b,c). . . . rechts_von(g,h). links_von(X1,X2)  rechts_von(X2,X1). über(1,2). über(2,3). . . . über(7,8). unter(Y1,Y2)  über(Y2,Y1). vertikal ((X,Y1), (X,Y2), oben)  reihe(X), über(Y1,Y2). vertikal ((X,Y1), (X,Y2), unten)  reihe(X), unter(Y1,Y2). analog: horizontal (3. Parameter: rechts, links) © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Topologie des Schachbretts (3) Verallgemeinerung von vertikal/horizontal: rechtwinklig (Feld1, Feld2, Richtung)  vertikal(Feld1, Feld2, Richtung). rechtwinklig(Feld1, Feld2, Richtung)  horizontal(Feld1, Feld2, Richtung). diagonale Nachbarschaft: diagonal( Feld1, Feld2, (Hor, Ver))  vertikal( Feld1, Feld3, Ver), horizontal( Feld3, Feld2, Hor). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Topologie des Schachbretts (4) Zusammenfassung von 'diagonal' und 'rechtwinklig': benachbart (Feld1, Feld2)  diagonal(Feld1, Feld2, _). benachbart(Feld1, Feld2)  rechtwinklig(Feld1, Feld2, _). indirekte Versionen aller Nachbarschaftsrelationen durch transitiven Abschluß: rechts_von* (X,Y)  rechts_von(X,Y). rechts_von*(X,Y)  rechts_von(X,Z), rechts_von*(Z,Y). (analog: links_von*, über*, unter*) vertikal* (X,Y,R)  vertikal(X,Y,R). vertikal*(X,Y,R)  vertikal(X,Z,R), vertikal*(Z,Y,R). (analog: horizontal*, rechtwinklig*, diagonal*, benachbart*) © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

© 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken Figuren und Farben farbe (w).  weiß farbe(s).  schwarz 8 7 6 5 4 3 2 1 gegner (s,w). gegner(w,s). stein (k).  König stein(d).  Dame stein(t).  Turm stein(l).  Läufer stein(s).  Springer stein(b).  Bauer a b c d e f g h © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Positionen von Figuren auf dem Brett 8 7 6 5 4 3 2 1 Beschreibung einer aktuellen Spielstellung durch Fakten: position (k, s, (c,8)). position(d, s, (b,5)). position(b, s, (g,7)). position(k, w, (f,1)). position(l, w, (e,2)). position(b, w, (c,3)). a b c d e f g h besetzt_von(Feld, Farbe)  position(_, Farbe, Feld). besetzt (Feld)  besetzt_von( Feld, _). frei (Feld)  feld(Feld), not besetzt(Feld). im_spiel (Stein, Farbe)  position(Stein, Farbe,_). geschlagen (S, F)  stein(S), farbe(F), not im_spiel(S, F). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Korrekte Positionierung von Figuren Bereits mit diesen einfachen Begriffen zum Beschreiben von Schachbrett und Spielkonstellationen sind viele inkorrekte Zustände konstruierbar, die durch geeignete Integritätsbedingungen verhindert werden müssen. Ein und dasselbe Feld darf nicht mit zwei verschiedenen Figuren besetzt sein: Eine Figur kann nicht gleichzeitig auf zwei verschiedenen Feldern stehen: constraint not doppelt_belegt with doppelt_belegt  position(Figur1, Farbe1, Feld), position(Stein2, Farbe2, Feld), (Stein1,Farbe1)  (Stein2,Farbe2) ! constraint not doppelt_positioniert with doppelt_positioniert  position(Stein, Farbe, Feld1), position(Stein, Farbe, Feld2), Feld1  Feld2 ! ? ? ? ? © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Feinere Figurenmodellierung constraint not doppelt_positioniert with doppelt_positioniert  position(Stein, Farbe, Feld1), position(Stein, Farbe, Feld2), Feld1  Feld2 ! . . . formalisiert leider nicht, was gemeint war !! Grund: Es gibt von den meisten Steinen mehrere Exemplare, die mit der bisherigen Modellierung nicht unterschieden werden können! Ausweg: "Feinere" Unterscheidung von Stein-Exemplaren etwa durch zusätzliche Angabe der Reihe, in der der Stein am Spielbeginn stand, z.B.: z.B.: position(b, w, (a,2)). ist völlig in Ordnung position(b, w, (b,2)). position(l, w, f , (c,4) ). position(l, w, c, (h,6) ). a b c d e f g h © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

weißer Springer, der auf (b, 1) beginnt ("Damenspringer") (s, w, b) Figuren statt Steine Um gleichzeitigen Zugriff auf alle Aspekte eines Stein-Exemplars zu gewährleisten: wieder Verwendung von strukturierten Termen zur Modellierung, z.B.: zur besseren Unterscheidung: neuer Begriff 'Figur' für 'Exemplar eines Steins': zum Unterscheiden von Figuren ohne Komponentenschreibweise: "Typprädikate" weißer Springer, der auf (b, 1) beginnt ("Damenspringer") (s, w, b) figur ((s, w, b)) Stein Farbe Reihe bauer ((b, F, R))  farbe(F), reihe(R). analog: springer/1, läufer/1, . . . weiss/1, schwarz/1, gegnerisch/2 . . . farbe_von/2 © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Weitere Integritätsaspekte Um zu verhindern, daß zu viele Figuren ins Spiel kommen, muß auch der "Vorrat" an Figuren entsprechend explizit angepaßt werden: figur( (b, w, a) ). figur( (t, w, a) ). figur( (b, w, b) ). figur( (t, w, h) ). . . . Entsprechend muß die Syntax für Positionsvergabe angepaßt und durch Typ- Constraints kontrolliert werden: position(k, s, (f, 5)). = = = > position( (k, s, e), (f, 5) ). constraint not fehlbelegung with fehlbelegung  position(Figur, _), not figur(Figur) ; fehlbelegung  position(_, Feld), not feld(Feld) ! © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Integrität bei Schachpositionen (3) Alle Figuren dürfen auf dem Schachbrett fehlen, nur die beiden Könige müssen in jeder Schachstellung auf dem Brett stehen: constraint beide_könige_im_spiel with beide_könige_im_spiel  im_spiel(k, w), im_spiel(k, s) ! Sonderregelung erforderlich für den Fall, daß ein Bauer zur gegnerischen Grundlinie vorstößt und "umgewandelt" werden kann (in eine höherwertige Figur, z.B. eine zusätzliche Dame): Wie kennzeichnet man solche Extra- figuren in der dritten Komponente eines figur-Terms? ganz sicher: noch diverse weitere Integritätsbedingungen zum Modellieren zulässiger Schachpositionen erforderlich © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Stellungsanalyse durch DB-Prädikate: Motivation gefesselt 8 7 6 5 4 3 2 1 gedeckt_von bedroht_durch im_schach a b c d e f g h © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Besetzbare und erreichbare Felder blockiert Vorgehensweise beim Modellieren von Zugmöglichkeiten. gefesselt a) pro Figur: 1) Felder, die die Figur auf einem leeren Schachbrett erreichen kann erreichbar 2) Felder, die diese spezielle Figur in der aktuellen Stellung besetzen kann besetzbar_1 b) für alle Figuren generell: erreichbare Felder, die aktuell tatsächlich besetzt werden können besetzbar besetzbar erreichbar © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

für alle Figuren gleichermassen: Besetzbare Felder gefesselt blockiert für alle Figuren gleichermassen: Eine Figur kann auf ein für sie im Prinzip besetzbares Feld (besetzbar_1) nur dann ziehen, wenn ° sie selbst nicht gefesselt ist, ° das Feld nicht von einer eigenen Figur blockiert wird. (Blockierende gegnerische Figuren können hingegen geschlagen werden.) schlagbar besetzbar (Figur, Feld1, Feld2)  besetzbar_1(Figur, Feld1, Feld2), farbe_von(Figur, Farbe), not besetzt_von(Feld2, Farbe), not gefesselt(Figur, Feld1). (noch zu definieren) © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Läufers Läufer können diagonal beliebig weit ziehen. von nach erreichbar (Figur, Feld1, Feld2)  läufer (Figur), diagonal*(Feld1, Feld2, Richtung). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Läufers (2) verdeckt (l, F1, F2)  diagonal*(F1, F3, Richtung), besetzt(F3), diagonal*(F3, F2, Richtung). egal, ob durch eigene oder fremde Figur (besetztes Feld selbst ist nicht verdeckt!) besetzbar_1 (Figur, Feld1, Feld2)  läufer(Figur), erreichbar(Figur, Feld1, Feld2), not verdeckt(l, Feld1, Feld2). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Turms Türme ziehen rechtwinklig, (analog zum diagonalen Ziehen der Läufer) erreichbar (Figur, Feld1, Feld2)  turm (Figur), rechtwinklig*(Feld1, Feld2, Richtung). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Turms (2) verdeckt (t, F1, F2)  rechtwinklig*(F1, F3, Richtung), besetzt(F3), rechtwinklig*(F3, F2, Richtung). besetzbar_1 (Figur, Feld1, Feld2)  turm (Figur), erreichbar(Figur, Feld1, Feld2), not verdeckt(t, Feld1, Feld2). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten der Dame Damen ziehen rechtwinklig wie Türme oder diagonal wie ein Läufer erreichbar (Figur, Feld1, Feld2)  dame(Figur), erreichbar((t, _, _) , Feld1, Feld2). erreichbar(Figur, Feld1, Feld2)  erreichbar((l, _, _), Feld1, Feld2). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten der Dame (2) auch Besetzbarkeit speziell für Damen über Turm und Läufer herleitbar besetzbar_1 (Figur, Feld1, Feld2)  dame(Figur), besetzbar_1((t, _, _) , Feld1, Feld2). besetzbar_1(Figur, Feld1, Feld2)  besetzbar_1((l, _, _), Feld1, Feld2). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Springers Springerzüge bereiten gerade Anfängern leicht Schwierigkeiten: "Rösselsprung" rote Pfeile blaue Pfeile erreichbar (Figur, Feld1, Feld2)  springer(Figur), vertikal(Feld1, Feld3, V), vertikal(Feld3, Feld4, V), horizontal(Feld4, Feld2, _). erreichbar(Figur, Feld1, Feld2)  springer(Figur), horizontal(Feld1, Feld3, H), horizontal(Feld3, Feld4, H), vertikal(Feld4, Feld2, _). gleiche Richtung beliebige Richtung © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Springers (2) Springer können durch eigene oder gegnerische Figuren nicht "aufgehalten" werden ("überspringen" sie). besetzbar_1 (Figur, Feld1, Feld2)  springer(Figur), erreichbar(Figur, Feld1, Feld2). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Bauern Grundprinzip der Bauernzüge denkbar einfach: Bauern bleiben in "ihren" Reihen gehen pro Zug eine Zeile "vorwärts" Weiss spielt stets von unten nach oben, schwarz in umgekehrter Richtung: erreichbar (Figur, Feld1, Feld2)  bauer(Figur), farbe_von(Figur, Farbe) richtung_von(Farbe, Richtung), vertikal(Feld1, Feld2, Richtung). richtung_von (w, oben). richtung_von(s, unten). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Bauern (2) 8 7 6 5 4 3 2 1 Ausnahme: im ersten Zug (aus der Ausgangs- position) ist ein Doppelschritt erlaubt erreichbar (Figur, (X,2), (X,4))  bauer(Figur), weiss(Figur), reihe(X). erreichbar(Figur, (X,7), (X,5))  bauer(Figur), schwarz(Figur), © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Bauern (3) 8 7 6 5 4 3 2 1 für Besetzbarkeit: Zwischenfeld bei Doppelschritt darf nicht blockiert sein Zielfeld darf zudem nicht vom Gegner besetzt sein (kein Schlagen in gerader Linie!!) besetzbar_1 (Figur, (X,2), (X,4))  bauer(Figur), weiss(Figur), reihe(X), not besetzt((X,3)), not besetzt_von((X,4), s). besetzbar_1(Figur, (X,7), (X,5))  bauer(Figur), schwarz(Figur), reihe(X), not besetzt((X,6)), not besetzt_von((X,5), w). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Bauern (4) Bauern können ihr direktes Nachbarfeld in Laufrichtung nur dann auch besetzen, wenn es nicht durch eine gegnerische Figur besetzt ist. (kein Schlagen möglich!!) besetzbar_1 (Figur, Feld1, Feld2)  bauer(Figur), farbe(Figur, Farbe), richtung_von(Farbe, Richtung), vertikal(Feld1, Feld2, Richtung), gegner(Farbe, Farbe1), not besetzt_von(Feld2, Farbe1). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Bauern (5) aber: vom Gegner besetztes Diagonal- feld kann (mit Schlagen) betreten werden besetzbar_1 (Figur, Feld1, Feld2)  bauer(Figur), farbe(Figur, Farbe), richtung_von(Farbe, Richtung) diagonal(Feld1, Feld2, (_, Richtung)), gegner(Farbe, Farbe1), besetzt_von(Feld2, Farbe1). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Bauern (6) Zusammenfassung der möglichen Bauernzüge: besetzbar_1 (Figur, Feld1, Feld2)  bauer(Figur), farbe(Figur, Farbe), richtung_von(Farbe, Richtung), vertikal(Feld1, Feld2, Richtung), gegner(Farbe, Farbe1), not besetzt_von(Feld2, Farbe1). Einfachschritt besetzbar_1 (Figur, Feld1, Feld2)  bauer(Figur), farbe(Figur, Farbe), richtung_von(Farbe, Richtung) diagonal(Feld1, Feld2, (_, Richtung)), gegner(Farbe, Farbe1), besetzt_von(Feld2, Farbe1). Doppelschritt besetzbar_1 (Figur, (X,2), (X,4))  bauer(Figur), weiss(Figur), reihe(X), not besetzt((X,3)), not besetzt_von((X,4), s). (analog für schwarze Bauern) diagonales Schlagen © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Königs Könige können (im Prinzip) jedes direkte Nachbarfeld erreichen erreichbar (Figur, Feld1, Feld2)  könig (Figur), benachbart(Feld1, Feld2). 1. Ausnahme für Besetzbarkeit: Könige dürfen nie ein vom Gegner bedrohtes Feld betreten! (Jede andere Figur hingegen darf "sich opfern"!) © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Zugmöglichkeiten des Königs (2) 2. Ausnahme für Könige: Ein angegriffener König darf ein Nachbarfeld nicht betreten, wenn er dort (vom selben Angreifer) nach dem Wegziehen immer noch bedroht wäre. ( Vorsicht: aktuell ist das fragliche Feld 3 nicht vom Turm bedroht! ) 2 1 3 besetzbar_1 (Figur1, Feld1, Feld3)  könig(Figur1), erreichbar(Figur1, Feld1, Feld3), farbe_von(Figur1, Farbe1), not bedroht(Farbe1, Feld3), not potentiell_bedroht(Figur1, Feld1, Farbe1, Feld3). Ausnahme 1 Ausnahme 2 (noch zu definieren) © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Potentiell bedrohte Felder "Potentielle Bedrohung" von Figuren, die auf der Sichtlinie eines Angreifers einfach nur weiterrücken: 2 1 3 potentiell_bedroht(Figur1, Feld1, Farbe1, Feld3)  bedroht_von(Figur2, Feld2, Farbe1, Feld1), stein_von(Figur2, Stein), verdeckt(Stein, Feld2, Feld3). (nur für Läufer, Türme und Damen definiert) © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Bedrohung von Feldern durch Figuren im Prinzip: Figuren bedrohen jedes von ihrer aktuellen Position aus besetzbare Feld. Begriff 'Bedrohung' ist hier potentiell zu verstehen: Wenn auf dem bedrohten Feld eine gegnerische Figur stände, könnte die bedrohende Figur sie schlagen - bedrohte Felder können aber auch leer sein. einzige Ausnahme: Bauern können nur diagonale Nachbarfelder (in Laufrichtung) zum Schlagen besetzen (und damit bedrohen) Projektion auf bedrohte Felder: bedroht_von (Figur1, Feld1, Farbe2, Feld2)  position(Figur1, Feld1), not bauer(Figur1), farbe_von(Figur1, Farbe1), gegner(Farbe1, Farbe2), besetzbar(Figur1, Feld1, Feld2). bedroht_von(Figur1, Feld1, Farbe2, Feld2)  position(Figur1, Feld1), bauer(Figur1), richtung(Farbe1, Richtung), diagonal(Figur1, Figur2, (_, Richtung)). bedroht (Farbe, Feld)  bedroht_von(_, _, Farbe, Feld). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

geschlagen werden könnte Gedeckte Figuren Auch beim (scheinbar inversen) Begriff 'gedeckt_von' muß wieder die Sonderrolle der Bauern berücksichtigt werden: gedeckt, weil L dort geschlagen werden könnte Es reicht nicht aus, das Feld, das gedeckt werden soll, mit der deckenden Figur besetzen zu können. Man muß dort auch schlagen dürfen! besetzbar, aber nicht gedeckt © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

gedeckt_von (Figur1, Feld1, Farbe2, Feld2)  Gedeckte Figuren (2) "Problem": Auf dem zu deckenden Feld kann (muß nicht) eine eigene Figur stehen. Das Feld ist damit nicht 'besetzbar', sondern nur 'besetzbar_1'. Verhinderung der Fesselung der deckenden Figur muß dafür aber explizit garantiert werden, wenn man 'besetzbar_1' verwendet. gedeckt_von (Figur1, Feld1, Farbe2, Feld2)  position(Figur1, Feld1), not bauer(Figur1), not gefesselt(Figur1, Feld1), farbe_von(Figur1, Farbe1), gegner(Farbe1, Farbe2), besetzbar_1(Figur1, Feld1, Feld2). gedeckt_von(Figur1, Feld1, Farbe2, Feld2)  position(Figur1, Feld1), bauer(Figur1), diagonal(Figur1, Figur2, _). gedeckt( Farbe, Feld)  gedeckt_von(_, _, Farbe, Feld). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Schach und Matt: Übersicht König beweglich einfaches Schach Angreifer schlagbar Schach abwendbar Schach abblockbar König nicht beweglich Schach sonst MATT König beweglich Schach abwendbar Doppelschach MATT König nicht beweglich © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

im_doppelschach(Spieler), not beweglich( (k, Spieler, e) ). Matt matt (Spieler)  im_doppelschach(Spieler), not beweglich( (k, Spieler, e) ). matt(Spieler)  im_schach(Spieler, Feld, Figur1, Feld1), not im_doppelschach(Spieler), not beweglich( (k, Spieler, e) ), gegner(Spieler, Gegner), not bedroht(Gegner, Feld), not abblockbar(Figur1, Feld1, Spieler, Feld) einfaches Schach kann auf irgendein Feld abziehen beweglich (Figur)  position(Figur, Feld), besetzbar(Figur, Feld, _ ). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Abblocken von Angriffen Angriffe von Läufern, Türmen und Damen können u.U. durch "Dazwischenziehen" eigener Figuren abgeblockt werden: 1 3 2 Welche Felder liegen "zwischen" Angreifer und Angegriffenem ? zwischen(Figur1, Feld1, Feld2, Feld3)  turm(Figur1), rechtwinklig*(Feld1, Feld2, Richtung), rechtwinklig*(Feld1, Feld3, Richtung), rechtwinklig*(Feld3, Feld2, Richtung). (analog für Läufer und Dame zu definieren) © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Abblocken von Angriffen (2) 1 3 damit definierbar: abblockbar(Figur1, Feld1, Spieler, Feld)  position(Figur2, Feld2), farbe_von(Figur2, Spieler), besetzbar(Figur2, Feld2, Feld3), zwischen(Figur1, Feld1, Feld, Feld3). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Ein Spieler steht im Schach, wenn sein König von irgendeiner 8 7 6 5 4 3 2 1 Ein Spieler steht im Schach, wenn sein König von irgendeiner gegnerischen Figur bedroht wird! a b c d e f g h hier: Feld = (c, 8) Feld1 = (e, 6) im_schach (Farbe, Feld, Figur1, Feld1)  position( (k, Farbe, e), Feld), bedroht_von(Figur1, Feld1, Farbe, Feld). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Ein Spieler steht im Doppelschach, wenn sein König von zwei gegnerischen Figuren gleichzeitig bedroht wird! (Schlagen eines Angreifers oder Abblocken eines Angriffs hilft dann nicht mehr !) im_doppelschach (Farbe)  im_schach(Farbe, Feld, Figur1, Feld1), im_schach(Farbe, Feld, Figur2, Feld2), Figur1  Figur2. © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

"Altlast" (d.h. immer noch nicht definiert): Fesselung von Figuren "Altlast" (d.h. immer noch nicht definiert): Wann ist eine Figur auf einem Feld gefesselt? gefesselt 1 Abziehen der gefesselten Figur würde direkt zum Schach des eigenen Königs führen. Nur Läufer, Türme und Damen können gegnerische Figuren fesseln. 2 gefesselt (Figur, Feld)  position(Figur, Feld), farbe_von(Figur, Farbe), position((k, Farbe, e), Feld1), position(Figur2, Feld2), gegnerisch(Figur, Figur2), zwischen(Figur2, Feld2, Feld1, Feld). © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Abhängigkeiten von Basisrelationen: weitgehend ausgelassen Abhängigkeitsgraph im folgenden: Auszug des Abhängigkeitsgraphen dieser Anwendung (Beschränkung auf alle wesentlichen Abhängigkeiten) Abhängigkeiten von Basisrelationen: weitgehend ausgelassen matt not not im_doppelschach not not im_schach bedroht abblockbar beweglich bedroht_von © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Abhängigkeitsgraph (2) bedroht gedeckt bedroht_von beweglich abblockbar not gedeckt_von besetzbar not not not besetzbar_1 not not verdeckt not not besetzt besetzt_von erreichbar gefesselt Basisrelationen und topologische Relationen © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Stratifikationsproblem Nicht auf den ersten Blick zu erkennen: Regelmenge ist nicht stratifizierbar !! bedroht bedroht_von not besetzbar_1 besetzbar Grund für diesen Zyklus: Könige können Nachbarfeld nur besetzen, wenn es nicht (von einer gegnerischen Figur) bedroht ist besetzbar_1 (Figur1, Feld1, Feld3)  könig(Figur1), farbe_von(Figur1, Farbe1), bedroht_von(Figur2, Feld2, Farbe1, Feld1), erreichbar(Figur1, Feld1, Feld3), not erreichbar(Figur2, Feld2, Feld3), not bedroht(Farbe1, Feld3). ? © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Stratifikationsproblem (2) not bedroht(w, Feld3) besetzbar_1 ((k, w, e), _, Feld3) bedroht_von (Figur1, Feld1, w, Feld3) farbe_von(Figur1', Farbe1'), gegner(Farbe1', s), besetzbar(Figur1', Feld1', Feld3). farbe_von(Figur1, Farbe1), gegner(Farbe1, w), besetzbar(Figur1, Feld1, Feld3). bedroht_von (Figur1', Feld1', s, Feld3) besetzbar_1((k, s, e), _, Feld3) not bedroht(s, Feld3) © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

Stratifikationsproblem (3) 8 7 6 5 4 3 2 1 Kritische Situation kann Eintreten, wenn beide Könige "in Opposition" zueinander stehen: Sind die roten Felder für die Könige besetzbar oder nicht ? intuitiv: nicht besetzbar, da vom gegnerischen König bedroht a b c d e f g h Wie kann man dieses Stratifikations- problem am besten lösen ? © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken

vorläufige Schlußfolie Dieser Einschub ist hiermit noch nicht endgültig abgeschlossen - es handelt sich also bei dieser Version zunächst nur um eine vorläufige Fassung. Eine Lösung für das Stratifikationsproblem sollte noch gefunden und entsprechende Modifikationen eingebaut werden. Zudem sollen noch einige Bemerkungen zu weiterführenden Konzepten wie Rochade und En passant-Schlagen folgen. Bitte schauen Sie bei Gelegenheit nach der endgültigen Version. © 2000 Prof. Dr. Rainer Manthey Deduktive Datenbanken