Contractor Programming

Gilles Chabert1 and Luc Jaulin2

1 Ecole des Mines de Nantes LINA CNRS UMR 6241,4, rue Alfred Kastler 44300 Nantes, France

gilles.chabert@emn.fr2 ENSIETA, 2, rue Fran cois Verny 29806 Brest Cedex 9, France

luc.jaulin@ensieta.fr

Abstract. This paper describes a solver programming method, calledcontractor programming, that copes with two issues related to constraintprocessing over the reals. First, continuous constraints involve an in-evitable step of solver design. Existing softwares provide an insufficientanswer by restricting users to choose among a list of fixed strategies.Our first contribution is to give more freedom in solver design by in-troducing programming concepts where only configuration parameterswere previously available. Programming consists in applying operators(intersection, composition, etc.) on algorithms called contractors that aresomehow similar to propagators.Second, many problems with real variables cannot be cast into the searchof vectors simultaneously satisfying the set of constraints, but a large va-riety of different outputs may be demanded from a set of constraints (e.g.,a paving with boxes inside and outside of the solution set). These out-puts can actually be viewed as the result of different contractors workingconcurrently on the same search space, with a bisection procedure in-tervening in case of deadlock. Such algorithms (which are not strictlyspeaking solvers) will be made easy to build thanks to a new branch &prune system, called paver.Thus, this paper gives a way to deal harmoniously with a larger set ofproblems while giving a fine control on the solving mechanisms. Thecontractor formalism and the paver system are the two contributions.The approach is motivated and justified through different cases of study.An implementation of this framework named Quimper is also presented.

1 Introduction

Constraint programming is a simple and efficient paradigm to handle a largeclass of combinatorial problems [40, 10, 44]. In presence of real-valued variables,constraint propagation algorithms combined with interval analysis [16, 22, 27,19, 9] are also particularly well-suited, included for real-world applications (see,e.g., [33, 21]). We shall refer to this interval variant of constraint programmingas interval programming. In spite of this adequacy, interval programming hasa moderate success. In our opinion, the reason is a lack of clear and unified

AdministrateurSticky Note@ARTICLE{ChabertJaulin09, author = {G. Chabert and L. Jaulin}, title = {{Contractor Programming}}, journal = {Artificial Intelligence}, volume= {173}, pages = {1079--1100}, year = {2009}}

formalism describing how solvers and derived programs are built. This paper isan attempt to fill this gap.

We propose a framework that allows one to build a continuous solver with afew lines, in a high-level syntax. More than just another tuning language, aprogramming framework is proposed.

Motivation

Three reasons justify the introduction of a solver programming framework inpresence of real variables.

1. Constraint programming is a declarative paradigm which means that a pro-grammer should spend most of the effort in modeling conveniently the prob-lem. This effort may comprise breaking symmetries, introducing global orsoft constraints, etc.. All these concepts are related to modeling and repre-sent, by the way, very active fields of research. In theory, the solver is a blackbox of which a programmer could ignore the details.Despite of this, there is always a need at some point to control the solver,as it is in all declarative languages (consider for instance Prolog cuts thatallow to rule out choices in the search). We can say that the overall efficiencyone gets is the combined result of efforts made on both aspects: modelingand solver control.With real variables, modeling facilities are limited. Constraints can usuallybe nothing but equations which means that mathematics is de facto theultimate modeling language1. The consequence is that solver control becomesan inevitable step if one is to improve efficiency.

2. Continuous solvers have a two-layered structure, namely interval analysisand constraint programming, The lower layer includes interval arithmeticsand interval numerical algorithms (e.g., an interval variant of the Newtoniteration) with round-off considerations. The upper layer includes branch& prune algorithms for describing sets of reals defined by constraints (oroptimizing a criterion under constraints). Since these layers correspond toquite different scientific communities, there is a need more than ever foran interface between them. In concrete words, it would be useful to give aconstraint programmer the ability to develop a continuous solver withoutdigging into details of interval analysis.

3. The last and possibly main point is related to the output of constraint solvers.With discrete domains, the output is always the set of solutions (or a subsetoptimizing some criteria). But in continuous domains, there may be a large

1 There is still a notable exception: geometrical constraints. Geometry represents asemantic level above algebra; as an example, the “intersection of three spheres” canbe introduced as a global constraints instead of three equivalent distance equations[1]. But, except in such cases, no improvement has to be expected from the modelingside.

2

variety of different outputs. First, one may look for a sub-paving (a setof boxes) encompassing the solutions and this is precisely what most ofthe existing solvers provide. They act as root finders. Next, in case of asolution set with a non-null volume, several sub-pavings are expected, eachsatisfying a different property, basically: “may contain a solution”, “doescontain a solution” or “contains only solutions”. Such solvers rather actas set describers. Actually, we will see through the examples of Section 2that the semantics behind the sub-pavings may completely change from oneproblem to the other2. As we will show, neither a root finder nor a setdescriber is adapted for solving these problems. Of course, ad-hoc solutionsalways exist, but the purpose is precisely to avoid a multiplicity of programswhere a single one would be enough. In practice, when people are facing aspecific constraint problem that requires a specific algorithm, they have toreverse-engineer the code of an existing solver. Often, they redevelop it fromscratch.

Contribution

We propose a formalism and an algorithm, called paver.

In the formalism, the different interval routines (evaluations, projections, ex-istence tests, etc.) are all wrapped in the very same object called contractor(see Section 3). Of course, the concept of contractor is not a novelty on its own.Our (first) contribution is to redefine various constraint programming techniques(propagation, shaving, parameter splitting, etc.) as operations over contractorsthat yield new contractors (Section 4). Syntactically, the contractor is then theunique atom, whence a certain simplicity. A solver can then be programed, ratherthan configured, by combining different contractors (examples are given in §4.2,§4.3, §5.1 and §5.5).

The paver algorithm is a generic solver. It takes a list of contractor, an initialbox and follows a classical recursion: the contractors are successively called onthe current box until either it gets empty or no more contraction could be done.In the latter case, the box is bisected and contractors are called back again.

The fact that different contractors work concurrently allows to solve problemsof quite different nature (see examples in §5.2, §5.3 or §5.4). This is our secondcontribution.

Hence, contractor programming consists in two distinct steps: contractor designand paver design. The former refers to the design of the most possible efficientcontractor for a given set (constraint) and shall be discussed in Section 4. Thelatter refers to the selection of contractors that yield the desired output, regard-less of efficiency.

2 We can say that no modeling language dedicated to the output exists so far, and thisis another important distinction with discrete problems where this modeling aspectis not as ubiquitous (solvers using explanations are counter-examples).

3

This framework is already supported by a real system named Quimper that willbe introduced in Section 6.

Thinking of contractor programming as an extension of constraint programmingis valid to the extent that contractors help in modeling the output of a problem.But, fundamentally, there is not such an extension since constraints basicallytell the “what” whereas contractors tell the “how”.

Note that branching will not be covered in this paper but one has to keep inmind that this part of the paver should be customizable as well. Only plainbisection will be used in the examples (variable are selected with a round-robinheuristic).

Related works

In discrete constraint programming, existing tools already give control mecha-nisms with sometimes an associated formalism. In constrained-based local search,the COMET system [46] offers a language allowing one to give his own definitionof moves and neighborhoods, the incremental computation of the impact after amove being done automatically.

In branch & prune systems, choice points and propagation can usually be con-trolled. The Choco [25], ILOG Solver [20] and Gecode [43] libraries allow tospecify the instantiation order for both variables and values. It can also be de-cided how to split domains (either instantiate or bisect domains, etc.).

Propagation has given rise to more sophisticated concepts. The aforementionedlibraries allow the programmer to associate his own propagator, or filtering al-gorithm, to a constraint. In Gecode, propagators can be automatically gener-ated from a formula. It is possible with Choco to control when propagators arelaunched thanks to a system of events (e.g., a bound is reduced, the variable isinstantiated, etc.). This allows, as a side effect, to schedule constraints in thepropagation loop (some costly propagators may ignore events of minor impor-tance). Events handling have to be implemented by the propagators in Gecode,albeit recent works about advisors [29] facilitate this task. These mechanisms areall related to modeling (a propagator is associated to a constraint), preservingdeclarativity. As far as we know, there is not a way to build new propagators,say, by composing different propagators. This is a difference with contractorprogramming that aims at building solvers rather than operational constraints.

In contrast, efficiency has always taken precedence over flexibility in continuousconstraint programming. Perhaps because of the prevailing numerical culture,solvers are indeed usually compared on a performance basis. As a consequence,none of the different existing implementations (Numerica [47], RealPaver [15],Alias [32], Rsolver [38], GlobSol [26], Baron [41], etc.) supply a good level ofopenness or extensibility. These libraries contain solvers or global optimizationalgorithms with a very high-level interface, basically restricting users to enter asystem of equations, set up some parameters and press enter. Of course, there

