Generalizing finite domain constraint solving

Abstract

This paper summarizes a constraint solving technique that can be used to reason effectively in the scope of a constraint language that supersedes common finite domain languages available in the litera-ture. The first part of this paper motivates the presented work and in-troduces the constraint language, namely Hereditarily Finite Sets (HFS) language. Then, the proposed constraint solver is detailed in terms of a set of rewrite rules which exploit finite domain reasoning within the HFS language. The presented approach achieves good efficiency without loosing the desired correctness and completeness properties that other solvers for HFS provide.

Full text

Page 1

Generalizing Finite Domain Constraint Solving
Federico Bergenti, Alessandro Dal Pal` u, and Gianfranco Rossi
Dipartimento di Matematica
Universit` a degli Studi di Parma
Viale G. P. Usberti, 53/A
43100 Parma, Italy
{federico.bergenti,alessandro.dalpalu,gianfranco.rossi}@unipr.it
Abstract. This paper summarizes a constraint solving technique that
can be used to reason effectively in the scope of a constraint language
that supersedes common finite domain languages available in the litera-
ture. The first part of this paper motivates the presented work and in-
troduces the constraint language, namely Hereditarily Finite Sets (HFS)
language. Then, the proposed constraint solver is detailed in terms of
a set of rewrite rules which exploit finite domain reasoning within the
HFS language. The presented approach achieves good efficiency without
loosing the desired correctness and completeness properties that other
solvers for HFS provide.
1 Introduction and Motivation
Finite Domain (FD) [5] constraint solvers have been effectively applied to a
great variety of problems in different application domains. Unfortunately, FD
constraint solving typically suffers from an inherent weakness from the point of
view of (i) expressive power and (ii) required a priori knowledge.
From the point of view of expressive power, FD constraint languages force
the domains of variables to bounded intervals (subset of a discrete universe,
often Z), which may lead to severe limitations in real-world applications where
domains of variables are often sparse sets, possibly of structured entities [12].
As a matter of fact, the use of intervals introduces an approximation in the
representation of domains that may result in reduced effectiveness of constraint
solving. Some constraint solvers address this issue and provide a means to deal
with non-interval domains, e.g., (i) FD set terms [20] of SICStus allow modeling
domains in terms of finite unions of intervals, and (ii) GNU Prolog transparently
switches between sparse and interval domain representations [5].
Furthermore, forcing domains in Z inhibits a natural representation of struc-
tured knowledge. The recent introduction of Finite Set (FS) constraints [11] aims
at overcoming such limitations because FS constraints model domains as collec-
tions of known sets. Such domains are normally expressed in terms of set intervals
[l..u] where l and u are known sets, usually of integers. A set interval [l..u] rep-
resents the set of all subsets of u that contain l, i.e., [l..u] = {x : x ⊆ u∧l ⊆ x}.
Many constraint solvers (including many CLP systems) now offer FS constraints,
e.g., ECLiPSe [14], Oz [19] and B-Prolog [22].

Page 2

FS constraints are explicitly derived from FD constraints and therefore they
retain the appreciated efficiency of the latter, while inheriting many of their
problems and limitations. In particular, available FS constraint solvers, e.g.,
Conjunto [11] and Cardinal [2], treat efficiently only interval domains that are
defined as the convex closure of a collection of elements. For example, given a
variable whose domain is {{a,b},{a,c},{d}}, the corresponding interval domain
is the set interval [{}..{a,b,c,d}].
Besides the mentioned expressive power limitations, it is also worth discussing
another important limitation of FD-like constraint languages. The practice of us-
ing FD-like reasoning in knowledge representation has shown that domains are
often unknown prior to reasoning and an important side effect of reasoning is re-
vealing the shape of domains. In many real-world cases, domains are not available
prior to computation, and they have to be acquired and/or computed; anyway,
constraints over them are often known in advance. Mentioned situations are not
really tractable with FD-like languages because their solvers typically attach
a possibly implicit (and redundant) domain to each variable before processing
constraints.
The difficulties connected with required a priori knowledge in FD-like reason-
ing are explicitly tackled by [10], which extends CLP(FD) to deal with incom-
plete knowledge on domains. The proposed system is based on the Interactive
CSP approach [6] and it uses domains as communication channels between the
CLP(FD) solver and an acquisition system.
The mentioned limitations in terms of expressive power and required a priori
knowledge do not reduce the notable importance of FD-like constraint languages
and solvers for their proved effectiveness in handling a great variety of problems.
Nonetheless, the urge for expressive power to support modeling of complex do-
mains that real-world applications require justifies the definition of constraint
languages and solvers that trade-off efficiency with expressive power and com-
pleteness, e.g., CLP(SET ) [9] and CLPS [4].
In particular, CLP(SET ) provides a constraint language that subsumes most
of the mentioned FD-like languages while delivering a correct and complete
constraint solver, at the cost of notable inefficiency. More in details, CLP(SET ),
and its Java porting JSetL [18], support modeling domains in terms of generic
extensional sets, usually called Hereditarily Finite Sets (HFS), that contain any
kind of object (and nested finite sets in particular). Moreover, such sets can be
constructed dynamically by means of common set operations and it is worth
mentioning that constraint solving can take place even over partially or totally
unspecified sets.
Unfortunately, the constraint solver of CLP(SET ) does not exploit the in-
formation that the domain of variables provides, and it does not even explicitly
express that a variable may have a domain. This leads to a very weak form of
propagation and most of constraint solving is basically a generate & test. For
example, given the following problem x ∈ {1,2,3,4,5}∧x ?= 10, the CLP(SET )
solver enumerates all possible values of x before asserting that x ?= 10 holds.

