Languages versus Packages for Constraint ... - Semantic Scholar

Languages versus Packages for Constraint Problem Solving Mark Wallace IC-Parc, Imperial College London, UK

Abstract. One strand of CP research seeks to design a small set of primitives and operators that can be used to build an appropriate algorithm for solving any given combinatorial problem. The aim is to \package" CP, simplifying its use, in contrast to current systems which oer application developers a full constraint programming language. In this talk we examine the risks of this line of research, and argue that our eld is still too immature to be ready for \packaging".

1 Introduction 1.1 Usability versus Functionality

Learning a constraint programming language is a major obstacle to the takeup of CP for industrial and other practical applications. Applications developers who wish to take advantage of the technology seek a variety of detours to avoid this obstacle. One approach is to use some familiar system or package to generate constraints which are then passed to CP. Another is to o
er CP in a packaged form, where solving methods are simply given as parameter settings. On the other hand with the rapidly growing variety of real-world CP applications, we are becoming increasingly aware of the limitations of current CP systems for modelling and solving large scale industrial problems. Indeed industrial practitioners of CP nd that every time they successfully solve a problem, the client's expectations are raised, and a new larger problem is proposed. Often the new requirement is for a more inclusive application which solves several interconnected problems. These inclusive applications require integrated solutions, which demand even more functionality of the underlying CP systems. A typical example is the extension of a planning system to include a simulator to assess plan quality, and ultimately an extension to perform on-the-day operational control for the delivered application with feedback to the planning module. The CP community is thus being driven in two directions. Firstly it is driven by usability requirements, in the direction of simpler programming interfaces, and a broader community of applications developers 1, 2]. Secondly it is driven by application needs in the direction of enhanced modelling and solving. Apparently these two directions are diametrically opposed. A simpler interface, which is easier to learn, is only possible if the user has limited control over the underlying functionality. More expressibility and more algorithmic control implies more complexity at the programmer interface.

Weighing up these two alternatives - better usability versus more functionality - the case for usability is very seductive, especially in a research climate where user takeup is a critical measure of research value. This paper argues the case against concentrating on usability at the current stage in the development of CP. There are two arguments for continuing to emphasise functionality at this stage. We rst give an argument against focussing on usability as a separate research topic. We then give an argument for ensuring that usability tracks functionality. Firstly, current usability results may not be a stepping stone into the future. Such results can misguide researchers into standardising on certain interfaces which may not be able to cope with facilities o
ered in future CP systems. Moreover application developers may be misled by the current interfaces into believing that CP is not suitable for their problems. A classic example of this was the view held by many CP practitioners for a while that mixed integer programming (MIP) was a technology in competition with CP. This was a consequence of standardisation on FD as the constraint solver for CP (despite the fact that a linear solver had earlier been the solver built into the rst instance CLP(R) of the CLP Scheme 3]). Secondly, by marrying usability research to the ongoing research into CP expressibility and solving power, we produce interfaces to state-ofthe-art CP facilities. One consequence is that the new functionality is immediatelymade available to applications developers, and this exploitation gives important feedback as to its relevance or otherwise. For instance the value of progress in symmetry breaking can be quickly established by making it available to applications developers, and not hiding it inside research prototypes that can only be used by the original researchers. Another interesting consequence is that the usability research in itself helps clarify the relationship between separate strands of functionality research, inspiring the researchers to build orthogonal functional components. Using symmetry breaking again as an example, we learn much more about its relation to other techniques, such as linear constraint solving, by building it into generic search routines that also integrate these techniques. This integration both raises important issues about making the new techniques generic, and it makes the new techniques available to application developers, integrated with the several forms of constraint handling and search needed to solve real life applications. This o
ers quick turnaround in validating new technology in combination with other innovations. For these reasons we advocate a research methodology that encourages CP interfaces to move forward hand-in-hand with the emerging functionality. Moreover we advocate a research methodology where di
erent kinds of functionality

are developed in the context of a single coherent system, behind a single, changing but coherent, user interface. This ensures that the relationship between these di
erent functionality enhancements are understood as early as possible.

1.2 Contents of this Paper