4

may be many parameters. For instance, it can be decided whether Alias hasto resort to the computation of the Hessian matrix or to ask RealPaver for theglobal consistency instead of a solution set. But there is no way to venture offthe beaten tracks.

A side contribution of this paper is a new representation for solution spaceswith non-empty interiors. More suitable representations have been proposed in[42] using quadtrees/octrees or in [48] using extreme vertices. However, quadtreesconsist in discretizing constraints and reasoning using this auxiliary representa-tion. This otherwise appealing method is therefore quite distant from intervalprogramming. Results of this paper are unlikely to be applicable in the contextof quadtrees.

Computing extreme vertices can be viewed as an independent operation to ob-tain a compact representation of a set of boxes. The dissertation [48] containsalso smart branching heuristics and a concept of active variables to preserve thealignment of small boxes. All these concepts are fully compatible with our frame-work and somehow orthogonal to contractors since they are related to branchingissues. They can be viewed as complementary to ours.

1.1 Notations and vocabulary

The set of all intervals is denoted by IR.

A Cartesian product of intervals is called a box. Intervals and boxes will be sur-rounded by brackets, e.g., [x]. The symbol [x] will always denote a n-dimensionalbox, except otherwise stated. If [x] is a box, x−i and x

+i will stand for the lower

and upper bound of [x]i respectively.

The width of a box [x] is the largest diameter of its components. The smallestbox enclosing a set S in denoted by �S.

A sub-paving of [x] is a set of non-overlapping boxes included in [x]. A sub-paving will either be considered as a collection of boxes {[x](1), . . . , } or as aunion [x](1) ∪ . . . depending on the context. Hence, a sub-paving can either beviewed as a discrete subset of IRn or as a compact subset of Rn.

A paving of [x] is a collection of sub-pavings K1, . . . , KN such that

[x] =⋃

1≤k≤N

⋃

[b]∈Kk

[b].

Finally, we will temporarily adopt the following definition. Let c be a constrainton the reals, i.e. c(x) is either true or false. A contractor for c is a functionC : IRn → IRn, usually given by a polynomial-time algorithm, such that:

∀[b] ∈ IRn,

