On the Cooperation of the Constraint Domains H, R and FD in CFLP

This paper tackles foundational and practical issues concerning the efficient use of constraints in CF LP languages and systems. Both the CLP and the CF LP schemes must be instantiated by a parametrically given constraint domain D which provides specific data values, constraints based on specific primitive operations, and a dedicated constraint solver. Therefore, there are different instances CLP (D) of the CLP scheme for various choices of D, and analogously for CF LP , whose instances CF LP (D) provide a declarative framework for any chosen domain D. Useful ‘pure’ constraint domains include the Herbrand domain H which supplies equality and disequality constraints over symbolic terms; the domain R which supplies arithmetic constraints over real numbers; and the domain F D which supplies arithmetic and finite domain constraints over integers. Practical applications, however, often involve more than one ‘pure’ domain, and sometimes problem solutions have to be artificially adapted to fit a particular choice of domain and solver.

Combining decision procedures for theories is a well-known problem, thoroughly investigated since the seminal paper of Nelson and Oppen (Nelson and Oppen 1979). In constraint programming, however, the emphasis is placed in computing answers by the interaction of constraint solvers with user given programs, rather than in deciding satisfiability of formulas. The cooperative combination of constraint domains and solvers has evolved during the last decade as a relevant research issue that is raising an increasing interest in the CLP community. Here we mention (Baader and Schulz 1995;Benhamou 1996;Monfroy 1996;Monfroy 1998;Granvilliers et al. 2001;Marin et al. 2001;Hofstedt 2001;Monfroy and Castro 2004;Hofstedt and Pepper 2007) as a limited selection of references illustrating various approaches to the problem. An important idea emerging from the research in this area is that of ‘hybrid’ constraint domain, built as a combination of simpler ‘pure’ domains and designed to support the cooperation of its components, so that more declarative and efficient solutions for practical problems can be promoted.

The first aim of this paper is to present a computational model for the cooperation of constraint domains in the CF LP context, where sophisticated functional programming features such as higher-order functions and lazy evaluation must collaborate with constraint solving. Our computational model is based on the CF LP scheme and goal solving calculus recently proposed in (López-Fraguas et al. 2004;López-Fraguas et al. 2007), which will be enriched with new mechanisms for modeling the intended cooperation. Moreover, we rely on the domain cooperation techniques proposed in our previous papers (Estévez-Martín et al. 2007;Estévez-Martín et al. 2007;Estévez-Martín et al. 2008), where we have introduced so-called bridges as a key tool for communicating constraints between different domains.

Bridges are constraints of the form X #== di,dj Y which relate the values of two variables X :: d i , Y :: d j of different base types, requiring them to be equivalent. For instance, X #== int,real Y (abbreviated as X #== Y in the rest of the paper) constrains the real variable Y :: real to take an integral real value equivalent to that of the integer variable X :: int. Note that the two types int and real are kept distinct and their respective values are not confused.

Our cooperative computation model keeps different stores for constraints corresponding to various domains and solvers. In addition, there is a special store where the bridge constraints which arise during the computation are placed. A bridge constraint X #== Y available in the bridge store can be used to project constraints involving the variable X into constraints involving the variable Y, or vice versa. For instance, the R constraint RX <= 3.4 (based on the inequality primitive <= -’less or equal’ -for the type real) can be projected into the F D constraint X #<= 3 (based on the inequality primitive #<= -’less or equal’ -for the type int) in case that the bridge X #== RX is available. Projected constraints are submitted to their corresponding store, with the aim of improving the performance of the corresponding solver. In this way, projections behave as an important cooperation mechanism, enabling certain solvers t

…(Full text truncated)…