Many of us in the CP community share a vision of the holy grail as a system that allows the application developer to simply state the problem and leave the computer to automatically solve it in the most e cient way possible. This paper argues that it is to early, now, to aim directly for that nal vision. Eventually, yes, but not yet. The paper does not present any analysis of the expressive power of constraint programming languages as compared with packages. In addressing the title \Languages versus Packages for Constraint Problem Solving", one might argue that a language with recursion is necessary to specify precisely a constraint solving behaviour, and a package whose parameters also had this expressive power should really be termed a \language". One could discuss where CP e
ort should be invested along the following continuum: { parameterising { conguring { scripting { programming We will not enter into any such ne disputation in this paper. Instead, the remainder of the paper will support the arguments formulated in this introduction. In the next section we examine the use of Mixed Integer Programming (MIP) for solving large combinatorial optimisation problems. The advantages and disadvantages of the MIP approach will be examined and we will consider its consequences on research in this area. Next we will consider the possibility - and possible consequences - of developing generic packages for combinatorial optimisation problems. The following section explores a research area - search in CP - relating the advances made by the research community to the consequent requirements on the interfaces and implementation of search engines. In particular we contrast languages and packages for specifying search behaviour. The discussions are summarised in the conclusion.

2 Mixed Integer Programming (MIP) - choked by its own success? In this paper, the argument for languages rather than packages will be presented in the context of a particular area of CP research: CP for combinatorial optimisation. This is, in the shorter term, the most industrially relevant aspect of CP research and it is therefore currently very important. Moreover this is the area with which I am most familiar in my own research. I believe the arguments also hold for other areas of CP research and application, but I only bring examples from the area of combinatorial optimisation (CO).

2.1 MIP Packages MIP is an approach for modelling and solving CO problems, that has been developed in the Mathematical Programming community over the last half century. It provides restricted modelling power, with only a few constraints, and o
ers specialised solving methods designed for these constraints. We caricature MIP as a packaged approach. In other words, even though in real life MIP systems o
er facilities to invoke external language procedures, we shall use \MIP" as if it was just a package. A number of commercial packages are available that support MIP modelling and solving 4{9], and a wide range of benchmark problems are available that can be run on any MIP package, thus giving an insight into the performance of its solving methods 10]. This state of a
airs has many benets. The interface between the user front end and the underlying solving methods is quite stable and well dened.1 MIP user front ends and modelling languages can be designed and enhanced independently of any work on the underlying solvers. Application-specic front-ends can be developed which are targeted at specic user communities. Solver performances can be directly compared, independently of their front ends.

2.2 Limitations of MIP

MIP only recognises two constraints, >= and integer.2 It is awkward, but quite fun, mapping any given problem into a combination of the above constraints. One can relatively quickly learn the necessary tricks for representing disjunction, negation and so on. Once one's got the idea, it is amazing how many CO problems one can model and solve using a MIP package. The English language has a reputation for being easy to learn, but hard to master. MIP is a bit like that. Not only can the MIP model quickly become very large and complicated even for problems which are simple to state, but also the performance of the MIP solver can become unacceptably poor. For nontrivial problems it is extremely hard to design the MIP model which has the best performance. It is even more di cult to recognise for which problems MIP is simply not a suitable approach. The result is that a great deal of time is invested in trying to design e cient MIP models for problems which might or might not be suitable for this approach. One example is the coins problem. What is the minimum number of coins you need in your pocket, in order to be able to buy any item costing up to one Euro? There are 6 coins below one Euro, value 1,2,5,10,20 and 50 cents, and with our coins we need to be able to construct every sum between 1 and 100. The model requires over 600 discrete variables, representing, for each cost between 1 and 100, the number of coins of each denomination used to make up that sum. The interface is only quite stable, in the sense that changes are under way. Research is shifting the linear/nonlinear frontier to convex/nonconvex. Ultimately the modelling power and solving methods of future mathematical programming packages, replacing MIP, will probably be based on this new dichotomy. 2 This is a slight exaggeration, which is intended to simplify rather than mislead. 1

This problem takes over 30 minutes to solve using MIP, but it is possible to add redundant constraints which tighten the formulation and cut the solving time down to a few seconds 11]. However suppose you now want to design a new set of six coins for the Euro, so as to optimise the solution to the above coins problem. The currency design problem is the same as the coins problem, except that now the denominations of the coins are part of the solution and not part of the input. This is not easy, and maybe not possible, to solve e ciently with MIP. The point is not just that MIP can't be used to solve all CO problems. The really awkward thing is that for a given problem there's no way of knowing whether or not MIP can be made to solve it e ciently. As an application developer, using a package, one's thinking is within the parameters of the package. If the package isn't solving the problem e ciently, parameter settings can be altered. A package is a box, and very often it's thinking outside the box that is needed for solving the problem! If one wants to solve the currency design problem, the best advice is probably not to use MIP. This is not intended to be a criticism of MIP, but just a recognition that for certain kinds of problem, of which this is an example, it is best not to be boxed into thinking in terms of MIP. Instead, using domain constraints, quite a simple program can generate an optimal six coin currency in a few seconds. The program, coded in ECLiPSe 12], is listed in the appendix.

3 Generic Packages for Combinatorial Problem Solving 3.1 The Aspiration

If the class of problems to be tackled are CO problems, then one might seek to assemble a set of packages which together encompass problems of this class. Acknowledging that probably P is not equal to NP, and that there will be problems that cannot be optimally solved in a reasonable amount of time, we can provide amongst our set of packages, incomplete, anytime, solvers that will return nearly optimal or nearly feasible solutions within realistic timescales. In principle, then, a two-stage process can be followed to solve any problem: rst choose the appropriate package and then set the parameters of that package optimally to solve the problem. A neutral problem modelling interface could be provided which allowed the application developer to map a problem down to each of the di
erent available packages by simply setting a parameter to guide the problem mapping software. Indeed there are already several commercial packages of this kind (see for example OptQuest 13], and Nimrod 14]). Thus we could in e
ect provide the user with a single generic package for all CO problems. As an aspiration, this is highly motivating. As an immediate objective, it is distorting and may threaten scientic progress in our community!

3.2 The Reality

One of the standard characters in any area of research is the champion of some approach, who is blind to any alternative. His near-relative is the salesman who

will sell the same solution to every customer, condently asserting that his solution will fully meet the needs of the customer. Suppose a generic package for combinatorial optimisation had been constructed. Suppose, moreover, it proved successful for a relatively wide variety of applications. The risk, particularly in the area of combinatorial optimisation, is that like MIP it could become a victim of its own success. Its protagonists would naturally tend to claim that it met all its objectives. If the package were a hammer, then all CO problems would be nails. Any problem not easily or e ciently handled by the package would be classed as peculiar, or particularly di cult. Herein lies the risk: instead of recognising deciencies in the package, there would be a tendency to marginalize the signicance of the problem. Since it is of the very nature of CO problems that for any given approach some problem instances will be recalcitrant, then don't blame the approach but blame the problem instead. The danger is that whatever package an applications developer has become accustomed to, (s)he may come to think of it as a generic package for CO problems. We have taken MIP as the example package in the previous section. The problem we are illustrating here is not a limitation of MIP at all, but a limitation of the thinking induced by packages. As one example, consider the progressive party problem 15]. Until Barbara Smith put CP onto the task, the problem owners could have reconciled themselves to the limitations of the MIP-based approach, assuming this was the best one could do for this kind of awkward problem. We have had similar experiences at IC-Parc and Parc Technologies. For various network scheduling problems the accepted wisdom was that they were too hard to solve optimally. Only when the new combination of CP and MIP was brought to bear, did it become evident that the problems themselves were not so hard, they were only hard to solve using particular kinds of approach. Linear programming was, and is, a tremendous advance and, enhanced to MIP, it has yielded optimal solutions to some very large CO problems. However, arguably, it has resulted in a certain distortion of the CO research. The e
ort invested in problems that can be modelled in MIP, such as the TSP 16], has far exceeded the e
ort invested in industrial problems with awkward side-constraints. The MIP model for such industrial problems typically requires unmanageably large numbers of discrete variables. Consequently real problems are simplied, by dropping or approximating their side-constraints. In this way the research e
ort remains concentrated on a class of problems which is dictated more by the available technology than by the demands of the real problems themselves. As a postscript, the arrival of CP on the scene has had quite an impact on MIP research. In particular more work has been invested in presolving and search control. Recently MIP has been used to solve the progressive party problem 17], and the lessons from CP have been used to obtain solutions reasonably fast. The OR and CP research communities are gaining a better and better understanding of the relative advantages of the di
erent technologies, and researchers are exploring new forms of hybridisation to get the best out of their combination.