Page 3

While the expressive power and the computational features of CLP(SET )
make it a good candidate to deliver a constraint language capable of addressing
the mentioned issues of FD-like languages and solvers, the inefficiencies of avail-
able implementations of CLP(SET ) prohibit its instant use in many problems
where FD-like solvers proved their relevance. A step towards a more effective use
of the CLP(SET ) language is represented by CLP(SET ,FD) [7] which integrates
FD constraints into CLP(SET ) thus allowing efficient processing of the former
through the use of an embedded FD solver. Advantages, however, are limited
to FD constraints only: CLP(SET ,FD) still retains the overall constraint solv-
ing technique of CLP(SET ), with no possibility to exploit domain information
except for the handling of FD constraints.
The overall goal of this paper is to combine the flexibility and expressive
power of CLP(SET )-like languages with the efficiency of FD-like languages, in
a more general manner. In order to achieve this goal, we propose to integrate
FD, FS and CLP(SET ) constraints into a single, uniform constraint language
and to extend the domain-driven constraint solving techniques of FD and FS to
the whole solver. For this reason, we develop a new (set) constraint solver that
replaces the standard CLP(SET ) solver and that exploits the information on
domains of variables to obtain improved efficiency.
The resulting language and solver can be viewed as a generalization of the
languages of FD and FS constraints, in which domains are allowed to be general
sets, containing elements of any kinds, possibly nested and partially specified.
On the other hand, the work described in this paper can be viewed as a gen-
eralization of [7], that allows retaining the expressive power of CLP(SET ) while
permitting the efficient processing of a larger class of CLP(SET ) constraints.
The paper is organized as follows. Next section presents the language of
HFS-constraints, focusing on the notion of variable domain. In Section 3, we first
present the architecture of the proposed constraint solver, and then we detail the
solver in terms of a set of rewrite rules which exploit FD-like reasoning within
the HFS language. Finally, in Section 4 we summarize the current state of the
implementation of our proposal and we point out some future work.
2 The HFS Constraint Language
This section details the syntax and semantics of the constraint language that we
consider in this work. It also highlights the peculiar features that the language
provides for treating domains of variables, which we exploited in the constraint
solver reported in the next section.
The language described here is a minor extension of the constraint language
provided by the CLP language CLP(SET ), and the Java library JSetL, which
delivers (most of) CLP(SET ) facilities for set solving in an object-oriented lan-
guage framework.

Page 4

