nextupprevious
Next: Decomposing Problems into Sub-problems using XOR-constraints Up: The GRT Planning System Previous: Local Optimal States

5.2  Defining XOR-constraints

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.

 

nextupprevious
Next: Decomposing Problems into Sub-problems using XOR-constraints Up: The GRT Planning System Previous: Local Optimal States

Ioannis Refanidis

14-8-2001