- Email: [email protected]
Executing Constraint Solver Collaborations
URL: http://www.elsevier.nl/locate/entcs/volume16.html 22 pages
An Environment for Designing/Executing Constraint Solver Collaborations Eric Monfroy CWI Kruislaan 413 1098 SJ Amsterdam, The Netherlands e-mail: [email protected]
Abstract
Constraint programming is a paradigm based on the notion of constraints and mechanisms for their resolution. Thus, the key point of this class of languages is not only to oer a wide class of constraints for declarativity reasons, but also to treat them eciently. For this purpose, the need for collaboration i.e., combination and cooperation of solvers is widely recognized. This new concept enables to solve problems that cannot be tackled or eciently solved with a single solver. Furthermore, the demand for integrating symbolic mathematical tools into automated deduction system has signicantly increased. In order to meet these motivations we propose BALI, an environment for designing/executing solver collaborations. BALI is a heterogeneous distributed collaborative problem solving system. It consists of a solver collaboration language and a host language. By providing several construction primitives (as concurrency, parallelism and sequentiality) and several combinators for their composition (as iterator or guarded control), the solver collaboration language enables to build complex solvers from elementary heterogeneous ones. The solvers are encapsulated in order to federate their dierent knowledge representations. We thus obtain agents that communicate and collaborate with each other. The host language, which is a constraint programming language, furnishes several strategies for manipulating constraints and executing solver collaborations i.e., agent collaborations.
1
Introduction
The need for cooperation and combination (i.e., collaboration) of solvers is widely recognized. The general view consists in doing several solvers collaborate in order to process constraints that cannot be solved (or eciently solved) by a single solver. Informally combination 16,11,17] focuses on building a solver for the union of theories, whereas cooperation 12,15,7] concerns communication problems between solvers devoted to a single domain. In this
c 1998 Published by Elsevier Science B. V.
Monfroy case the collaborating \elementary" solvers share the constraints according to their specicities. Cooperative distributed problem solving has also been studied in A.I. 20,2], in the eld of knowledge processing systems 1], and for integrating symbolic mathematical tools 8] in automated deduction. Designing new solvers is usually a tedious task. Therefore it is important to focus on re-usability and integration issues. Some systems (like the cooperative architecture of Marti Rueher 12] and CoSAc 15]) have already been proposed for implementing the three notions of solver integration, solver cooperation and re-usability. Although they signicantly ease integration and cooperation, they require good knowledge of the basic level components of the systems (constraint manager, communication manager, . . . ) for adding new solvers. Moreover, they provide only one paradigm (asynchronous communication for 12], synchronous communication for CoSAc) and are restricted to cooperation: hence they do not allow the user to build all the collaborations he would like. Furthermore, they do not provide the user with high level control primitives to compose the solvers. This lead us to propose a new Binding Architecture for soLver Integration (BALI) which enables to make collaborate heterogeneous solvers by encapsulating them into agents. In this paper, we will use either agent or solver since we stress more on the meaning of the knowledge return by an agent than on its representation. Furthermore, we consider than the solver encapsulation (i.e., our agent) provides a translator that enables the agents to communicate with each other. BALI is a domain independent environment for specifying and executing solver collaborations integrating several paradigms. BALI consists of a solver collaboration language and a host language. The rst one is a glass-box mechanism which enables linking black-boxes tools i.e., the solvers (or agents). It permits to build agent collaborations (also called solver collaborations i.e., solver cooperation or solver combination) by composing agent solvers thanks to various collaboration primitives: sequentiality, parallelism, and concurrency. Sequentiality means that a solver/agent E2 will execute on the constraint store returned by a solver/agent E1 . When several agents are working in parallel, the constraint store C is split into several sub-stores with respect to the admissible constraints of each solver. Then the results of all the solvers and the unprocessed constraints are gathered together to constitute a new store equivalent to C . Concurrency is interesting when several solvers can execute on similar parts of the constraint store but with dierent methods or strategies. Then the result of the rst solver S which terminates and the constraints not processed by S are combined to constitute a new equivalent store. The results of the other solvers are not taken into account, and the corresponding agents are even stopped. These concepts can be connected thanks to combinators (iterators, guarded control, . . . ) in order to realize more complex solver collaborations. For example it is possible to repeat a collaboration of solvers till no more information is extracted from the store. 2
Monfroy The host language is a constraint programming language and possibly a constraint logic programming language 10,18,9,5] which enables to execute the designed collaborations with respect to three strategies called solving strategies . The rst strategy consists in determining the satisability of the constraint store each time a new constraint occurs (\incremental use of a solver"). The alternative to this method is to solve the constraint store when reaching a nal state (e.g. the end of resolution for logic programming). These solving strategies depend on the solvers and their complexity: for practical reasons it is important to test satisability as soon as a new constraint is added to the store. But for expensive in time solvers this method introduces a signicant extra cost and it is better to launch them only once. Another possible strategy is to allow the user to trigger the solvers when he needs to, for example to test the satisability after a lots of constraints have been settled. Furthermore, BALI allows several solver collaborations, associated to dierent solving strategies to coexist in a single system. For example solver S1 can be used incrementally while S2 only execute at the end and S3 is always triggered by the user. A prototype showed the feasibility of our approach and its interest in practice as well. More details about BALI, its implementation, and examples can be found in 14]. We have determined the primitives required in the collaboration language of BALI after some discussions with potential users about their needs, and after some studies of the cooperation (as well as combination) mechanisms of some working systems. Thus, although most of the current realizations are related to non-linear constraints, the eld of potential applications of BALI is wide. The paper is organized as follows. In Section 2 a collection of denitions is given. Then we introduce the notions of agent solver, solver ordering, as well as constraint system enrichment which enables to extend the scope of a solver. In Section 3 we assume that we have several agent solvers on the same constraint system enrichment, and that we want to combine them and to make them cooperate (Section 3.2). Then (Section 3.3) we provide primitives to build solver/agent collaborations from agent solvers. In order the designed solver to be an agent solver, some restrictions are presented: in fact each agent solver must dene an ordering included in a \global" Noetherian ordering over the constraint system. Section 3.4 describes a grammar to compose the construction primitives. The associated language i.e., the solver collaboration language of BALI, provides instructions to control the construction of the solver collaboration. The reader should be aware that the construction primitives of the solver collaboration language and the control primitives of the host language are issued from experiments and user requirements. An operational semantics of the solver collaboration language is detailed in Section 3.5. This semantics is based on transitions rules between congurations composed of a solver expression and a constraint store. Section 4 is devoted to the host 3
Monfroy language and an operational semantics describing the mechanisms associated to each application strategy of the solver collaborations. In order to illustrate the ease to design a solver/agent collaboration in BALI, an application (see Section 5) is detailed. In this section we simulate the solver collaboration and the strategies of CoSAc, a system for cooperating solvers over non-linear polynomial constraints. Finally (Section 6) we compare BALI to existing systems and we present the major directions for future work.
2 The basic framework In this section we introduce several concepts and denitions that will be used in the rest of the paper. We adopt a general denition of a constraint system, an agent solver and its admissible constraints i.e., the constraints it handles. These notions are applied in Section 3 for describing a solver collaboration language, and in Section 3.5 for detailing its operational semantics. 2.1 Computation domain The general scheme of constraint programming (CP) denes the class of CP(X ) languages: each CP language is obtained by instantiating the parameter X which is a quadruple representing a constraint system. Denition 2.1 A constraint system is a quadruple ( D V L) where: - is a many-sorted rst-order signature given by a set of sort symbols S , a set of function symbols F, and a set of predicate symbols P , - D is a -structure whose domain is the union S of the pairwise disjoint domains jD j for each sort s of S (jDj = 2S jD j), - V is the of pairwise disjoint nonempty sets V of S -sorted variables, S union V V = 2S - L is the closure of a non-empty set of atomic ( V )-formulas (the set of quantier free rst order formulas built over the signature and the variables of V ) by conjunction and disjunction. L is called the set of constraints. An atomic ( V )-formula of L is called an atomic constraint (or primitive constraint ). In the following, the many-sorted nature of a constraint system will be exploited for extending the use of solvers on constraints systems dierent than their own ones. A sort is simply the set of its elements and s1 s2 : : : range over the set of sorts. V denotes the subset of V containing the variables of sort s , and jD j denotes the domain associated to the sort s i.e. the subset of jDj on which variables of sorts s can take their values. In general, L is strictly included in L( ) (the set of all ( V )-formulas closed under conjunction and disjunction). We denote by CS the set of constraint systems. For any signature , let D be a -structure and L be the set 4 si
si
i
si
si
i
si
si
si
i
si
i
i
V
Monfroy of constraints. Then, a primitive constraint (also called atomic constraint ) has the form ( 1 n ) where is a predicate symbol of P and 1 n p are terms. L refers to the set of primitive constraints and 1 2 range over the set Lp. A constraint is a rst order formula built from primitive constraints and the logical connectives ^ and _. L^ denotes the set of conjunctions of primitives constraints, L the set of constraints and 1 2 range over L. The projection operator i ( ) denotes the -th disjuncts of in DNF ( i( ) 2 L^), i ( ) denotes without the disjunct i( ) and #( ) represent the number of disjunct of . The notation ( ) refers to the set of variables in , and 1 2 range over the set of variables. We call jDj the domain of computation of ( D L). To denote that is valid in the structure D we write D j= . c
p t :::t
p
t :::t
c c :::
C
C C :::
C
C
i
C
C
C
C
C
C
C
V ar C
x x :::
V
F
F
2.2 Agent Solvers Intuitively, an agent solver is an algorithm which transforms a constraint C into a new constraint C 0 which is \simpler" than C , but equivalent to C in the structure D. Furthermore, the repeated application of this algorithm always terminates and reaches a xed point which is called in solved form . Denition 2.2 An agent solver (or solver for short) on a constraint system ^ ! L such that: 8C 2 C S = ( D V L) is a computable function S : L L^ D j= S (C ) , C and 8C 2 L^ 9n 2 N S n+1 (C ) = S n (C ) We assume that for each agent solver S and each constraint C , S (C ) is in disjunctive normal form (DNF) i.e. we assume that the output of a solver is automatically Wtransformed into DNF. We also assume that if C is in L n L^, then S (C ) = i#(=1C ) S (i (C )) i.e. disjunctions are treated by a backtracking mechanism. The notion of agent solver is used to dened a notion of ordering on constraints associated to a solver. Intuitively this means that the output of an agent solver is considered \smaller" (by denition) than its input i.e. our notion of a solver can be viewed as simplication. Denition 2.3 Let S be an agent solver on the constraint system C S . Then, the relation S is dened on C S as follows: C1 S C2 if 9n 2 N s.t. C1 = n S (C2 ). Proposition 2.4 The relation S dened by S on the constraint system C S is a quasi-ordering. Furthermore, the related ordering
Monfroy itively we require that the sorts (resp. variables) of S are also sorts (resp. variables) of . We say that a many-sorted signature 1 is included in a many-sorted signature 2 (denoted by 1 2 ) if S1 S2 , F1 F2 , and P1 P2 . 1 is strictly included in 2 (denoted by 1 2) if 1 2 and either S1 S2 , or F1 F2 , or P1 P2 . Denition 2.5 Let Emb be two many-sorted signatures with Emb . and DEmb ) be a S structure (resp. a Emb structure) with jDj = S letjDDs(resp. s j (resp. jDEmb j = s 2SEmb jDEmb j). DEmb is an embedding of D if: s 2S s s 8 i 2 SEmb jDEmb j = jD j and the (injective) identity mapping from jDEmb j to jDj is a morphism from DEmb to D We can remark that if DEmb is an embedding of D then DEmb ( 1 n) = D ( 1 in Emb n ) and DEmb ( 1 n ) = D ( 1 n ) holds for all and 1 n in jDEmb j. We use the notation DEmb Struct D for DEmb is an embedding of D, and DEmb Struct D if DEmb is a strict embedding of D (i.e. Emb or jDEmbj jDj). Denition 2.6 A constraint system Emb = (Emb DEmb Emb LEmb) is an embedding of the constraint system = ( D L) if DEmb Struct D and Emb . If Emb is an embedding of , we also say that is an enrichment of Emb. Denition 2.7 Let = ( D L) be a constraint system, be a solver on S = (S DS S LS ) and be a primitive constraint of . Then is a admissible primitive constraint over if 2 LS and S is an embedding of . Obviously we have: D j= ( ) , . Intuitively, this means that the constraint system of is \smaller" than the one of but that all the sorts used in are completely contained in . The second condition on inclusion of set of variables (see denition 2.6) insures that the answer of the solver is in the constraint system of . Hence these restrictions ensure that a solver does not lose solutions when applied to a constraint system enrichment. Example 2.8 This rst example shows the use of a solver on 0 to solve a constraint on a constraint system enrichment of 0. Let = ( D L) be a constraint system, where jDj is composed of the integers N and of the lists of integer N . Let N s and N be the sorts of . Let + : N s N s ! N s , : N s N s ! N s , : Ns N ! N , : ! N , all the symbols of N (0,1,2,. . . ), and the empty list be the N s be variables of sort N s symbols of . Let be a variable of sort N and and f g 2 . 1 dened by (3 1 2]) = ^ ( ) = ^ +2 = 1 and 2 dened by + + 2 = 4 are constraints of L. Let be a solver on 0 = (0 D0 0 L0) with jD0j = N and D0 interprets + and of 0 as usual on N . Since D0 Struct D and 2 is a primitive constraint of L0 then 2 6 CS
CS
i
i
i
i
s
i
i
f
f
x :::x
p
x :::x
p
x :::x
x :::x
p f
x :::x
CS
CS
V
V
CS
V
V
CS
CS
CS
CS
CS
V
V
S
c
CS
CS
S
c
c
CS
CS
S c
CS
c
S
c
c
CS
c
S
CS
CS
CS
V
List
List s
cons
car
CS
List s
List s
List s
L
L X Y
V
c
CS
List s
c
X
cons
Y
X Y
L
car L
X
X
S
V
c
c
Monfroy is S admissible over
CS
.
Example 2.9 This example illustrates the restrictions of the Denition 2.7. Let = ( D L) be a constraint system, with C = jDj, let f+ 0 1g be symbols of and S = fC s g. Let be a solver on 0 = (0 D0 0 L0) with the symbols f+ g in , R = jD0j and S = fRs g . Let be the constraint 2 + 1 = 0 on with 2 . Although is in L0, is of sort admissible and will not be handled by . This is due C s . Then is not to the restriction on constraint system embedding: it prevents to execute a solver on a constraint whose all sorts (contained in the functions, predicates and variables of the constraint) are not in the constraint system of the solver. We can see on this example that: if is solved with , then has no solution and if is solved with a solver on C then has two solutions and . CS
V
S
X
V
X
V
c
0
CS
c
CS
c
X
S
S
c
S
c
c
c
i
i
The notion of admissible primitive constraint is extended to all constraints in the following way: S ( ^ 0) = S ( ) ^ S ( 0). If is a admissible primitive constraint S ( ) = , else S ( ) = >. Obviously we have: D j= ( S ( )) , S ( ). Similarly we dene S ( ), the non-admissible constraint, of over by: S ( ^ 0 ) = S ( ) ^ S ( 0). If is not a admissible primitive constraint S ( ) = , else S ( ) = >. S
S
C
c
c
c
C
c
C
c
c
C
c
S
c
C
c
c
C
S
C
C
c
CS
S
c
Property 2.10 If
is a solver on C SS , then S ? dened as follows is a solver on every enrichment C S = ( D V L) of C SS : 8C 2 L^ S ? (C ) = S (S (C )) ^ S (C ) S
Example 2.11 (Example 2.8 continued) 2 is the admissible constraint of c2
over
CS
, and
c
X
S
+ 2 = 1 is the admissible constraint of S
c1
over
CS
.
3 Solver/Agent Collaborations In this section we consider several agent solvers working on embeddings of a single constraint system ( is an enrichment of all the constraint systems of the solvers). These solvers are \basic" solvers (or \elementary" solvers) and we study how they can collaborate together on the enrichment to build \complex" solvers called solver collaborations or agent collaborations. The dierences between cooperation and combination of solvers exposed in Section 1 are formally described. Then the primitives to compose the agent solvers (Section 3.3) and the language (Section 3.4) that allows one to build these collaborations (cooperation or combination of solvers) are examined. We then dene the operational semantics to the solver collaboration language. But rst some criteria for termination have to be given they are used to prove that solver/agent collaborations are agent solvers. 7 CS
CS
CS
Monfroy 3.1 Compatibility and Termination For proving the termination of solver collaborations, we may need to embed all solver orderings into a \global" Noetherian ordering <. This ordering can be viewed as a complexity measure (such as the number of variables in the constraint, or the width of intervals) for practical applications. The notion of < compatible solver is introduced in order to dene the \compatibility" between solvers. Denition 3.1 Let C S = ( D V L) be a constraint system, S be a solver on C S and < be a Noetherian ordering on a superset of L. Then S is < compatible if
Monfroy (S2 DS2 S2 LS2 ) (with f+ g S2 , and jDS2 j = N ). Then DS1 Struct D and DS2 Struct D and thus 1, 2 can be combined on .
V
S
S
CS
The tuple ( 1 n ) is a solver collaboration if it is either a solver cooperation or a solver combination. So that a solver collaboration could be an agent solver w.r.t. denition 2.2, all the solver orderings have to be included in a \global ordering", and the \global constraint system" has to be an enrichment of all the solver constraint systems: this insure a compatibility between the solvers. These conditions are detailed formally in next sections. S :::S
3.3 Collaboration Primitives The composition of agent solvers require some mechanisms called collaboration primitives. They dened concepts that rst enable to apply some solvers on pieces of the constraint and then permit to re-create a constraint equivalent but simpler than the input one. BALI allows for three collaboration primitives: sequentiality, parallelism, concurrency. Each one corresponds to a special paradigm and enables dierent kinds of collaboration. For each of these primitives, we give an informal denition, a formal denition, and restrictions that make the collaborations be agent solvers in the sense of denition 2.2. 3.3.1 Sequential Solvers/Agents Sequential solvers enables to execute an agent on a constraint store which is the result of another agent. Denition 3.6 Let S1 (resp. S2 ) be a solver on C S1 (resp. C S2 ) and let C S = ( D V L) be an enrichment of C S1 and C S2 . Then S1 S2 is a sequential composition of solvers if: 8C 2 L ^
( ) =
S1 S2 C
_
#(S1? (C)) i=1
?
( ( ?( )))
S2 i S1 C
Proposition 3.7 Let S1 and S2 be two agent solvers on C S1 and C S2 (respectively) and let C S be an enrichment of C S1 and C S2 . Then S1? S2? is an agent solver on C S if there exists a Noetherian ordering < on C S such that ? ? S1 and S2 are < compatible. Moreover, S1 S2 is < compatible.
3.3.2 Parallel Solvers/Agents This second primitive allows one to execute several agents in parallel. The constraint store is split into disjoint subproblems w.r.t. the admissible constraint of each solvers. When the last agent terminates, the result of all solvers and the unprocessed constraints are gathered. This primitive is useful for processing equalities and inequations with different solvers, applying specialized solvers on parts of the store (e.g. quadratic solver), or for treating simultaneously constraints over disjoint sorts, . . . 9
Monfroy Two conjunctions of primitive constraints C = ^ni=1 ci and C 0 = ^mj=1c0j are disjoint i 8(i j ) 2 1 :: n] 1 :: m] ci 6= c0j Denition 3.8 Let S1 : : : Sn be n solvers on respectively CS1 : : : CSn and
let CS = ( D V L) be an enrichment of each CSi. Then S1? : : : Sn? execute in parallel on CS , denoted S1? k : : : k Sn? if: 8(i j ) 2 1 n]2 s.t. i 6= j , S (C ) and 8C 2 L^ S1? k : : : k Sn? (C ) = W Sj (C ) are? disjoint for all C ^2n L^, (and ? (k1 :::kn )2 1#(S1 (C ))]::: 1#(Sn? (C ))] i=1 ki Si (C )) i
Proposition 3.9 S1? k : : : k Sn? is an agent solver on CS if there exists a
Noetherian ordering < s.t. all the agent solvers Si are < compatible. Moreover, S1? k : : : k Sn? is < compatible. 3.3.3 Concurrent Solvers/Agents This last primitive deals with the concept of concurrency and provides a nondeterministic choice function. The constraint store is split into sub-problems (which overlap or not) w.r.t. the admissible constraints of each solvers. The result of concurrent solvers is not a combination of the answers of all solvers, but the output of a single solver and the non-admissible constraint of this solver. Furthermore, concurrent solving is parameterized by functions. Each of these functions determine how the resulting store is chosen. This choice is made at run-time by a function associated to . returns the constraint satisfying some required conditions w.r.t. the quickest solver and the form of the solutions. A standard function is basic which returns the rst agent which nishes. But more complex functions are also possible such as the one which selects the rst solver which returns a constraint in solved form. The major use of this primitive is the following. When the user has several similar solvers on disposal, he generally does not know which one is the best suited for his problem. So he can execute all the solvers concurrently and keep the solution of the quickest one. This is still more signicant when the agents are expensive in time as in the case of Grobner bases computation or Diophantine equation solving. Denition 3.10 Let S1 : : : Sn be n solvers on respectively CS1 : : : CSn
and let CS = ( D V L) be an enrichment of each CSi. Then S1? : : : Sn? execute concurrently, denoted (S1?? : : :?Sn? ) if: 8C 2 L^ (S1?? : : :?Sn? )(C ) = (S1?(C ) : : : Sn? (C )) where is a function associated with which determines at run-time which Si(C ) will be the answer of (S1?? : : :?Sn? )(C ) (see Section 3.4 for operational details about functions). Proposition 3.11 (S1? ? : : :?Sn? ) is an agent solver on CS if there exists a
Noetherian ordering < s.t. S1 : : : Sn are < compatible agent solvers. Moreover, (S1? ? : : :?Sn? ) is < compatible. 10
Monfroy 3.4 Solver/Agent Collaboration Language It is now possible to build complex solvers on a constraint system CS using the collaboration primitives introduced in the previous section. The language for solver collaboration of BALI manipulates expressions describing complex collaborations of agents. The construction primitives (sequentiality, parallelism, concurrency) introduced in Section 3 are composed using the combinators (iterators, guarded control, . . . ) introduced in this section. First the agent collaboration language is explicated. A program written in this language describes a solver collaboration (operational point of view) also called a solver expression (algorithmic point of view). Id 2 identifiers S 2 solvers 2 conditional selection Col ::= Id = E E ::= } j Id j B j E1 E2 j EP j E0 :: on B then E1 else E2 j repeat(E ) j (EC ) B ::= S j S k B EP ::= E j E k EP EC ::= E j E ?EC Fig. 1. Syntax of the solver/agent collaboration language of
BALI
The language is described by the grammar of Figure 1. In the following, we will denote by E (resp. B, . . . ) the set of solver expressions that can be derived from the non terminal E (resp. B , . . . ). We call constraint store the current conjunction C of basic constraints. C denotes the set of contexts and S tores the set of constraint stores. } is the identity solver, it is dened as follows: } : S tores ! S tores and }(C ) = C . The identiers Id are names for solver expressions. They are useful for two main purposes: rst, several solver collaborations can act in the host language depending on the strategies, and second, solver expressions can be collected in a library and used as it or as part of an expression. The Col rule allows for naming solver expressions. S represents a basic solver (or elementary solver ), this means that this solver cannot be dissociated. B is either a basic solver or some basic solvers working in parallel \ k ". B is at the opposite of EP which is either a solver expression or some solver expressions executing in parallel. EC is similar to EP but with the concurrency paradigm \ ? ": the result of EC depends on the functions. These functions are conditional selection of concurrency. They are associated with functions which examine the context to choose, at run-time, the basic solver (resp. the expression of basic solvers from B) that will return the constraint store after the execution of several solvers (resp. expression of solvers) in concurrency. If no solver returns a constraint that 11
Monfroy satises the function, the previous constraint store is kept. The prole of the functions is : (E C )n ! C where each context from C is the result of the execution of the solver associated in the Cartesian product and n is the number of solver expressions working concurrently. The prole of the functions is : E n ! E \ " denotes the sequential composition: E1 E2 means E2 will execute on the context returned by E1. repeat(E ) is an iterator: E is repeated till the constraint store reaches a xed point i.e. till E n+1(C ) = E n(C ). The last control primitive is \E0 :: on B then E1 else E2 ". This primitive executes E1 if the guard E0 is satised, else E2 . The guard is determined by the last executed basic solver expression (in B). So if E0 terminates with B , then E1 is executed, else E2. Property 3.12 A collaboration of agent solvers is an agent solver if there exists a Noetherian ordering < on CS s.t. all the agent solvers occurring in the collaboration are < compatible. 3.5 Operational Semantics In this section we present an operational semantics for the solver/agent collaboration language of BALI. First some operations on the constraint store are needed in order to simplify the constraints. These operations are domainindependent and can be viewed as a garbage collector. Then a complete description of the operational semantics is given. It describes the behavior of the system by means of transition rules from state to state. 3.5.1 Operations on the Constraint Store The constraint store C is updated after each application of a solver S (using the results of the solvers, and the non S -admissible constraints) and transformed in DNF. Since the solvers work on conjunctions of constraints, the disjunction are managed by a backtracking mechanism using a stack (see Section 3.5.2). These operations are extended to solver expressions, and detailed in the operational semantics in section 3.5. Idempotency C ^ C ! C Bottom C ^? ! ? Top C ^> ! C
Fig. 2. Simplication rules on the constraint store
Rules of Figure 2 are required to simplify the store: they are applied modulo the associativity and commutativity axioms. The simplication rules are universal and domain-independent. But the Idempotency rule for example can be extended to take the semantics of the computation domain into account: 12
Monfroy then it will remove more redundancies (for example on R , ^ ! ). Hence the user can complete the simplication system to take the domain into account. Remark 3.13 In order to obtain a kind of satisability procedure collaboration, the user can duplicate these rules for disjunctions. For example a rule _-Idempotency: _ ! removes duplicated solutions, or a rule _-Top: _ > ! > concludes to the satisability of a disjunction of constraints if at least one of the constraint is >. X
a
a
X >
X > a
C
C
C
C
Propagation
X
2 V d 2 (D L)
X = d
^ C ! C d=X ]
Fig. 3. Propagation rule on the constraint store
The Propagation rule (Figure 3) propagates the value of a variable to the whole constraint store. The application of simplication and propagation rules modulo the associativity and commutativity axioms transforms into a normal form ( ) ofWthe store. This normal form is not unique. Since ( ) is in DNF, ( ) = ni=1 i and the projection operator can be used on it. Remark 3.14 Since they perform syntactical transformations, simplication and propagation rules can be seen as generic solvers over all constraint systems. C
nf C
nf C
nf C
C
3.5.2 Solver/Agent Collaboration Semantics In this section we give an operational semantics for solver collaborations. We present the semantics such that inessential details are abstracted and the execution of the solvers and the updates of the constraint store are highlighted. The behavior of the system is expressed by transition rules that are divided into two classes: the transformation rules, and the auxiliary rules. We represent the situation of a constraint C waiting to be processed by the solver expression E by the pair hE C i. We shall dene a transformation between such pairs of congurations based on the execution of a single basic solver. Hence a single step relation between two congurations B hE C i ! hE C i means the execution of a basic solver B from E on the constraint store C leads to the conguration in which it remains to execute E on C . The transformations ! are labeled with the name of the solver B from B involved in this step. They describe visible actions on the conguration: the action of the solver B modies the current constraint store. As stated in section 2.2, the input of a solver is a conjunction of primitive constraints (even if formally we consider they can handle disjunctions), and its output can be a disjunction (non determinism). A backtrack mechanism allows one to deal with constraint disjunctions. This mechanism uses a stack which memorizes congurations that will be evaluated when backtracking. 13 0
0
0
0
Monfroy Thus, a conguration stack and a current conguration h i compose the current state which is represented by :h i ( :h i or h i if the stack is empty). The usual operations on stacks and a simplication operation are dened for the conguration stack (Figure 4). P
E C
P
E C
P
E C
E C
Push P ush(P hE C i) ! P:hE C i Pop P op(P:hE C i) ! P :hE C i Simplify P:hE >i ! P Fig. 4. Operations on the conguration stack
The transformation between congurations is extended to transformation between states: B :h i ! :h i Hence the operational semantics associates with each possible state the new state obtained by applying the solver (from B) of the current conguration to the current store. If returns a disjunction of constraints , h 1( )i becomes the current conguration and h 1 ( )i is pushed on the stack. The other class of transition rules, the auxiliary rules , do not modify the constraints store. They either output the current constraint store (printing of the solutions for success and next) or performs the backtrack mechanism i.e. in case of fail, they exchange the current conguration with a conguration of the stack (for example backtrack). Constraint solving is expressed by sequence of transitions, called derivations : h 1 1i = :h i !t1 t!1 i:h i ii !t t!1 :h} ni = h} ni A state with an empty stack and a current conguration containing the identity solver is called a nal state. A derivation is successful if at least one of the states is h} i with 6= ? or :h} i with 6= ?. In the rst case the transition (auxiliary rule) applied after this state is labeled with success and leads to the special state success. In the second case the transition applied after this state is labeled with next. If a derivation is not successful, we say that it is failed. The answer constraint is the disjunctive constraint whose disjuncts are all the constraint stores on which a next or success transformation has been applied during the derivation. The semantics is given in SOS style 19] (Structural Operational Semantics). Figure 5 shows the auxiliary rules while Figure 6 describes the transformation rules. We have seen how to build complex agent using the solver collaboration language of BALI. In Section 4 we present a way to integrate the designed solvers in a constraint programming language i.e. the host language of BALI. 14 P
E C
P
0
0
E C
0
B
C
0
E
E C
n
P
C
:::
E C
C
i
P
P
E C
C
0
E
C
C
i
:::
C
n
P
C
C
Monfroy fail
h ?i fail ! fail E
backtrack
h
P: E C
next
i:h
?i backtrack ! h 1 ( ) i : h 1 ( )i 6= ? next i : h} i ! h 1 ( )i : h 1 ( )i 6= ? success h} i ! success E1
P: E
C
E
C
C
h
P: E C
success
0
C
P: E
C
0
E
C
0
C
C
Fig. 5. Auxiliary rules 4
Host Language
In this section we propose a host language which allows executing the solver collaboration designed in the previous section. Furthermore, the host language provides three solving strategies i.e. strategies to apply the solvers/agents. Thus, as mentioned in Section 1, we can associate a solver collaboration to each solving strategy of the host language. Hence several solver collaborations can be applied for a single application. The host language is not necessarily a LP language, but we illustrate the strategies and their operational semantics on a Prolog like host language. Thus, by combining solver collaborations (Constraint Programming: CP) and a Logic Programming host language (LP), we obtain a Constraint Logic Programming (CLP) language i.e. CP+LP=CLP. Thus, we describe a CLP system which involves several solvers. In the following we assume that solver collaborations are agent solvers. Thus, for sake of simplicity, we will often write solver or agent, instead of solver/agent collaboration or agent solver. There are three strategies for the application of agents. The rst one consists of an \incremental" solver Sinc : this means that Sinc is run each time a new constraint is added to the store. For each new constraint, the consistency of the store is tested w.r.t. Sinc , and the store is also simplied by Sinc . The second strategy executes the solver S n when the initial goal has been completely processed. In the last strategy the user decides when the solvers are triggered. For this purpose he has on disposal a set of solver symbols Suser = fSu u g that can be inserted in the bodies of the predicates as usual atoms. \Incremental" strategy tries to detect as soon as possible the failure cases. Thus, inc is typically a fast procedure (such as interval propagation or Gaussian elimination) since it is often applied during computation. In the other hand, n is usually a slow solver that is too expensive in time (such as Grobner bases computation, quantier elimination, completion procedure) to be launched each time a new constraint is encountered. It can also be a solver 15 i
S
S
:::S i
Monfroy sequential solve
hS C i ! h} nf (S (C ))i P :hS E C i ! P:hE 1 (nf (S (C )))i : hE 1 (nf (S (C )))i S
?
S
?
parallel solve
?
hE1 C i !!1 h} C1 i : : : hE C i !! h} C i W ^ (C )i : hE V (C )i P :hE1 k : : : k E E C i 1 ! P:hE =1 =1 1 where j 2 1 n], k 2 1 #(S (C ))] and fk1 : : : k g 6= f1 : : : 1g. ? B
? Bn
n
B k:::kBn
n
jkj
n
n
n i
ki
i
i
? j
j
on then
i
n
hE0 C i !! h} C i P :hE0 :: on B then E1 else E2 E C i ! P:hE1 E 1 (C )i : hE1 E 1 (C )i ?
B
0
B
on else
0
0
hE0 C i !!1 h} C i B1 6= B2 P :hE0 :: on B2 then E1 else E2 E C i !1 P:hE2 E 1 (C )i : hE2 E 1 (C )i ? B
0
B
repeat
0
0
hE0 C i !! h} C i C 6= C P :hrepeat(E0 ) E C i ! P:hrepeat(E0 ) E 1 (C )i : hrepeat(E0 ) E 1 (C )i ?
B
0
0
B
stop repeat
0
0
hE0 C i !! h} C i P :hrepeat(E0 ) E C i ! P :hE C i ?
B
B
basic concurrent solve
hE C i !! h} C i P :h(E1 ? : : :?E ) E C i ! P:hE 1 (C )i : hE 1 (C )i ?
i
B
n
B
0
0
0
concurrent solve hE C i !! h} C i (E1 (C ) : : : E (C )) = E (C ) P :h(E1 ? : : :?E ) E C i ! P:hE 1 (C )i : hE 1 (C )i ?
B
0
i
n
B
n
0
i
0
Fig. 6. Transformation rules
which aims at giving a special form at the solution (i.e. a more readable solution for the user as normalizing procedures). Thus, it is better to launch this solver only once, after the goal has been processed. The S are applied when the user knows the hard points of its program (when \large set" of constraints are stated for example) and where the inconsistencies can appear. So he prefers to test satisability before going further on. The second kind of application of \user solvers" is the need of solutions at precise points (to draw graphics for example). S can be viewed as usual atoms: they are inserted in the goal and are triggered when their are encountered during resolution. In the following we describe the operational semantics of the three strate16 ui
ui
Monfroy gies. Sinc , S n and Suser are either solver collaborations or the identity solver (if they have not been dened). " denotes the set of predicate symbols denable by a program. An atom has the form p(t1 : : : tn) where t1 : : : tn are terms and p 2 ". A CLP program is a collection of rules a B where a is an atom and B is a conjunction of atoms, constraints of L and solver symbols Su 2 Suser (i.e. names of solver collaborations). A goal G is a conjunction of atoms, constraints and solver symbols. Let the set of rules of P with p in the head be: p(x1 : : : xn) B1 : : : p(x1 : : : xn) Bn. Then the logical semantics of p is: 8x1 : : : xn p(x1 : : : xn) $ 9y11 : : : y1e1 B1 _ : : : _ 9yn1 : : : yne Bn where the yij are the variables in Bj that are not in fx1 : : : xn g. As in Section 3.5.2 the operational semantics is described as a transition system between states (i.e. the system performs the so called \top-down execuR tion" 9]): P :hA C i ! P :hA C i. hA C i represents the current conguration where A is a conjunction of atoms, constraints, and solver symbols, and C is the current constraint store. P is a stack of congurations, and R denotes the name of the transition rule. An initial goal G is a state hG i. i
n
0
0
0
rewrite
P :hA ^ a C i !r P:hA ^ B2 Sinc (C ^ (a = h2 ))i : : : hA ^ Bn Sinc (C ^ (a = hn ))i : hA ^ B1 Sinc (C ^ (a = h1 ))i if a is an atom, hi Bi are renamed to new variables, a and hi have the same predicate symbol.
atom fail
hA ^ a C i atom!fail fail if a is an atom and for every h B of P and a have dierent predicate symbols.
atom backtrack
hA ^ a C i atom!fail fail P:hA C i : hA ^ a C i atom backtrack ! P :hA C i if a is an atom and for every h B of P and a have dierent predicate symbols. 0
0
0
0
Fig. 7. Atom processing
In the following the solvers are considered to return an answer in DNF. This means that the result of the next and success rules of the operational semantics of the solver collaboration language are collected together. The rules are split into two sets. The rst one (Figure 7) formalizes the treatment of an atom. In the rules, a = h (where a and h are atoms) denotes the conjunction of equations between corresponding arguments of a and h. The second set of rules (Figure 8) describes the action of the solvers (w.r.t. their associated strategies) on the constraint store. inc solve executes the 17
Monfroy incremental solver when a constraint is encountered in the goal. user solve apply the solver u to the constraint store when a solver symbol occurs in the goal. nal solve executes the solver collaboration n on the constraints remaining in the store after has been completely processed. c
S i
C
S
G
inc solve
P :hA ^ c C i inc!solve P:hA 2 (Sinc (C ^ c))i : : : hA #(Sinc (C ^c)) (Sinc (C ^ c))i : hA 1 (Sinc (C ^ c))i if c is a constraint
user solve
P :hA ^ Su C i !u P:hA 2 (Su (C ))i : : : hA #(S (C )) (Su (C ))i : hA 1 (Su (C ))i if Su is a solver symbol i
i
ui
i
i
i
nal solve
P :h C i !f P:h 2 (S n (C ))i : : : h #(Sn (C )) (S n(C ))i : hA 1 (S n (C ))i Fig. 8. Solver Processing
The last set of rules are auxiliary rules (Figure 9). They do not modify the store, but they treat special cases. They are self understanding. backtrack
P:hA0 C 0i : hA ?i backtrack ! P :hA0 C 0 i
fail
hA ?i fail ! fail
next
P:hA0 C 0i : h C i next ! P :h A 0 C 0 i
success
h C i success ! success
Fig. 9. Auxiliary rules of the host language
5 Application to Non-Linear Polynomial Constraints This application is devoted to non-linear constraints over real numbers. It is a simulation of CoSAc15] which is a CLP system over the domain of non-linear polynomial constraints. Its solvers consist in several cooperating agents communicating through a client/server architecture. The solvers and the strategies we describe in this section correspond to the one of CoSAc. This application illustrates how easy it is to emulate or to design a CLP system with BALI. The constraint system = ( D L) of CoSAc is dened as follows. is composed of a single sort R s , the function symbols + , the predicate 18 CS
V
=
Monfroy symbols = <, and all the symbols of N . jDj is the set of real numbers R , and D interprets + = < as usual on R . V is the nite set of variables fX1 : : : Xn g. The set of admissible constraint L is the set composed of all the equations P1RP2 where P1 and P2 are non-linear polynomial in the ring Q(x1 : : : xn)X1 : : : Xn], and R 2 f=
0
0
Monfroy primitive. The rst solvers of S n and S n are \factorized", and we obtain: S n = maple exp gb psi(repeat(maple uni eq lin) repeat(maple uni) ecl) S n is always as ecient as the most ecient of the two collaborations S n and S n. Thus, the simulation of CoSAc with BALI becomes more ecient than CoSAc itself. The global complexity measure which ensures the termination of the system is the number of variables in the constraint store. All the elementary solvers are compatible with this measure, even chr lin. It adds only once slack variables and then performs elimination. CS is an enrichment of all the solver constraint systems. Although Grobner bases are a decision procedure on C , they are a simplier on R : it returns constraints that are equivalent to the input on R . Thus, Sinc , S n , S n ,and S n are agent solvers on CS . 0
00
00
0
0
6
00
Conclusion
The environment we have presented consists in a solver/agent collaboration language and a host language. The rst one oers combinators (as iterators, guarded control) and collaboration primitives (paradigms as sequentiality, parallelism and concurrency) to built complex solvers from elementary ones. This environment is motivated by the need of a general scheme for integrating, composing and re-using heterogeneous solvers, as agents for ecient constraints handling. Furthermore, we need the system to be $exible and generic so that it can be parameterized by dierent domains. The mechanisms we propose fullls the user requirements: solver collaborations are designed in a declarative way and integrated into a host language where constraints are processed and solvers are executed. Already existing schemes for solver collaboration are of two kinds: either they are built-in cooperations (i.e. the mechanisms are mixed and form a single black-box solver 13]) or they provide an architecture (based on a client/server architecture) dedicated to a single domain 12,15]. Although these latter are closer to BALI, they do not provide such a complete and $exible environment: both are linked to the host language they apply to a single domain i.e. non-linear polynomial constraints they use a unique paradigm (asynchronous communication for 12] and synchronous communication for 15]) the collaborations are xed (the add of a new solver is not a simple task and the control is xed) they allow for cooperation but not for combination. Other directions have to be investigated for extending the set of constraints the solvers can handle. We would like to merge the notions of solver extension into BALI i.e. we want to complete the solver admissible constraints with new function symbols to increase declarativity. For this purpose we do not want to design a new solver from scratch, but we prefer to extend existing ones of the domain. 20
Monfroy
References 1] A. Aiba, K. Yokota, and H. Tsuda. Heterogeneous Distributed Cooperative Problem Solving System Helios and its Cooperation Mechanisms. International Journal of Cooperative Information Systems, 4(4):369{385, 1995. 2] E.H. Durfee, V.R. Lesser, and D.D. Corkill. Cooperative distributed problem solving. In P.R. Cohen E.A. Feigenbaum, A.Barr, editor, The Handbook of Arti cial Intelligence, volume IV, pages 83{147. Addison-Wesley Pub. Co., 1989. 3] J-C. Faug ere. R esolution des systemes d' equations alg ebriques. PhD thesis, Universit e Paris 6, 1994. 4] T. Fr uhwirth. Constraint Handling Rules. In A. Podelski, editor, Constraint Programming: Basics and Trends, volume 910 of Lecture Notes in Computer Science. Springer Verlag, 1995. 5] T. Fr uhwirth, A. Herold, V. Kuechenho, T. Le Provost, P. Lim, E. Monfroy, and M. Wallace. Constraint logic programming - an informal introduction. In G. Comyn, M. Ratclie, and N. Fuchs, editors, Logic programming in action : proceedings LPSS'92, Second international logic programming Summer school, Zurich, Switzerland, volume 636 of LNAI. Springer Verlag, 1993. 6] Keith O. Geddes, Gaston H. Gonnet, and Benton L. Leong. Maple V : Language reference manual. Springer Verlag, New York, Berlin, Paris, 1991. 7] L. Granvilliers. A symbolic-numerical branch and prune algorithm for solving non-linear polynomial systems. Journal of Universal Computer Science, Springer, 4:125{146, 1998. 8] K. Homann and J. Calmet. Combining Theorem Proving and Symbolic Mathematical Computing. In J.A. Campbell J. Calmet, editor, Integrating Symbolic Mathematical Computation and Arti cial Intelligence (AISMC-2), volume 958 of Lecture Notes in Computer Science, pages 18{29. Springer Verlag, 1995. 9] J. Jaar and M. Maher. Constraint Logic Programming: a Survey. Journal of Logic Programming, 19,20:503{581, 1994. 10] Joxan Jaar and Jean-Louis Lassez. Constraint logic programming. In Proceedings of the 14th ACM Symposium on Principles of Programming Languages, Munich, Germany, pages 111{119. ACM Press, January 1987. 11] H. Kirchner and C. Ringeissen. Combining symbolic constraint solvers on algebraic domains. Journal of Symbolic Computation, 18(2):113{155, 1994. 12] P. Marti and M. Rueher. A Distributed Cooperating Constraints Solving System. International Journal on Arti cial Intelligence Tools, 4(1&2):93{113, 1995. 21
Monfroy 13] N. McPhee, S.-C. Chou, and X.-S. Gao. Mechanically proving geometry theorems using a combination of wu's method and collins' method. In Alan Bundy, editor, Proceedings of the 12th International Conference on Automated Deduction CADE-12, LNAI, pages 401{415, 1984. 14] E. Monfroy. Collaboration de solveurs pour la programmation logique a contraintes. PhD Thesis, Universit e Henri Poincar e-Nancy I, November 1996. (also available in english). 15] E. Monfroy, M. Rusinowitch, and R. Schott. Implementing Non-Linear Constraints with Cooperative Solvers. In Proc. of SAC'96, pages 63{72, February 1996. 16] C. G. Nelson and D. C. Oppen. Simplications by cooperating decision procedures. ACM Transactions on Programming Languages and Systems, 1(2), 1979. 17] C. Ringeissen. Cooperation of decision procedures for the satisability problem. In Frontiers of Combining Systems, Applied Logic. Kluwer Academic Publishers, 1996. 18] V. Saraswat. Concurrent Constraint Programming. MIT Press, Cambridge, London, 1993. 19] G. Winskel. The formal semantics of programming languages. MIT Press, Cambridge, London, 1993. 20] M. Yokoo, H. Durfee, T. Ishida, and K. Kuwabara. Distributed Constraint Satisfaction for Formalizing Distributed Problem Solving. In In Proceedings of the Twelfth IEEE International Conference on Distributed Computing Systems, pages 614{621, June 1992.
22
An Environment for Designing/Executing Constraint Solver Collaborations Eric Monfroy CWI Kruislaan 413 1098 SJ Amsterdam, The Netherlands e-mail: [email protected]
Abstract
Constraint programming is a paradigm based on the notion of constraints and mechanisms for their resolution. Thus, the key point of this class of languages is not only to oer a wide class of constraints for declarativity reasons, but also to treat them eciently. For this purpose, the need for collaboration i.e., combination and cooperation of solvers is widely recognized. This new concept enables to solve problems that cannot be tackled or eciently solved with a single solver. Furthermore, the demand for integrating symbolic mathematical tools into automated deduction system has signicantly increased. In order to meet these motivations we propose BALI, an environment for designing/executing solver collaborations. BALI is a heterogeneous distributed collaborative problem solving system. It consists of a solver collaboration language and a host language. By providing several construction primitives (as concurrency, parallelism and sequentiality) and several combinators for their composition (as iterator or guarded control), the solver collaboration language enables to build complex solvers from elementary heterogeneous ones. The solvers are encapsulated in order to federate their dierent knowledge representations. We thus obtain agents that communicate and collaborate with each other. The host language, which is a constraint programming language, furnishes several strategies for manipulating constraints and executing solver collaborations i.e., agent collaborations.
1
Introduction
The need for cooperation and combination (i.e., collaboration) of solvers is widely recognized. The general view consists in doing several solvers collaborate in order to process constraints that cannot be solved (or eciently solved) by a single solver. Informally combination 16,11,17] focuses on building a solver for the union of theories, whereas cooperation 12,15,7] concerns communication problems between solvers devoted to a single domain. In this
c 1998 Published by Elsevier Science B. V.
Monfroy case the collaborating \elementary" solvers share the constraints according to their specicities. Cooperative distributed problem solving has also been studied in A.I. 20,2], in the eld of knowledge processing systems 1], and for integrating symbolic mathematical tools 8] in automated deduction. Designing new solvers is usually a tedious task. Therefore it is important to focus on re-usability and integration issues. Some systems (like the cooperative architecture of Marti Rueher 12] and CoSAc 15]) have already been proposed for implementing the three notions of solver integration, solver cooperation and re-usability. Although they signicantly ease integration and cooperation, they require good knowledge of the basic level components of the systems (constraint manager, communication manager, . . . ) for adding new solvers. Moreover, they provide only one paradigm (asynchronous communication for 12], synchronous communication for CoSAc) and are restricted to cooperation: hence they do not allow the user to build all the collaborations he would like. Furthermore, they do not provide the user with high level control primitives to compose the solvers. This lead us to propose a new Binding Architecture for soLver Integration (BALI) which enables to make collaborate heterogeneous solvers by encapsulating them into agents. In this paper, we will use either agent or solver since we stress more on the meaning of the knowledge return by an agent than on its representation. Furthermore, we consider than the solver encapsulation (i.e., our agent) provides a translator that enables the agents to communicate with each other. BALI is a domain independent environment for specifying and executing solver collaborations integrating several paradigms. BALI consists of a solver collaboration language and a host language. The rst one is a glass-box mechanism which enables linking black-boxes tools i.e., the solvers (or agents). It permits to build agent collaborations (also called solver collaborations i.e., solver cooperation or solver combination) by composing agent solvers thanks to various collaboration primitives: sequentiality, parallelism, and concurrency. Sequentiality means that a solver/agent E2 will execute on the constraint store returned by a solver/agent E1 . When several agents are working in parallel, the constraint store C is split into several sub-stores with respect to the admissible constraints of each solver. Then the results of all the solvers and the unprocessed constraints are gathered together to constitute a new store equivalent to C . Concurrency is interesting when several solvers can execute on similar parts of the constraint store but with dierent methods or strategies. Then the result of the rst solver S which terminates and the constraints not processed by S are combined to constitute a new equivalent store. The results of the other solvers are not taken into account, and the corresponding agents are even stopped. These concepts can be connected thanks to combinators (iterators, guarded control, . . . ) in order to realize more complex solver collaborations. For example it is possible to repeat a collaboration of solvers till no more information is extracted from the store. 2
Monfroy The host language is a constraint programming language and possibly a constraint logic programming language 10,18,9,5] which enables to execute the designed collaborations with respect to three strategies called solving strategies . The rst strategy consists in determining the satisability of the constraint store each time a new constraint occurs (\incremental use of a solver"). The alternative to this method is to solve the constraint store when reaching a nal state (e.g. the end of resolution for logic programming). These solving strategies depend on the solvers and their complexity: for practical reasons it is important to test satisability as soon as a new constraint is added to the store. But for expensive in time solvers this method introduces a signicant extra cost and it is better to launch them only once. Another possible strategy is to allow the user to trigger the solvers when he needs to, for example to test the satisability after a lots of constraints have been settled. Furthermore, BALI allows several solver collaborations, associated to dierent solving strategies to coexist in a single system. For example solver S1 can be used incrementally while S2 only execute at the end and S3 is always triggered by the user. A prototype showed the feasibility of our approach and its interest in practice as well. More details about BALI, its implementation, and examples can be found in 14]. We have determined the primitives required in the collaboration language of BALI after some discussions with potential users about their needs, and after some studies of the cooperation (as well as combination) mechanisms of some working systems. Thus, although most of the current realizations are related to non-linear constraints, the eld of potential applications of BALI is wide. The paper is organized as follows. In Section 2 a collection of denitions is given. Then we introduce the notions of agent solver, solver ordering, as well as constraint system enrichment which enables to extend the scope of a solver. In Section 3 we assume that we have several agent solvers on the same constraint system enrichment, and that we want to combine them and to make them cooperate (Section 3.2). Then (Section 3.3) we provide primitives to build solver/agent collaborations from agent solvers. In order the designed solver to be an agent solver, some restrictions are presented: in fact each agent solver must dene an ordering included in a \global" Noetherian ordering over the constraint system. Section 3.4 describes a grammar to compose the construction primitives. The associated language i.e., the solver collaboration language of BALI, provides instructions to control the construction of the solver collaboration. The reader should be aware that the construction primitives of the solver collaboration language and the control primitives of the host language are issued from experiments and user requirements. An operational semantics of the solver collaboration language is detailed in Section 3.5. This semantics is based on transitions rules between congurations composed of a solver expression and a constraint store. Section 4 is devoted to the host 3
Monfroy language and an operational semantics describing the mechanisms associated to each application strategy of the solver collaborations. In order to illustrate the ease to design a solver/agent collaboration in BALI, an application (see Section 5) is detailed. In this section we simulate the solver collaboration and the strategies of CoSAc, a system for cooperating solvers over non-linear polynomial constraints. Finally (Section 6) we compare BALI to existing systems and we present the major directions for future work.
2 The basic framework In this section we introduce several concepts and denitions that will be used in the rest of the paper. We adopt a general denition of a constraint system, an agent solver and its admissible constraints i.e., the constraints it handles. These notions are applied in Section 3 for describing a solver collaboration language, and in Section 3.5 for detailing its operational semantics. 2.1 Computation domain The general scheme of constraint programming (CP) denes the class of CP(X ) languages: each CP language is obtained by instantiating the parameter X which is a quadruple representing a constraint system. Denition 2.1 A constraint system is a quadruple ( D V L) where: - is a many-sorted rst-order signature given by a set of sort symbols S , a set of function symbols F, and a set of predicate symbols P , - D is a -structure whose domain is the union S of the pairwise disjoint domains jD j for each sort s of S (jDj = 2S jD j), - V is the of pairwise disjoint nonempty sets V of S -sorted variables, S union V V = 2S - L is the closure of a non-empty set of atomic ( V )-formulas (the set of quantier free rst order formulas built over the signature and the variables of V ) by conjunction and disjunction. L is called the set of constraints. An atomic ( V )-formula of L is called an atomic constraint (or primitive constraint ). In the following, the many-sorted nature of a constraint system will be exploited for extending the use of solvers on constraints systems dierent than their own ones. A sort is simply the set of its elements and s1 s2 : : : range over the set of sorts. V denotes the subset of V containing the variables of sort s , and jD j denotes the domain associated to the sort s i.e. the subset of jDj on which variables of sorts s can take their values. In general, L is strictly included in L( ) (the set of all ( V )-formulas closed under conjunction and disjunction). We denote by CS the set of constraint systems. For any signature , let D be a -structure and L be the set 4 si
si
i
si
si
i
si
si
si
i
si
i
i
V
Monfroy of constraints. Then, a primitive constraint (also called atomic constraint ) has the form ( 1 n ) where is a predicate symbol of P and 1 n p are terms. L refers to the set of primitive constraints and 1 2 range over the set Lp. A constraint is a rst order formula built from primitive constraints and the logical connectives ^ and _. L^ denotes the set of conjunctions of primitives constraints, L the set of constraints and 1 2 range over L. The projection operator i ( ) denotes the -th disjuncts of in DNF ( i( ) 2 L^), i ( ) denotes without the disjunct i( ) and #( ) represent the number of disjunct of . The notation ( ) refers to the set of variables in , and 1 2 range over the set of variables. We call jDj the domain of computation of ( D L). To denote that is valid in the structure D we write D j= . c
p t :::t
p
t :::t
c c :::
C
C C :::
C
C
i
C
C
C
C
C
C
C
V ar C
x x :::
V
F
F
2.2 Agent Solvers Intuitively, an agent solver is an algorithm which transforms a constraint C into a new constraint C 0 which is \simpler" than C , but equivalent to C in the structure D. Furthermore, the repeated application of this algorithm always terminates and reaches a xed point which is called in solved form . Denition 2.2 An agent solver (or solver for short) on a constraint system ^ ! L such that: 8C 2 C S = ( D V L) is a computable function S : L L^ D j= S (C ) , C and 8C 2 L^ 9n 2 N S n+1 (C ) = S n (C ) We assume that for each agent solver S and each constraint C , S (C ) is in disjunctive normal form (DNF) i.e. we assume that the output of a solver is automatically Wtransformed into DNF. We also assume that if C is in L n L^, then S (C ) = i#(=1C ) S (i (C )) i.e. disjunctions are treated by a backtracking mechanism. The notion of agent solver is used to dened a notion of ordering on constraints associated to a solver. Intuitively this means that the output of an agent solver is considered \smaller" (by denition) than its input i.e. our notion of a solver can be viewed as simplication. Denition 2.3 Let S be an agent solver on the constraint system C S . Then, the relation S is dened on C S as follows: C1 S C2 if 9n 2 N s.t. C1 = n S (C2 ). Proposition 2.4 The relation S dened by S on the constraint system C S is a quasi-ordering. Furthermore, the related ordering
Monfroy itively we require that the sorts (resp. variables) of S are also sorts (resp. variables) of . We say that a many-sorted signature 1 is included in a many-sorted signature 2 (denoted by 1 2 ) if S1 S2 , F1 F2 , and P1 P2 . 1 is strictly included in 2 (denoted by 1 2) if 1 2 and either S1 S2 , or F1 F2 , or P1 P2 . Denition 2.5 Let Emb be two many-sorted signatures with Emb . and DEmb ) be a S structure (resp. a Emb structure) with jDj = S letjDDs(resp. s j (resp. jDEmb j = s 2SEmb jDEmb j). DEmb is an embedding of D if: s 2S s s 8 i 2 SEmb jDEmb j = jD j and the (injective) identity mapping from jDEmb j to jDj is a morphism from DEmb to D We can remark that if DEmb is an embedding of D then DEmb ( 1 n) = D ( 1 in Emb n ) and DEmb ( 1 n ) = D ( 1 n ) holds for all and 1 n in jDEmb j. We use the notation DEmb Struct D for DEmb is an embedding of D, and DEmb Struct D if DEmb is a strict embedding of D (i.e. Emb or jDEmbj jDj). Denition 2.6 A constraint system Emb = (Emb DEmb Emb LEmb) is an embedding of the constraint system = ( D L) if DEmb Struct D and Emb . If Emb is an embedding of , we also say that is an enrichment of Emb. Denition 2.7 Let = ( D L) be a constraint system, be a solver on S = (S DS S LS ) and be a primitive constraint of . Then is a admissible primitive constraint over if 2 LS and S is an embedding of . Obviously we have: D j= ( ) , . Intuitively, this means that the constraint system of is \smaller" than the one of but that all the sorts used in are completely contained in . The second condition on inclusion of set of variables (see denition 2.6) insures that the answer of the solver is in the constraint system of . Hence these restrictions ensure that a solver does not lose solutions when applied to a constraint system enrichment. Example 2.8 This rst example shows the use of a solver on 0 to solve a constraint on a constraint system enrichment of 0. Let = ( D L) be a constraint system, where jDj is composed of the integers N and of the lists of integer N . Let N s and N be the sorts of . Let + : N s N s ! N s , : N s N s ! N s , : Ns N ! N , : ! N , all the symbols of N (0,1,2,. . . ), and the empty list be the N s be variables of sort N s symbols of . Let be a variable of sort N and and f g 2 . 1 dened by (3 1 2]) = ^ ( ) = ^ +2 = 1 and 2 dened by + + 2 = 4 are constraints of L. Let be a solver on 0 = (0 D0 0 L0) with jD0j = N and D0 interprets + and of 0 as usual on N . Since D0 Struct D and 2 is a primitive constraint of L0 then 2 6 CS
CS
i
i
i
i
s
i
i
f
f
x :::x
p
x :::x
p
x :::x
x :::x
p f
x :::x
CS
CS
V
V
CS
V
V
CS
CS
CS
CS
CS
V
V
S
c
CS
CS
S
c
c
CS
CS
S c
CS
c
S
c
c
CS
c
S
CS
CS
CS
V
List
List s
cons
car
CS
List s
List s
List s
L
L X Y
V
c
CS
List s
c
X
cons
Y
X Y
L
car L
X
X
S
V
c
c
Monfroy is S admissible over
CS
.
Example 2.9 This example illustrates the restrictions of the Denition 2.7. Let = ( D L) be a constraint system, with C = jDj, let f+ 0 1g be symbols of and S = fC s g. Let be a solver on 0 = (0 D0 0 L0) with the symbols f+ g in , R = jD0j and S = fRs g . Let be the constraint 2 + 1 = 0 on with 2 . Although is in L0, is of sort admissible and will not be handled by . This is due C s . Then is not to the restriction on constraint system embedding: it prevents to execute a solver on a constraint whose all sorts (contained in the functions, predicates and variables of the constraint) are not in the constraint system of the solver. We can see on this example that: if is solved with , then has no solution and if is solved with a solver on C then has two solutions and . CS
V
S
X
V
X
V
c
0
CS
c
CS
c
X
S
S
c
S
c
c
c
i
i
The notion of admissible primitive constraint is extended to all constraints in the following way: S ( ^ 0) = S ( ) ^ S ( 0). If is a admissible primitive constraint S ( ) = , else S ( ) = >. Obviously we have: D j= ( S ( )) , S ( ). Similarly we dene S ( ), the non-admissible constraint, of over by: S ( ^ 0 ) = S ( ) ^ S ( 0). If is not a admissible primitive constraint S ( ) = , else S ( ) = >. S
S
C
c
c
c
C
c
C
c
c
C
c
S
c
C
c
c
C
S
C
C
c
CS
S
c
Property 2.10 If
is a solver on C SS , then S ? dened as follows is a solver on every enrichment C S = ( D V L) of C SS : 8C 2 L^ S ? (C ) = S (S (C )) ^ S (C ) S
Example 2.11 (Example 2.8 continued) 2 is the admissible constraint of c2
over
CS
, and
c
X
S
+ 2 = 1 is the admissible constraint of S
c1
over
CS
.
3 Solver/Agent Collaborations In this section we consider several agent solvers working on embeddings of a single constraint system ( is an enrichment of all the constraint systems of the solvers). These solvers are \basic" solvers (or \elementary" solvers) and we study how they can collaborate together on the enrichment to build \complex" solvers called solver collaborations or agent collaborations. The dierences between cooperation and combination of solvers exposed in Section 1 are formally described. Then the primitives to compose the agent solvers (Section 3.3) and the language (Section 3.4) that allows one to build these collaborations (cooperation or combination of solvers) are examined. We then dene the operational semantics to the solver collaboration language. But rst some criteria for termination have to be given they are used to prove that solver/agent collaborations are agent solvers. 7 CS
CS
CS
Monfroy 3.1 Compatibility and Termination For proving the termination of solver collaborations, we may need to embed all solver orderings into a \global" Noetherian ordering <. This ordering can be viewed as a complexity measure (such as the number of variables in the constraint, or the width of intervals) for practical applications. The notion of < compatible solver is introduced in order to dene the \compatibility" between solvers. Denition 3.1 Let C S = ( D V L) be a constraint system, S be a solver on C S and < be a Noetherian ordering on a superset of L. Then S is < compatible if
Monfroy (S2 DS2 S2 LS2 ) (with f+ g S2 , and jDS2 j = N ). Then DS1 Struct D and DS2 Struct D and thus 1, 2 can be combined on .
V
S
S
CS
The tuple ( 1 n ) is a solver collaboration if it is either a solver cooperation or a solver combination. So that a solver collaboration could be an agent solver w.r.t. denition 2.2, all the solver orderings have to be included in a \global ordering", and the \global constraint system" has to be an enrichment of all the solver constraint systems: this insure a compatibility between the solvers. These conditions are detailed formally in next sections. S :::S
3.3 Collaboration Primitives The composition of agent solvers require some mechanisms called collaboration primitives. They dened concepts that rst enable to apply some solvers on pieces of the constraint and then permit to re-create a constraint equivalent but simpler than the input one. BALI allows for three collaboration primitives: sequentiality, parallelism, concurrency. Each one corresponds to a special paradigm and enables dierent kinds of collaboration. For each of these primitives, we give an informal denition, a formal denition, and restrictions that make the collaborations be agent solvers in the sense of denition 2.2. 3.3.1 Sequential Solvers/Agents Sequential solvers enables to execute an agent on a constraint store which is the result of another agent. Denition 3.6 Let S1 (resp. S2 ) be a solver on C S1 (resp. C S2 ) and let C S = ( D V L) be an enrichment of C S1 and C S2 . Then S1 S2 is a sequential composition of solvers if: 8C 2 L ^
( ) =
S1 S2 C
_
#(S1? (C)) i=1
?
( ( ?( )))
S2 i S1 C
Proposition 3.7 Let S1 and S2 be two agent solvers on C S1 and C S2 (respectively) and let C S be an enrichment of C S1 and C S2 . Then S1? S2? is an agent solver on C S if there exists a Noetherian ordering < on C S such that ? ? S1 and S2 are < compatible. Moreover, S1 S2 is < compatible.
3.3.2 Parallel Solvers/Agents This second primitive allows one to execute several agents in parallel. The constraint store is split into disjoint subproblems w.r.t. the admissible constraint of each solvers. When the last agent terminates, the result of all solvers and the unprocessed constraints are gathered. This primitive is useful for processing equalities and inequations with different solvers, applying specialized solvers on parts of the store (e.g. quadratic solver), or for treating simultaneously constraints over disjoint sorts, . . . 9
Monfroy Two conjunctions of primitive constraints C = ^ni=1 ci and C 0 = ^mj=1c0j are disjoint i 8(i j ) 2 1 :: n] 1 :: m] ci 6= c0j Denition 3.8 Let S1 : : : Sn be n solvers on respectively CS1 : : : CSn and
let CS = ( D V L) be an enrichment of each CSi. Then S1? : : : Sn? execute in parallel on CS , denoted S1? k : : : k Sn? if: 8(i j ) 2 1 n]2 s.t. i 6= j , S (C ) and 8C 2 L^ S1? k : : : k Sn? (C ) = W Sj (C ) are? disjoint for all C ^2n L^, (and ? (k1 :::kn )2 1#(S1 (C ))]::: 1#(Sn? (C ))] i=1 ki Si (C )) i
Proposition 3.9 S1? k : : : k Sn? is an agent solver on CS if there exists a
Noetherian ordering < s.t. all the agent solvers Si are < compatible. Moreover, S1? k : : : k Sn? is < compatible. 3.3.3 Concurrent Solvers/Agents This last primitive deals with the concept of concurrency and provides a nondeterministic choice function. The constraint store is split into sub-problems (which overlap or not) w.r.t. the admissible constraints of each solvers. The result of concurrent solvers is not a combination of the answers of all solvers, but the output of a single solver and the non-admissible constraint of this solver. Furthermore, concurrent solving is parameterized by functions. Each of these functions determine how the resulting store is chosen. This choice is made at run-time by a function associated to . returns the constraint satisfying some required conditions w.r.t. the quickest solver and the form of the solutions. A standard function is basic which returns the rst agent which nishes. But more complex functions are also possible such as the one which selects the rst solver which returns a constraint in solved form. The major use of this primitive is the following. When the user has several similar solvers on disposal, he generally does not know which one is the best suited for his problem. So he can execute all the solvers concurrently and keep the solution of the quickest one. This is still more signicant when the agents are expensive in time as in the case of Grobner bases computation or Diophantine equation solving. Denition 3.10 Let S1 : : : Sn be n solvers on respectively CS1 : : : CSn
and let CS = ( D V L) be an enrichment of each CSi. Then S1? : : : Sn? execute concurrently, denoted (S1?? : : :?Sn? ) if: 8C 2 L^ (S1?? : : :?Sn? )(C ) = (S1?(C ) : : : Sn? (C )) where is a function associated with which determines at run-time which Si(C ) will be the answer of (S1?? : : :?Sn? )(C ) (see Section 3.4 for operational details about functions). Proposition 3.11 (S1? ? : : :?Sn? ) is an agent solver on CS if there exists a
Noetherian ordering < s.t. S1 : : : Sn are < compatible agent solvers. Moreover, (S1? ? : : :?Sn? ) is < compatible. 10
Monfroy 3.4 Solver/Agent Collaboration Language It is now possible to build complex solvers on a constraint system CS using the collaboration primitives introduced in the previous section. The language for solver collaboration of BALI manipulates expressions describing complex collaborations of agents. The construction primitives (sequentiality, parallelism, concurrency) introduced in Section 3 are composed using the combinators (iterators, guarded control, . . . ) introduced in this section. First the agent collaboration language is explicated. A program written in this language describes a solver collaboration (operational point of view) also called a solver expression (algorithmic point of view). Id 2 identifiers S 2 solvers 2 conditional selection Col ::= Id = E E ::= } j Id j B j E1 E2 j EP j E0 :: on B then E1 else E2 j repeat(E ) j (EC ) B ::= S j S k B EP ::= E j E k EP EC ::= E j E ?EC Fig. 1. Syntax of the solver/agent collaboration language of
BALI
The language is described by the grammar of Figure 1. In the following, we will denote by E (resp. B, . . . ) the set of solver expressions that can be derived from the non terminal E (resp. B , . . . ). We call constraint store the current conjunction C of basic constraints. C denotes the set of contexts and S tores the set of constraint stores. } is the identity solver, it is dened as follows: } : S tores ! S tores and }(C ) = C . The identiers Id are names for solver expressions. They are useful for two main purposes: rst, several solver collaborations can act in the host language depending on the strategies, and second, solver expressions can be collected in a library and used as it or as part of an expression. The Col rule allows for naming solver expressions. S represents a basic solver (or elementary solver ), this means that this solver cannot be dissociated. B is either a basic solver or some basic solvers working in parallel \ k ". B is at the opposite of EP which is either a solver expression or some solver expressions executing in parallel. EC is similar to EP but with the concurrency paradigm \ ? ": the result of EC depends on the functions. These functions are conditional selection of concurrency. They are associated with functions which examine the context to choose, at run-time, the basic solver (resp. the expression of basic solvers from B) that will return the constraint store after the execution of several solvers (resp. expression of solvers) in concurrency. If no solver returns a constraint that 11
Monfroy satises the function, the previous constraint store is kept. The prole of the functions is : (E C )n ! C where each context from C is the result of the execution of the solver associated in the Cartesian product and n is the number of solver expressions working concurrently. The prole of the functions is : E n ! E \ " denotes the sequential composition: E1 E2 means E2 will execute on the context returned by E1. repeat(E ) is an iterator: E is repeated till the constraint store reaches a xed point i.e. till E n+1(C ) = E n(C ). The last control primitive is \E0 :: on B then E1 else E2 ". This primitive executes E1 if the guard E0 is satised, else E2 . The guard is determined by the last executed basic solver expression (in B). So if E0 terminates with B , then E1 is executed, else E2. Property 3.12 A collaboration of agent solvers is an agent solver if there exists a Noetherian ordering < on CS s.t. all the agent solvers occurring in the collaboration are < compatible. 3.5 Operational Semantics In this section we present an operational semantics for the solver/agent collaboration language of BALI. First some operations on the constraint store are needed in order to simplify the constraints. These operations are domainindependent and can be viewed as a garbage collector. Then a complete description of the operational semantics is given. It describes the behavior of the system by means of transition rules from state to state. 3.5.1 Operations on the Constraint Store The constraint store C is updated after each application of a solver S (using the results of the solvers, and the non S -admissible constraints) and transformed in DNF. Since the solvers work on conjunctions of constraints, the disjunction are managed by a backtracking mechanism using a stack (see Section 3.5.2). These operations are extended to solver expressions, and detailed in the operational semantics in section 3.5. Idempotency C ^ C ! C Bottom C ^? ! ? Top C ^> ! C
Fig. 2. Simplication rules on the constraint store
Rules of Figure 2 are required to simplify the store: they are applied modulo the associativity and commutativity axioms. The simplication rules are universal and domain-independent. But the Idempotency rule for example can be extended to take the semantics of the computation domain into account: 12
Monfroy then it will remove more redundancies (for example on R , ^ ! ). Hence the user can complete the simplication system to take the domain into account. Remark 3.13 In order to obtain a kind of satisability procedure collaboration, the user can duplicate these rules for disjunctions. For example a rule _-Idempotency: _ ! removes duplicated solutions, or a rule _-Top: _ > ! > concludes to the satisability of a disjunction of constraints if at least one of the constraint is >. X
a
a
X >
X > a
C
C
C
C
Propagation
X
2 V d 2 (D L)
X = d
^ C ! C d=X ]
Fig. 3. Propagation rule on the constraint store
The Propagation rule (Figure 3) propagates the value of a variable to the whole constraint store. The application of simplication and propagation rules modulo the associativity and commutativity axioms transforms into a normal form ( ) ofWthe store. This normal form is not unique. Since ( ) is in DNF, ( ) = ni=1 i and the projection operator can be used on it. Remark 3.14 Since they perform syntactical transformations, simplication and propagation rules can be seen as generic solvers over all constraint systems. C
nf C
nf C
nf C
C
3.5.2 Solver/Agent Collaboration Semantics In this section we give an operational semantics for solver collaborations. We present the semantics such that inessential details are abstracted and the execution of the solvers and the updates of the constraint store are highlighted. The behavior of the system is expressed by transition rules that are divided into two classes: the transformation rules, and the auxiliary rules. We represent the situation of a constraint C waiting to be processed by the solver expression E by the pair hE C i. We shall dene a transformation between such pairs of congurations based on the execution of a single basic solver. Hence a single step relation between two congurations B hE C i ! hE C i means the execution of a basic solver B from E on the constraint store C leads to the conguration in which it remains to execute E on C . The transformations ! are labeled with the name of the solver B from B involved in this step. They describe visible actions on the conguration: the action of the solver B modies the current constraint store. As stated in section 2.2, the input of a solver is a conjunction of primitive constraints (even if formally we consider they can handle disjunctions), and its output can be a disjunction (non determinism). A backtrack mechanism allows one to deal with constraint disjunctions. This mechanism uses a stack which memorizes congurations that will be evaluated when backtracking. 13 0
0
0
0
Monfroy Thus, a conguration stack and a current conguration h i compose the current state which is represented by :h i ( :h i or h i if the stack is empty). The usual operations on stacks and a simplication operation are dened for the conguration stack (Figure 4). P
E C
P
E C
P
E C
E C
Push P ush(P hE C i) ! P:hE C i Pop P op(P:hE C i) ! P :hE C i Simplify P:hE >i ! P Fig. 4. Operations on the conguration stack
The transformation between congurations is extended to transformation between states: B :h i ! :h i Hence the operational semantics associates with each possible state the new state obtained by applying the solver (from B) of the current conguration to the current store. If returns a disjunction of constraints , h 1( )i becomes the current conguration and h 1 ( )i is pushed on the stack. The other class of transition rules, the auxiliary rules , do not modify the constraints store. They either output the current constraint store (printing of the solutions for success and next) or performs the backtrack mechanism i.e. in case of fail, they exchange the current conguration with a conguration of the stack (for example backtrack). Constraint solving is expressed by sequence of transitions, called derivations : h 1 1i = :h i !t1 t!1 i:h i ii !t t!1 :h} ni = h} ni A state with an empty stack and a current conguration containing the identity solver is called a nal state. A derivation is successful if at least one of the states is h} i with 6= ? or :h} i with 6= ?. In the rst case the transition (auxiliary rule) applied after this state is labeled with success and leads to the special state success. In the second case the transition applied after this state is labeled with next. If a derivation is not successful, we say that it is failed. The answer constraint is the disjunctive constraint whose disjuncts are all the constraint stores on which a next or success transformation has been applied during the derivation. The semantics is given in SOS style 19] (Structural Operational Semantics). Figure 5 shows the auxiliary rules while Figure 6 describes the transformation rules. We have seen how to build complex agent using the solver collaboration language of BALI. In Section 4 we present a way to integrate the designed solvers in a constraint programming language i.e. the host language of BALI. 14 P
E C
P
0
0
E C
0
B
C
0
E
E C
n
P
C
:::
E C
C
i
P
P
E C
C
0
E
C
C
i
:::
C
n
P
C
C
Monfroy fail
h ?i fail ! fail E
backtrack
h
P: E C
next
i:h
?i backtrack ! h 1 ( ) i : h 1 ( )i 6= ? next i : h} i ! h 1 ( )i : h 1 ( )i 6= ? success h} i ! success E1
P: E
C
E
C
C
h
P: E C
success
0
C
P: E
C
0
E
C
0
C
C
Fig. 5. Auxiliary rules 4
Host Language
In this section we propose a host language which allows executing the solver collaboration designed in the previous section. Furthermore, the host language provides three solving strategies i.e. strategies to apply the solvers/agents. Thus, as mentioned in Section 1, we can associate a solver collaboration to each solving strategy of the host language. Hence several solver collaborations can be applied for a single application. The host language is not necessarily a LP language, but we illustrate the strategies and their operational semantics on a Prolog like host language. Thus, by combining solver collaborations (Constraint Programming: CP) and a Logic Programming host language (LP), we obtain a Constraint Logic Programming (CLP) language i.e. CP+LP=CLP. Thus, we describe a CLP system which involves several solvers. In the following we assume that solver collaborations are agent solvers. Thus, for sake of simplicity, we will often write solver or agent, instead of solver/agent collaboration or agent solver. There are three strategies for the application of agents. The rst one consists of an \incremental" solver Sinc : this means that Sinc is run each time a new constraint is added to the store. For each new constraint, the consistency of the store is tested w.r.t. Sinc , and the store is also simplied by Sinc . The second strategy executes the solver S n when the initial goal has been completely processed. In the last strategy the user decides when the solvers are triggered. For this purpose he has on disposal a set of solver symbols Suser = fSu u g that can be inserted in the bodies of the predicates as usual atoms. \Incremental" strategy tries to detect as soon as possible the failure cases. Thus, inc is typically a fast procedure (such as interval propagation or Gaussian elimination) since it is often applied during computation. In the other hand, n is usually a slow solver that is too expensive in time (such as Grobner bases computation, quantier elimination, completion procedure) to be launched each time a new constraint is encountered. It can also be a solver 15 i
S
S
:::S i
Monfroy sequential solve
hS C i ! h} nf (S (C ))i P :hS E C i ! P:hE 1 (nf (S (C )))i : hE 1 (nf (S (C )))i S
?
S
?
parallel solve
?
hE1 C i !!1 h} C1 i : : : hE C i !! h} C i W ^ (C )i : hE V (C )i P :hE1 k : : : k E E C i 1 ! P:hE =1 =1 1 where j 2 1 n], k 2 1 #(S (C ))] and fk1 : : : k g 6= f1 : : : 1g. ? B
? Bn
n
B k:::kBn
n
jkj
n
n
n i
ki
i
i
? j
j
on then
i
n
hE0 C i !! h} C i P :hE0 :: on B then E1 else E2 E C i ! P:hE1 E 1 (C )i : hE1 E 1 (C )i ?
B
0
B
on else
0
0
hE0 C i !!1 h} C i B1 6= B2 P :hE0 :: on B2 then E1 else E2 E C i !1 P:hE2 E 1 (C )i : hE2 E 1 (C )i ? B
0
B
repeat
0
0
hE0 C i !! h} C i C 6= C P :hrepeat(E0 ) E C i ! P:hrepeat(E0 ) E 1 (C )i : hrepeat(E0 ) E 1 (C )i ?
B
0
0
B
stop repeat
0
0
hE0 C i !! h} C i P :hrepeat(E0 ) E C i ! P :hE C i ?
B
B
basic concurrent solve
hE C i !! h} C i P :h(E1 ? : : :?E ) E C i ! P:hE 1 (C )i : hE 1 (C )i ?
i
B
n
B
0
0
0
concurrent solve hE C i !! h} C i (E1 (C ) : : : E (C )) = E (C ) P :h(E1 ? : : :?E ) E C i ! P:hE 1 (C )i : hE 1 (C )i ?
B
0
i
n
B
n
0
i
0
Fig. 6. Transformation rules
which aims at giving a special form at the solution (i.e. a more readable solution for the user as normalizing procedures). Thus, it is better to launch this solver only once, after the goal has been processed. The S are applied when the user knows the hard points of its program (when \large set" of constraints are stated for example) and where the inconsistencies can appear. So he prefers to test satisability before going further on. The second kind of application of \user solvers" is the need of solutions at precise points (to draw graphics for example). S can be viewed as usual atoms: they are inserted in the goal and are triggered when their are encountered during resolution. In the following we describe the operational semantics of the three strate16 ui
ui
Monfroy gies. Sinc , S n and Suser are either solver collaborations or the identity solver (if they have not been dened). " denotes the set of predicate symbols denable by a program. An atom has the form p(t1 : : : tn) where t1 : : : tn are terms and p 2 ". A CLP program is a collection of rules a B where a is an atom and B is a conjunction of atoms, constraints of L and solver symbols Su 2 Suser (i.e. names of solver collaborations). A goal G is a conjunction of atoms, constraints and solver symbols. Let the set of rules of P with p in the head be: p(x1 : : : xn) B1 : : : p(x1 : : : xn) Bn. Then the logical semantics of p is: 8x1 : : : xn p(x1 : : : xn) $ 9y11 : : : y1e1 B1 _ : : : _ 9yn1 : : : yne Bn where the yij are the variables in Bj that are not in fx1 : : : xn g. As in Section 3.5.2 the operational semantics is described as a transition system between states (i.e. the system performs the so called \top-down execuR tion" 9]): P :hA C i ! P :hA C i. hA C i represents the current conguration where A is a conjunction of atoms, constraints, and solver symbols, and C is the current constraint store. P is a stack of congurations, and R denotes the name of the transition rule. An initial goal G is a state hG i. i
n
0
0
0
rewrite
P :hA ^ a C i !r P:hA ^ B2 Sinc (C ^ (a = h2 ))i : : : hA ^ Bn Sinc (C ^ (a = hn ))i : hA ^ B1 Sinc (C ^ (a = h1 ))i if a is an atom, hi Bi are renamed to new variables, a and hi have the same predicate symbol.
atom fail
hA ^ a C i atom!fail fail if a is an atom and for every h B of P and a have dierent predicate symbols.
atom backtrack
hA ^ a C i atom!fail fail P:hA C i : hA ^ a C i atom backtrack ! P :hA C i if a is an atom and for every h B of P and a have dierent predicate symbols. 0
0
0
0
Fig. 7. Atom processing
In the following the solvers are considered to return an answer in DNF. This means that the result of the next and success rules of the operational semantics of the solver collaboration language are collected together. The rules are split into two sets. The rst one (Figure 7) formalizes the treatment of an atom. In the rules, a = h (where a and h are atoms) denotes the conjunction of equations between corresponding arguments of a and h. The second set of rules (Figure 8) describes the action of the solvers (w.r.t. their associated strategies) on the constraint store. inc solve executes the 17
Monfroy incremental solver when a constraint is encountered in the goal. user solve apply the solver u to the constraint store when a solver symbol occurs in the goal. nal solve executes the solver collaboration n on the constraints remaining in the store after has been completely processed. c
S i
C
S
G
inc solve
P :hA ^ c C i inc!solve P:hA 2 (Sinc (C ^ c))i : : : hA #(Sinc (C ^c)) (Sinc (C ^ c))i : hA 1 (Sinc (C ^ c))i if c is a constraint
user solve
P :hA ^ Su C i !u P:hA 2 (Su (C ))i : : : hA #(S (C )) (Su (C ))i : hA 1 (Su (C ))i if Su is a solver symbol i
i
ui
i
i
i
nal solve
P :h C i !f P:h 2 (S n (C ))i : : : h #(Sn (C )) (S n(C ))i : hA 1 (S n (C ))i Fig. 8. Solver Processing
The last set of rules are auxiliary rules (Figure 9). They do not modify the store, but they treat special cases. They are self understanding. backtrack
P:hA0 C 0i : hA ?i backtrack ! P :hA0 C 0 i
fail
hA ?i fail ! fail
next
P:hA0 C 0i : h C i next ! P :h A 0 C 0 i
success
h C i success ! success
Fig. 9. Auxiliary rules of the host language
5 Application to Non-Linear Polynomial Constraints This application is devoted to non-linear constraints over real numbers. It is a simulation of CoSAc15] which is a CLP system over the domain of non-linear polynomial constraints. Its solvers consist in several cooperating agents communicating through a client/server architecture. The solvers and the strategies we describe in this section correspond to the one of CoSAc. This application illustrates how easy it is to emulate or to design a CLP system with BALI. The constraint system = ( D L) of CoSAc is dened as follows. is composed of a single sort R s , the function symbols + , the predicate 18 CS
V
=
Monfroy symbols = <, and all the symbols of N . jDj is the set of real numbers R , and D interprets + = < as usual on R . V is the nite set of variables fX1 : : : Xn g. The set of admissible constraint L is the set composed of all the equations P1RP2 where P1 and P2 are non-linear polynomial in the ring Q(x1 : : : xn)X1 : : : Xn], and R 2 f=
0
0
Monfroy primitive. The rst solvers of S n and S n are \factorized", and we obtain: S n = maple exp gb psi(repeat(maple uni eq lin) repeat(maple uni) ecl) S n is always as ecient as the most ecient of the two collaborations S n and S n. Thus, the simulation of CoSAc with BALI becomes more ecient than CoSAc itself. The global complexity measure which ensures the termination of the system is the number of variables in the constraint store. All the elementary solvers are compatible with this measure, even chr lin. It adds only once slack variables and then performs elimination. CS is an enrichment of all the solver constraint systems. Although Grobner bases are a decision procedure on C , they are a simplier on R : it returns constraints that are equivalent to the input on R . Thus, Sinc , S n , S n ,and S n are agent solvers on CS . 0
00
00
0
0
6
00
Conclusion
The environment we have presented consists in a solver/agent collaboration language and a host language. The rst one oers combinators (as iterators, guarded control) and collaboration primitives (paradigms as sequentiality, parallelism and concurrency) to built complex solvers from elementary ones. This environment is motivated by the need of a general scheme for integrating, composing and re-using heterogeneous solvers, as agents for ecient constraints handling. Furthermore, we need the system to be $exible and generic so that it can be parameterized by dierent domains. The mechanisms we propose fullls the user requirements: solver collaborations are designed in a declarative way and integrated into a host language where constraints are processed and solvers are executed. Already existing schemes for solver collaboration are of two kinds: either they are built-in cooperations (i.e. the mechanisms are mixed and form a single black-box solver 13]) or they provide an architecture (based on a client/server architecture) dedicated to a single domain 12,15]. Although these latter are closer to BALI, they do not provide such a complete and $exible environment: both are linked to the host language they apply to a single domain i.e. non-linear polynomial constraints they use a unique paradigm (asynchronous communication for 12] and synchronous communication for 15]) the collaborations are xed (the add of a new solver is not a simple task and the control is xed) they allow for cooperation but not for combination. Other directions have to be investigated for extending the set of constraints the solvers can handle. We would like to merge the notions of solver extension into BALI i.e. we want to complete the solver admissible constraints with new function symbols to increase declarativity. For this purpose we do not want to design a new solver from scratch, but we prefer to extend existing ones of the domain. 20
Monfroy
References 1] A. Aiba, K. Yokota, and H. Tsuda. Heterogeneous Distributed Cooperative Problem Solving System Helios and its Cooperation Mechanisms. International Journal of Cooperative Information Systems, 4(4):369{385, 1995. 2] E.H. Durfee, V.R. Lesser, and D.D. Corkill. Cooperative distributed problem solving. In P.R. Cohen E.A. Feigenbaum, A.Barr, editor, The Handbook of Arti cial Intelligence, volume IV, pages 83{147. Addison-Wesley Pub. Co., 1989. 3] J-C. Faug ere. R esolution des systemes d' equations alg ebriques. PhD thesis, Universit e Paris 6, 1994. 4] T. Fr uhwirth. Constraint Handling Rules. In A. Podelski, editor, Constraint Programming: Basics and Trends, volume 910 of Lecture Notes in Computer Science. Springer Verlag, 1995. 5] T. Fr uhwirth, A. Herold, V. Kuechenho, T. Le Provost, P. Lim, E. Monfroy, and M. Wallace. Constraint logic programming - an informal introduction. In G. Comyn, M. Ratclie, and N. Fuchs, editors, Logic programming in action : proceedings LPSS'92, Second international logic programming Summer school, Zurich, Switzerland, volume 636 of LNAI. Springer Verlag, 1993. 6] Keith O. Geddes, Gaston H. Gonnet, and Benton L. Leong. Maple V : Language reference manual. Springer Verlag, New York, Berlin, Paris, 1991. 7] L. Granvilliers. A symbolic-numerical branch and prune algorithm for solving non-linear polynomial systems. Journal of Universal Computer Science, Springer, 4:125{146, 1998. 8] K. Homann and J. Calmet. Combining Theorem Proving and Symbolic Mathematical Computing. In J.A. Campbell J. Calmet, editor, Integrating Symbolic Mathematical Computation and Arti cial Intelligence (AISMC-2), volume 958 of Lecture Notes in Computer Science, pages 18{29. Springer Verlag, 1995. 9] J. Jaar and M. Maher. Constraint Logic Programming: a Survey. Journal of Logic Programming, 19,20:503{581, 1994. 10] Joxan Jaar and Jean-Louis Lassez. Constraint logic programming. In Proceedings of the 14th ACM Symposium on Principles of Programming Languages, Munich, Germany, pages 111{119. ACM Press, January 1987. 11] H. Kirchner and C. Ringeissen. Combining symbolic constraint solvers on algebraic domains. Journal of Symbolic Computation, 18(2):113{155, 1994. 12] P. Marti and M. Rueher. A Distributed Cooperating Constraints Solving System. International Journal on Arti cial Intelligence Tools, 4(1&2):93{113, 1995. 21
Monfroy 13] N. McPhee, S.-C. Chou, and X.-S. Gao. Mechanically proving geometry theorems using a combination of wu's method and collins' method. In Alan Bundy, editor, Proceedings of the 12th International Conference on Automated Deduction CADE-12, LNAI, pages 401{415, 1984. 14] E. Monfroy. Collaboration de solveurs pour la programmation logique a contraintes. PhD Thesis, Universit e Henri Poincar e-Nancy I, November 1996. (also available in english). 15] E. Monfroy, M. Rusinowitch, and R. Schott. Implementing Non-Linear Constraints with Cooperative Solvers. In Proc. of SAC'96, pages 63{72, February 1996. 16] C. G. Nelson and D. C. Oppen. Simplications by cooperating decision procedures. ACM Transactions on Programming Languages and Systems, 1(2), 1979. 17] C. Ringeissen. Cooperation of decision procedures for the satisability problem. In Frontiers of Combining Systems, Applied Logic. Kluwer Academic Publishers, 1996. 18] V. Saraswat. Concurrent Constraint Programming. MIT Press, Cambridge, London, 1993. 19] G. Winskel. The formal semantics of programming languages. MIT Press, Cambridge, London, 1993. 20] M. Yokoo, H. Durfee, T. Ishida, and K. Kuwabara. Distributed Constraint Satisfaction for Formalizing Distributed Problem Solving. In In Proceedings of the Twelfth IEEE International Conference on Distributed Computing Systems, pages 614{621, June 1992.
22