2.1 Syntax and semantics
As usual, the syntax of the language is defined by its signature Σ that is a triple
?V,F,Π? where V is a fixed finite set of variables, F is the set of constant and
function symbols, and Π is the set of constraint predicate symbols allowed in
the language.
The set F of constant and function symbols is
{∅,ins,int} ∪ Z ∪ FZ∪ FU
where: ∅, ins, and int are the set constructors; Z is the denumerable set of con-
stants representing the integer numbers, i.e., Z = {0,−1,1,−2,2,...}; FZ is
a set of function symbols representing operations over integer numbers, such
as +,−,∗,div,mod; FU is a (possibly empty) set of user-defined constant and
function symbols.
The set Π of constraint predicate symbols is
{=} ∪ ΠS∪ R ∪ {set,integer} ∪ Neg
where: ΠS is a set of predicate symbols representing the usual set-theoretic
operations, such as ∈,⊆,union,inters,||,diff,size; R is a set of predicate symbols
representing the usual comparison relations over integer numbers, such as ≤,>;
Neg is a set of predicate symbols representing the negated counterparts of most
of other predicate symbols, such as ?=, ?∈, not integer.
A primitive HFS-constraint is any atomic predicate built using the symbols
from the signature. A non-primitive HFS-constraint is a conjunction of primitive
HFS-constraints.
The intuitive semantics of the various symbols is as follows1. The symbol ∅
represents the empty set. ins(t,s) represents the set composed of the element
t union the elements of the set s, i.e., {t} ∪ s. For example, ins(1,s), where s
is an uninitialized variable, represents the (unbounded) set {1} ∪ s. int(a,b,s)
represents the set composed of the elements in the interval [a,b] union the el-
ements of the set s. If a, b are integer constants, [a,b] is the set of integers
{x : x ≥ a∧x ≤ b}; if a, b are ground terms denoting sets, [a,b] is the set of sets
{x : a ⊆ x ∧ x ⊆ b}, that is the bounded lattice induced by the subset relation
⊆ having a as its greatest lower bound and b as its least upper bound.
It is worth noting that ins and int are different constructors for terms de-
noting the same notion of set. Thus, terms constructed using ins and int can be
tested, e.g. for equality, and they can be combined. For example, ins(1,int(10,20,
ins(100,∅))) represents the set containing all integers between 10 and 20 with
the integers 1 and 100. We call a term built using the set constructors ins and
int an extended set term.
The predicates = and ∈ represent the equality and the membership relation-
ships, respectively; the predicate union represents the union relation: union(r,s,t)
1A formal discussion of these concepts is out of the scope of this paper and can be
found in [7]

Page 5

holds iff t = r ∪ s; the predicate || represents the disjoint relationship between
two sets: s || t holds iff s ∩ t = ∅; and so on.
Symbols in Z are mapped to the elements of Z, while functions in FZ and
the predicate symbols ≤,≥, etc. are mapped to functions and relations over Z
in the natural way.
We say that a HFS-constraint containing only predicates taken from {=,?=
,∈,?∈,union,||,≤,size,set,integer} is in canonical form. As a matter of fact, [9]
shows that all other predicates in Π can be defined as non-primitive constraints
using the above together with the HFS theory.
Sets are defined by means of the set constructors ins and int as shown above.
For the sake of simplicity, however, we will often use the following more conve-
nient notations:
{t1|t}
as a shorthand for
ins(t1,t)
and
{t1.. t2|t}
as a shorthand for
int(t1,t2,t)
writing {t1} and {t1.. t2}, respectively, when t is the empty set. This notation
is easily extended to the case of n elements (possibly mixing the ins and int
constructors, e.g., {1,10..20,100}). With a little abuse of terminology, we call a
syntactic object of the form t1..t2a range term.
Various concrete language facilities are provided to make set definition sim-
pler. For example, in JSetL, we can provide an array of elements when creating
a set object; furthermore, an interval of integers can be specified at set creation
by giving the lower and upper bounds of the interval. In CLP(SET ), a special
syntax is provided to denote a set obtained by n applications of the set construc-
tor ins as a list of n elements with curly brackets, as in the usual mathematical
notation.
Elements of a set can be values of any type (not necessarily homogeneous),
including logical variables and other sets. Hence, sets can be nested at any level,
e.g., {1,{∅,{a}},{{{b}}}}. Moreover, sets can be partially specified, i.e., they
can contain uninitialized logical variables in place of single elements.
It is worth noting that we assume that the constraints of the language deal
naturally with set terms made of single elements and intervals, possibly mixed
together. For example:
– 13 ∈ {1..10,15,20..100}
– union({1,5,7},{3..6},R)
– {1,3,x} = {1..3}
are all admissible HFS-constraints, whose solved forms are: false, R = {1,3..7},
and x = 2, respectively. The availability of extended set terms is particularly
useful to represent non-interval sets, e.g., the ones obtained from the constraint
diff({1..10},{5},R), whose solved form is R = {1..4,6..10}.