4 Languages not Packages - the Case of Search In this section we discuss the issue of search in CP. This is an active area of research which seems to be highly representative of CP research in general. For these reasons we shall use it as the example research area in comparing languages and packages.

4.1 Search Frameworks Incremental Labelling One of the rst attempts to categorise the di
erent

search algorithms was by Nadel 18]. He named various constraint propagation algorithms as AC 1=5 : : : AC 1=2, AC 1 : : : AC 3. (The range of algorithms continues to grow, though after AC 7 a new nomenclature was introduced). He then categorised di
erent search algorithms as a combination of tree search (TS) and propagation (see Nadel's Categories below). Later Haralick and Elliott 19] Backtracking TS + AC 1=5 Forward Checking TS + AC 1=4 Partial Lookahead TS + AC 1=4 + AC 1=3 Full Lookahead TS + AC 1=4 + AC 1=2 Table 1. Nadel's Categories

identied the fail
rst heuristic and this was generalised into variable and value choice heuristics. Another orthogonal search facility identied by 19] was \Remember what you have done to avoid making the same mistake". This has been generalised into intelligent backtracking and nogood learning. Finally, within the framework of tree-search, there are di
erent ways of exploring the tree breadth-rst, depth rst etc. In short any given algorithm in the class of search algorithms which label a single variable with a chosen value at each search step, can be specied by four classes of parameters: { Lookahead { Variable/Value choice heuristics { Looking back { Tree exploration For brevity we term this class of search algorithms incremental labelling algorithms. The encapsulation of incremental labelling in a package, does serve to simplify and clarify control of search within this framework. Incremental labelling has provided a basis for several packages for performing search. In introducing the package AISearch 20] Peter Bouthoorn writes: \the programmer should be able to concentrate on the representation of the problem at hand and need not bother

with the implementation of the actual search algorithm". Parameterisable search algorithms are also available from Tudor Hulubei 21], where the search is dened in terms of generic choice operators (called \decomposition" algorithms) and generic lookahead operators (called \lters"). Generic CSP search algorithms are also supplied for teaching support purposes 22]. In a wider framework, a generic package for solving valued CSPs is available from 23], which supports not only tree search but other search methods.

Drawbacks of Packaging Each of these packages provides, as a package must,

a xed list of alternatives for specifying the search behaviour. The real danger of this approach is not the choice of list, but the thinking that such lists enforce upon language and applications developers. For example on the assumption that control over looking ahead and looking back are not enough to focus an incremental labelling search, considerable investment has been put into the automatic generation of search heuristics for variable and value choices 24{26]. The risk is that this research e
ort may have limited practical payo
if only a few large scale industrial problems can be solved by any incremental labelling algorithm. The wider scientic community is developing algorithms every day to solve hard combinatorial problems (see, for example, the Annals of Operations Research, Annals of Mathematics and Articial Intelligence, Journal of Heuristics, European Journal of Operations Research) and the vast majority do not t the above framework. Just as an MIP package is probably inappropriate for the currency design problem, so incremental labelling may not be appropriate for large scale industrial problems. In each of the next four subsections we will consider a particular search functionality and what special requirements it imposes on the underlying language for describing search. The practical importance of these four search functionalities has emerged over recent years. Clearly they only emerged because applications developers were not trapped into a search framework where these functionalities were not available. As the journals listed above illustrate, new search functionalities are appearing continually, so these four are merely a sample.

4.2 Multiple Search Routines The Issue For problems whose decision variables are all of the same type, a

single global search routine can o
er the necessary functionality. However, even simple problems can involve di
erent types of decision variable. The currency design problem above, for example, has one set of decision variables governing the denominations of the coins, and another set of decision variables specifying how many coins of each denomination must be \kept in the (optimal) pocket". A good search algorithm labels the denominations rst, and then the numbers of coins. The extension from one search routine to two, one search being done after the other, is quite simple and obvious. More challenging are applications where labelling the di
erent types of variables needs to be interleaved. Consider the problem of an ad-hoc sensor network.

The problem involves a set of sensors and a set of targets. A solution is the assignment of a sensor to each target, restricting the number of sensors used, so as to optimise some objective. The best search algorithm rst selects a sensor to be active and then assigns it to an appropriate subset of the targets, before repeating on the remaining sensors and targets. Technically this problem involves two kinds of decision variables: an on/o variable for each sensor, and, for each target/sensor pair an on/o assignment variable. The search routine labels a sensor variable to on, and then labels all the target/sensor variables associated with that sensor. Let us abstract from the specic problem, calling the variables type1 and type2. In this case the master search routine is the one that labels type1 variables. After each choice point in the master search routine, a subsidiary search routine is invoked to label an associated subset of the type2 variables.3

Language Requirement Consider a search package designed, however cleverly,

for a single global search routine with one type of decision variable. Its adaptation to handle more than one type of decision variable in the currency design problem is easy: the search package must be invoked twice, once on the denomination variables and once on the number variables. However this search package cannot be adapted for the ad-hoc sensor network problem because that requires a master search routine which invokes another search routine at every choice point. Instead a language is needed in which it is possible to specify, for any (master) search routine, what search (sub)routine to invoke on which variables after each choice point.

4.3 Computing Heuristics during Search The Issue Credit search (CS) 12, p.126] assigns a given portion of the remain-

ing search e
ort to di
erent subtrees of the current node. Limited Discrepancy Search (LDS) 28] constrains the \distance" between any partial assignment and a given preferred assignment. Both forms of search rely on a value ordering heuristic which associates preferred values with each of the unlabelled decision variables. Given a xed value ordering on all the decision variables of a problem, suppose we start at the search leaf node where each variable takes its preferred value. If we design a local search operator which switches a variable to a less preferred value, then LDS corresponds to the exploration of increasing neighbourhoods of the original assignment. A substantive di
erence between LDS and local search only emerges when we admit dynamic value ordering heuristic which changes according to the current partial assignment. Typical value ordering heuristics are largely static: the 3

W. Harvey pointed out that a suciently sophisticated variable selection procedure, which exploited the association between type2 and type1 variables could be used to achieve the same behaviour as our sensor example. However master/subproblem search routines are a necessary feature of several mathematical programming algorithms like branch and price 27].

