Abstract
Constraint programming is a family of techniques for solving combinatorial problems, where the problem is modelled as a set of decision variables (typically with finite domains) and a set of constraints that express relations among the decision variables. One key concept in constraint programming is propagation: reasoning on a constraint or set of constraints to derive new facts, typically to remove values from the domains of decision variables. Specialized propagation algorithms (propagators) exist for many classes of constraints.
The concept of support is pervasive in the design of propagators. Traditionally, when a domain value ceases to have support, it may be removed because it takes part in no solutions. Arc-consistency algorithms such as AC2001 [in: Proceedings 17th International Joint Conference on Artificial Intelligence (IJCAI 2001), 2001, pp. 309–315] make use of support in the form of a single domain value. GAC algorithms such as GAC-Schema [in: Proceedings 15th International Joint Conference on Artificial Intelligence (IJCAI 97), 1997, pp. 398–404] use a tuple of values to support each literal. We generalize these notions of support in two ways. First, we allow a set of tuples to act as support. Second, the supported object is generalized from a set of literals (GAC-Schema) to an entire constraint or any part of it.
We design a methodology for developing correct propagators using generalized support. A constraint is expressed as a family of support properties, which may be proven correct against the formal semantics of the constraint. We show how to derive correct propagators from the constructive proofs of the support properties. The framework is carefully designed to allow efficient algorithms to be produced. Derived algorithms may make use of dynamic literal triggers or watched literals [in: Proc. 12th International Conference on the Principles and Practice of Constraint Programming (CP 2006), 2006, pp. 182–197] for efficiency. Finally, three case studies of deriving efficient algorithms are given.
Introduction
In this paper we provide a formal development of the notion of support in constraint satisfaction. This notion is ubiquitous and plays a vital role in the understanding, development, and implementation of constraint propagators, which in turn are the keystone of a successful constraint solver. While we focus on a formal development in this paper, our purpose is not to describe formally what is currently seen in constraint satisfaction. Instead, we generalize the notion of support so that it can be used in a wider variety of propagators. The result is the first step in a twin programme of developing a formal understanding of constraint algorithms, while also developing notions such as generalized support which should lead to improved constraint algorithms in the future.
The methodology presented here for formal development of propagators is based on the proofs-as-programs and propositions-as-types interpretations of constructive type theory [11,17]. Like the earlier development in [9], the approach presented here uses a constructive type theory as the formal framework for specifying and developing programs. There, the proofs were mechanically checked in the Nuprl theorem prover [12], here the development is formal but proofs have not been mechanically checked.
The paper is structured as follows. In this section, we introduce the key concepts used in our method and give an overview of related work. In Section 2 we define the basic mathematical concepts used in the rest of the paper. In Section 3 we define generalized support and present the method for development of constraint propagators that are correct by construction. In Section 4 we present three case studies where we apply our method. In the third case study we develop and implement a new propagator that can be more efficient than the existing propagator in a popular constraint solver. Finally we conclude in Section 5.
Overview of the constraint satisfaction problem
A constraint is simply a relation over a set of variables. Many different kinds of information can be represented with constraints. The following are simple examples: one variable is less than another; a set of variables must take distinct values; task A must be scheduled before task B; two objects may not occupy the same space. It is this flexibility which allows constraints to be applied to many theoretical, industrial and mathematical problems.
The classical constraint satisfaction problem (CSP) has a finite set of variables, each with a finite domain, and a set of constraints over those variables. A solution to an instance of CSP is an assignment to each variable, such that all constraints are simultaneously satisfied – that is, they are all true under the assignment. Solvers typically find one or all solutions, or prove there are no solutions. The decision problem (‘does there exist a solution?’) is NP-complete [1], therefore there is no known polynomial-time procedure to find a solution.
Solving CSP
Constraint programming includes a great variety of domain specific and general techniques for solving systems of constraints. Since CSP is NP-complete, most algorithms are based on a search which potentially explores an exponential number of nodes. The most common technique is to interleave splitting and propagation. Splitting is the basic operation of search, and propagation simplifies the CSP instance. Apt views the solution process as the repeated transformation of the CSP until a solution state is reached [1]. In this view, both splitting and propagation are transformations, where propagation simplifies the CSP by removing domain values that cannot take part in any solution. A splitting operation transforms a CSP instance into two or more simpler CSP instances, and by recursive application of splitting any CSP can be solved.
Systems such as Choco [21], IBM ILOG CPLEX CP Optimizer [18] and Minion [14,15] implement highly optimized constraint solvers based on search and propagation, and (depending on the formulation) are able to solve large problem instances quickly.
Our focus in this paper is on propagation algorithms. A propagation algorithm operates on a single constraint, simplifying the containing CSP instance by removing values from variables in the scope of the constraint. Values which cannot take part in any solution are removed. For example, a propagator for
Proofs to propagators
Researchers frequently invent new algorithms and (sometimes) give proofs of correctness, of varying rigour. In this paper we provide a formal semantics of CSP. This allows us to formally characterize correctness of constraint propagators, and therefore aid the proof of correctness of propagators. Following this, we lay the groundwork for automatic generation of correct propagators. The method is to write a set of support properties which together characterize the constraint. Each property is inserted into a schema, and a constructive proof of the schema is generated. This proof is then translated into a correct-by-construction propagator. This method is based on the concept of generalized support, described in the next section. Finally, we give examples of this method by deriving propagators for the
Generalized support
Central to this work is the notion of support. This notion is used informally in many places (for example, in the description of the algorithm GAC-Schema [7]) and more formally by Bessière [5]. We generalize the concept of support, and develop a formal framework to allow us to produce rigorous proofs of the correctness of propagators that exploit the generalized concept of support.
Support is a natural concept in constraint programming. Constraint propagators remove unsupported values from variable domains, thus simplifying a CSP instance. Supported values cannot be removed, since they may be contained in a solution. Thus a support is evidence that a value (or set of values) may be contained in a solution. If no support exists, it is guaranteed that a value (or set of values) is not contained in any solution.
A support property characterises the supports of a particular value (or set of values) for a particular constraint. For example, three support properties of an element constraint are given by Gent et al. [15]. Each of these three properties is used to create a propagator, such that the three propagators together achieve generalized arc consistency. In this instance, writing down support properties assisted in proving the propagators correct.
We show that correct support properties can be used to create propagators that are correct by construction. We describe a general propagation schema, which is a description of what should be proved when support is lost for a given support property. This captures how propagators work in practice. They are triggered when it is noted that the current support is lost. The propagator then seeks to re-establish support. This might be possible on the current domains, or it may need to narrow domains (i.e. remove some values of some variables), or it may be that no new support is possible and the constraint is guaranteed to be false. The propagation schema specialized for a given support property can be proven constructively. The proof contains sufficient information to be translated into a correct propagator. We envisage two main uses for such a propagator. For some constraints, it may be an efficient propagator that can be used directly. Otherwise, the constructed propagator may be used as part of an informal argument for the correctness of an efficient propagator.
Related work
There are a number of items of related work with related or similar goals, however the approach taken in each case is quite different to our approach. Apt and Monfroy [2] generate propagation rules such as
Van Hentenryck, Saraswat and Deville [27] designed indexicals, a high-level language for implementing propagators. Indexicals allow straightforward and transparently correct implementations of propagators for simple constraints, however there is no way to implement sophisticated propagators for global constraints using indexicals. Tack, Schulte and Smolka [26] presented a specification language for constraints on finite set variables, and an implementation language called set projectors that is inspired by indexicals. They present a method to automatically translate specifications into set projectors. Our approach is much broader than either indexicals or set projectors, since both restrict the form of propagation algorithms that can be implemented.
Beldiceanu, Carlsson and Petit [4] describe constraints using finite state automata extended with counters. For a constraint C, the automaton for C can check whether any given assignment satisfies C. Beldiceanu, Carlsson and Petit give a method to translate an automaton into a set of short constraints (a decomposition) such that propagating them will propagate the original constraint C, and there are (in some cases) guarantees of the strength of propagation. The approach has been subsequently refined, for example by linking overlapping prefixes and suffixes of constraints [3]. Their approach generates decompositions of a particular form, whereas in this paper our focus is on deriving efficient propagators.
Cohen, Jefferson and Petrie [10,19] studied the properties of triggers, in particular comparing static triggers with movable triggers on a number of constraint classes and consistencies. They prove lower bounds on the number of triggers required, showing in most cases that many more static triggers are required compared to movable triggers. To do this they generalise the concept of support in a similar way to us, however their work treats each propagator as a monolithic black box whereas we are interested in constructing propagators and proving correctness and other properties of them.
Definitions and notation
The standard mathematical account
We start by giving the standard definition of a constraint satisfaction problem (e.g. see [5,13]). Formal definitions of the notations used here are given below. A Constraint Satisfaction Problem (CSP) is given by a triple We say a Z-tuple τ satisfies constraint A solution to a CSP (Constraint Satisfaction Problem).
(Satisfying tuple).
(Solution).
Variable naming conventions, ranges, and literals
We use lower case letters (possibly subscripted or primed) from near the end of the Latin alphabet
Ranges are defined as follows.
Vectors
We use uppercase letters
We write finite vectors as sequences of values enclosed in angled brackets, (e.g.
Membership in a vector is defined as follows.
If
Signatures
A signature σ is a function mapping variables in X to their associated domains. Thus, signatures are functions The relation ⊏ is well-founded if restricted to signatures with finite domains. (Signature Inclusion Well-founded).
Relations
In the description of a CSP given above, a constraint
Given a signature σ mapping the variables in schema Y to their domains, a relation
All tuples in
The values in each column come from the specified domain for that column:
Schemata are vectors of variable names with no restriction on how many times a variable may occur. Thus it is possible to have a wellformed relation whose schema has common names for multiple columns. Given a signature σ over a schema X, a tuple τ is called a X-tuple if
Tuple coherency
Conceptually, relations provide a representation for storing valuations (assignments of values to variables) and so we must distinguish between tuples which represent coherent valuations (even when their schemata may contain duplicate variable names) and tuples that do not. This motivates the following definitions.
The wellformedness condition on relations requires values in columns labeled by a variable come from the domain of that variable, but does not rule out cases where a single tuple with multiple columns named by the same variable have different values in those columns.
Consider the relation
An X-tuple τ is coherent w.r.t. variable z iff the following holds.
In many constraint solvers, incoherent tuples may arise during a computation, but they are never counted among solutions. For example, the Global Cardinality constraint
Strictly speaking, because incoherent tuples do not count as solutions, the semantics could be specified simply disallowing them. However, this approach would rule out faithful finer grained representations of the internal states of constraint solvers which do generate incoherent tuples, for example when searching for support. Based on this, we have decided to include them although this adds some complexity to the specification.
Selection is an operation mapping relations to relations generating new ones from old by filtering rows (tuples) based on predicates on the values in the tuple.
Given a relation
The tuples selected from a relation by index selection are not guaranteed to be coherent with respect to schema Y.
Given a relation
Thus a tuple τ is included in a selection
(Selection Wellformed).
For all well-formed relations
Finally, we define coherent selection as follows.
Projection
Projection is an operation for creating new relations from existing ones by allowing for the deletion, reordering and duplication of columns. We use a generalized version here that allows duplicate names. This is because many constraint solvers (including Minion [14] for example) allow schemata to contain duplicate names.
(Projection maps exist).
For all vectors X and Y, if
Note that there is no restriction on the relative lengths of X and Y, e.g. it is possible for any of the following to hold:
Consider
Given X and Y, if
(Tuple Projection Wellformed).
Given X and Y, if
Whenever
Suppose
This observation is made precise by the following lemma.
For all X and Y, and for all projection maps f and g witnessing
Since projections Z where
For all X, Y and Z, if
So far we have defined projection of a single tuple, potentially with repeated variables in the schema. We lift the notation tuple-wise to relations as given by the following definition. Given X and Y, and a wellformed relation
For all well-formed relations
(Relation Projection).
(Relation Projection WF).
Equivalence of constraints
Now that we have relation projection, we are able to define an equivalence of constraints which does not depend on the ordering (or the length) of schemata.
(Schema Equivalence).
Schema equivalence requires only that X and Y contain the same set of variables. The order of variables and the number of duplicates are not restricted.
(Constraint Equivalence).
There are several steps to the constraint equivalence definition. First, it is required that the schemata are equivalent. Then we find a projection map f that will be used to reorder the schema X to match Y. Coherent selection is used to remove the incoherent tuples of both constraints. The schema X of the first constraint is reordered to match Y. Finally, the two constraints are equivalent if they have the same set of coherent tuples.
Incoherent tuples are removed before reordering the schema X, therefore any projection map f will produce the same set of reordered tuples (as in Example 3).
Syntactic definition of relations
Constraints are rarely presented extensionally but are instead described in some syntactic way. We introduce the following notation to denote the map from syntactic descriptions to their extensional meanings.
(Semantics).
Given a syntactic description of a constraint (say
So, if we have a constraint
Propagation and support
Propagation is the process of narrowing the domains of variables so that solutions are preserved. This effectively shrinks the search-space and is one of the fundamental techniques used in constraint programming. It has been described ([13, pp. 17]) as a process of inference to distinguish it from search. Most work on propagation considers the constraints singly.
(Generalized Arc Consistency).
Given a constraint
(Generalized Arc Consistency).
Given a constraint
Enforcing GAC is the strongest form of propagation that considers constraints singly and acts only on the variable domains. Other forms of consistency (such as bound consistency) lie between GAC and no change (i.e.
Support
The concept of support was introduced in Section 1.4. Support is evidence that a set of domain values (or a single value) are consistent for some definition of consistency (for example, GAC) for a particular constraint C. If a set of values have no support, then they cannot be part of any solution to C, and therefore can be eliminated from variable domains without losing any solutions to the CSP. The concept of support is central to the process of propagation.
In [5, pp. 37] Bessière gives a description of when a tuple supports a literal. We use a more expressive model where support (or perhaps we should call it evidence) is defined by sets of tuples. In most cases, supports will be singletons (i.e. they are simply represented by a set containing a single tuple). However, some constraints require a set of tuples to express the condition for support.
Consider the AllDifferent constraint
Extensional constraints (sets of tuples) are interpreted disjunctively, i.e. as long as the set is non-empty, a solution exists. Similarly, support exists if the support set is non-empty. Our generalization of support is to model it as a set of tuples interpreted conjunctively i.e. they all must be valid for support to exist. Thus, a generalized support set is a disjunction of conjunctions (
We use the following as a simple running example throughout this section. Consider the constraint
A support property is a predicate that takes a set of tuples and a signature, and identifies whether the set of tuples is in fact a support. We will use support properties to define the behaviour of propagators.
(Support property).
Given a schema Y and signature σ over Y, a support property is a predicate
(Support Set for a property P).
Given a schema Y and a signature σ over Y and a property of sets of Y-tuples,
Note that support sets are minimal w.r.t. the property P since they contain no subset which also satisfies the property.
Consider Example 5, the constraint
A collection of properties is supported if they all are. If (Support for a collection of properties).
Admissible properties and triggers
Our language for properties is unrestrained and allows us to specify properties that are not sensible for specifying propagators. Therefore an admissibility condition is required. We define p-admissibility as follows.
(P-admissibility).
We say a property P is p-admissible if it satisfies the following condition
P-admissibility is a kind of stability condition on properties that guarantees that if a
Continuing Example 5, the support property
A constraint solver has a trigger mechanism which calls propagators when necessary. Each propagator registers an interest in domain events by placing triggers. For example, if a propagator placed a trigger on
In this paper, we focus on literal triggers which can be moved during search. We consider two different types of movable literal trigger: those which are restored as search backtracks (named dynamic literal triggers), and those which are not restored (named watched literals [15]).
The definition of p-admissibility allows the use of dynamic literal triggers, among other types. Watched literals are preferable to dynamic literal triggers because there is no need to restore them when backtracking, which saves space and time. However, it is not always possible to apply watched literals. We define an additional condition on properties named backtrack stability, which is sufficient to allow the use of watched literals.
(Backtrack Stability).
We say a property P is backtrack stable if it satisfies the following condition.
Backtrack stability states that any non-empty support S under
Continuing Example 5, the support property
Backtrack stability is in fact too strong: it is not necessary for a support to remain valid for all larger signatures, it is only necessary for it to remain valid at signatures that are reachable on backtracking. However it is sufficient for the purposes of this paper.
Backtrack stability also depends on the form of properties. The element support properties presented in Section 4.1.1 are not backtrack stable. However, they can be reformulated to be backtrack stable, by dividing them up as we show in Section 4.1.2.
For some property
For example,
(Properties True and False).
We define the constant properties True and False by lifting them to functions of sets of tuples.
(True singleton).
For all Y and for every signature σ over Y,
Note, that it might be assumed that if any of the domains in σ are empty, then there should be no support, even for the True property. Checking for emptiness is not a function of support, but is done at a higher level.
(False Empty).
For all Y and for every signature σ over Y,
(True and False are p-admissible).
The properties True and False are p-admissible.
We can combine supports by taking the conjunctions or disjunctions of their properties.
We define the conjunction and disjunction of support properties as follows.
We state the following lemma without proof.
Given a schema Y and signature σ for Y and two p-admissible properties P and Q, then
Extensional support for literals
(Support Property (for a Literal)).
Given a schema Y, a signature σ over Y, and a literal
If
Assume
Given a schema Y and a signature σ on Y, if
Note that
Literal support captures support for variable-value pairs. Generalized support is support for some property not necessarily representable by a single tuple. Thus, if any tuple in a generalized support is lost, then the support no longer holds. In Example 4 (GAC AllDifferent) we gave a list of literals as evidence that an AllDifferent constraint is GAC. A list of literals would be represented as a generalized support in our framework by using the support property for a literal (for each literal individually) then finding support for a collection of properties (as in Definition 11).
Constraint solvers typically allow movable triggers to be placed on literals, so the connection between literals and our definition of generalized support is important for this paper. A generalized support may be less compact than the set of literals it represents. However, the implementation of a propagator may correctly place triggers on the set of literals. Generalized support is merely an abstraction used in our framework.
Soundness and completeness of a collection of propagators
Propagators narrow domains to minimize the search space and provide evidence that the narrowed domains have not eliminated any solutions. Constraints may be implemented by a collection of propagators. To show that the propagators are correct with respect to the constraint they support we show they are sound and complete.
Soundness
Soundness says that for the most restricted non-empty signatures (ones where all domains in the signature have been narrowed to a singleton) the propagator must be able to distinguish between the constraint being empty or inhabited by a single tuple. If support is non-empty at a singleton domain then the constraint must be true there as well. The definition of soundness presented here is related to the one in [26].
(Propagator Soundness).
Given a constraint C with schema Y and a set of properties
Thinking of support as evidence for truth, one might expect soundness to be characterized as follows:
Completeness
Completeness guarantees that if the extensional representation of a constraint is non-empty at a signature σ then there is support for the family of properties
(Propagator Completeness).
Given a constraint C with schema Y and a set of properties
If
(Local Completeness).
Given a set of properties
If
Our definition of completeness ensures that a propagator derived from a support property does not fail early, therefore it is merely a correctness property. It is similar in intention to Maher’s definition of weak completeness [20], although Maher’s definition only applies to singleton domains.
Soundness and completeness as defined here are the minimum conditions required for a propagator to operate correctly, thus popular notions of consistency such as GAC,
This property corresponds to a propagator that waits until all variables are assigned before checking the constraint. Any practical propagator is stronger than this.
Soundness and completeness are not the only options for characterizing the correctness of a set of generalized support properties. For example, in [15] it is shown that a set of properties imply the domain is GAC. Other forms of consistency such as bound consistency could also serve as correctness conditions for a set of properties.
The methodology for formal development of propagators for a constraint C is as follows:
Describe a set of support properties ( For each property Prove the soundness and completeness of
The propagation schema
We present the following schematic formula whose constructive proofs capture the methods of generating support for a particular property P.
(Propagation Schema).
Given a signature σ, a schema X, and a p-admissible property P, constructive proofs of the following statement yield a propagator for P.
We are interested in constructive proofs2
There is a classical proof of propagator schema that is independent of the property P and carries no interesting computational content.
Given a p-admissible support property P, a constructive proof of the propagator schema yields a function that takes as input a set S, evidence that a new signature Evidence that there is no support for P in
In the propagation schema, if we assume the antecedent
Because property P is p-admissible, if we have
In this section we present three case studies of applying our methodology.
A propagator for the element constraint
The element constraint is widely useful in specifying a large class of constraint problems. It has the form
(Element Semantics).
The element constraint is widely used because it represents the very basic operation of indexing a vector [28]. For example, Gent et al. model Langford’s number problem and quasigroup table generation problems using element [15].
In [15, pp. 188] three properties to establish GAC for the element constraint are characterized. We restate theorem 1 from that paper here:
Given a constraint of the form
(Theorem 1 of reference [15]).
Support properties
Each of the three properties above can be characterized as support properties.
(Element Support Properties).
With a schema X and variables y and z and a signature σ, there are three properties corresponding to three propagators for establishing GAC for the element constraint
Note that for property
This specification corresponds to a set of dynamic literal triggers [15]. Ideally a static assignment trigger would be used for
Property
Property
It is easy to prove that the three properties act as intended:
Given a signature σ, we have:
(1) is true if and only if
(2) is true if and only if
(3) is true if and only if
The if directions are all easy. For (1), if the first disjunct of For Only if, first suppose that (1) is true. If Suppose (2) is true. We have Suppose (3) is true. Since
Following our methodology, we first prove that properties
(
is p-admissible).
We case split on the disjuncts of
For the second disjunct of
Since
The proof is the same as above, with z and y exchanged, i and a exchanged, and
Each of these smaller properties then requires two literals as support, or (if
Now that we have established p-admissibility for each of We consider Let C be an element constraint of the form The proof consists of constructing If We consider Let If We consider Let If (
Now we prove that the conjunction of the element support properties (Definition 21) is sound and complete using the semantics of element (Definition 20). We will write
Let σ be an arbitrary singleton signature. Since σ is a singleton it encodes a single tuple (say τ). Assume
Assume The first disjunct of
Note that if ( If there is no support for ( The completeness of (
The propagators derived here to enforce GAC on the element constraint are not identical to those presented by Gent et al. [15]. However they do follow the same general scheme. The main difference is that the propagators here use dynamic literal triggers in place of watched literals and a static assignment trigger. The concept of generalized support has allowed us to create these propagators within one formal framework.
Triggering the AllDifferent constraint
The AllDifferent constraint is widely used and has a powerful GAC propagator introduced by Régin [22]. In this section we give a sketch of how the propagator may be represented in our framework. The propagator is based on graph theory. It establishes GAC in a single invocation, but can be expensive. AllDifferent ensures that each variable in the schema takes a different value, as defined below.
(AllDifferent Semantics).
Gent, Miguel and Nightingale [16] presented a method for using dynamic literal triggers with Régin’s algorithm. The key idea is to construct a set of literal supports such that (while all the literal supports are valid) the algorithm will always follow the same trajectory and therefore no new value deletions are necessary to maintain GAC.
Given that the algorithm enforces GAC in a single call, it is most appropriate to represent it with a single support property. The support property is very simple and essentially treats the propagator as a black box. Our goal is to capture the interaction between the propagator and the rest of the solver, not to represent the entire propagator as we did for the Element constraint.
(AllDifferent Support Property).
Given a schema X and a signature σ over X, we define a support property for the constraint
In Example 4 we gave an example of
P-admissibility
We make an informal argument that
Gent et al. prove that the algorithm will make no value deletions under
Propagation schema, soundness and completeness
We sketch a proof of the propagation schema for
Ordinarily we would prove soundness and completeness of a collection of properties. However, since we have a single property that precisely enforces GAC, these proofs are not necessary because both soundness and completeness are consequences of GAC.
Discussion
We have shown that our framework is sufficiently general to capture the triggering of the GAC AllDifferent propagator. GAC AllDifferent differs substantially from Element, yet our framework can represent both.
New watched literal propagators for occurrence constraints
The two constraints
Occurrence constraints arise in many problems. For example, in a round-robin tournament schedule, it may be required that no team plays more than twice at each stadium [29], represented by occurrenceleq constraints. In car sequencing (car factory scheduling), occurrence constraints may be used to avoid placing too much demand on a work-station [25].
First we present the formal semantics of occurrenceleq and occurrencegeq, followed by support properties for the two constraints.
(Occurrenceleq Semantics).
(Occurrencegeq Semantics).
Support properties
(Occurrence Support Properties).
Given a schema X, value a and occurrence count c,
When it is no longer possible to satisfy the first disjunct, a corresponding propagator must narrow the domains to satisfy the second disjunct, by setting c variables to a. At this point, the constraint is trivially satisfied so S may be empty.
P-admissibility and backtrack stability
We now prove that both properties meet the p-admissibility requirement.
(
is p-admissible).
The property
We case split on the disjuncts of
The property
We case split on the disjuncts of
In order for the two propagators to make use of watched literals, we must prove that both properties are backtrack stable. The watched literals representing a support are not backtracked, so a support must remain a support as search backtracks (and the domains are widened). The two occurrence support properties are backtrack stable according to Definition
13
. For both properties, the second disjunct is irrelevant because it is satisfied by
Now we give a constructive proof of the propagation schema for
(
Support Generation).
We consider
Let
S contains one literal for each index in I. At least one item in S is invalid (by the antecedant). The proof proceeds by constructing
When
The proof explicitly re-uses variable indices but not b values from S. This fits well with Minion’s watched literal implementation, which notifies the propagator once for each invalid literal in S. However, the proof does not require the use of watched literals, it allows many concrete implementations and may be used with any propagation-based solver.
It is straightforward to prove the propagation schema for
We consider
The proof is the same as the proof of
This proof also re-uses variable indices from S and thus fits well with Minion’s watched literal infrastructure.
Now we prove the soundness and completeness of both properties, and hence the correctness of the two propagators.
(Occurrenceleq Sound).
Let σ be an arbitrary singleton signature. Since σ is a singleton it encodes a single tuple (say τ). Assume
Since σ is singleton, the first disjunct of
The proof that
Assume
Once again, the proof that
The occurrence propagators implemented in Minion 0.12 use static triggers. Therefore they may be invoked when support has not been lost. By comparison, these watched literal propagators are only invoked when one of the literals in the support is lost.
We implemented the
We compare against the existing propagator for
We constructed a benchmark CSP as follows. We have a vector of variables X where
The solver branches on variables in X in index order, and branches for 1 before 2. Once variable
WatchedProp watches 11 literals of the form
Table 1 shows that StaticProp scales approximately linearly in the number of search nodes explored, but WatchedProp speeds up as search progresses. With a limit of 100 million nodes, WatchedProp is more than twice as fast as StaticProp.
Times for the WatchedProp and StaticProp algorithms, median of 16 runs on a dual processor Intel Xeon E5520 at 2.27 GHz
Times for the WatchedProp and StaticProp algorithms, median of 16 runs on a dual processor Intel Xeon E5520 at 2.27 GHz
We have shown that our framework can be used to create highly efficient watched literal propagators for occurrence constraints, and that these outperform conventional propagators that use static triggers. There is no requirement for the propagators to maintain GAC. In this case we have proven that the propagators are sound and complete, the most basic requirements for correctness. The framework is entirely agnostic about whether the propagator maintains GAC, some form of bound consistency or indeed some custom consistency that is specific to the type of constraint.
Conclusions and future work
This paper has made a number of contributions to the formal study of constraint solving, in particular of propagation in constraint solving. We have shown that we can define formally a notion of generalized support, which generalizes the standard notion of support in constraint satisfaction. This generalization allows us to work with propagators that might not have been seen as using support. Since our definition is so general, we introduced the notion of p-admissible support properties. The definition of p-admissibility corresponds to the use of a particular kind of trigger within the constraint solver. Triggers are events which cause propagators to be called within the solver, and p-admissibility guarantees that any event which might cause support to be lost is observed by some trigger. In this paper we have focussed on a definition of p-admissibility corresponding to literal triggers (that are activated by deletion of a particular value from the domain of a variable). We have given a formal description of constraint propagation. Given a p-admissible support property, we have defined the propagation schema. A constructive proof of the propagation schema shows how a propagator can be constructed to find new support when support is lost. We have given examples of this for the specific constraints
Our work on propagators is not merely a formalisation of existing standard usage in constraint programming. We are not aware of a definition of support as general as ours within constraints. The notion of generalized support should be directly useful in constraints, enabling a much better understanding of propagation algorithms in the constraint community. Our hypothesis is that almost all propagators used in constraint solvers can be seen as reasoning with some form of support property, even though most propagators are not currently presented as doing so. Once this hypothesis is confirmed, we can present propagation algorithms in a much more uniform fashion, as well as building constraint solvers to exploit these propagation algorithms. Thus our intended future work consists of two strands: first continuing the formal development we have started here, and second demonstrating the application of our work to the constraints community.
Footnotes
Acknowledgements
The work of the authors has been partially supported by the following UK EPSRC grants: EP/E030394/1, EP/F031114/1, EP/H004092/1, and EP/M003728/1, support for which we are very grateful.
