Constraint logic programming is a variant of logic programming including concepts from constraint satisfaction. A constraint logic program is a logic program that contains constraints in the body of clauses. An example of a clause including a constraint is A(X,Y) :- X+Y>0, B(X), C(Y). In this clause, X+Y>0 is a constraint; A(X,Y), B(X), and C(Y) are literals like in regular logic programming. Intuitively, this clause tells one condition under which the statement A(X,Y) holds: this is the case if X+Y is greater than zero and both B(X) and C(Y) are true.
Like in regular logic programming, programs are queried about the provability of a goal. A proof for a goal is composed of clauses whose constraints are satisfied and whose literals can in turn be proved using other clauses. Execution is done by an interpreter, which starts from the goal and recursively scans the clauses trying to prove the goal. Constraints encountered during this scan are placed in a set called constraint store. If this set is found out to be unsatisfiable, the interpreter backtracks, trying to use other clauses for proving the goal. In practice, satisfiability of the constraint store may be checked using an incomplete algorithm, which is one that does not always detect inconsistency.
Overview
Formally, constraint logic programs are like regular logic programs, but the body of clause can contain constraints, in addition to the regular logic programming literals.
The semantics of constraint logic programs can be defined in terms of a virtual interpreter that maintains a pair during execution. The first element of this pair is called current goal; the second element is called constraint store. The current goal contains the literals the interpreter is trying to prove; constraints and equality of terms are considered literals, so they can occur in the goal; the constraint store contains all constraints the interpreter has assumed satisfiable so far.
Initially, the current goal is the goal and the constraint store is empty. The interpreter proceed by removing the first element from the current goal and analyzing it. This analysis may end up in a recursive call or a failure; the interpreter backtracks in the second case. It may also generate an addition of new literals to the current goal and an addition of new constraint to the constraint store. The interpreter stops when the current goal is empty and the constraint store is satisfiable.
Each step of the algorithm is as follows. The first literal of the goal is considered and removed from the current goal. If it is a constraint, it is added to the constraint store. If it is a literal, a clause whose head has the same predicate of the literal is chosen; the clause is rewritten by replacing its variables with new variables (what is important is that these new variables do not already occur in the goal); the body of the clause is then placed in front of the goal; the equality of each argument of the literal with the corresponding one of the rewritten clause head is placed in front of the goal as well.
Some checks are done during these operations. In particular, the constraint store is checked for consistency every time a new constraint is added to it. In principle, whenever the constraint store is unsatisfiable the algorithm could backtrack. However, checking unsatisfiability at each step would be inefficient. For this reason, an incomplete satisfiability checker may be used instead.
The interpreter stops when the current goal is empty and the constraint store is not detected unsatisfiable.
The constraints of constraints logic programming are typically of three classes: constraints over terms, constraints over reals, and constraints over finite domains, which are usually interpreted as sets of integers.
Terms and constraints
Different definitions of terms are used, generating different kinds of constraint logic programming: over trees, reals, or finite domains. A kind of constraint that is always present is the equality of terms. Such constraints must be present, as the interpreter adds t1=t2 to the goal whenever a literal P(...t1...) is replaced with the body of a clause whose rewritten head is P(...t2...).
Tree terms
In the basic case of constraint logic programming, terms are variables, constants, and functors applied to other terms. In this case, the only considered constraints are equality or disequality between terms. Equality is particularly important, as constraints t1=t2 are often generated by the intepreter.
A constraint t1=t2 can be simplified if both terms are functors applied to other terms. If the two functors are the same and the number of subterms is also the same, this constraint can be replaced with the pairwise equality of subterms. If the terms are composed of different functors or the same functor but on different number of terms, the constraint is unsatisfiable.
If one of the two terms is a variable, the only allowed value the variable can take is the other term. As a result, the other term can replace the variable in the current goal and constraint store, thus practically removing the variable from consideration. In the particular case of equality of a variable with itself, the constraint can be removed as always satisfied.
In this form of constraint satisfaction, variable values are terms.
Reals
Constraint logic programming with real numbers uses real expressions as terms. When no functors are used, terms are expressions over reals, possibly including variables. In this case, each variable can only take a real number as a value.
Precisely, terms are expressions over variables and real constants. Equality between terms is a kind of constraint that is always present, as the interpreter generates equality of terms during execution. As an example, if the first literal of the current goal is A(X+1)</math> and the interpreter has chosen a clause that is A(Y-1):-Y=1 after rewriting is variables, the constraints added to the current goal are X+1=Y-1 and . The rules of simplification used for functors are obviously not used: X+1=Y-1 is not unsatisfiable just because the first expression is built using + and the second using -.
Reals and functors can be combined, leading to terms that are expressions over reals and functors applied to other terms. Formally, variables and real constants are expressions, as any arithmetic operator over other expressions. Variables, constants (zero-arity-functors), and expressions are terms, as any functor applied to terms. In other words, terms are built over expressions, while expressions are built over numbers and variables. In this case, variables ranges over real numbers and terms. In other words, a variable can take a real number as a value, while another takes a term.
Equality of two terms can be simplified using the rules for tree terms if none of the two terms is a real expression. For example, if the two terms have the same functor and number of subterms, their equality constraint can be replaced with the equality of subterms.
Finite domains
The third class of constraints used in constraint logic programming is that of finite domains. Values of variables are in this case taken from a finite ___domain, often that of integer numbers. For each variable, a different ___domain can be specified: X::[1..5] for example means that the value of X is between 1 and 5. The ___domain of a variable can also be given by enumerating all values a variable can take; therefore, the above ___domain declaration can be also written X::[1,2,3,4,5]. This second way of specifying a ___domain allows for domains that are not composed of integers, such as X::[george,mary,john]. If the ___domain of a variable is not specified, it is assumed to be the set of integers representable in the language. A group of variables can be given the same ___domain using a declaration like [X,Y,Z]::[1..5].
The ___domain of a variable may be reduced during execution. Indeed, as the interpreter adds constraints to the constraint store, it performs constraint propagation to enforce a form of local consistency, and these operations may reduce the ___domain of variables. If the ___domain of a variable becomes empty, the constraint store is inconsistent, and the algorrithm backtracks. If the ___domain of a variable becomes a singleton, the variable can be assigned the unique value in its ___domain. The forms of consistency typically enforced are arc consistency, hyper-arc consistency, and bound consistency. The current ___domain of a variable can be inspected using specific literals; for example, dom(X,D) finds out the current ___domain D of a variable X.
As for domains of reals, functors can be used with domains of integers. In this case, a term can be an expression over integers, a constant, or the application of a functor over other terms. A variable can take an arbitrary term as a value, if its ___domain has not been specified to be a set of integers or constants.
Labeling
The labeling literals are used to check satisfiability or partial satisfiability of the constraint store and to find a satisfying assignment of variables on finite domains. A labeling literal is of the form labeling([variables]), where the argument is a list of variables over finite domains. Whenever the interpreter evaluates such a literal, it performs a search over the domains of variables to find an assignment that satisfies all relevant constraints. Typically, this is done by a form of backtracking: variables are evaluated in order, trying all possible values for each of them, and backtracking when inconsistency is detected.
The first use of the labeling literal is to actual check the satisfiability of the constraint store. Indeed, when the interpreter adds a constraint to the constraint store, it only checks or enforces a form of local consistency on it. This operation may not detect inconsistency even if the constraint store is unsatisfiable. A labeling literal over all variables of the constraint store enforces a complete satisfiability test to be performed.
The second use of the labeling literal is to actually determine an evaluation of the variables that satisfies the constraint store. Without the labeling literal, variables are assigned values only when the constraint store contains a constraint of the form X=value and when local consistency reduces the ___domain of a variable to a single value. A labeling literal over some variables forces these variables to be evaluated. In other words, after the labeling literal has been considered, all variables are assigned a value.
Typically, constraint logic programs are written in such a way labeling literals are evaluated only after as much constraints as possible have been accumulated in the constraint store. This is because labeling literals enforce search, and search is more efficient if there are more constraints to be satisfied. A constraint satisfaction problem is typicall solved by a constraint logic program having the following structure:
solve(X):-constraints(X), labeling(X)
constraints(X):- (all constraints of the CSP)
When the interpreter evaluates the goal solve(args), it places the rewritten body of the first clause in the current goal. Since the first goal is constraints(X'), the second clause is evaluated, and this operation moves all constraints in the current goal and eventually in the constraint store. The literal labeling(X') is then evaluated, forcing a search for a solution of the constraint store. Since the constraint store contains exactly the constraints of the original constraint satisfaction problem, this operation searches for a solution of the original problem.
Reference
- Dechter, Rina (2003). Constraint processing. Morgan Kaufmann. ISBN 1-55860-890-7
- Apt, Krzysztof (2003). Principles of constraint programming. Cambridge University Press. ISBN 0-521-82583-0
- Marriot, Kim (1998). Programming with constraints: An introduction. MIT Press.
{{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help) ISBN 0-262-13341-5
- Frühwirth, Thom (2003). Essentials of constraint programming. Springer.
{{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)CS1 maint: multiple names: authors list (link) ISBN 3-540-67623-6
See also