only dynamic aspect is to drop values removed from a variable's domain by propagation. In fact CS and LDS are most useful when problem-specic dynamic value ordering heuristics are exploited - for example using an optimal solution for a linear relaxation of the problem. A signicant enhancement of this approach for LDS is to use multiple value ordering heuristics, and only to count a discrepancy if both heuristics agree on the best value for a certain variable, and this variable is assigned a di
erent value 29].

Language Requirement To support the above functionality the system needs

to be able to re o
, at every node in a search tree, one or more problem solvers that solve some di
erent relaxations, or variants, of the current problem and utilises the result to construct search heuristics for the next search step.

4.4 Updating Entailed Information at Search Nodes The Issue Consider a constraint satisfaction problem, and a current assignment

of values to variables. The satisfaction problem can be handled as an optimisation problem by minimising the amount of \unsatisfaction". This can be measured in two ways. Either a penalty can be associated with each violated constraint 30, 31], or a penalty can be associated with each variable occurring in any violated constraints 32]. For the purposes of this discussion we shall use the rst measure, taking GSAT as an example. GSAT uses local search, in which each move is a change in the assignment of one variable. GSAT uses \steepest ascent", at each step choosing a variable and value combination which minimises the remaining \unsatisfaction". Steepest ascent hill climbing is, typically, expensive to implement because of the necessity to nd the best amongst the set of neighbours. For implementing GSAT e ciently it is necessary to maintain a quantity of \red-tape" - redundant information about the current assignment that helps in nding the best neighbour. Accordingly, for each decision variable and for each constraint, the implementation maintains a record of what would happen to that constraint if the variable assignment was changed (either the constraint would become true, or it would stay true, or it would become false). This redtape is used to e ciently maintain further red-tape (recording the change in the number of satised constraints if the variable's assignment were to be changed). In short the change to the variable assignment is propagated to the red-tape, and propagation continues along the red-tape (with apologies for the mixed metaphor). In the same way the e cient implementation of any local search algorithm requires red tape. The choice of what red tape to maintain depends on the problem constraints, the cost function and the parameters governing the local search routine. For the GSAT example much of the red-tape is needed for the purposes of achieving steepest ascent. Other local search algorithms, such as simulated annealing, would require quite di
erent red-tape.

Language Requirement What is needed to enable the programmer to have

such control is a language such as Localizer 33] which maintains red tape as \invariants". It is tempting to think that the same red tape could be associated with any problem, e.g. for each variable, constraint and domain value the e
ect of changing that variable to take that value. However conict minimisation problems may use a wide variety of cost functions. One could, for example, associate a degree of violation with each constraint, reecting how badly it is violated. One could also make the red-tape update algorithm constraint-specic. E ciency is crucial in local search, so this control is absolutely necessary for the algorithm.

