Fair Hierarchical Constraint Logic Programming

We propose a variant of Hierarchical Constraint Logic Programming (HCLP) which is more general than standard CLP, but less general than the HCLP scheme of Borning, Wilson, and others. We conjecture that our variant, Fair HCLP, will have better semantics than HCLP, especially under hierarchy composition, and will be more amenable to incremental implementations. 1 Motivation The HCLP scheme of Borning, Wilson, and others [1, 3, 7] greatly extends the expressibility of the general CLP scheme [4]. A semantics has been de ned for it and some instances of it have been implemented [7]. However, the semantics is not as natural as one might hope, and the implementations are inherently less e cient than those of CLP. We believe that these two issues may be related, and suggest that a less expressive scheme may go some way to overcoming both of them. Therefore, we propose a half-way house between CLP and HCLP, called FHCLP (Fair Hierarchical CLP). It is adequate for some of the standard examples of hierarchies in the literature. It is de nitely not su cient to express some of the other examples directly, but it is possible to rephrase them to fall within the scope of FHCLP. 2 Hierarchical Constraint Logic Programming A good introduction to HCLP can be found in Molly Wilson's PhD thesis [7, chapter 4]; here is a brief overview. Just as Logic Programming can be extended to CLP, so CLP can be extended to a Hierarchical CLP scheme including both hard and soft constraints. The HCLP scheme is parameterised not only by the constraint domain D but also by the comparator C, which is used to compare and select from the di erent ways of satisfying the optional or soft constraints. An HCLP rule has the form p(t) :{ q1(t); : : : ; qm(t); l1c1(t); : : : ; lncn(t): where t is a list of terms, p; q1; : : : ; qm are atoms and l1c1; : : : ; lncn are labelled constraints. A program is a collection of rules, and a query is a multi-set of atoms. The strengths of the di erent constraints are indicated by a non-negative integer label. Constraints labelled with a zero are required, while constraints labelled j are preferred over those labelled j + 1. (A program can include a list of symbolic names, such as required , strongly-preferred etc., for the strength labels, which will be mapped to the natural numbers by the interpreter. If the strength label on a constraint is omitted, it is assumed to be required .) Goals are executed as in CLP, except that initially non-required constraints are accumulated but otherwise ignored1. If a goal is successful but with a non-unique answer, the accumulated hierarchy of optional constraints is then solved, which re nes the valuations in the solution. The method used to solve the non-required constraints will vary from domain to domain, and for di erent comparators within a given domain. Extra answer valuations may be produced on backtracking. The constraint store S is partitioned into the set of required constraints S0 and the set of optional ones Si. The solution set for the whole hierarchy is a subset of the solution set of S0, such that no other solution could be `better' i.e. for all levels up to k, Sk is satis ed to the same extent as for any other solution, and for level Sk+1 this solution is better, in terms of some comparator, than all others. Backtracking and incomparable hierarchies give rise to multiple possible solution sets, each a subset of the solution to S0. Certain comparators can be used with any domain. For example, locally-predicate-better prefers one solution to another if it satis es more constraints at some level, and an equal number of constraints at all previous levels. Another comparator is unsatis ed-countbetter which tries to minimise the number of constraints which are not satis ed at a given level, as opposed to trying to maximise the number satis ed. Other comparators can only be used if the domain has a metric (such as the real numbers) in which case it is possible to ask by how much a particular answer fails to satisfy a given constraint. Least-squares-better selects solutions which minimise the sum of the squares of the errors. For example, if two optional constraints are X = 1 and X = 4, a predicate comparator would o er two solutions, X = 1 or X = 4, both of which satisfy only one of the two constraints (the maximum possible in this case), whereas least-squares-better would choose X = 2:5. Other statistical functions can be used as comparators too. With all comparators, weights can be used within a particular level of the hierarchy in order to in uence the solution, but a heavily weighted constraint at a given level is completely dominated by the lightest constraint at any higher level. The only exception to this may be in the case of `regional' comparators which consider more than one level of the hierarchy at once. 3 Monotonicity and Fairness It is recognised that, unlike most standard constraint schemes, HCLP is non-monotonic (note the subtitle of [8]). Thus the standard compositional properties for sets of solutions based on intersection do not carry over into the hierarchical view. We have analysed what aspect of HCLP causes the non-monotonicity; it appears to us that HCLP su ers from discontinuities when, on backtracking say, the solution jumps from one sub-space (of the solutions to the required constraints) to another. This e ect may be thought of as due to `spikes' in the search tree. In Figure 1, if W1 and W2 are mutually inconsistent constraints, then there is a big jump from one of the child solution nodes of W1 to W2. Similarly, an even bigger leap is needed from the solution space containing S1 and S2 to that of S3. These leaps are caused by mutually inconsistent constraints at the same level of 1This is an implementation detail but, while it is not essential, it helps us to understand the di erent role of required and optional constraints. Menezes et al. use a di erent strategy [6]. 2 preference. Therefore FHCLP `bans' such clashing constraints. (An alternative approach to regaining these properties is discussed in the section on Further Work and in [5].) TTTTT QQQQQQQ TTTTT R S1,S2 W1 W2 S3 W4 W3 Figure 1: Spike tree. Dashed lines separate mutually inconsistent constraints. Solid lines denote set inclusion (solution-space inclusion). Example: if two people of equal rank in an organisation want to schedule a meeting, and one of them prefers the hours before 11am while the other prefers 4-6pm, it would be unfair to choose one time rather than the other, which is what HCLP would do with a predicate comparator. Hence the name Fair HCLP. However, if the company president prefers any part of the afternoon to any part of the morning, it is no longer unfair to choose a time between 4pm and 6pm. In other words, if one of the two clashing preferences contradicts a more important constraint, then it is ignored and does not cause any unfairness. What does it mean to say that FHCLP bans clashes? There are three alternatives: FH1: Any hierarchy containing mutually inconsistent `relevant' constraints at the same level of preference is deemed to have no solutions. This is similar to the case in standard CLP, inconsistent constraints lead to failure and an empty solution set, or in HCLP if the contradictory constraints are both required. De nition of relevance: all constraints at level 0 are relevant. A constraint at level n is relevant i it does not contradict a relevant constraint at level m, for any m < n. This allows for very e cient implementation (see below), but loses one of the motivations for HCLP, which is that once we have satis ed the required constraints we are guaranteed to get a solution (except in certain pathological situations [2]). The optional constraints simply choose the best, if there is more than one. To have a consistent set of required constraints but still be told `no solutions' due to a lower-level clash might be considered a failure of some kind of `liveness' condition. 2 FH2: If level j (j > 0) of the hierarchy contains mutually inconsistent relevant constraints, all levels greater than or equal to j are ignored. The solutions are just the solutions to the hierarchy of levels 0 to j 1. 2 3 FH3: If level j (j > 0) of the hierarchy contains mutually inconsistent relevant constraints, just those constraints are discarded2, and we continue to solve the rest of the hierarchy. Example: if two people of equal rank in an organisation want to schedule a meeting, and one of them prefers the hours before 11am while the other prefers 4-6pm, and the least important person in the organisation likes to have meetings at 2pm, then that is the time that will be chosen, as the more important constraints will have been discarded. 2 Allowing weaker preferences to override stronger ones which have been `knocked-out', as in FH3, might seem too radical. Therefore, given the lack of liveness of FH1, FH2 seems the most sensible of the three alternatives. For ease of presentation, the implementation strategy for FH2 will be discussed after that for FH1. FH1 could be implemented in the following way: sort the constraints by the preference order. For each constraint, if it contradicts a previously encountered constraint which was more preferred, discard it. If it contradicts a previously encountered constraint at the same level, stop with `failure'. If all the constraints are of the same strength, no matter what its strength label is, this collapses into a standard CLP implementation. More interesting, the implementation only needs to remember two levels of constraints: one is `all levels more preferred than this one' and the other is `this level'. The moment the label changes, the current level can be merged into the previous ones, and then re-initialised to be empty of any constraints at the new, lower, level. The merge will never fail, as any inconsistent constraints have already been discarded. But what if a weak constraint contradicts a medium which itself contradicts