constraint-basierte programmiersprachen
TRANSCRIPT
Künstl Intell (2012) 26:47–54DOI 10.1007/s13218-011-0153-4
FAC H B E I T R AG
Constraint-basierte Programmiersprachen
Von den Ursprüngen in der logischen Programmierung bis zu heutigen Anwendungen
Thomas König · Petra Hofstedt
Eingegangen: 31. Juli 2011 / Angenommen: 4. November 2011 / Online publiziert: 3. Dezember 2011© Springer-Verlag 2011
Zusammenfassung Dieser Beitrag zeichnet zunächst kurzdie in den logischen Sprachen begründete Geschichte derConstraint-Programmierung nach. Einige einführende Bei-spiele erläutern die Grundbegriffe und stellen den grundle-genden deklarativen Modellierungsansatz dar. Im Hauptteildes Beitrags werden einige moderne und verbreitete Sys-teme zur Constraint-basierten Programmierung vorgestellt– sowohl neue Programmiersprachen als auch Bibliothekenfür existierende Sprachen. Ein durchgängiges Beispiel ver-anschaulicht dabei die Unterschiede und Vorzüge der ver-schiedenen Ansätze.
Schlüsselwörter Constraints · Programmierung · Sprachen
1 Einführung
Die Constraint-basierten Programmiersprachen haben ihreUrsprünge in der logischen Programmierung und auf demGebiet der Künstlichen Intelligenz.
In den 1980er Jahren wurden erste Sprachen des Cons-traint Logic Programming (CLP) Paradigmas [10] vorge-stellt, die als Generalisierung der logischen Programmie-rung entstanden. Hierbei sind die speziellen Constraints derlogischen Programmierung syntaktische Gleichheiten, diedurch Unifikation gelöst werden.
T. König (�) · P. HofstedtProgramming Languages and Compiler Construction,Brandenburg University of Technology Cottbus, Postfach 101344,03013 Cottbus, Deutschlande-mail: [email protected]
P. Hofstedte-mail: [email protected]
Sprachen, wie CLP(R), Prolog II/III oder CHIP integrier-ten Constraints spezieller Domänen (z. B. lineare arithmeti-sche, boolesche und/oder finite-domain Constraints) zusam-men mit ihren Lösungsmechanismen in Prolog (siehe [14,Kapitel 12]).
Ab den 1990er Jahren wurden Constraints und Constraint-basierte Sprachen verstärkt praktisch angewendet. Damiteinhergehend wurden Constraints in Sprachen anderer Para-digmen integriert und Bibliotheken für in der Praxis etablier-te Sprachen geschaffen, z. B. die C++-Bibliotheken IBMILOG Solver ([9], [14, Kapitel 13]) und GECODE [27] oderdie JAVA-Bibliotheken JACOP [29] und CHOCO [23].
Darüber hinaus wurden eine Reihe weitergehender An-sätze entwickelt, hierunter Constraint-basierte Modellie-rungssprachen wie OPL [18], Concurrent Constraint Pro-gramming (CCP) [15], regelbasierte Programmierung, z. B.CHR [4] oder die Integration von Constraints und lokalenSuchverfahren in der Sprache COMET [20].
Heute untersucht und nutzt die Constraint-Programmie-rung eine Kombination von Techniken verschiedener For-schungsgebiete, unter anderen der Künstlichen Intelligenz,der Programmiersprachen, des Operations Research, derComputeralgebra und der mathematischen Logik.
Die Constraint Programmierung wird vielfältig in Praxisund Wissenschaft angewendet, häufig für Planungsproble-me, zur Optimierung und zum Scheduling von Ressourcenund Abläufen, aber auch zum Design und zur Verifikationvon Schaltkreisen, für Programmanalysen zur Optimierungund Fehlererkennung in Compilern, zur Verarbeitung natür-licher Sprache, beim automatischen Beweisen und in derMolekularbiologie. Für eine ausführliche Darstellung ver-weisen wir auf [14], insbesondere die Kapitel 22–26.
Im Folgenden führen wir in Abschn. 2 in das Gebiet derConstraint-Programmierung (CP) ein und stellen wichtigeKonzepte, wie Constraint, Constraint Satisfaction Problem,
48 Künstl Intell (2012) 26:47–54
Domäne sowie Constraint-Löser vor und illustrieren sie anHand von Beispielen. In Abschn. 3 gehen wir dann auf dieIntegration von Konzepten der CP in Programmiersprachenein, stellen konkrete Beispiele vor und vergleichen die un-terschiedlichen Ansätze. Abschnitt 4 fasst den Beitrag zu-sammen und gibt einen Ausblick.
2 Constraint-Programmierung
Ein Constraint ist eine mathematisch beschriebene Bezie-hung (Relation) zwischen Unbekannten (Variablen), dieWerte aus ihrem jeweiligen Definitionsbereich (Domäne)annehmen. Auf diese Weise ist es möglich, Einschränkun-gen zu beschreiben, welche bei der gleichzeitigen Belegungaller Unbekannten mit Werten einzuhalten sind. Constraintseignen sich somit zur deklarativen Modellierung von Pro-blemen. Die Lösungen sind die Variablenbelegungen, wel-che die Konjunktion aller aufgestellten Constraints erfüllen.
Ein Constraintsystem ist die mathematische Formalisie-rung von Syntax, Semantik und Domänen von Constraints.Es beschreibt also detailliert die zur Modellierung eines Pro-blems zur Verfügung stehenden Constraints und die Defini-tionsbereiche der Unbekannten.
Typische Constraintsysteme eignen sich zum Beispiel zurModellierung von linearen oder polynomiellen (Un-)glei-chungssystemen, von aussagenlogischen Erfüll barkeitspro-blemen oder von endlichen kombinatorischen Problemen:
Beispiel 1 In einem semialgebraischen Constraintsystembeschreibt die Konjunktion der Constraints x2
1 + x22 = 1,
x1 ≤ 0 und x2 ≥ 0 den zweiten Quadranten des Einheits-kreises.
Beispiel 2 Das (unlösbare) Problem drei paarweise be-nachbarte Länder l1, l2 und l3 mit nur zwei Farben TRUE
und FALSE auf einer politischen Landkarte so einzufärben,dass benachbarte Länder verschieden gefärbt sind, lässtsich in einem booleschen Constraintsystem wie folgt model-lieren: (l1 ⊕ l2) ∧ (l2 ⊕ l3) ∧ (l3 ⊕ l1) ≡ TRUE, wobei ⊕ fürdas exklusive Oder steht.
Diese beiden ersten Beispiele zeigen aufgrund der Unter-schiedlichkeit ihrer Domänen bereits, dass unterschiedlicheConstraintsysteme sehr unterschiedliche Methoden verlan-gen, um zum einen die Erfüllbarkeit (einer Konjunktion vonConstraints) zu prüfen und um dann gegebenenfalls eine Lö-sung zu finden. Auch existieren häufig mehrere Lösungen,unter denen die in einem gewissen Sinne „beste“ Lösung ge-sucht ist. Die zur Bestimmung dieser optimalen Lösung her-angezogenen Zielfunktionen werden je nach Domäne eben-falls auf sehr unterschiedliche Weise in die Lösungsverfah-ren integriert.
Listing 1 ECLiPSe-PROLOG: Kosmos-Alphametik
1 cosmos(Digits) :-2 Digits = [S,O,N,E,M,D,T,R,K],3 Digits :: 0..9,4 Carries = [C1,C2,C3,C4,C5],5 Carries :: 0..2,
6 alldifferent(Digits),7 S + C5 #= K,8 S + T + C4 #= O + 10*C5,9 O + M + E + C3 #= S + 10*C4,
10 N + O + R + C2 #= M + 10*C3,11 N + N + N + C1 #= O + 10*C2,12 E + D + E #= S + 10*C1,
13 labeling(Carries),14 labeling(Digits).
In den folgenden Beispielen dieses Beitrags werden wirausschließlich Constraintsysteme mit endlichen Domänenbetrachten. Viele endliche kombinatorische Probleme undOptimierungsprobleme können sehr elegant in diesen soge-nannten Finite-Domain- oder kurz FD-Constraintsystemenmodelliert werden. Das Ziel ist dabei die Reduktion des Pro-blems auf ein Constraint Satisfaction Problem (CSP) oder –im Falle eines Optimierungsproblems – auf ein ConstrainedOptimization Problem (COP).
Ein CSP (X, D, C) besteht aus:
– einer Menge von Variablen X = {x1, . . . , xn},– einer Liste von (endlichen) Domänen D = 〈Dx1, . . . ,Dxn〉,
wobei Dxidie Menge der möglichen Werte von xi ist und
– einer Menge C von Constraints, welche die zulässigen Va-riablenbelegungen einschränken
und im Falle eines COPs (X, D, C, f ) zusätzlich aus:
– einer Zielfunktion f :Dx1 × · · · × Dxn→ N, welche dieQualität einer Lösung bewertet.
Zulässige Variablenbelegungen sind dabei implizit durch dieConstraints x1 ∈ Dx1 , . . . , xn ∈ Dxn eingeschränkt.
Dieser heute sehr gut erforschte und auch kommerziellsehr bedeutsame Modellierungsansatz wird mit folgendemkombinatorischen Rätsel illustriert, das als reizvoller Vor-gänger der inzwischen populären Sudokus gelten darf:
Beispiel 3 Eine Alphametik ist ein mathematisches Rätsel,bei dem in einer arithmetischen Gleichung ohne Variablendie Ziffern der zur Basis 10 notierten Konstanten durchBuchstaben ersetzt sind. Dabei stehen gleiche Buchstabeneindeutig für gleiche Ziffern. Die Lösung des Rätsel bestehtin der Aufdeckung dieser Injektion. Eine gelungene Alpha-metik zeichnet sich durch die Eindeutigkeit der Lösung undeine sprachliche Bedeutung der resultierenden Buchstaben-folgen aus, wie etwa in folgendem Beispiel [22]:
Sonne + Mond + Sterne = Kosmos
Künstl Intell (2012) 26:47–54 49
Ähnlich wie bei vielen anderen mathematisch, d. h. meistdeklarativ formulierten Problemstellungen ist auch hier einzur Beschreibung der Lösung geeignetes CSP sehr leicht er-kennbar. Es werden neun Variablen zur Repräsentation derBuchstaben benötigt (X = {S,O,N,E,M,D,T ,R,K}).Jede dieser neun Variablen steht für eine der Dezimalzif-fern (D = 〈DS, . . . ,DK〉 mit Dx = {0, . . . ,9} für x ∈ X),wobei die Variablen paarweise verschiedene Werte erhaltenund die arithmetische Gleichung erfüllen müssen.
Je nach verwendetem Constraintsystem und Modellie-rungsansatz können diese beiden verbal formulierten Cons-traints unterschiedlich umgesetzt werden. Die paarweiseVerschiedenheit der neun Variablen kann durch 36 Ungleich-heits-Constraints beschrieben werden oder durch ein globa-les Verschiedenheits-Constraint ∀x, y ∈ X:x �= y ⇒ val(x)
�= val(y).Die arithmetische Gleichung kann durch ein einzelnes
Gleichheits-Constraint ausgedrückt werden, indem die Va-riablen entsprechend der Gleichung mit ihrem Stellenwertmultipliziert und aufsummiert werden. Eine Alternative istdie spaltenweise Modellierung als schriftliche Addition, in-dem zusätzliche Übertragsvariablen eingeführt werden.
Eine Implementierung der Alphametik als CSP inder constraint-logischen Programmiersprache ECLiPSe-PROLOG [2, 26] ist in Listing 1 angegeben. Im Stil der lo-gischen Programmierung wird zunächst die Liste Digitsmit der Variablenmenge X unifiziert. Das zweistellige Prä-dikat :: bindet die Variablen an ihre Domänen und dasalldifferent-Constraint sichert die paarweise Ver-schiedenheit der Belegungen. Danach werden unter Nut-zung der Übertragsvariablen C1 bis C5 sechs Gleichheits-Constraints mittels des Prädikats #= formuliert. Ganz zu-letzt wird eine Instanziierung der Variablen durch daslabeling-Prädikat angefordert.
Die Implementierung in Listing 1 offenbart einen grund-legenden Unterschied zwischen logischer und constraint-logischer Programmierung. Es fällt auf, dass arithmetischeConstraints aufgestellt werden, bevor die Bindung der Varia-blen an konkrete Werte erfolgt. Dies erfordert im Vergleichzu den logischen Sprachen – hier müssen die Variablen erstvollständig gebunden und falsche Belegungen nachträglichverworfen werden – ein aufwendigeres Auswertungsmodell.Gleichzeitig ermöglicht dies aber eine effizientere Lösungs-suche, da schon Teilbelegungen der Variablen frühzeitig alsfalsch erkennbar sind.
Auswertungs- oder Berechnungsmodelle für Constraint-basierte Programmiersprachen basieren zumeist auf soge-nannten Constraint-Stores. Darin werden die Constraints imVerlauf der Auswertung gesammelt und dabei auf Konsis-tenz überprüft. Ein inkonsistenter Store weist auf eine Nicht-erfüllbarkeit des CSP hin. Die Constraints im Store werdengenutzt, um die Domänen der Variablen durch Anwendunggeeigneter Schlussregeln zu verkleinern (Pruning). Zusätz-lich werden geeignete Strategien angewendet, um den Raum
der verbliebenen Variablenbelegungen effizient nach Lösun-gen zu durchsuchen (Branching).
Constraint-basierte Programmiersprachen stellen demNutzer Mittel zur Verfügung, die Suche im reduzierten Lö-sungsraum den konkreten CSPs anzupassen. Die Reduzie-rung des Lösungsraums bleibt dabei zumeist dem Laufzeit-system der Programmiersprache überlassen. Dementspre-chend kann die Quintessenz der Constraint-Programmierungnach [19] auf die folgende Formel gebracht werden:
Constraint-Programmierung = Constraints + Suche
3 Constraint-basierte Programmiersprachen
Freuder [3] charakterisiert die Constraint-basierte Program-mierung als
„. . . one of the closest approaches computer sciencehas yet made to the Holy Grail of programming: theuser states the problem, the computer solves it.“
Der Nutzer beschreibt also lediglich das Problem, in-dem er die Eigenschaften der gesuchten Lösungen nennt.Der eigentliche Berechnungsvorgang wird (weitgehend)dem Computer, d. h. dem Laufzeitsystem der Constraint-basierten Programmiersprache überlassen.
In diesem Abschnitt stellen wir verschiedene Ansätze zurIntegration der Constraint-Programmierung in die program-miersprachliche Praxis vor und zeigen jeweils, wie das be-schriebene deklarative Ideal konkret umgesetzt wird.
Dazu stellen wir in Abschn. 3.1 zunächst kurz das sogenannte Magic-Sequence-Problem vor. Wir werden die-ses Finite-Domain-Problem nachfolgend wiederholt als Bei-spiel aufgreifen. In Abschn. 3.2 diskutieren und vergleichenwir Programmiersprachen und Bibliotheken zur Constraint-basierten Problembeschreibung. Einige Sprachen verfolgenspezielle, „nicht-klassische“ Ansätze zur Berechnung vonLösungen. In Abschn. 3.3 stellen wir als Beispiel dafür dieSprache COMET vor, welche Techniken der lokalen Suchein die Constraint-Programmierung integriert.
3.1 Das Magic-Sequence-Problem
Eine magische Folge (engl. magic sequence) der Länge n
ist eine selbstbezüglich, aber dennoch wohldefinierte Folgenatürlicher Zahlen Sn = 〈s0, . . . , sn−1〉 mit der Eigenschaft,dass die Anzahl der Folgeglieder die gleich null sind gleichdem Folgeglied mit Index null ist und so weiter für alle Indi-zes, also #i Sn = si für alle i < n. So ist z. B. 〈2,0,2,0〉 einemagische Folge der Länge vier sowie 〈4,2,1,0,1,0,0,0〉eine solche der Länge acht.
Das Magic-Sequence-Problem besteht darin, zu einemgegebenen n ∈ N eine magische Folge der Länge n zu fin-den. Verweise auf dieses Problem finden sich schon früh in
50 Künstl Intell (2012) 26:47–54
mathematischen Rätselsammlungen, z. B. wird in [5, S. 128]eine magische Folge der Länge zehn gesucht.
Zwei Eigenschaften machen dieses Problem für die Constraint-Programmierung interessant, so dass es heute als einklassischer Benchmark [25, Problem 19] für Constraintsys-teme gilt.
Einerseits können die Kardinalitätsbedingungen#i Sn = si der Definition einer magischen Folge sehr leichtdurch einen so genannten Kardinalitätskombinator ausge-drückt werden. Generell ist ein Kombinator ein Werkzeug,um auf bestimmte Weise aus einfacheren kompliziertereConstraints zusammenzusetzen. Der Kardinalitätskombina-tor zählt, wie oft die Instanziierung eines Constraints erfüllt,d. h. die Reifikation des Constraints wahr ist, so wie dies inder Definition #i Sn = |〈sj | sj = i, j < n〉| zum Ausdruckkommt.
Andererseits können aus der Definition weitere notwen-dige Eigenschaften von magischen Folgen abgeleitet wer-den, welche dem Modell später als so genannte redundanteConstraints hinzugefügt werden können. Offensichtlich giltfür jede magische Folge
∑si = n und
∑i · si = n. Redun-
dante Constraints bewirken im Allgemeinen, dass der Such-raum rascher und stärker beschnitten werden kann und füh-ren die Suche nach einer Lösung so schneller zum Ziel.
Einige Constraintsysteme [30] bieten einen so genann-ten globalen Kardinalitätskombinator (engl. global cardi-nality constraint, gcc), welcher eine ganze Reihe von lo-kalen Kardinalitätsbedingungen zu einem einzelnen globa-len Constraint zusammenfasst. Die Nutzung dieses globalenConstraints führt zu sehr einfachen Modellen für das Magic-Sequence-Problem [28].
3.2 Constraint-basierte Bibliotheken und Sprachen
Constraints werden als Sprachelemente in Form von Basis-Constraints der spezifischen Domänen (z. B. lineare Con-straints, FD-Constraints, boolesche Constraints, ggf. Ziel-funktionen) integriert. Der Auswertungsmechanismus derSprache muss zur Behandlung dieser Constraints einen ent-sprechenden Lösungsalgorithmus bereitstellen. Die Spra-chen unterstützen darüber hinaus typischerweise die Bil-dung von Constraint-Konjunktionen und von nutzerdefi-nierten Constraints. Weiterhin kann der ProgrammiererConstraint-Löser-Operationen, wie die Überprüfung der Er-füllbarkeit, die Berechnung von Lösungen oder die Opti-mierung anstoßen. Meist ist es auch möglich, vordefinier-te Suchtechniken und Heuristiken zu erweitern oder selbstneue zu formulieren.
Beispiel 4 Das Magic-Sequence-Problem wird in Listing 2durch das nutzerdefinierte Constraint magicS gelöst. Esbesteht aus einer Konjunktion von Basis-Constraints ver-schiedener ECLiPSe-Bibliotheken. Mit Hilfe des Iterator-
Listing 2 ECLiPSe-PROLOG: Magic Sequence [26, Examples]
1 magicS(N,Sequence) :-2 length(Sequence,N),3 Sequence :: 0..N-1,
4 (5 for(I,0,N-1),6 foreach(Si,Sequence),7 foreach(I,Indices),8 param(Sequence)9 do
10 occurrences(I,Sequence,Si)11 ),
12 N #= sum(Sequence),13 N #= Sequence * Indices, % Skalarprodukt
14 search(Sequence,0,first_fail,15 indomain,complete,[]).
Konstrukts in den Zeilen 4 bis 11 werden die Kardinalitäts-Constraints für die Elemente der magischen Folge auf-gestellt. Die angegebenen Iteratoren for und foreachschreiten gleichzeitig fort und erzeugen dabei immer neuelokale Variablen. Der param-Iterator macht die Varia-ble Sequence im Rumpf sichtbar. Die Suche wird in denZeilen 15 f. durch die generische Suchoperation searchrealisiert, die hier durch die Variablenauswahlheuristikfirst_fail gesteuert wird.
Während Constraints als natürliche Erweiterung der lo-gischen Prädikate in PROLOG betrachtet werden können, istihre Integration in Sprachen anderer Paradigmen wenigeroffensichtlich. Die Integration von Constraints in Program-miersprachen erfolgt prinzipiell in zwei Ausprägungen [8]:
Constraint-basierte Sprachen (im engeren Sinne) Auf dereinen Seite können Sprachen syntaktisch und semantisch er-weitert oder auch vollständig neu entworfen werden. Diesschließt im Allgemeinen die Realisierung neuer Mechanis-men zur Auswertung mit ein. Dabei stellt die Integrationder zustandsfreien bzw. zeitlosen Constraints in den impera-tiven bzw. zeitbehafteten Informationsfluss eine besondereHerausforderung dar [7]. Beispiele für Constraint-basierteSprachen sind die logisch-imperative Sprache ALMA-0 [1]als Erweiterung von MODULA-2, die multiparadigmatischeSprache OZ [17] oder die funktional-logische Sprache CUR-RY [6].
Constraint-Bibliotheken Der zweite Weg der Integrati-on Constraint-basierter Konzepte sind Bibliotheken füretablierte Programmiersprachen. Constraints, Constraint-Löser, Suchtechniken und Suchräume werden hier in derHost-Sprache nachgebildet. Ein Wechsel der Programmier-sprache oder des Paradigmas ist nicht erforderlich, wo-durch die Nutzerakzeptanz erhöht wird. Die Problembe-schreibung und Lösung wird inhaltlich von anderen Teilen
Künstl Intell (2012) 26:47–54 51
Listing 3 CHOCO: Magic Sequence
1 int n = ...2 int[] indices = new int[n];3 for (int i = 0; i < n; ++i)4 indices[i] = i;
5 CPModel m = new CPModel();
6 IntegerVariable[] seq =7 Choco.makeIntVarArray("seq",n,0,$n-1$);
8 for (int i : indices)9 m.addConstraint(
10 Choco.occurrence(seq[i],seq,i));
11 m.addConstraint(12 Choco.eq(n,Choco.sum(seq)));13 m.addConstraint(14 Choco.eq(n,Choco.scalar(indices,seq)));
15 CPSolver s = new CPSolver();16 s.read(m);17 s.solve();
des Programms separiert. Da die Constraint-basierten Kon-zepte extern durch Bibliotheken angebunden werden, müs-sen sie aber im Programm explizit gehandhabt werden, waszu schlechterer Lesbarkeit und eingeschränkter Flexibilitätführt.
Constraint-Bibliotheken werden in der Praxis erfolgreichangewendet. Beispiele dafür sind die JAVA-BibliothekenCHOCO [23] und JACOP [29] sowie die C++-BibliothekenGECODE [27] insbesondere für Finite-Domain-Constraintsund IBM ILOG Solver [9] für Constraints verschiedener Do-mänen.
Mit den folgenden beiden Beispielen werden zwei Um-setzungen des Magic-Sequence-Problem vergleichend ge-genüber gestellt: eine bibliotheksbasierte JAVA-Implemen-tierung und ein Programm in der Constraint-basierten Spra-che OPL.
Beispiel 5 Listing 3 zeigt einen Ausschnitt der Implemen-tierung des Magic-Sequence-Problems in JAVA unter Nut-zung der CHOCO-Bibliothek. Sichtbar wird, dass hier (undtypisch für den Bibliothekansatz) das Constraint-Modell undder zugehörige Löser explizit als Objekte erzeugt und ge-handhabt werden müssen. Dabei wird die Klarheit der ma-thematischen Problembeschreibung durch syntaktische De-tails der Programmiersprache verdeckt.
Die beiden anderen zuvor genannten Constraint-Bib-liotheken GECODE und IBM ILOG Solver folgen einemmit Beispiel 5 vergleichbaren Ansatz. Die MCP-Bibliothek(Monadic Constraint Programming) [16, 21] zur ConstraintProgrammierung in HASKELL realisiert die Constraint-Integration mit Hilfe von Monaden in ähnlicher Weise.
Dem gegenüber folgt die Optimization ProgrammingLanguage [18] IBM ILOG OPL dem zuvor beschriebenen
Listing 4 OPL: Magic Sequence [14, Kapitel 13]
1 int n = ...
2 range Indices 0..n-1;3 var Indices seq[Indices];
4 solve {5 forall(i in Indices)6 seq[i] = sum(j in Indices) (seq[j] = i);
7 sum(i in Indices) seq[i] = n;8 sum(i in Indices) seq[i] * i = n;9 };
sprach-basierten Ansatz. Sie wurde als domänenspezifischeModellierungssprache für die mathematische Programmie-rung und kombinatorische Optimierung konzipiert und aufBasis der IBM ILOG Solver-Bibliothek realisiert. Sie ver-meidet die explizite Handhabung von Programmierkonzep-ten als externe Konstrukte oder Objekte und unterstützt soeinen mathematisch klaren Programmierstil.
Beispiel 6 Listing 4 zeigt die Implementierung unseres Bei-spiels in OPL. Die explizite Erzeugung und Handhabungvon Objekten wird vermieden, stattdessen wird eine klaremathematische Formulierung des Problems realisiert.
3.3 Constraints und lokale Suche
Das der Constraint-Programmierung zugrunde liegende Be-rechnungsmodell besteht in der Kooperation zweier Kompo-nenten, deren Zusammenwirken schrittweise den Lösungs-raum bis hin zu einer Lösung einengt: ein Constraint-Löserreduziert die Domänen der Variablen und ein Suchmechanis-mus zerlegt das Problem in Teilprobleme wenn die Auswer-tung der Constraints keine weitere Verkleinerung des Such-raums mehr ermöglicht.
Basierend auf diesem klassischen Ansatz der Constraint-Programmierung hat sich in jüngerer Zeit ein Berechnungs-modell [12] etabliert, das der zweiten Komponente – derSuche – eine größere Bedeutung einräumt. Constraints be-halten ihre Bedeutung als Mittel zur Modellierung des Pro-blems, sind aber nur noch mittelbar an der Berechnung derLösung beteiligt. Lokale Suchverfahren [11] werden ge-nutzt, um ausgehend von einer initialen Variablenbelegungdurch sukzessive, kleine Veränderungen zu einer Lösungdes Problems zu gelangen. Diese Suchschritte werden durchein geeignetes Maß gesteuert, welches den Grad der Verlet-zung des Constraint-Modells beschreibt. Die Suche wird ty-pischerweise solange fortgesetzt, bis alle Constraints erfülltsind.
Die objektorientierte Constraint-basierte Programmier-sprache COMET [20, 24] realisiert dieses Berechnungsmo-dell. Listing 5 zeigt in COMET-Syntax ein Modell für dasMagic-Sequence-Problem, das den Modellen in anderen
52 Künstl Intell (2012) 26:47–54
Listing 5 COMET: Magic Sequence – Modell [20]
1 int n = ...2 range Indices = 0..n-1;
3 Solver<LS> m();4 ConstraintSystem<LS> S(m);
5 var{int} seq[Indices](m,Indices) := 0;
6 forall(i in Indices)7 S.post(8 exactly(seq[i],9 all(j in Indices) seq[j] == i));
10 S.post(sum(i in Indices) seq[i] == n);11 S.post(sum(i in Indices) seq[i] * i == n);
12 m.close();
Constraint-basierten Programmiersprachen sehr ähnelt. Daszweistellige exactly-Constraint in Zeile 8 legt die Anzahlder Constraints fest, die in der durch den all-Kombinatorerzeugten Konjunktion von Gleichheits-Constraints simul-tan erfüllt sein müssen. Der entscheidende Unterschied fin-det sich in Zeile 5, in der nicht nur eine Constraint-Variableerzeugt, sondern diese außerdem mit einer initialen, inkon-sistenten Lösung vorbelegt wird.
Constraints sind in COMET so genannte differentiable ob-jects, die als zusätzliche Eigenschaft ein Maß für den Gradihrer Verletzung beinhalten. Darüber hinaus können sie Aus-kunft geben, wie sehr sich dieses Maß unter einer gegebenenNeubelegung der Variablen ändern würde. Dazu implemen-tieren Constraints die folgende Schnittstelle:
interface Constraint<LS> {var{int} violations()var{int} violations(var{int})
int getAssignDelta(var{int},int)int getSwapDelta(var{int},var{int})...
Die Methode violations() liefert einen Wert für dieVerletzung des Constraints und violations(var{int})den Teil, den die übergebene Variable daran hat. Die Metho-de getAssignDelta liefert die Änderung der Verletzungbei einer Neubelegung der Variable mit dem übergebenenWert und analog die Methode getSwapDelta die Ände-rung bei Vertauschung der Werte der beiden Variablen.
Darauf basierend und unter Nutzung weiterer Abstraktio-nen für Selektoren können sehr einfach komplexe Heuris-tiken und Metaheuristiken zur Umsetzung der lokalen Su-che implementiert werden. Listing 6 zeigt die Umsetzungeiner max-Conflict/min-Conflict-Heuristik, angereichert miteiner Tabu-Search-Metaheuristik, welche die erneute Ände-rung der zuletzt geänderten Variablen für eine gewisse Zeittabuisiert. Unter allen nicht tabuisierten Variablen wird jeneausgewählt, deren Wert den größten Einfluss auf die Verlet-zung des gesamten Constraint-Modells aufweist. Diese er-
Listing 6 COMET: Tabu-Suche [20]
13 int tabu[Indices] = 0;14 Counter it(m,0);...
22 while (S.violations() > 0) {
23 selectMax(i in Indices : tabu[i] <= it)24 (S.violations(seq[i]))
25 selectMin(v in Indices : seq[i] != v)26 (S.getAssignDelta(seq[i],v)) {
27 seq[i] := v;28 tabu[i] = it + 5;29 }
30 it++;31 }
Listing 7 COMET: Restart-Komponente [20]
15 int restartFreq = 10 * n;
16 whenever it@changes()17 if (it % restartFreq == 0)18 forall(i in Indices) {19 seq[i] := 0;20 tabu[i] = 0;21 }
hält als neuen Wert wiederum jenen, der sich am günstigstenauf die Verletzung des Gesamtmodells auswirkt. Bei meh-reren gleichwertigen Auswahlmöglichkeiten wird randomi-siert.
Eine bei Tabu-Search-Heuristiken häufig verwendeteTechnik um lokalen Optima zu entkommen besteht dar-in, nach einer gewissen Zeit innerhalb derer keine Lö-sung gefunden wurde, die Suche neu zu starten. CO-MET stellt sprachliche Mittel bereit, um die Änderungvon Variablen mit einer Ereignisbehandlung zu verknüp-fen. Auf diese Weise lässt sich, wie in Listing 7 gezeigt,die regelmäßige Wiederherstellung der initialen Lösungund die Rücksetzung der Tabu-Zähler sehr leicht realisie-ren.
Weitere und deutlich umfangreichere Beispiele für dieConstraint-unterstützte lokale Suche finden sich in [13, 20].
Die Unterschiede der Programmiermodelle von COMET
und Sprachen der klassischen Constraint-Programmierungsind aus operationaler Sicht bereits in der Nutzung des Mo-dells angelegt: klassisch werden Constraints zur Beschnei-dung des Suchraums durch Constraint-Löser genutzt, wäh-rend in COMET Constraints als differentiable objects im-plementiert sind und als Mittel zur Steuerung der Suchegenutzt werden. Aus konzeptioneller Sicht ist zu betonen,dass Variablen in COMET zustandsbehaftet sind und im Ver-lauf der Berechnung bis hin zu einer Lösung verändert wer-den.
Künstl Intell (2012) 26:47–54 53
4 Schluss
In diesem Beitrag wurde anhand einiger typischer Beispie-le der deklarative Ansatz der Constraint-Programmierung –die konzeptionelle Trennung von Problembeschreibung undLösungssuche – vorgestellt. Einerseits wurde deutlich ge-macht, wie sich die Constraint-Programmierung aus der lo-gischen Programmierung entwickelte und andererseits ge-zeigt, welche Alternativen zum constraint-logischen Ansatzfür die programmiersprachliche Integration von Constraintsheute existieren.
Das Ziel dieser Entwicklung war stets, deklarative Mo-delle zur Problembeschreibung und Lösung in der Praxiszu etablieren. Dies ist insbesondere mit den teilweise freiverfügbaren Constraint-Bibliotheken für die weit verbreite-ten objektorientierten Programmiersprachen C++ und JAVA
aber auch mit den speziellen Constraint-basierten Program-miersprachen gelungen.
Ausblickend ist zu sagen, dass die Freiheit des Nutzerszur problemspezifischen Gestaltung der Suche zukünftigdurch automatisierte Suchtechniken auch aus anderen For-schungsgebieten der künstlichen Intelligenz komplementiertwerden wird. Hierin zeigt sich einmal mehr der integrativeCharakter der Constraint-Programmierung.
Anhang
ECLiPSe-PROLOG: Vorspann zu Listing 1 bzw. 2
:- lib(ic). % Listing 1 und 2:- lib(ic_global). % nur Listing 2
CHOCO: Vor- und Nachspann zu Listing 3
import choco.Choco;import choco.cp.solver.CPSolver;import choco.cp.model.CPModel;import choco.kernel.model.
variables.integer.IntegerVariable;...
for (int i = 0; i < n; ++i)System.out.print(s.getVar(seq[i]).getVal() + " ");
COMET: Vor- und Nachspann zu Listing 5
import cotls;...
cout << seq << endl;
Literatur
1. Apt KR, Schaerf A (1999) The alma project, or how first-order lo-gic can help us in imperative programming. In: Olderog ER, Stef-fen B (Hrsg) Correct system design. Lecture notes in computerscience, Bd 1710. Springer, Berlin, S 89–113
2. Apt KR, Wallace M (2007) Constraint logic programming usingeclipse. Cambridge University Press, Cambridge
3. Freuder EC (1997) In pursuit of the holy grail. Constraints2(1):57–61
4. Frühwirth T, Raiser F (eds) (2011) Constraint handling rules: com-pilation, execution, and analysis. Books on Demand, Stoughton
5. Gardner M (1979) Mathematical circus. Knopf, New York6. Hanus M, Antoy S, Braßel B, Kuchen H, López-Fraguas FJ, Lux
W, Moreno-Navarro JJ, Steiner F (2006) Curry. An integratedfunctional logic language. Version 0.8.2
7. Hofstedt P (2010) Constraint-based object-oriented programming.IEEE Softw 27(5):53–56
8. Hofstedt P (2011) Multiparadigm constraint programming langua-ges. Springer, Berlin
9. ILOG Solver 6.0. user’s manual. ILOG, 10/200310. Jaffar J, Lassez JL (1987) Constraint logic programming. In:
14th ACM symposium on principles of programming languages(POPL), S 111–119
11. Michalewicz Z, Fogel DB (2004) How to solve it: modern heuri-stics. Springer, Berlin
12. Michel L, Van Hentenryck P (2000) Localizer. Constraints 5:41–82
13. Michel L, Van Hentenryck P (2003) Comet in context. In: Procee-dings of the Paris C. Kanellakis memorial workshop on the occa-sion of his 50th birthday: principles of computing & knowledge(PCK50). ACM, New York, S 95–107
14. Rossi F, Van Beek P, Walsh T (Hrgs) (2006) Handbook of cons-traint programming. Foundations of artificial intelligence. Else-vier, Amsterdam
15. Saraswat VA (1993) Concurrent constraint programming. MITPress, Cambridge
16. Schrijvers T, Stuckey P, Wadler P (2009) Monadic constraint pro-gramming. J Funct Program 19(6):663–697
17. Smolka G, Henz M, Würtz J (1995) Object-oriented concurrentconstraint programming in Oz. In: Saraswat VA, Van HentenryckP (eds) Principles and practice of constraint programming. MITPress, Cambridge. Chap 2
18. Van Hentenryck P (1999) The OPL optimization programminglanguage. MIT Press, Cambridge
19. Van Hentenryck P (2007) Constraint programming as declara-tive algorithmics. In: Benhamou F, Jussien N, O’Sullivan B(eds) Trends in constraint programming. ISTE, London, S 25–39.Chap 1
20. Van Hentenryck P, Michel L (2005) Constraint-based local search.MIT Press, Cambridge
21. Wuille P, Schrijvers T (2009) Monadic constraint programmingwith gecode. In: Frisch AM, Lee J (Hrsg) 8th international work-shop on constraint modelling and reformulation, S 171–185
22. Zweistein (2004) Logelei. In: Die Zeit, 3123. Chocosolver. http://www.emn.fr/z-info/choco-solver. Last visited
2011-11-0224. Dynadec: Constraint-based local search. http://dynadec.com/
technology/constraint-based-local-search/. Last visited 2011-11-02
25. A problem library for constraints. http://www.csplib.org/. Last vi-sited 2011-11-02
26. The ECLiPSe constraint programming system. http://eclipseclp.org/. Last visited 2011-11-02
27. Gecode—generic constraint development environment. http://www.gecode.org/. Last visited 2011-11-02
28. Global constraint catalog: global_cardinality. http://www.emn.fr/z-info/sdemasse/gccat/Cglobal_cardinality.html. Last visited2011-11-02
29. JaCoP—Java constraint programming solver. http://jacop.osolpro.com/. Last visited 2011-11-02
30. SICStus prolog: combinatorial constraints. http://www.sics.se/sicstus/docs/latest4/html/sicstus.html/Combinatorial-Constraints.html. Last visited 2011-11-02
54 Künstl Intell (2012) 26:47–54
Thomas König schloss sein Infor-matik-Studium an der Brandenbur-gischen Technischen Hochschule inCottbus im Jahr 2010 ab. Er arbei-tet seither als akademischer Mit-arbeiter am dortigen Lehrstuhl fürProgrammiersprachen und Compi-lerbau. Seine Forschungsinteressensind die Constraint- und Multipara-digmatische Programmierung.
Petra Hofstedt ist Professorin fürInformatik und leitet den Lehrstuhlfür Programmiersprachen und Com-pilerbau an der BrandenburgischenTechnischen Hochschule in Cott-bus. Sie promovierte an der Tech-nischen Universität in Dresden undhabilitierte an der Technischen Uni-versität Berlin. Ihre Forschungs-interessen liegen insbesondere aufdem Gebiet der Constraint-Program-mierung und der Multiparadigmati-schen Programmiersprachen.