4.5 Constraints as Search Node Choices The Issue The nal issue is the introduction of problem renement rather than

labelling for making choices during search. A search choice may be to assign a value to a variable, or it may be simply to impose an additional constraint on the problem. One area where constraints are typically used in this way during search is in scheduling applications. Instead of labelling a task start time, a search step is often made by imposing an ordering on two tasks (i.e. imposing a constraint that the end time of one task precedes the start time of the other). A nal assignment of task start times can be completed easily when enough of the tasks have been ordered. Note that for scheduling problems, the use of an ordering choice rather than an assignment is common to both tree search algorithms and local search methods, such as Tabu search. A general approach employing constraints instead of labels during search has been called \probing" 34]. The problem constraints are divided into \easy" constraints and \hard" constraints. For probing the following conditions should hold: { a conjunction of easy constraints is also an easy constraint { it is always possible to express a hard constraint as a disjunction of easy constraints. (Assuming the assignment of a value to a variable is an easy constraint, then any nite constraint can be captured as a disjunction of easy constraints.) Search is by nding an optimal solution to the current easy constraints, selecting a violated hard constraint (if there is one) and imposing one of the easy constraints in its equivalent disjunction. This denes a complete search tree, whose leaves are easy problems whose optimal solutions also satisfy all the hard constraints of the original problem.

