To save content items to your account,
please confirm that you agree to abide by our usage policies.
If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account.
Find out more about saving content to .
To save content items to your Kindle, first ensure no-reply@cambridge.org
is added to your Approved Personal Document E-mail List under your Personal Document Settings
on the Manage Your Content and Devices page of your Amazon account. Then enter the ‘name’ part
of your Kindle email address below.
Find out more about saving to your Kindle.
Note you can select to save to either the @free.kindle.com or @kindle.com variations.
‘@free.kindle.com’ emails are free but can only be saved to your device when it is connected to wi-fi.
‘@kindle.com’ emails can be delivered even when you are not connected to wi-fi, but note that service fees apply.
FOR SOME SPECIFIC domains and constraints for which no efficient solving methods exist or are known to exist specialised techniques have been developed. The aim of this chapter is to illustrate such techniques on a number of examples. In each case they amount to reducing a given CSP to a simpler one that is equivalent to the original one. Because in general from the resulting CSP one cannot immediately generate solutions to it, these methods amount in the terminology of Chapter 4 to incomplete constraint solvers. We define these incomplete constraint solvers using the proof theoretic framework introduced in Section 4.1, so by means of the proof rules that work on CSPs.
Ideally, we would like to use the general rules defined in Chapter 5. Unfortunately, this is easier said than done. Consider for example the HYPER-ARC CONSISTENCY rule of Section 5.3 that is clearly of interest, since given a constraint C on the variables x1, …, xk, it allows us to remove all ‘unneeded’ elements from the domains of the variables x1, …, xk. When the constraints are defined using a specific language, it is not clear how to compute the new variable domains that appear in the rule conclusion. So for each specific language we rather provide rules that are defined syntactically and consequently can be readily implemented.
IN THE PREVIOUS chapters we discussed various aspects of constraint programming. We did it by concentrating on the relevant ingredients of this programming style separately. In principle we could put them together using the general framework of Section 3.2. There are, however, other issues that naturally arise when one tries to incorporate these techniques in a programming language or system. In this chapter we shall discuss these matters and also shed light on the resulting programming style. At the same time we shall provide a short summary of various research topics currently pursued in constraint programming.
We discuss in turn the issues concerned with modeling (in Section 9.1), constraint programming languages (in Section 9.2), constraint propagation (in Section 9.3), constraint solvers (in Section 9.4), search (in Section 9.5) and over-constrained problems (in Section 9.6). Finally, at the end of the chapter, in the bibliographic remarks, we provide pointers to a number of useful surveys that should allow the reader to embark on research in constraint programming. As the final bibliography is just ‘next door’ we do not list the, rather extensive, list of references at the end of this chapter.
Modeling
Recall that in Chapter 1 we formulated the following principle:
Constraint programming is about a formulation of the problem as a constraint satisfaction problem and about solving it by means of domain specific or general methods.
THE AIM OF this chapter is to discuss various examples of constraint satisfaction problems (CSPs2 in short). The notion of a CSP is very general, so it is not surprising that these examples cover a wide range of topics. We limit ourselves here to the examples of CSPs that are simple to explain and that illustrate the use of general methods of constraint programming. In particular, we included here some perennial puzzles, since, as it has been recognised for some time, they form an excellent vehicle to explain certain principles of constraint programming.
As already mentioned in Chapter 1 the representation of a problem as a CSP is usually called modeling. The selected examples clarify a number of aspects of modeling. First, as we shall see, some of the problems can be formalised as a CSP in a straightforward way. For other problems the appropriate representation as a CSP is by no means straightforward and relies on a non-trivial ‘background’ theory that ensures correctness of the adopted representation. Also for several problems, more than one natural representation exists.
When presenting the CSPs it is useful to classify them according to some criterion. In general, the techniques used to solve CSPs depend both on the domains over which they are defined and on the syntax of the used constraints. In most examples we use some simple language to define the constraints. Later, in Chapters 4 and 6, we shall be more precise and shall discuss in detail specific languages in which the constraints will be defined.
IDEALLY, WE WOULD like to solve CSPs directly, by means of some efficient algorithm. But the definition of a CSP is extremely general, so, as already mentioned in Chapter 1, no universal efficient methods for solving them exist. Various general techniques were developed to solve CSPs and in the absence of efficient algorithms a combination of these techniques is a natural way to proceed.
In Chapter 3 we explained that the main idea is to reduce a given CSP to another one that is equivalent but easier to solve. This process is called constraint propagation and the algorithms that achieve this reduction are called constraint propagation algorithms. They are discussed in Chapter 7. These algorithms usually aim at reaching some form of ‘local consistency’. Several forms of local consistency have been defined but it is not clear how to provide a satisfactory formalisation of this notion. So we rather confine ourselves to a review of the most common types of local consistency. Informally, local consistency means that some subparts of the considered CSP are in a ‘desired form’, for example consistent.
To achieve a smooth transition between this chapter and Chapter 7, each time we introduce a notion of local consistency we also provide its characterisation. These characterisations are then used in Chapter 7 to generate the appropriate constraint propagation algorithms. They are based on the proof theoretic framework introduced in Section 4.1.
THIS BOOK IS about constraint programming, an alternative approach to programming which relies on a combination of techniques that deal with reasoning and computing. It has been successfully applied in a number of fields including molecular biology, electrical engineering, operations research and numerical analysis. The central notion is that of a constraint. Informally, a constraint on a sequence of variables is a relation on their domains. It can be viewed as a requirement that states which combinations of values from the variable domains are admitted. In turn, a constraint satisfaction problem consists of a finite set of constraints, each on a subsequence of a given sequence of variables.
To solve a given problem by means of constraint programming we first formulate it as a constraint satisfaction problem. To this end we
introduce some variables ranging over specific domains and constraints over these variables;
choose some language in which the constraints are expressed (usually a small subset of first-order logic).
This part of the problem solving is called modeling. In general, more than one representation of a problem as a constraint satisfaction problem exists. Then to solve the chosen representation we use either
domain specific methods,
or
general methods,
or a combination of both.
The domain specific methods are usually provided in the form of implementations special purpose algorithms.
THE ALGORITHMS THAT achieve local consistency are called constraint propagation algorithms. In the literature, perhaps to confuse newcomers entering the field, several other names have also been used. In fact, we found the following alternative names for these algorithms: consistency, local consistency, local propagation, consistency enforcing, Waltz, filtering and narrowing algorithms. The aim of this chapter is to discuss various constraint propagation algorithms. These algorithms form a crucial ingredient of the generic procedure Solve of Figure 3.1 from Section 3.2 that can be used to solve a given CSP.
Sometimes a CSP can already be solved solely by means of a constraint propagation algorithm. Examples are furnished by some of the results proved in Chapter 5, namely the Consistency 2 Theorem 5.48, the Directional Arc Consistency Theorem 5.49, and the Directional Path Consistency Theorem 5.50. Another example is provided by the crossword puzzle of Example 2.8. We saw at the end of Section 5.2 that the CSP that represents this puzzle can be solved by transforming it to an equivalent arc consistent CSP. So arc consistency turned out to be sufficient to find a solution to this CSP.
When introducing in Chapter 5 several local consistency notions we characterised them by means of proof rules of the proof theoretic framework of Section 4.1. Also in Chapter 6 we defined some incomplete constraint solvers using rules.
BY A constraint solver we mean any procedure that transforms a CSP into an equivalent one. In practice we are interested in efficient constraint solvers. In this book we distinguish between complete and incomplete constraint solvers.
Intuitively, a complete constraint solver transforms the initial CSP to one from which it is straightforward to generate all solutions to or to determine that no solution exists. Admittedly, this statement is imprecise. In the case of the solvers discussed in this chapter we shall make it precise by employing the notion of a solved form. Its definition depends on the type of constraints used.
We call a constraint solver that is not complete an incomplete constraint solver. Intuitively, such a constraint solver transforms the initial CSP into a simpler one, all solutions to which can be eventually found by a, possibly repeated, case analysis modeled by splitting. As such a repeated case analysis results in general in an exponential running time, we do not allow it to be a part of the constraint solvers.
For the incomplete solvers a natural question arises what they actually achieve. To clarify this issue we introduce various notions of local consistency. This explains the order of the chapters that follow. In this one we focus on some complete constraint solvers, in the next one on various notions of local consistency and in Chapter 6 we study a number of incomplete constraint solvers.
For a number of domains and constraints complete constraint solvers were developed. The aim of this chapter is to illustrate such solvers by means of three well-known examples.
AT THIS STAGE it is useful to get a better feeling of what constraint programming is about. Recall that we stated in Chapter 1 that in constraint programming the programming process is limited to a generation of constraints and a solution of these constraints by means of domain specific or general methods. The aim of this chapter is to provide an intuitive introduction to these methods. In the subsequent chapters we shall discuss them in a more detailed and precise way.
To discuss these techniques it is useful to formalise appropriate notions of equivalence between CSPs. We do this in Section 3.1. Then we describe in Section 3.2 a general framework which allows us to explain the basics of constraints programming. It involves various procedures that capture specific aspects of constraint programming. Subsequently we illustrate these procedures by means of two extended examples. In Section 3.3 we consider the Boolean CSPs and in Section 3.4 constrained optimization problems involving the polynomial constraints on integer intervals.
Equivalence of CSPs
We mentioned already in Chapter 1 that we view constraint programming as a process of transforming the CSPs. To describe this process closer it is useful to formalise a number of notions concerning CSPs.
First, recall that a constraint C on a sequence of variables y1, …, yk with respective domains D1, …, Dk associated with them is a subset of D1 × … × Dk.
Education matters. The lack of education on functional programming languages and techniques is visible on a daily basis. Our students, co-workers, friends, and colleagues just don't know enough about these ideas and therefore often fail to implement the best possible solutions for their programming problems.
The purpose of Educational Pearls is to address the education problem of our community from many different angles. It will include contributions on curricula issues, educational software support, and educational experiences. They will help teachers, professors, researchers, and software developers to promote functional programming languages and techniques in their respective contexts.
The following three figures (figures 10, 11 and 12) were not shown in the original published version of the article. These figures constitute the entire static semantics of the STAL type system.
We show that a non-duplicating transformation into Continuation-Passing Style (CPS) has no effect on control-flow analysis, a positive effect on binding-time analysis for traditional partial evaluation, and no effect on binding-time analysis for continuation-based partial evaluation: a monovariant control-flow analysis yields equivalent results on a direct-style program and on its CPS counterpart, a monovariant binding-time analysis yields less precise results on a direct-style program than on its CPS counterpart, and an enhanced monovariant binding-time analysis yields equivalent results on a direct-style program and on its CPS counterpart. Our proof technique amounts to constructing the CPS counterpart of flow information and of binding times. Our results formalize and confirm a folklore theorem about traditional binding-time analysis, namely that CPS has a positive effect on binding times. What may be more surprising is that the benefit does not arise from a standard refinement of program analysis, as, for instance, duplicating continuations. The present study is symptomatic of an unsettling property of program analyses: their quality is unpredictably vulnerable to syntactic accidents in source programs, i.e., to the way these programs are written. More reliable program analyses require a better understanding of the effect of syntactic change.
When I was a student, Simula was one of the languages taught in introductory programming language courses and I vividly remember a sticker one of our instructors had attached to the door of his office, saying “Simula does it with class”. I guess the same holds for Haskell except that Haskell replaces classes by type classes.
This paper presents Biglook, a widget library for an extended version of the Scheme programming language. It uses classes of a Clos-like object layer to represent widgets and Scheme closures to handle graphical events. Combining functional and object-oriented programming styles yields an original application programming interface that advocates a strict separation between the implementation of the graphical interfaces and the user-associated commands, enabling compact source code. The Biglook implementation separates the Scheme programming interface and the native back-end. This permits different ports for Biglook. The current version uses GTK+ and Swing graphical toolkits, while the previous release used Tk.