{

C([b]) ⊆ [b] and∀x ∈ [b]\C([b]) c(x) is not satisfied.

5

Note that the concept of contractor will be generalized in our formalism (seeSection 3). Thanks to interval arithmetics, many contractors can be built withrespect to an equation f(x) = 0, where f : Rn → Rm.

Example 1. Consider f : R2 → R with f(x) = x1−exp(x2) and define C : IR2 →

IR2 as follows: C([x]) := ([x1] ∩ exp([x2]), [x2] ∩ log[x1]). C is a contractor with

respect to f(x) = 0.

Contractor versus propagator. In spite of appearance, contractor is notjust a new name for propagator. A propagator is associated to a constraint anddestined to be called in a propagation loop. As we will see, a contractor isnot necessarily associated to a constraint and may have nothing to do withpropagation. Furthermore, we will add a continuity condition in the definitionof a contractor (see §3.2) that does not exist for propagators. Finally, the termfiltering was not chosen because of a conflict with the everyday meaning offiltering in many areas dealing with continuous systems (e.g., Kalman filtering).

1.2 The ABC of interval programming

Let us end this introduction by a very quick description of what interval pro-gramming is all about.

The basic algorithm of interval programming is the root finder. Consider a systemof equations f(x) = 0, where x is a variable in Rn and f a mapping from Rn

to Rm. A root finder wrap solutions into boxes of any desired precision (leavingaside floating-point considerations) by using a branch & prune process, wherethe prune operation is performed by a contractor.

Here is the sketch of the algorithm. Note that a stack is used for the depth-firstsearch and that the precision criterion chosen here is width[x] < ε.

algorithm root-finder(function f, box [x](0))output: a sub-pavingpush [x](0) on the stackwhile the stack is not empty| pop [x] from the stack| [x]′ ← C([x]) where C is a contractor w.r.t. f(x) = 0| if [x]′ is not empty| | if width [x]′ < ε| | | insert [x]′ into the output sub-paving| | else| | | bisect [x]′ into two subboxes [x](1) and [x](2)

| | | push [x](1) and [x](2) on the stack

Of course, the existing implementations are much more sophisticated. But thissimplified description is enough from a language perspective. In the ideal case

6

of a square system (m = n) without singularity, solutions are punctual (andcertification can be demanded). In the general case, a n−m dimensional surfaceis described. This is illustrated in Figure 1.

Fig. 1. An enclosure of {x ∈ [−0.5, 2.5]×[−2.5, 0.5], f(x) = 0} with f(x) = exp(x1x2)−sin(x1 − x2).

Consider now f : Rn → Rm, and [x]× [y] ∈ Rn+m. We may look for the followingset inverse:

f−1([y]) ∩ [x] := {x ∈ [x] | ∃y ∈ [y] y = f(x)}.

Note that set inversion is a particular subclass of quantified constraints (see,e.g., [12, 39]). The root-finder algorithm will split the whole solution set intosmall boxes, as depicted in Figure 2.a.

In this case (i.e., when the solution set has a non-null n-dimensional volume) wemight expect the solver to dissociate boxes that may contain solutions (boundaryboxes) from boxes that only contain solutions (inner boxes). Clearly, precision isonly required for boundary boxes, splitting an inner box being useless and evencounter-productive.

A more appropriate output is given in Figure 2.b. Hence, an enhanced algorithmset-describer can be derived from root-finder by inserting an inner testbefore the call to the contractor. The design of inner tests has been a matter ofstudy in several publications (see, e.g., [13, 18, 14]).

2 Motivating examples

The purpose of this section is to present five different problems tractable byinterval programming and to show that neither root-finder nor set-describer

7

(a) (b)

Fig. 2.

A set inversion problem f(x) ∈ [y] with f(x) =p

x21 + x22 and [y] = [3, 6] in

[x] = [−7, 7] × [−7, 7]. (a) The output of the set inversion problem as defined in §2.1(i.e., small boxes enclosing all the solutions). (b) A more adapted output for the sameset inversion problem, including inner test.

are adapted. Once again, we do not claim that no algorithm exist for theseproblems. We just claim that no algorithm exist that solves them all. Note thatroot-finder and set-describer will not be two different algorithms in ourformalism.

2.1 A decomposable problem

In several applications, systems are sufficiently sparse to be decomposed by equa-tional or geometric techniques [24, 36, 6]. Consider for example the following sys-tem of distance constraints in two dimensions. There are 5 points connected by6 distance equations. Points A and B are fixed and the three others are theunknowns. Instead of directly solving the 6x6 overall system, we can processprogressively in three steps. We can solve the first triangle {A, B, C}, which isa 2 × 2 system. Because of rigidity, there is only a finite number of solutions(two flips). Then, for each solution, the second triangle {B, C, D} can be solvedbecause C is fixed. Finally, the triangle {C, D, E} can be solved in turn once Cand D are fixed.

In general, solving the decomposed problem (here, seven 2×2 systems includingflips) is faster than solving the global problem (here, one 6 × 6 system). Nostandard root finder allows to implement such strategies. The state of the artabout decomposition-based solving methods contains dedicated algorithms.

8

B

CD

E

A

Fig. 3. A decomposable system.

2.2 Enhanced description of the ring

Let us consider again the set inversion problem introduced in §1.2. We mentionedthat an inner test was necessary (whence the set-describer algorithm) but aninner contractor could also be introduced in this case and would actually bemuch more adapted.

Indeed, the set inversion problem can be easily formulated as a conjunction oftwo inequalities. It has been shown (see [8, 2]) in the case of inequalities that,by a negation trick, the problem can be reversed so that any contracted regionof the reversed problem lies inside the feasible region of the original one.

Remember that [y] ∈ IR. We have

c(x) ⇐⇒ f(x) ∈ [y] ⇐⇒ y− ≤ f(x) and f(x) ≤ y+

Hence, a point is unfeasible if

y− > f(x) or f(x) > y+.

Now, we can contract a box [x] with respect to y− > f(x) and f(x) > y+. If[x](1) and [x](2) are the two resulting boxes, then [x]\([x(1)]∪ [x(2)]) is inside thesolution set {x ∈ [x] | c(x)}. In such situation, it would be fruitful to replace thecurrent search space [x] by [x(1)]∪[x(2)] and to memorize that the complementaryspace is inner. The set-describer algorithm is therefore not really adapted.

2.3 Level surfaces

Level surfaces is somehow a generalization of the previous problem, and can bestated as follows. Consider f : Rn → R and N decreasing values y1 > . . . > yN .The goal is to classify all the points of an initial domain [x] according to the

9

constraints:f(x) ≥ y1

or f(x) ≥ y2...

or f(x) ≥ yN ,

(1)

with a priority corresponding to the intuitive idea that we are more interestedin the highest values: the surface level y1, i.e., the number of points satisfyingf(x) ≥ y1 must be maximized first. Then, the surface level y2 must be maximizedand so on. Figure 4.a shows an example of 4 surface levels. Note that this problemcould be easily generalized to a MAX-SAT problem.

(a) (b)

Fig. 4. Surfaces levels f(x) ≥ yi. (a) An example with y1 = 0.8, y2 = 0.6, y3 = 0.4,y4 = 0.2 and f(x) = sin(x

21 + x

22)/(exp(x1) + x

22), in [x] = [−2, 2] × [−2, 2]. Darkness

increases with f . (b) The same example decomposed into set inversion problems.

Let us now focus on input/output. Of course, using directly (1) as an inputconstraint makes no sense, since (1) is equivalent to f(x) ≥ yN . One could rathersolve N times the set inversion problem f(x) ∈ [yk, yk+1] and superimpose thedifferent outputs (see Figure 4.b). However, this is not satisfactory for at leasttwo reasons.

First, the boundaries around each level surface (the little white boxes in Figure4.b) should not appear, except for the lowest one. This undesirable boundarieswill be cleared off in Figure 11. One could circumvent this effect by slightlyenlarging the intervals [yk, yk+1] before computing the inversions, making levelsurfaces overlap. Another trick would simply be to move the boundary sub-paving of the kth surface level into the inner sub-paving of the (k − 1)th levelsurface. However, in both cases, we “cheat” and lose reliability of the result.

10

Second, the decomposition of the input problem into N sub-problems and theaggregation of the intermediate results requires extra and undesirable manipu-lations from the user.

2.4 Set inclusion

Given two sets defined by constraints c1 and c2, the set inclusion problem consistsin proving or refuting that one set is included in the other. This is illustrated inFigure 5.a.

(a) (b)

Fig. 5. Set inclusion. (a). Two subsets of [x] = [−3, 1]×[−1, 3] defined by constraints:c1(x) ⇐⇒ exp(x1x2) − sin(x2 − x1) ∈ [−0.1, 0.1] (in dark gray) and c2(x) ⇐⇒exp(x1 − x2) × sin(x1x2) ∈ [−0.1, 0.1] (in light gray). We have set(c1) ⊆ set(c2). (b)The same set inclusion problem decomposed into set inversion problems.

We shall denote by set(c) the set associated to a constraint:

set(c) = {x ∈ Rn | c(x) is true}.

Using the conjunction of c1 and c2 as an input in algorithm set-describer mayaddress the problem in the following situations: if no solution is found, then noset can be included in the other since these sets do not intersect at all. In theother way around, if the whole initial box is included in the inner sub-pavingthen the two sets coincide. Except in these extreme cases, nothing can be said.

As before, one may solve separately c1 and c2, and check for the inclusion ofboth the inner & boundary sub-pavings of c1 into the inner sub-paving of c2 (seeFigure 5.b). Again, this requires undesirable manipulations from the user; but,worse, processing in this way is extremely inefficient. Assume that a box B in

11

Figure 5.b is detected as inner in the paving of set(c2) and recursively bisectedand contracted in the paving of set(c1) until either boundary or inner boxes arefound. All this work could be spare since the inclusion set(c1)∩B ⊆ set(c2)∩B isalready established. Hence, this decomposition involves a huge number of uselesscomputations.

Of course, one could legitimately object that in the example given in Figure 5,c1 can be reversed as in §2.2 to c̄1 so that running a standard solver with c̄1 andc2 will do the job as expected. Indeed, if no solution is found, no point satisfyc2 and c̄1, i.e., set(c2) ⊆ set(c1). However, in general, a constraint cannot bereversed while an inner test is still possible. As an example, a constraint c1(x)of the following form:

c1(x) ⇐⇒ ∃y ∈ [0, 1]

{

f(x,y)=0g(x,y)=0

cannot be reversed if y has multiple occurrences while testing for an inner boxis possible (an algorithm is given in [12]).

2.5 Bounded-error Parameter estimation

This last example is rather devoted to solver design: the problem is not new interms of input/output but requires a specific strategy.

Consider the following model of a real-time system [23]:

f(p, t) = 20 exp(−p1t)− 8 exp(−p2t)

where p1 and p2 are two unknown parameters. Assume that a vector of 10 mea-surements y1, . . . , y10 is available, these measurements corresponding to timest1, . . . , t10 respectively.

The question is to compute a rigorous enclosure of all the feasible p1 and p2from the experimental data, taking into account uncertainties on both yi and ti.Hence, given intervals [ti] and [yi], we have to describe the following set:

{(p1, p2) | ∀i ∈ [1..10], ∃yi ∈ [yi], ∃ti ∈ [ti] yi = f(p, ti)}.

If we restrict ourselves to a single measurement (instead of 10), the problemboils down to a simple set inversion, with a thick constant [ti]. Hence, the set tobe computed seems to be nothing but the intersection of 10 set inversions. Theset-describer algorithm seems to suit well.

In fact, the multi-incidence of t in the expression of f makes this strategy in-efficient. Indeed, whatever is the underlying method used for the contractor orthe inner test, the domain of t has to be small for the resulting operator to besharp. Hence, the domain of t has to be split by the solver. This is illustrated inFigure 6.

12

(a) (b)

Fig. 6. The parameter estimation problem. (a) The set of feasible points (p1, p2).(b) The result using a standard contraction and inner test without splitting the domainsof ti (bisection precision is 0.01). First, a very few of inner boxes could be found. Second,the outer enclosure is not sharp at all.

Second, introducing the vector t as variables makes the search space dimensionjumps from 2 to 12 unless one wants to solve the 10 problems separately. Thisleads to a combinatorial explosion.

In conclusion, there is a need for splitting the component ti (and only thisone) inside the contractor and inner test associated to the ith measure. To ourknowledge, no available solver is generic enough to be tuned in this way.

3 A new formalism

We show now that the different examples of Section 2 can be solved as suggestedby the very same algorithm, a generic solver called paver, when expressed in thecontractor formalism.

We describe the paver and the formalism in this section. We will provide concreteexamples of contractors in Section 4 and subsequently revisit the problems ofSection 2.

3.1 The “contract and classify” paver

To help intuition, let us consider the problem in §2.3. It turns out from this exam-ple that several sets have to be described simultaneously, each set correspondingto a different constraint.

13

Let us assume that sets are disjoint. We will see below how to circumvent thecase of overlapping sets.

Each point of the initial space has to be classified with respect to these sets. Fora given point x, this means that the membership of x to the different sets canbe tested successively. If one test succeeds, then x can be marked as treated andassociated to the corresponding set.

A generic interval solver can directly be derived from this “test and classify”principle. Remember first that a contractor C can be easily built from any con-straint c. The contractor C has the following property: if C([x]) = [y] (i.e., [y]is the contraction of [x]) then every eliminated point in [y]\[x] does not satisfyc. Thus, with a simple negation trick, a contractor C̄ such that all eliminatedpoints satisfy c is as easy to build.

Example 2. Consider the set inversion problem, in §2.2. A point inside the ringsatisfies f(x) ∈ [y]. Consider a contractor C̄ built from f(x) 6∈ [y]. If C̄([x]) = [y]then [x]\[y] is inside the ring.

Given a box [x] and a constraint c, if the complementary contractor C̄ reduces[x] to [y], then [x]\[y] can be classified, i.e., mark as “inside c”. Then, the paverproceeds as follows (the algorithm is detailed below). The solver takes as inputa list of contractors and an initial box [x](0). The first contractor is enforced on[x] := [x](0). If the contraction is effective, a smaller box [x]′ is returned and thedifference3 [x]\[x]′ is stored in a sub-paving associated to the first contractor.Only [x]′ is left to be treated, and the second contractor is called. When allthe contractors become ineffective on a box [x], we can say that the commonfixpoint of all contractors is reached and [x] is bisected. The whole process isthen repeated until the list of boxes becomes empty. We will see in the nextsection how the termination of the algorithm can be guaranteed.

3 Note that resorting to a simple tree structure avoids to explicitly describe the dif-ference between [x] and [x]′: the latter simply becomes a subnode of the former.

14

algorithm paver(contractors C1, . . . , Ck, box [x](0))

output: a paving of [x](0)

create k empty subpavings K1, . . . , Kkpush [x](0) on the stackwhile the stack is not empty| pop [x] from the stack| do| | fixpoint ← true| | i ← 1| | while [x] 6= ∅ and i≤k| | | [x]′ ← Ci([x])| | | if [x]′ 6= [x]| | | | Ki ← Ki ∪([x]\[x]

′)| | | | fixpoint ← false| | | | [x]← [x]′

| | | i← i + 1| while [x] 6= ∅ and fixpoint=false| if [x] 6= ∅| | bisect [x] into two subboxes [x](1) and [x](2)

| | push [x](1) and [x](2) on the stack

Note that paver is not an AC3-like algorithm, for essentially two reasons. First,contractors given to the paver algorithm usually involve all the variables merelybecause they all correspond to sets (or more generally, to sub-pavings) whichhave the same dimension as the initial box. This is not a rule but a “user advice”.One can put different constraints at this level in order to trace their contractionpower. But, the paver level is intended to deal with sets while all the constraintsrelated to a given set should be encapsulated in the same outer or inner con-tractor, as explained further. Second, because the semantics of contractors goesbeyond that of constraints, the order in which they are called may have an in-fluence on the quality of the result (the number of boxes in a subpaving). Forinstance, a contractor designed to detect a very weak condition should preferablybe called on last resort (we might lose boxes satisfying a stronger condition).

3.2 Contractors

Definition 1 (Contractor). A contractor is a mapping C from IRn to IRn

such that

(i) ∀[x] ∈ IRn, C([x]) ⊆ [x] (contraction)(ii) (x ∈ [x], C({x}) = {x})⇒ x ∈ C([x]) (consistency)(iii) C({x}) = ∅ ⇔ (∃ε > 0, ∀[x] ⊆ B (x, ε) , C([x]) = ∅) (continuity)

where B (x, ε) is the ball centered on x with radius ε.

A box [x] is said to be insensitive to C if C([x]) = [x] and sensitive otherwise. Byextension, a point x is said to be sensitive or insensitive whether {x} is sensitive

15

or not. Property (i) states that a box can only be reduced by a contractor.Property (ii) states that no insensitive points can be removed. Finally, property(iii) is required for properties on the paver as we will explain further.

The set associated to a contractor C is the union of all of its insensitive points:

set(C) = {x ∈ Rn, C(x) = x}.

The continuity property of C implies that set(C) is closed.

If C is a contractor for a constraint c, in the classical sense of the word (see§1.1), then set(C) ⊇ set(c). An important novelty in our formalism is to considersets associated to contractors rather than to constraints. This allows a rigorousdescription of the output of our paver (see Proposition 2). A contractor is notonly an algorithm, it can also be interpreted as a subset of Rn, and all thestandard operations on sets can be extended to contractors. We define:

(C1 ∩ C2)([x]) := C1([x]) ∩ C2([x]) (intersection)

(C1 ∪ C2)([x]) := �(

C1([x]) ∪ C2([x]))

(union)

(C1 ◦ C2)([x]) := C1(C2([x])) (composition)C∞1 := C1 ◦ C1 ◦ C1 ◦ . . . (iterated composition)

C1 ⊓ C2 := (C1 ∩ C2)∞ (iterated intersection)

C1 ⊔ C2 := (C1 ∪ C2)∞ (iterated union).

(2)

All these operations are stable, i.e., they only yield contractors.

We also introduce the following definition:

Definition 2. Let C1, . . . , Ck be a collection of contractors.

C1, . . . , Ck are complementary if set(C1) ∩ . . . ∩ set(Ck) = ∅,C1, . . . , Ck are independent if ∀i 6= j, set(Ci)C ∩ set(Cj)C = ∅.

Additional properties of contractors play a significant role:

C is monotonous if [x] ⊆ [y]⇒ C([x]) ⊆ C([y]),C is minimal if ∀[x] ∈ IRn, C([x]) = �([x] ∩ set(C)),C is idempotent if ∀[x] ∈ IRn, C(C([x])) = C([x]).

(3)

Given a contractor C on Rn×Rm, we also define the two following contractorson Rn:

C∪[y]([x]) :=⋃

y∈[y] πx(C([x], y)

C∩[y]([x]) :=⋂

y∈[y] πx(C([x], y)

with πx([x], [y]) := [x]. The first operation is called proj-union and the secondproj-intersection. Once again, these operations are stable in the set of contrac-tors. We have:

set(C∪[y]) = {x, ∃y ∈ [y], (x, y) ∈ set(C)},set(C∩[y]) = {x, ∀y ∈ [y], (x, y) ∈ set(C)}.

16

Fig. 7. Proj-Union. We consider a contractor C on IR2 with S := set(C). (a) Repre-sentation of C∪[y] when [y] is degenerated (a real y). The contraction on [x] results inan enclosure of {x ∈ [x] | (x, y) ∈ S}. Since C is continuous, when both [x] and [y] aredegenerated, the enclosure is minimal, i.e., C∪y(x) = {x} iff (x, y) ∈ S. (b) Principle ofan implementation resorting to parameter splitting and union of sub-contractions (theinterval [y] is decomposed as finely as possible). (c) Result of the proj-intersection inpractice: only an outer approximation of set(C∪[y]) is obtained.

This result being rather intuitive, the proof is not given (see Figures 7 and8). In practice, these operators are implemented as follows. For the proj-union,[y] is split into a sequence of small subintervals [y]i. Then, the contractor C isenforced on each sub-domain [x]× [yi] and the hull of the results is returned. Forthe proj-intersection, a sequence of points yi are sampled from [y], C is enforceon [x]× {yi} and the intersection of the results is returned.

Although examples of contractors will be the topic of Section 4, we shall in-troduce right here the precision contractor Cε that has a special status. Thiscontractor is aimed at controlling the precision of the paver or scheduling con-tractors (see §5.1 and §5.3) and will be implicitly referred to in the subsequentpropositions.

Definition 3 (Precision contractor). Given ǫ > 0, the precision contractorCε is defined as follows:

Cε([x]) :=

{

[x] if width([x]) > ǫ∅ otherwise.

Many properties could be stated on contractors. As an example, the set of idem-potent and monotonous contractors is a complete lattice for the inclusion. Listingthese properties would be out of the scope of this paper, which is rather aimedat introducing the concepts. However, the fundamental properties of the pavergiven in the previous section are based on the properties of contractors and weare now in position for proving them.

17

Fig. 8. Proj-intersection. (a) In a similar way as in Figure 8, given a fixed interval[y], C∩[y] allows to constrain x ∈ R with ∀y ∈ [y], (x, y) ∈ S. (b) Principle of animplementation resorting to parameter splitting and intersection. (c) Result of theproj-intersection in practice: only an outer approximation of set(C∩[y]) is obtained.

3.3 Paver properties

Proposition 1 (Termination). Let {C1, . . . , Ck} be a list of complementarycontractors. The paver terminates for any initial box [x](0).

Proof. Assume by contradiction that paver does not terminate. Hence, there isa sequence of non-empty boxes [x](i) and x̃ ∈ [x](0) such that for all i > 0:

(i) [x](i) ⊂ [x](i−1) (strict inclusion, i.e., [x](i) 6= [x](i+1))(ii) C1([x]

(i)) = . . . = Ck([x](i)) = [x](i)

(iii) x̃ ∈ [x](i)

Indeed, (i) is a direct consequence of the properties of contractors and bisectionsand (ii) is due to the fixpoint postcondition of the inner while loop inside thepaver algorithm. Finally, for all i, pick a point x̃(i) ∈ [x](i) (which is nonempty).The sequence is bounded so it admits at least one accumulation point x̃. Sincefor all i, [x](i) is a closed set that contains the whole subsequence (x̃(j))j≥i, italso contains this accumulation point x̃. Hence, (iii) holds.

Now, each box [x](i) can be identified to a 2n-tuple u(i) of its vertices coordi-nates. This identification can be made isometric with appropriate distances (theHausdorff distance on IRn and its counterpart on R2n). For all component j,

1 ≤ j ≤ 2n, the sequence u(i)j is either increasing or decreasing, and bounded by

a component of x̃. Hence, it converges to a point ūj . By the inverse isometry,it follows that the sequence of boxes [x](i) converges then to a box ¯[x]. Further-more, the width of this box is necessarily null (i.e., ¯[x] is a degenerated box {x̄})since

∀i ≥ 0, rad([x](i+n)) ≤1

2rad([x](i)).

18

Next, we have set(C1)∩. . .∩set(Ck) = ∅ which means that at least one contractorCl satisfies x̄ 6∈ set(Cl). By applying the continuity property of Cl (see Definition1) we obtain that there exists ǫ and i such that [x](i) ⊆ B(x̄, ǫ) and Cl([x]

(i)) = ∅,i.e., a contradiction. �

To ensure the complementarity between contractors, we usually resort to theprecision contractor because set(Cε) = ∅.

Informally, the following proposition states that, up to a given precision ǫ, thesub-paving associated to a contractor matches the intersection of the other con-tractors sets. Since the set of a contractor usually approximates the set relatedto an initial constraint, we have now a clear semantics for the paver.

Proposition 2 (Sub-pavings characterization). Let {C1, . . . , Ck} be a listof independent contractors and Cε such that set(Cε) = ∅. Let us denote byK1, . . . , Kk and Kǫ the sub-paving returned by paver for C1, . . . , Ck and Cε re-spectively. We have:

∀i, 1 ≤ i ≤ k,⋂

j 6=i

set(Cj)\Ki ⊆ Kǫ .

Proof. First of all, paver terminates thanks to the previous proposition. Let i bean index, 1 ≤ i ≤ k. For all j 6= i we have by hypothesis set(Ci)C ∩ set(Cj)C = ∅hence set(Ci)

C ⊆ set(Cj) which implies set(Ci)C ⊆ ∩j 6=i set(Cj). Since ∀[x] ∈ Kiwe have [x] ⊆ set(Ci)c (by applying the consistency of Ci), then Ki ⊂ set(Ci)C ⊂∩j 6=i set(Cj). The two last inclusions are strict because set(Ci)C is open whilethe other sets are closed. It follows that

⋂

j 6=i set(Cj)\Ki is nonempty.

Take [x] in this set and assume [x] 6∈ Kǫ. The box [x] has been removed from thesearch by Cl with 1 ≤ l ≤ k, i.e. [x] ⊆ set(Cl)C . Since [x] ∈

⋂

j 6=i set(Cj) thenl = i which leads to a contradiction since [x] 6∈ Ki. �

4 Contractor design

In this section, we present some contractors and operations that do not helpin modeling problems but in improving the efficiency of a paver. We basicallyexplain how to manage a constraint c, i.e., the different ways to build a contrac-tor C satisfying set(C) = set(c). Likewise, all the operations op will preserveassociated sets. E.g., an unary operator op will satisfy for all contractor C,set(op(C)) = set(C).

Hence, contractors and operations in this section will not have an influence onthe result, in terms of sub-paving characterization. On the other hand, they maydecrease the time complexity or the space complexity (i.e., the number of boxesin a sub-paving).

19

We will overlook technical details on purpose here, sticking to generalities. Theinterested reader may refer to Section 6 where important implementation choiceswe made for our own system are disclosed.

We shall distinguish numerical contractors, those which are directly built froma numerical constraint, and those which are the result of an operation (such ascomposition) between other contractors.

Numerical contractors can be related to equations, inequalities or systems ofequations. The point is that a large part of interval analysis routines can bewrapped into these contractors. As announced above, a good separation canthen be obtained between numerical skills (the design of numerical contractors)and constraint programming skills (the design of compound contractors).

In this layered framework, constraint propagation will be generalized to con-tractor propagation. A possible implementation of the corresponding operator(propag) will be described in detail in §6.3.

4.1 Numerical contractors

Several contractors can be associated to an equation f(x) = 0.

The simplest one consists in evaluating with interval arithmetics f([x]) andchecking whether 0 belongs to the image range or not. If 0 6∈ f([x]) then [x]can be contracted to the empty set. Otherwise, it is left unchanged. This con-tractor can therefore be qualified as binary (in the sense that it keeps all ornothing). This test can be easily extended to inequalities. This contractor canbe given many variants, based on various symbolic or numerical processing asthe two following examples show.

Example 3. Assume that there exist several equivalent expressions for f , sayf1, . . . , fk, each of them minimizing the multi-incidence of a different variable.Since the overestimation of interval evaluation grows with the multi-incidence ofvariables (see [34]), we get to sharper results by computing f1([x])∩ . . .∩ fk([x])instead of f([x]), whence a more accurate (but slower) test.

Example 4. On the numerical side, we can resort to the centered form, i.e.,compute f(x0) + f

′([x])([x] − x0) instead of f([x]) where x0 is an arbitrarypoint inside [x]. Higher-order Taylor formulas may also be payfull. One may alsointroduce intermediate monotonicity tests. Consider a two-dimensional vector x.If ∂f

∂x1([x]) turns to be a positive interval then f is increasing with respect to

x1 so that f([x]) can be replaced by [f({x−1 } × [x2]), f({x

+1 } × [x2])], a smaller

interval.

More sophisticated contractors associated to a constraint c (equation or inequal-ity) compute an outer estimation of the feasible set, i.e., C([x]) is a nontrivialsuperset of {x ∈ [x] | c(x)}. Three important techniques can be found in theliterature:

20

1. Forward-backward traversals of the syntax tree with intermediate intervalcomputations, such as HC4Revise [3].

2. Univariate interval Newton iterations (as performed by the narrowing oper-ator of box consistency [47]).

3. Linear relaxations (see [30] and references therein). In such techniques, anonlinear constraint is cast into a linear program which feasible region en-compasses the original solution set.

Given an equation f(x) = 0, we will denote by Cf in the sequel an arbitrarycontractor among those above.

Of course, numerical techniques can also handle several equations simultane-ously, i.e., a system of equations. Many of them are derived from a multivariateinterval Newton, one famous variant being the Hansen-Sengupta algorithm [17].In case of linear equalities, many dedicated algorithms also exist (see [35] or[37]). One can be easily convinced that all these algorithms act as contractors.

4.2 Propagation

The propagation operator allows to implement interval variants of the classicalAC3 algorithm such as hull consistency (see, e.g., [3, 11]) but also many morealgorithms. This operator illustrates by itself the potential of our framework, interms of contractor design. The key idea is to propagate contractors instead ofconstraints.

Given a list of contractors, the principle is to obtain the fixpoint of their com-position, i.e., (C1 ◦ · · · ◦Cm)∞ at a lower computation price. We shall denote bypropag our operator. We have:

set(propag(C1, . . . , Cm)) = set((C1 ◦ · · · ◦ Cm)∞)

which means that propag is a pure efficiency contractor (it has no impact on theoutput).

An implementation of this operator will be proposed in §6.3.

Let us now recall that the hull consistency enforces bound consistency for eachequation. In practice, only a relaxation of bound-consistency is calculated viathe HC4Revise algorithm. The resulting propagation algorithm is called HC4. Inour framework, given a list of constraints c1, . . . , cm, the HC4 algorithm is simplyreimplemented as follows

HC4(c1, . . . , cm) ← propag(HC4Revise(c1), . . . , HC4Revise(cm))

A more interesting direct application is a multi-level propagation. Sometimes,we would like to group constraints we know to have strong “dependencies”. Forinstance, one may find relevant to perform an intermediate fixpoint with con-straints that strictly share the same variables. Consider three sets of constraints

21

{c1, c2, c3}, {c4} and {c5, c6}. The following contractor will ensure that a con-straint in a subset (say, c4) will not be wakened between constraints of othersubsets (say, c1 and c2).

propag(propag(c1, c2, c3),c4,propag(c5, c6))

4.3 Shaving

The purpose of this section is to show that other operators exist besides propag.

Shaving is an operation that allows to implement refutation techniques, similarto SAC [5] with discrete domains. With continuous domains, refutation is usedto shrink endpoints only (instead of any value inside the domains) so that thestructure of interval is always maintained (whence the fancy name shaving).

Detailing the algorithm here would take too much room. We shall only give arough description.

A shaving operator shave takes a contractor C. Given a box [x], the resultingcontractor shave(C) contracts “slices” with C, i.e., subboxes obtained from [x]by restricting the domain [x]k of one component to a small subinterval [x

−k , x

−k +ǫ]

or [x+k −ǫ, x+k ]. When the result of the subcontraction is an empty set, the slice is

removed. Otherwise, contraction is tried on a smaller slice. This recursion leadsto consistent endpoints. More formally, the resulting box [y] := (shave(C))([x])satisfies ∀k = 1, . . . , n

C([y]1 × · · · × [y]k−1 × {y−k } × [y]k+1 × · · · × [y]n) 6= ∅

andC([y]1 × · · · × [y]k−1 × {y

+k } × [y]k+1 × · · · × [y]n) 6= ∅.

The shaving operator can also be given many variants mainly because of theslicing which can either be optimistic (“try large slices first”) or pessimistic(“check consistency of endpoints first”).

Given m constraints c1, . . . , cm, a box consistency operator (see [4, 45, 47]) canbe reimplemented in our framework as follows:

propag(shave(univNewton(c1)),. . . ,shave(UnivNewton(cm)))

where UnivNewton is an univariate interval Newton contractor (see §4.1). The3B consistency defined in [31] can be reimplemented as follows:

shave(HC4(c1, . . . , cm)).

5 Revisiting examples

We now revisit all the examples in our framework. By convention, the sub-pavingof the precision contractor will always be represented in white in the pictures.

22

As a preliminary example, consider the system of equations in Figure 1 page 7and remember that the goal is to enclose the solution set into a sub-paving. Bya direct application of our formalism, we then need two contractors:

1. A contractor Cf , to remove unfeasible points.2. The precision contractor Cε.

The desired output is given in Figure 9. This time, the result of the outer con-traction appears as a sub-paving with only unfeasible points. The roots are allin the sub-paving of the precision contractor.

Fig. 9. System of equations, with an outer and precision contractor. The sub-pavingof the outer contractor is in light gray.

5.1 A decomposable problem

Assume that each subsystem (called block) has to be solved by a combinationof propagation and interval Newton. Of course, a multivariate interval Newton(denoted by newton henceforth) requires a square system. When one variableis fixed (e.g., xC and yC when the second triangle is to be solved), it must notbe considered as a variable by newton but rather as an interval constant. Suchinformation typically enters as a “static” parameter (see §6.1). For that reason,the newton contractor takes two arguments: the set of constraints and the setof variables. Similarly, let us refine the behaviour of the precision contractor Cε(see §4). This contractor will also take here a subset S of variables in parameter.A box [x] is emptied by Cε(S) if and only if the domains of the components inS all have a diameter lower than ε.

23

In the sequel, dPQ denotes the distance constraint between two points P and Q.

For each block (here: a triangle), the solving strategy is implemented thanks tothe following operator block contractor:

block contractor({c1, . . . , ck}, {x1, . . . , xk}) ←HC4(c1,. . . ,ck) ∩ newton({c1, . . . , ck}, {x1, . . . , xk})

For instance, a paver run with block contractor({dBD, dCD}, {xD, yD}) (andCε) with xC and yC fixed (i.e., their domains have a diameter less than ε) willsolve the second triangle in the required manner, i.e., using propagation andNewton.

The step-by-step solving method proposed in §2.1 can then be directly imple-mented with the following contractor:

block contractor({dAC, dBC},{xC , yC})∩ ( Cε({xC , yC})∪ ( block contractor({dBD, dCD}, {xD, yD})∩ ( Cε({xC , yC , xD, yD})∪ block contractor({dDE, dCE}, {xE, yE})))

provided that variables are bisected block after block. In more details, the vari-ables of the first block {xC , yC} must be bisected (say, in a round-robin fashion)until precision is achieved for both of them. The bisection procedure must thenproceed to the second block, and so on. Branching procedures are not coveredin this paper but this mechanism is orthogonal to contractors and one should beeasily convinced that a block-wise bisection is easy to set up.

5.2 Enhanced description of the ring

In the set inversion problem, we need to characterize {x | f(x) ∈ [y]}. This meansthat two sets have to be described by contractors: {x | f(x) ∈ [y]} (the ring)and {x | f(x) 6∈ int([y])} (the complementary of the ring). Put [y] = [y−, y+]and g(x) := f(x)− y.

To deal with unfeasible points, we need an outer contractor. This contractor,denoted by Cf∈[y], can be simply defined as follows:

Cf∈[y] := [x] 7→ πx(Cg([x], [y])).

The points inside the ring have to be classified with an inner contractor. Asexplained in §2.2, the latter comes naturally with the negation of the problem.We have

c(x) ⇐⇒ f(x) ∈ [y] ⇐⇒ y− ≤ f(x) and f(x) ≤ y+

⇐⇒ f(x) ∈ [y−, +∞) and f(x) ∈ (−∞, y+].

24

Fig. 10. A description of the ring involving outer and inner contractors.

Hence,c̄(x) ⇐⇒ f(x) ∈ (−∞, y−) or f(x) ∈ (y+, +∞)

=⇒ f(x) ∈ (−∞, y−] or f(x) ∈ [y+, +∞)

Therefore, the contractor

Cf 6∈[y]([x]) := [x] 7→ πx(Cg([x], (−∞, y−])) ∪ πx(Cg([x], [y

+, +∞)))

only removes unfeasible points for c̄, i.e., feasible points for c.

Now, set(Cf∈[y]) ∩ set(Cf 6∈[y]) is the boundary of the ring, which is non empty.Hence, we have to add a precision contractor to ensure the termination of the al-gorithm. The result is depicted in Figure 10. Since Cf∈[y] and Cf 6∈[y] are indepen-dent, the ring represented on the figure can be interpreted as an approximationof the set to be described (see proposition 2).

5.3 Level surfaces

First of all, the contractor Cf∈[yi,+∞) (as defined in the previous paragraph)

could be associated to the ith level surface {f ≥ yi}. Of course, in this way, thecontractor of the lowest surface level would preempt most of the boxes, leadingto a bad result (independence does not hold).

Introducing a priority between the different contractors (in addition to indepen-dence) does not need any extra concept. We just need to adapt the contractorsto their actual semantics: a (sufficiently small) box [x] must be classified withthe contractor of the ith surface level only if

[x] is inside the ith surface leveland [x] does not intersect the (i−1)th surface level

or [x] has a small width (lower than ε)

25

Fig. 11. An appropriate paving, with smooth boundaries between surface levels.

The desired contractor Ci is then obtained by simply rewriting these conditionsin terms of sub-contractors:

Ci := Cf 6∈[yi,+∞) ∪(

Cf∈[yi−1,+∞) ∩Cε)

or, using a sub-distributivity rule:

Ci := Cf 6∈[yi−1,+∞] ∩(

Cf∈[yi,+∞) ∪Cε)

.

Finally, we need as before an outer contractor for all the surface levels, namely,Cn+1 := Cf∈(−∞,yn]. Moreover, the intersection of C1∩ . . .∩Cn+1 is {x | f(x) =yn} and, as usual, this set can be treated by a precision contractor Cε. Figure11 shows the desired output.

5.4 Set inclusion

The set inclusion problem can be solved efficiently in our formalism by using thefollowing simple reasoning.

A box [x] can be discarded from the search either if it does not belong to set(c1)or if it is included in set(c2). Indeed, in both cases, [x] cannot compromise theassertion to be proven since ∀x ∈ [x] we have c1(x)=⇒ c2(x).

Hence, an inner contractor C1 for c1 and an outer contractor C2 for c2 can beused jointly. Only the box that both (possibly) contain points inside set(c1) andoutside set(c2) are bisected. The result is depicted in Figure 12.

No precision need to be introduced if int(set(c1)) ⊆ set(c2) (where int stands forinterior) since the algorithm will end in this case (we have set(C1)∩set(C2) = ∅).But we still need a precision contractor Cε in case of non inclusion.

26

Fig. 12. The set inclusion problem solved by a more adapted algorithm. Boxes in darkgray does not belong to set(c1). Boxes in light gray are inside set(c2). We resort tosplitting only in regions where boundaries of set(c1) and set(c2) are close.

5.5 Bounded-Error Parameter estimation

As we evoked above, modeling this problem makes no difficulty. The overallinner contractor is the union of the inner contractors related to each measure,say, Cgi 6∈[yi] with gi(p) := f(p, ti) and ti ∈ [ti]. Here, the interval extension of giis a thick function since an interval constant [ti] substitutes for the variable ti.

Likewise, the intersection of the outer contractors Cgi∈[yi] defines an outer con-tractor for the whole problem.

For efficiency, we have to split ti inside the ith outer and inner contractor. Con-

sider first outer contraction: (p1, p2) is feasible if at least one value in [ti] satisfiesf(p, ti) ∈ [yi]. Hence, if a point (p, ti) ∈ R

3 is insensitive to Cf∈[yi] then p mustbe insensitive to the outer contractor. The proj-union defined in §4 exactly fitsthis requirement. We define:

Couter := C∪[t1]f(p,t1)∈[y1]

∩ . . . ∩ C∪[t10]f(p,t10)∈[y10]

Similarly, the proj-intersection fits the requirement for the inner contraction.Indeed, a point (p, ti) ∈ R

3 sensitive to Cf 6∈[yi] must be discarded by the innercontractor. We define:

Cinner := C∩[t1]f(p,t1) 6∈[y1]

∪ . . . ∪ C∩[t10]f(p,t10)) 6∈[y10]

A paving resulting from the combination of these contractors is shown in Figure13.

27

Fig. 13. Parameter estimation solved with inner and outer contractors based on proj-union and proj-intersection. The precision of the paver is still 0.01.

6 The Quimper System

Besides theoretical investigations, contractor programming has also given rise toa real system named Quimper (QUick Interval Modeling and Programming in abounded-ERror context). This system includes today three different programs:qPave (a graphical tool for paving sets in 2D), qSolve (a tool for listing numericalresults, typically in high dimension) and qTraj (a graphical tool tailored toconstraint problems derived from differential equations).

These are light-weighted programs that only manage input/ouput, i.e., the lan-guage for writing contractors (the “Quimper language”) and the interface forconfiguring, running the paver and handling generated pavings. They are linkedto a C++ library called Ibex (Interval-Based Explorer) that implements a con-tractor programming framework.

Ibex is based itself on the Profil/Bias library [28] for the low-level intervalarithmetics. However, part of this library has been wrapped into functions thatmanage all the borderline cases (infinite bounds, values out of definition domains,empty sets, etc.) so that arithmetic operations are always exception-free. Thisexplains why a modified release of Profil/Bias is included in the Ibex package.

All these software components are under GPL licence and can be downloadedonline [7]. A user guide for Quimper (including the grammar of the Quimperlanguage), as well as a complete documentation of Ibex classes are availableon the same site. An archive containing all the examples of this paper in theQuimper syntax is also provided.

Ibex/Quimper has been developed by the first author but this software mustrather be considered as a prototype since a real collaborative open-source project

28

continuing this work is about to be on the rails. This project will start on a newbasis but not from scratch thanks to the existing code.

The purpose of this section is to give some insight on the Ibex system. For con-venience, we shall adopt some object-oriented coding notations. A contractor Cis a class with the main function being contract, i.e., for a box [x]

C.contract([x])

contracts [x] with C.

Generalizing constraint propagation to contractor propagation required some-what to make the interface of contractors inherit from constraints. First, we canask a contractor whether the domain of a given variable can impact the resultof the contraction or not. This notion simply generalizes the incidence graph ofa constraint network.

A contractor C, as a class, therefore implements a Boolean function involvesthat takes in argument the index j of a variable, i.e.,

C.involves(j)

returns false or true. Note that, by default, a contractor always returns true.In the parlance of object-oriented programming, this function needs not neces-sarily be overridden.

Second, we also added a few parameters to the contract function above, besidesthe box to be contracted. This is what next paragraph deals with.

6.1 Indicators

Every contractor has its own set of specific parameters. For instance, the precisioncontractor Cε (maxdiamGT in the Quimper syntax) takes a parameter ε. Theinterval Newton also needs a parameter for controlling the termination of theiteration: when a step does not reduce any interval by more than a given ratio, theprocedure stops. This ratio can be set externally. These parameters are relatedto the semantics specific to contractors (e.g., the precision contractor has bydefinition a threshold) or their implementations. They are usually set once forall (as constructor parameters). We shall not consider this type of parametersany further.

There is another type of parameters required by constraint programming algo-rithms for efficiency reasons, called indicators. The purpose of these parametersis to notify contractors during the search about the context in which they arecalled. For instance, we may inform a contractor that only a contraction on agiven variable is actually expected (any other contraction being superfluous).If the time complexity of the contractor depends on the number of variables,some work is spared. We may also inform the contractor that only the domain

29

of a given variable has been modified since the last call. Again, if the contractorworks incrementally, this will speed up contraction.

Two indicators have been integrated in our system, corresponding precisely tothe examples just given. The first is named scope and contains the subset ofvariables to be treated. The second is named impacted and contains the subsetof variables which domain has been impacted.

The semantics of indicators is constrained by one single fundamental property:they can be ignored by a called contractor without spoiling soundness (i.e., losingsolutions), whence their name. If one develops a contractor that ignores the scopeindicator, this contractor can still be passed as argument to an operator, shouldthe latter be based on the communicability of this information (e.g., propagatebelow). The consequence is only a loss of efficiency.

Hence, only two indicators are proposed today but the nice point with indicatorsis that new ones can be invented at any time and integrated progressively in thesubsequent implementations of contractors. In other words, backward compati-bility is complete. We just had to put all the indicators in a dictionary structure.The real signature of the contract function is:

contract(box [x], dictionary indicators).

As an example, one can ask a contractor C to focus on the two first variablesonly in the following way:

C.contract([x], {scope = {0, 1}}).

6.2 Numerical Contractors

There is nothing particular in the implementation of numerical contractors inQuimper, except that indicators have to be managed.

– The binary test 0 ∈ f([x]) is actually not proposed in Quimper, but such acontractor would necessarily ignore all the indicators.

– HC4Revise is implemented. The complexity of this contractor is linear in thelength of the constraint expression. Hence, contracting for a single variableamounts to contracting for all the variables (up to a small constant factor).In Quimper, HC4Revise ignores the scope indicator.

– The univariate interval Newton is implemented. As contrary to HC4Revise,this contractor deals with one particular variable at a time. Setting the scopeindicator to a single variable divides the contraction time by the number ofvariables.

– Linear relaxations are not yet implemented. Now, since a linear program-ming solver is called iteratively to reduce the bounds of each initial variable,the scope indicator would have to be taken into account as with univariateNewton.

30

The multivariate interval Newton is also implemented and ignores the scope andimpacted indicators.

6.3 Propagation

Here is how the propagation operator is implemented in Quimper.

Our convention for indices is to use i and j for contractors and variables respec-tively. When a couple (i, j) is revised, the ith contractor has to work on the jth

variable. If the revision succeeds (a significant part of the ith domain is removed)then the agenda is updated with the following classical procedure:

update agenda(integer i, integer j, subset scope)| forall i′ 6= i such that Ci′ .involves(j)| | forall j′ such that Ci′ .involves(j′)| | | if j′ ∈ scope\{j} then add (i′, j′) in the agenda

Now, if a revision (i, j) fails, there still may be a residual contraction. Further-more, some subcontractors may not take into account the scope indicator so thatunsolicited contractions can appear as the propagation loop goes along. At somepoint, the accumulation of these small contractions on a variable j can add up toa significant contraction. The agenda must be updated in consequence. In thiscase, the jth variable is the source but there is not a particular contractor. Theagenda must then be updated with all the couples (i, j), i describing the set ofcontractors. This is what the next procedure does.

update agenda(integer j, subset scope)| forall i such that Ci.involves(j)| | forall j′ such that Ci.involves(j′)| | | if j′ ∈ scope then add (i, j′) in the agenda

Now, let us give the main procedure. Two local boxes are defined, the first isused to measure the result of each revision (the contraction of Ci over xj) whilethe latter measure the contractions collected since the last time xj triggered anupdate.

contract(box [x], subset scope, subset impacted)box [xrev]← [x] // keeps track of domains before last revisionbox [xupd]← [x] // keeps track of domains before last updateforall j′ ∈ impacted| update agenda(j′,scope)integer last i ← −1 // keeps track of the last contractor calledwhile the agenda is not empty| pop (i, j) from the agenda| | subset scope’ ← {j}; // we want to revise the jth variable only| | subset impacted’ ← {}; // no domain has been touched ...| | if (i 6= last i) // ... unless we popped a different contractor| | | impacted’ ← { all variables }; // so that all may have been impacted

31

| | | forall j′ such that Ci.involves(j′) // and all the constraint variables| | | | [xrev]j′ ← [x]j′ // are now potentially impactable.| | | last i ← i; // i becomes the last contractor called| | Ci.contract([x], scope’, impacted’)| | if [xupd]j\[x]j is sufficiently small // check accumulated contraction| | | if [xrev]j\[x]j is sufficiently small // check last revision| | | | update agenda(i,j,scope) // fine propagation| | | else| | | | update agenda(j,scope) // coarse propagation

| | | | [x]updj ← [x]j

6.4 Some performance results

All the examples in this paper have been executed almost instantaneously (lessthan 0.1 second) when the precision was not high (this corresponds to the figureswith apparent boxes).

Figure 4.(a) was obtained by setting the precision of Cǫ to ǫ := 0.01. The pavingcontains 17768 boxes and was generated in ∼ 1.2s.

Figure 5.(a) was obtained with two natural contractors corresponding to theconstraints c1(x) and (c̄1(x)∧ c2), with a precision set to ǫ := 0.005. The pavingcontains 40844 boxes and was generated in ∼ 2.2s.

Figure 6.(a) was obtained with ǫ := 0.001 and by splitting 10 times the parameterdomain inside the contractors C∪ and C∩. Computation time was 26 secondsin this case, mainly because of the parameter splitting process which occurssystematically. The paving includes 17768 boxes.

7 Conclusion

We have presented a new framework for interval programming. The benefits ofthis framework are twofold. First, a large class of constraint-based problems cannow be addressed with a unique simple algorithm, called paver. Second, a fullcontrol on the solving process is at hand, including the core of the propagationloop.

This framework is entirely built on the concept of contractor: inputs are con-tractors instead of constraints. Similarly, outputs are related to contractor setsinstead of constraints sets. As just said, this –apparently small– change in mod-eling can lead to significant improvements in the design of new solvers but alsoin a declarative way. In a sense, the imperative aspect of solvers is now sub-sumed in the declarative one: the end user write constraints while the constraintprogrammer write contractors.

This approach is supported by a real system called Quimper which solves quicklyall the different problems mentioned in this paper.

32

There are plenty of possible extensions for this work. The first one is perhaps todeal with global optimization. This extension would probably resort to dynamiccontractors, i.e., contractors parameterized by a value that can be updated dur-ing the solving process. Orthogonally to contractors that potentially remove allunfeasible points, local finders that find peculiar feasible points seem to be a keyfeature as well.

References

1. H. Batnini and M. Rueher. Décomposition Sémantique pour la Résolution deSystèmes d’Equations de Distance. JEDAI, Journal Electronique d’IntelligenceArtificielle, 2(1), 2004.

2. F. Benhamou and F. Goualard. Universally Quantified Interval Constraints. InCP’00: 6th International Conference on Principles and Practice of Constraint Pro-gramming, pages 67–82, 2000.

3. F. Benhamou, F. Goualard, L. Granvilliers, and J-F. Puget. Revising Hull andBox Consistency. In ICLP, pages 230–244, 1999.

4. F. Benhamou, D. McAllester, and P. Van Hentenryck. CLP(intervals) revisited. InInternational Symposium on Logic programming, pages 124–138. MIT Press, 1994.

5. C. Bessière and Debruyne R. Optimal and Suboptimal Singleton Arc ConsistencyAlgorithms. In IJCAI, 19th International Joint Conference on Artificial Intelli-gence, pages 54–59, 2005.

6. C. Bliek, B. Neveu, and G. Trombettoni. Using Graph Decomposition for Solv-ing Continuous CSPs. In CP’98: 4th International Conference on Principles andPractice of Constraint Programming, pages 102–116. Springer, 1998.

7. G. Chabert. IBEX, an Interval-Based EXplorer. http://www.ibex-lib.org.8. H. Collavizza, F. Delobel, and M. Rueher. Extending Consistent Domains of Nu-

meric CSP. In IJCAI, Sixteenth International Joint Conference on Artificial In-telligence, pages 406–413, 1999.

9. E. Davis. Constraint Propagation with Interval Labels. Artificial Intelligence,32(3):281–331, 1987.

10. R. Dechter. Constraint Processing. Morgan Kaufmann Publishers Inc., San Fran-cisco, CA, USA, 2003.

11. F. Delobel, H. Collavizza, and M. Rueher. Comparing Partial Consistencies. Re-liable Computing, 5(3):213–228, 1999.

12. A. Goldsztejn. A branch and prune algorithm for the approximation of non-linearAE-solution sets. In SAC’06: Proceedings of the 2006 ACM symposium on Appliedcomputing, pages 1650–1654, 2006.

13. A. Goldsztejn and L. Jaulin. Inner and Outer Approximations of ExistentiallyQuantified Equality Constraints. In CP’06: 12th International Conference on Prin-ciples and Practice of Constraint Programming, pages 198–212. Springer, 2006.

14. C. Grandón, G. Chabert, and B. Neveu. Generalized Interval Projection: A NewTechnique for Consistent Domain Extension. In IJCAI, 20th International JointConference on Artificial Intelligence, pages 94–99, 2007.

15. L. Granvilliers and F. Benhamou. Algorithm 852: RealPaver: An Interval Solverusing Constraint Satisfaction Techniques. ACM Transactions on MathematicalSoftware, 32(1), 2006.

16. E. Hansen. Global Optimization using Interval Analysis (second edition). Dekker,2003.

33

17. E.R. Hansen and S. Sengupta. Bounding Solutions of Systems of Equations UsingInterval Analysis. BIT Numerical Mathematics, 21(2):203–211, 1980.

18. P. Herrero, M.A. Sainz, J. Veh́ı, and L. Jaulin. Quantified Set Inversion Algorithmwith Applications to Control. Reliable Computing, 11(5):369–382, 2005.

19. E. Hyvönen. Constraint Reasoning Based on Interval Arithmetic: The TolerancePropagation Approach. Artificial Intelligence, 58(1-3):71–112, 1992.

20. ILOG. ILOG Solver. http://www.ilog.com/products/cp/.21. L. Jaulin. Localization of an Underwater Robot using Interval Constraint Prop-

agation. In CP’06: 12th International Conference on Principles and Practice ofConstraint Programming, 2006.

22. L. Jaulin, M. Kieffer, O. Didrit, and E. Walter. Applied Interval Analysis. Springer,2001.

23. L. Jaulin and E. Walter. Guaranteed Bounded-Error Parameter Estimation forNonlinear Models with Uncertain Experimental Factors. Automatica, 35(5):849–856, 1999.

24. C. Jermann, G. Trombettoni, B. Neveu, and P. Mathis. Decomposition of Geomet-ric Constraint Systems: a Survey. IJCGA, International Journal of ComputationalGeometry and Applications, 16(5–6):479–511, 2006.

25. N. Jussien, G. Rochart, and X. Lorca. The CHOCO Constraint ProgrammingSolver. In CPAIOR’08 workshop on Open-Source Software for Integer and Con-traint Programming (OSSICP’08), 2008.

26. R. B. Kearfott. GlobSol. http://interval.louisiana.edu/GlobSol.27. R.B. Kearfott. Rigorous Global Search: Continuous Problems. Springer, 1996.28. O. Knüppel. Profil/Bias. http://www.ti3.tu-harburg.de/Software/PROFILEngli

sch.html.29. M. Z. Lagerkvist and C. Schulte. Advisors for Incremental Propagation. In CP’07:

13th International Conference on Principles and Practice of Constraint Program-ming. Springer, 2007.

30. Y. Lebbah, C. Michel, and M. Rueher. Efficient Pruning Technique Based on LinearRelaxations. In COCOS, volume 3478 of Lecture Notes in Computer Science, pages1–14, 2003.

31. O. Lhomme. Consistency Techniques for Numeric CSPs. In IJCAI, 13th Interna-tional Joint Conference on Artificial Intelligence, pages 232–238, 1993.

32. J-P. Merlet. Alias. http://www-sop.inria.fr/coprin/logiciels/ALIAS.33. J-P. Merlet. Solving the Forward Kinematics of a Gough-type Parallel Manipulator

with Interval Analysis. International Journal of Robotics Research, 23(3):221–236,2004.

34. R. Moore. Interval Analysis. Prentice-Hall, 1966.35. A. Neumaier. Interval Methods for Systems of Equations. Cambridge University

Press, 1990.36. B. Neveu, G. Chabert, and G. Trombettoni. When Interval Analysis Helps Inter-

Block Backtracking. In CP’06: 12th International Conference on Principles andPractice of Constraint Programming. Springer, 2006.

37. S. Ning and R.B. Kearfott. A Comparison of Some Methods for Solving LinearInterval Equations. SIAM Journal of Numerical Analysis, 34(1):1289–1305, 1997.

38. S. Ratschan. RSolver. http://rsolver.sourceforge.net.39. S. Ratschan. Quantified constraints under perturbation. Journal of Symbolic Com-

putation, 33(4), 2002.40. F. Rossi, P. van Beek, and T. Walsh. Handbook of Constraint Programming (Foun-

dations of Artificial Intelligence). Elsevier Science Inc., 2006.

34

41. N. Sahinidis. BARON, Branch-And-Reduce Optimization Navigator. http://www.andrew.cmu.edu/user/ns1b/baron/baron.html.

42. D. Sam-Haroud and B. Faltings. Consistency Techniques for Continuous Con-straints. Constraints, 1:85–118, 1996.

43. C. Schulte, M. Lagerkvist, and G. Tack. Gecode. http://www.gecode.org/.44. P. Van Hentenryck. The OPL optimization programming language. MIT Press,

Cambridge, 1999.45. P. Van Hentenryck, D. McAllester, and D. Kapur. Solving Polynomial Systems

Using a Branch and Prune Approach. SIAM Journal of Numerical Analysis,34(2):797–827, 1997.

46. P. Van Hentenryck and L. Michel. Constraint-Based Local Search. The MIT Press,2005.

47. P. Van Hentenryck, L. Michel, and Y. Deville. Numerica: A Modeling Languagefor Global Optimization. MIT Press, Cambridge, 1997.

48. X-H. Vu. Rigorous Solution Techniques for Numerical Constraint SatisfactionProblems. PhD Thesis, Swiss Federal Institute Of Technology In Lausanne, 2005.

35