The Language Requirement To build a probing algorithm it is necessary

to give, implicitly or explicitly, the disjunction of easy constraints equivalent to each hard constraint, and specify the solver for the easy constraints. Clearly a programming language is necessary to build any probing algorithm.

4.6 Languages and Packages for Search in CP

For some purposes it su ces to dene a search procedure with a few global parameters (in MIP packages, for example , and in the traditional AI world with global procedures such as A*). However for more complex \hybrid" problems the need for more specic ad-hoc search control becomes quickly apparent. The traditional search control inherited from Prolog was, and is, a very strong inuence on search procedures, even for CP systems that are embedded in other languages. The procedure is expressed in terms of a recursion down the tree from root to leaf, with node propagation behaviour and search ordering heuristics expressed as a subprocedure invoked at each recursive call (i.e. node of the tree). However two concepts have emerged that are hard to shoehorn into the standard recursive procedure: local search and the separation of search tree specication and (incomplete) search tree exploration. New languages such as Localizer 33] and Salsa 35] have appeared, and new libraries such as ToOLS 36]. A paradigm for search control is emerging where the behaviour is expressed as a complex term whose components are subordinate search procedures and parameters. The interplay of tree search and local search within a search procedure is becoming better understood, although the handling of multiple types of decision variable in a search procedure is not yet taken seriously (ToOLS currently o
ers only sequencing and concurrent execution as ways of combining search procedures). The current research e
ort on search control encapsulates the discussion in this paper. Researchers whose CP world has domain variables, dene search control languages which simply ignore the challenging requirements of mathematical approaches such as branch and price 27]. Their contribution is important, but we must not let an elegant search control language, applicable only to a limited form of constraint handling, hold back the e
orts to develop search control for the full set of CP tools. The new search languages may - perhaps must - be less elegant than the old but this should not prevent their reaching a wide audience.

5 Conclusion Packages are easy to use, and can help to establish CP across the world in academia and industry. Moreover packages can be extended and adapted to take new concepts and ideas into account. However these extensions are ultimately incoherent and can stie progress. For example the CSP framework can be extended to accommodate optimisation, uncertainty, and dynamic problems, but for all three extensions together, as encountered in real applications, the framework may be more of a hindrance than a help 37]. The internal combustion engine is, all acknowledge, an old technology which has limited scope to meet the need for energy conservation, but it is so well researched that new young technologies cannot at rst compete. Thus the very success of the old technology blights future technology. This is a scenario we should be determined to avoid in CP.

