In order to avoid local optimal
states, we provide Grt with
knowledge of relations between facts, where exactly one of the facts can hold
in each state. We call these relations XOR-constraints.
Definition 2 (XOR-constraint). An XOR-constraint is a relation between
ground facts. The relation is valid in a state, if exactly one of the
participating facts holds in that state.
The general form of an
XOR-constraint schema is the following:
((xor f1 f2 ...) c1 c2 ...)
where fi are the
facts that cannot co-appear in any state and ci are static
facts that provide supplementary conditions such as type constraints, relations
between objects, etc.
XOR-constraints can be
formalized for almost any domain. For example, in the logistics domain
we could define the following XOR-constraints:
( (xor ( at ?Truck *
) ) ( truck ?Truck ) )
( (xor ( at
?Plane * ) ) ( plane ?Plane ) )
( (xor ( at ?Package * ) (in
?Package * ) ) ( package ?Package ))
Question marks (?)
precede named variables, whereas asterisks (*) denote no-named ones. The
definitions mean that for every instantiation of the named variables that
appear in an XOR-constraint and for all the valid instantiations of the
no-named variables, according to the predicate definitions, exactly one ground
fact can hold in each valid and complete state. The above XOR-constraints
schemas are general definitions that can be grounded in several ways, according
to the different ways in which their named variables can be instantiated.
In some cases, it is
possible to have XOR-constraints that incorporate AND relations. For example,
if in the logistics domain the predicate (out ?Package) is defined, which means that a package is not loaded
either in a truck or in a plane, then the relevant constraint should be
written:
( ( xor ( and ( ( at ?Package * ) ( out
?Package ) ) ( in ?Package * ) )
( package ?Package ) )
Note that some facts
may not appear in any XOR-constraint, while some others may appear in more than
one. Henceforth, we refer to facts that appear in at least one XOR-constraint
as XOR-constrained facts.
It is a requirement of
the current version of Grt that
the XOR-constraints are included in the domain definition. However, they could
be computed analytically, based on the mutual exclusion relations between the
facts of a problem, since mutually exclusive facts cannot appear simultaneously
in any valid state. However, providing them manually allows for some form of
guidance, since the domain engineer can leave out some of them, since they
would lead to pointless decompositions.
The notion of
XOR-constraints is not new in planning. Gerevini and Schubert (1998) proposed a
method for the automatic inference of state constraints from the action
definitions and the initial state. Single
valuedness constraints or sv
constraints are the closest to the XOR-constraints. But sv constraints concern instantiations of
the same predicate, while XOR-constraints can be relations between ground facts
of different predicates. However, in more recent work (2000a, 2000b), they
extended their work to also infer XOR-constraints.
The object oriented
domain specification formalism introduced by McCluskey & Porteous (1997) is
similar to XOR-constraints. According to this, states are not defined as collections
of facts but as collections of objects, each object having its own internal
status. So, XOR-constraints can be implicitly defined from the requirement that
all object attributes are single valued.
Ioannis
Refanidis
14-8-2001