The introduction of CP packages, where functionality is made available at the user interface by parameters, will tend to reduce the exibility of the interface. Unlike a package, guided by parameters, a language can be extended much more easily to accommodate new concepts and facilities. Moreover the research and development on a single CP language can be shared between many di
erent researchers working on di
erent kinds of functionality. CP language research, accordingly, maps onto the research methodology outlined above. Our research at IC-Parc is built around the ECLiPSe constraint programming language 12]. The language has provided the exibility to admit all the features described in this paper. Our research, and those of others in the community, have pushed the language in directions we never expected. The language framework, however, has enabled us to work on modelling features, new solvers, new search methods and new combinations of all these. In consequence we would advocate CP research to be carried out, as far as possible, within the framework of a coherent CP language or a family of languages.

Acknowledgements Many thanks to Carmen Gervet, Warwick Harvey and Joachim Schimpf for lots of ideas and feedback on drafts of the paper. The ECLiPSe team, including Joachim, Kish, Warwick, Andy S. and Andy C., are the people who really make the case for CP languages, by doing such a great job with ECLiPSe.

An ECLiPSe Program for The Currency Design Problem :- lib(ic). :- lib(branch_and_bound).

% For CP solver % For CP search

% +N: Number of different coins in the currency % +Max: Need exact change for anything costing between 1 and Max % ?Values: Values of the different coins in the currency % (in increasing order) % ?Numbers: The number of each type of coin needed (for the above) % -Total: The total number of coins needed - this must be minimal design_currency(N,Max,Values,Numbers,Total) :init_vars(N,Max,Values,Numbers), coins_constraints(Max,Values,Numbers,NeedCoinsList), redundant_constraints(Values,Numbers), Total #= sum(Numbers), minimize( search(Values,Numbers,NeedCoinsList), Total ).

init_vars(N,Max,Values,Numbers) :length(Values,N), Values #:: 1..Max, length(Numbers,N), Numbers #:: 1..Max. coins_constraints(Max,Values,Numbers,NeedCoinsList) :( for(Amount,0,Max), foreach(NeedCoins,NeedCoinsList), param(Values,Numbers) do gen_constraint(Amount,Values,Numbers,NeedCoins) ). gen_constraint(Amount,Values,Numbers,NeedCoins) :( foreach(Value,Values), foreach(HaveCoin,Numbers), foreach(NeedCoin,NeedCoins), foreach(Product,Products) do NeedCoin #>= 0, NeedCoin #=< HaveCoin, Product #= Value*NeedCoin ), Amount #= sum(Products). redundant_constraints(Values,Numbers) :( fromto(Values,V1|NV],NV,_]), fromto(Numbers,N|NN],NN,_]) do NV=V2|_], % If N * V1 >= V2, then you can always replace the % Nth V1 coin with an extra V2 coin N * V1 #=< V2 - 1 ). search(Values,Numbers,NeedCoinsList) :labeling(Values), labeling(Numbers), ( foreach(NeedCoins,NeedCoinsList) do labeling(NeedCoins) ). % Euro Coins Problem: % ?- design_currency(6,100,1,2,5,10,20,50],Numbers,Total). % Currency Design Problem % (allow 6 different coins, and exact change up to 100): % ?- design_currency(6,100,Values,Numbers,Total).

References 1. Cycorp: A nite domain constraint solver optimized to work with opencyc (2002) For Cyc see www.opencyc.org and for the package see \org.opencyc.constraintsolver". 2. Mller, J., Andersen, H., Hulgaard, H.: (Product conguration over the internet) citeseer.nj.nec.com/531891.html. 3. Jaar, J., Lassez, J.L.: Constraint logic programming. In: Proceedings of the 14th ACM POPL Symposium, Munich, West Germany (1987) 4. ILOG: CPLEX (2002) www.ilog.com/products/cplex/. 5. Dash: Xpress-MP (2003) www.dashoptimization.com/products.html. 6. GAMS: GAMS: The general algebraic modeling system. (Online documentation at: www.gams.com) 7. Paragon Decision Technology B.V.: AIMMS: Advanced integrated multidimensional modeling software. (Online documentation at: www.aimms.com) 8. Software, M.: MPL: Mathematical programming language. (Online documentations at: www.maximal-usa.com/mpl/) 9. Savelsbergh, M.: MINTO - Mixed INTeger Optimizer. (Online documentations at: www.isye.gatech.edu/faculty/Martin_Savelsbergh/software/) 10. Mittelmann, H.: Benchmarks for optimization software (2003) http://plato.la.asu.edu/bench.html. 11. Bockmayr, A.: MIP model for the coins problem. Personal Communication (1997) 12. Cheadle, A., Harvey, W., Sadler, A., Schimpf, J., Shen, K., Wallace, M.: ECLiPSe: an introduction (2003) www.icparc.ic.ac.uk/eclipse/reports/icparc-03-1.pdf. 13. Glover, F.: (OptQuest: The optimization process) www.decisioneering.com/spotlight/spotlight14d.html. 14. Abramson, D.: (Nimrod/O: A software environment for building high performance optimising decision support systems from computational models) www.csse.monash.edu.au/~davida/nimrodo/. 15. Smith, B.M., Brailsford, S., Hubbard, P., Williams, H.P.: The Progressive Party Problem: Integer Linear Programming and Constraint Programming Compared. In: CP95: Proceedings 1st International Conference on Principles and Practice of Constraint Programming), Marseilles (1995) 16. Moscato, P.: TSPBIB home page. www.densis.fee.unicamp.br/~moscato/TSPBIB_home.html (2000) 17. Kalvelagen, E.: On solving the progressive party problem as a MIP. Technical report, GAMS Development Corp., Washington DC (2002) www.gams.com/~erwin/ppp.pdf. 18. Nadel, B.: 9. Symbolic Computation. In: Tree Search and Arc Consistency in Constraint Satisfaction Algorithms. Springer (1988) 19. Haralick, R.M., Elliott, G.L.: Increasing tree search eciency for constraint satisfaction problems. Articial Intelligence 14 (1980) 263{313 20. Bouthoorn, P.: (AISearch) http://sal.kachinatech.com/Z/3/AISEARCH.html. 21. Hulubei, T.: (The csp library) www.hulubei.net/tudor/csp/index.html. 22. Russell, S., Norvig, P.: (CSP problems and solvers) http://aima.cs.berkeley.edu/python/csp.html#CSP. 23. de Givry, S.: (VCSP) www.inra.fr/bia/ftp/T/VCSP/docs/vcsp.txt. 24. Kask, K., Dechter, R.: A general scheme for automatic generation of search heuristics from specication dependencies. Articial Intelligence 129 (2001) 91{131

25. Larrosa, J., Meseguer, P.: Generic CSP techniques for the job-shop problem. In: IEA/AIE (Vol. 2). Volume 1416 of Lecture Notes in Computer Science., Springer (1998) 46{55 26. Minton, S.: Automatically conguring constraint satisfaction problems: A case study. Constraints 1 (1996) 7{44 27. Savelsbergh, M.: Branch-and-price: Integer programming with column generation. www.isye.gatech.edu/faculty/Martin_Savelsbergh/publications/eoo.pdf

(2002) 28. Harvey, W.D., Ginsberg, M.L.: Limited discrepancy search. In: Proc. IJCAI- Vol. 1, Morgan Kaufmann, 1995 (1995) 607{615 29. Caseau, Y., Laburthe, F., Silverstein, G.: A meta-heuristic factory for vehicle routing problems. In: Proc. Principles and Practice of Constraint Programming. (1999) 144{158 30. Freuder, E., Wallace, R.: Partial constraint satisfaction. Articial Intelligence 58 (1992) 31. Selman, B., Levesque, H.J., Mitchell, D.: A new method for solving hard satisability problems. In: Proceedings of the Tenth National Conference on Articial Intelligence, AAAI Press (1992) 440{446 32. Minton, S., Johnston, M.D., Philips, A.B., Laird, P.: Minimizing conicts: a heuristic repair method for constraint satisfaction and scheduling problems. Articial Intelligence 58 (1992) 33. Michel, L., Van Hentenryck, P.: Localizer. Constraints 5 (2000) 41{82 34. El Sakkout, H., Wallace, M.: Probe backtrack search for minimal perturbation in dynamic scheduling. Constraints 5 (2000) 359{388 35. Laburthe, F., Caseau, Y.: SALSA: A language for search algorithms. Constraints 7 (2002) 255{288 36. de Givry, S., Jeannin, L.: ToOLS: A library for partial and hybrid search methods (2003) Presented at CPAIOR'03, Montreal, www.crt.umontreal.ca/cpaior/article-degivry.pdf. 37. Wallace, M.G.: Search in AI - escaping from the CSP straightjacket. In: Proc. 14th European Conference on Articial Intelligence, IOS Press (2000) 770{776