Multi-valued Action Languages in CLP(FD)

12/15/2009 ∙ by Agostino Dovier, et al. ∙ New Mexico State University Università Perugia 0

Action description languages, such as A and B, are expressive instruments introduced for formalizing planning domains and planning problem instances. The paper starts by proposing a methodology to encode an action language (with conditional effects and static causal laws), a slight variation of B, using Constraint Logic Programming over Finite Domains. The approach is then generalized to raise the use of constraints to the level of the action language itself. A prototype implementation has been developed, and the preliminary results are presented and discussed. To appear in Theory and Practice of Logic Programming (TPLP)

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

The construction of intelligent agents that can be effective in real-world environments has been a goal of researchers from the very first days of Artificial Intelligence. It has long been recognized that an intelligent agent must be able to

acquire, represent, and reason with knowledge. As such, a reasoning component has been an inseparable part of most agent architectures in the literature.

Although the underlying representations and implementations may vary between agents, the reasoning component of an agent is often responsible for making decisions that are critical to its existence.

Logic programming languages offer many properties that make them very suitable as knowledge representation languages. Their declarative nature supports the modular development of provably correct reasoning modules [Baral]

. Recursive definitions can be easily expressed and reasoned upon. Control knowledge and heuristic information can be declaratively and incrementally introduced in the reasoning process. Furthermore, many logic programming languages offer a natural support for non-monotonic reasoning, which is considered essential for common-sense reasoning 

[Lif99]. These features, along with the presence of efficient inference engines [Apt2003, MS98, SimonsTesi, GLM04, claspcitaz], make logic programming an attractive paradigm for knowledge representation and reasoning.

In the context of knowledge representation and reasoning, a very important application of logic programming has been in the domain of reasoning about actions and change and, more specifically, planning. Planning problems have been effectively encoded using Answer Set Programming (ASP) [Baral]—where distinct answer sets represent different trajectories leading to the desired goal. Other logic programming paradigms, e.g., Constraint Logic Programming over Finite Domains (CLP(FD)) [CLP1, Apt2003], have been used less frequently to handle problems in reasoning about actions (e.g., [rei01, thielscher]). Comparably more emphasis has been placed in encoding planning problems as (non-logic programming) constraint satisfaction problems [lopezbacchus].

Recent proposals on representing and reasoning about actions and change have relied on the use of concise and high-level languages, commonly referred to as action description languages; some well-known examples include the languages and  [GL98] and extensions like  [Eiter-K] and  [BaralS02]. Action languages allow one to write propositions that describe the effects of actions on states, and to create queries to infer properties of the underlying transition system. An action domain description is a specification of a planning domain using an action language.

The goal of this work is to explore the relevance of constraint solving and constraint logic programming [MS98, Apt2003] in dealing with action languages and planning. The push towards this exploratory study came from recent investigations [DFPiclp05, JETAI08] aimed at comparing the practicality and efficiency of answer set programming versus constraint logic programming in solving various combinatorial and optimization problems. The study indicated that CLP offers a valid alternative, especially in terms of efficiency, to ASP when dealing with planning problems. Furthermore, CLP offers the flexibility of programmer-developed search strategies and the ability to handle numerical constraints.

The first step, in this paper, is to illustrate a scheme that directly processes an action description specification, in a language similar to  [GL98], producing a CLP(FD) program that can be used to compute solutions to the planning problem. Our encoding has some similarities to the one presented by Lopez and Bacchus [lopezbacchus], although we rely on constraint logic programming instead of plain constraint satisfaction (CSP), and our action language supports static causal laws and non-determinism—while the work of Lopez and Bacchus is restricted to STRIPS-like specifications.

While the first step relies on using constraints to compute solutions to a planning problem, the second step brings the expressive power of constraints to the level of the action language, by allowing multi-valued fluents and constraint-producing actions to be used in the domain specification. The extended action language (named ) can be as easily supported by the CLP(FD) framework, and it allows a declarative encoding of problems involving actions with resources, delayed effects, and maintenance goals. These ideas have been developed in a prototype, and some preliminary experiments are reported.

We believe that the use of CLP(FD) can greatly facilitate the transition of declarative extensions of action languages to concrete and effective implementations, overcoming some inherent limitations (e.g., efficiency and limited handling of numbers) of other logic-based systems (e.g., ASP).


The presentation is organized as follows. The first part of our paper (Sections 2 and 3) provides an overview of the action language and illustrates our approach to modeling problem specifications in using constraints and constraint logic programming. Section 4 provides motivations for the proposed multi-valued extensions. Section 5 introduces the full syntax of the new language . The action language  expands the previous language to a language with constraints and multi-valued fluents, that enables the use of dynamic and static causal laws (a.k.a. state constraints), executability conditions, and non-Markovian forms of reasoning with arbitrary relative or absolute references to past and future points in time. The semantics and the abstract implementation of  is incrementally developed in Section 6, where we first consider a sub-language not involving non-Markovian references, and later we extend it to the full . A concrete implementation in CLP(FD) is described in Section 7, and an experimental evaluation is discussed in Section 8. Section LABEL:sec:related presents an overview of related efforts appeared in the literature, while Section LABEL:sec:endofit presents conclusions and the directions for future investigation.

2 The Action Language

“Action languages are formal models of parts of the natural language that are used for talking about the effects of actions” [GL98]. Action languages are used to define action descriptions that embed knowledge to formalize planning problems. In this section, we use the same variant of the language used in [SON01]—see also Section LABEL:sec:related for a comparison. With a slight abuse of notation, we simply refer to this language as .

2.1 Syntax of

An action signature consists of a set of fluent names, a set of action names, and a set of values for fluents in . In this section, we consider Boolean fluents, hence .111For simplicity, we use to denote false and to denote true. Consequently, we often say that a fluent is true (resp., false) if its value is (resp., ). A fluent literal is either a fluent or its negation . Fluents and actions are concretely represented by ground atomic formulae from an underlying logic language . For simplicity, we assume that the set of terms is finite—e.g., either there are no function symbols in , or the use of functions symbols is restricted, for instance by imposing a fixed maximal depth on the nesting of terms, to avoid the creation of arbitrary complex terms.

The language allows us to specify an (action) domain description . The core components of a domain description are its fluents—properties used to describe the state of the world, that may dynamically change in response to execution of actions—and actions—denoting how an agent can affect the state of the world. Fluents and actions are introduced by assertions of the forms fluent() and action(). An action description relates actions, states, and fluents using axioms of the following types —where [list-of-conditions] denotes a list of fluent literals:222We will sometimes write true as a synonymous for the empty list of conditions.

  • causes(, , [list-of-conditions]): this axiom encodes a dynamic causal law, describing the effect (i.e., truth assignment to the fluent literal ) of the execution of action in a state satisfying the given conditions

  • caused([list-of-conditions], ): this axiom describes a static causal law—i.e., the fact that the fluent literal is true in any state satisfying the given preconditions.

Moreover, preconditions can be imposed on the executability of actions by means of assertion of the forms:

  • executable(, [list-of-conditions]): this axiom asserts that, for the action to be executable, the given conditions have to be satisfied in the current state.

A domain description is a set of static causal laws, dynamic laws, and executability conditions. A specific planning problem contains a domain description along with a set of observations describing the initial state and the desired goal:

  • initially() asserts that the fluent literal is true in the initial state

  • goal() asserts that the goal requires the fluent literal to be true in the final state.

In the specification of an action theory, we can take advantage of a Prolog-like syntax to express in a more succinct manner the laws of the theory. For instance, to assert that in the initial state all fluents are true, we can simply write the following rule:

instead of writing a fact initially() for each possible fluent . Remember that the notation is a syntactic sugar for the logical formula

where are all the variables present in .

%% Some Type Information barrel(5). barrel(7). barrel(12). liter(0). liter(1). liter(12). %% Identification of the fluents fluent(cont(B,L)):- barrel(B), liter(L), L B. %% Identification of the actions action(fill(X,Y)):- barrel(X), barrel(Y), X Y. %% Dynamic causal laws causes(fill(X,Y), cont(X,0), [cont(X,LX), cont(Y,LY)]) :- action(fill(X,Y)), fluent(cont(X,LX)), fluent(cont(Y,LY)), Y-LY LX. causes(fill(X,Y), cont(Y,LYnew), [cont(X,LX), cont(Y,LY)]) :- action(fill(X,Y)), fluent(cont(X,LX)), fluent(cont(Y,LY)), Y-LY LX, LYnew is LX+LY. causes(fill(X,Y), cont(X,LXnew), [cont(X,LX), cont(Y,LY)]) :- action(fill(X,Y)), fluent(cont(X,LX)), fluent(cont(Y,LY)), LX Y-LY, LXnew is LX-Y+LY. causes(fill(X,Y), cont(Y,Y), [cont(X,LX), cont(Y,LY)]) :- action(fill(X,Y)), fluent(cont(X,LX)), fluent(cont(Y,LY)), LX Y-LY. %% Executability conditions executable(fill(X,Y), [cont(X,LX), cont(Y,LY)]) :- action(fill(X,Y)), fluent(cont(X,LX)), fluent(cont(Y,LY)), LX > 0, LY < Y. %% Static causal laws caused([cont(X,LX)], neg(cont(X,LY))) :- fluent(cont(X,LX)), fluent(cont(X,LY)), barrel(X), liter(LX), liter(LY), LXLY. %% Description of the initial and goal state initially(cont(12,12)). initially(cont(7,0)). initially(cont(5,0)). goal(cont(12,6)). goal(cont(7,6)). goal(cont(5,0)).
Figure 1: description of the 12-7-5 barrels problem.
Example 1

Figure 1 presents an encoding of the three-barrel planning problem using the language . There are three barrels of capacity (an even number), , and , respectively. At the beginning, the largest barrel is full of wine while the other two are empty. We wish to reach a state in which the two larger barrels contain the same amount of wine. The only permissible action is to pour wine from one barrel to another, until the latter is full or the former is empty. Figure 1 shows the encoding of the problem for . Notice that we also require that the smallest barrel is empty at the end.    

2.2 Semantics of

If is a fluent, and is a set of fluent literals, we say that if and only if and if and only if . A list of literals denotes a conjunction of literals, hence if and only if for all . We denote with the set A set of fluent literals is consistent if there is no fluent s.t. and . If then is complete. A set of literals is closed w.r.t. a set of static laws , if for all it holds that implies . The set is defined as the smallest set of literals containing and closed w.r.t. . is uniquely determined and not necessarily consistent.

The semantics of an action language on the action signature is given in terms of a transition system [GL98], consisting of a set of states, a total interpretation function (in this section ), and a transition relation .

Given a transition system and a state , let:

Observe that is consistent and complete.

Given a set of dynamic laws , , for the action and a state , we define the (direct) effects of in as follows:

The action is said to be executable in a state if it holds that

(1)

where , , for , are the executability axioms for the action in . Observe that multiple executability axioms for the same action are considered disjunctively. Hence, for each action , at least one executable axiom must be present in the action description.333Observe that even if an action is “executable”, its execution may lead to an inconsistent state (which effectively prevents the use of such action in that context). Even though “enabled” would be a better term to use for an action that can be executed in a state, we prefer to maintain the same terminology as used for in [SON01]—see also Remark 2.

Let be an action description defined on the action signature , composed of dynamic laws , executability conditions , and static causal laws .

The transition system described by is a transition system such that:

  • is the set of all states such that is closed w.r.t. ;

  • is the set of all triples such that is executable in and

    (2)

Let be a planning problem instance, where is a consistent and complete set of fluent literals. A trajectory in is a sequence

such that for all .

A sequence of actions is a solution (a plan) to the planning problem if there is a trajectory in such that:

  • for each , and

  • for each .

The plans characterized in this definition are sequential—i.e., we disallow concurrent actions. Observe also that the desired plan length is assumed to be given.

Remark 1

In this paper we focus on sequential plans only. Hence, we assume that only one action is executed in each state transition composing a given trajectory.

Note that the constraint-based encoding we will propose in the rest of this manuscript can be easily adapted to deal with concurrent actions. Nevertheless, we have opted to ignore this aspect in this manuscript, to avoid further complications of notation, and dealing with issues of concurrency goes beyond the scope of this paper. The interested reader is referred to [DFPlpnmr09] for some further considerations on this matter.

Remark 2

Notice that the satisfaction of (1) is just a necessary requirement for the executability of an action and it might not represent a sufficient precondition. Indeed, as far as the definition of transition system is considered, it is easy to see that, even if (1) is satisfied for certain and , the execution of in might be inhibited because of the contradictory effects of the causal laws. A simple example is represented by the following action description :

executable(,[]).
causes(,,[]).
causes(,neg(),[]).

The action is always executable (according to its executability law), but the execution of would yield an inconsistent situation. Indeed, the execution of does not correspond to any state transition in the transition system described by .

The above example also suggests a possible extension of the action description language that involves laws of the form

The semantics for such an extended action language can be defined by replacing the condition (1), with the following one:

where executable(, ), , executable(, ) and nonexecutable(, ), , nonexecutable(, ), for and , are defined for the action . Thus, the action is executable only if at least one of the s is satisfied and all s are unsatisfied in the state .

An alternative interpretation of the nonexecutable axioms can be adopted. Namely, the law nonexecutable(, ) can be considered simply as shorthand for the pair of dynamic causal laws causes(, , ) and causes(, neg(), ). (Actually, this possibility also applies to the languages proposed in [GL98]).

This shows that (non)executability laws do not increase the expressive power of the action language. Nevertheless, the availability of both types of laws permits the direct and explicit formalization of preconditions for actions execution.

3 Modeling and Planning Problems Using Constraints

Let us describe how action descriptions are mapped to finite domain constraints. We will focus on how constraints can be used to model the possible transitions from each individual state of the transition system.

FromState3(100,80)(100,120) ToState3(300,80)(300,120) 3(200,100)(200,115)
Figure 2: Action constraints from state to state. (The states are described by fluents, , and one among possible actions is executed.)

3.1 Modeling an Action Theory as Constraints

Let us consider a domain description and the state transition system described by . Let us also denote with and the starting and ending states of an arbitrary transition of such a system. We assert constraints that relate the truth value of fluents in and . This is intuitively illustrated in Figure 2, where and .444For the sake of readability, the two variables named FromState and ToState are also used in the concrete implementation of (cf., Section 3.3 and Figure 6).

A Boolean variable is introduced to describe the truth value of each fluent literal in a state. The value of a fluent literal in is represented by the variable ; analogously, its value in the destination state is represented by the variable . For the sake of simplicity, we will freely refer to these variables as Boolean entities—and compose them with logical connectives to form Boolean expressions—as well as 0/1 variables—and compose them with arithmetic operators. Concrete CLP(FD) systems, e.g., SICStus, ECLiPSe, and BProlog,555Web sites for some CLP(FD) systems. SICStus: www.sics.se/sicstus.html, ECLiPSe: http://87.230.22.228/, BProlog: http://www.probp.com/ enable this type of alternative perspectives, providing basic primitive constraints (e.g., #= and #>) and Boolean compositions of constraints.

Given a conjunction of literals we will denote with the expression . We will also introduce, for each action , a Boolean variable , representing whether the action is executed or not in the transition from to under consideration.

Given a specific fluent literal , we develop constraints that determine when is true and false. Let us consider the dynamic causal laws that have as a consequence:

Let us also consider the static causal laws related to

Finally, for each action we will have its executability conditions:

(3) (4) (6) (7)

Figure 3: The constraint for the fluent literal (cf., Section 3.1).

Figure 3 describes the Boolean constraints that can be used in encoding the relations that determine the truth value of the fluent literal . In the table, we denote with the complement of literal , i.e., if is the fluent , then is , while if is the literal then is the fluent . The intuitive meaning of the constraints is as follows:

(3)

This constraint states that dynamic causal laws making true can fire if their conditions are satisfied and the corresponding actions are chosen for execution.

(4)

This constraint captures the fact that at least one of the static causal laws that make true is applicable.

(6)

This constraint expresses the fact that a fluent literal can be made true during a transition form state to state , either by a dynamic causal law (determined by ) or a static causal law (determined by ).

(6)

This constraint is used to guarantee consistency of the action theory—in no situations a fluent and its complement are both made true.

(7)

This constraint expresses the fact that a fluent literal is true in the destination state if and only if it is made true (by a static or a dynamic causal law) or if is true in the initial state and its truth value is not modified by the transition (i.e., inertia). Observe the similarity between this constraint and the successor state axiom commonly encountered in situation calculus [sitcalc].

We will denote with the conjunction of such constraints.

Given an action domain specification over the signature and two states and , we introduce the system of constraints which includes:

  • for each fluent literal in the language of , the constraints .

  • the constraint

    (8)
  • for each action , the constraints

    (9)

Notice that the sequentiality of the plan if imposed through the constraint (8), while constraint (9) reflects actions’ executability conditions.

3.2 Soundness and Completeness Results

Let us proceed with the soundness and completeness proofs of the constraint-based encoding. Consider a state transition from the state to the state and the corresponding constraint described earlier.

Let and be the sets of fluent literals that hold in and , respectively. Note that, from any specific (resp., ), we can obtain a consistent assignment (resp., ) of truth values for all the variables (resp., ) of (resp., ). Conversely, each truth assignment (resp., ) for all variables (resp., ) corresponds to a consistent and complete set of fluents (resp., ).

Regarding the occurrence of actions, recall that in each state transition a single action occurs and its occurrence is encoded by a specific Boolean variable, . Let denote the assignment of truth values for such variables such that if and only if occurs in the state transition from to .666We will use mapping applications either as or in postfix notation as . Note that the domains of , , and are disjoint, so we can safely denote with the composition of the three assignments. With a slight abuse of notation, in what follows we will denote with the direct effects of an action in . Observe that .

Theorem 1 states the completeness of the system of constrains introduced in Section 3.1. It asserts that for any given , if a triple belongs to the transition system described by , then the assignment satisfies the constraint .

Theorem 1 (Completeness)

Let . If belongs to the transition system described by , then is a solution of the constraint .

In constraints (3)–(7) of Figure 3 and (8)–(9) defined at the end of Subsection 3.1, a number of auxiliary constraint variables are defined, whose values are uniquely determined once the values of the fluents are assessed. In other words, when , , and are fixed, the substitution uniquely determines the value of the right-hand sides of the constraints . To prove the theorem, we need to verify that if , then the constraints and along with the constraints about the action variables (i.e., constraints of the form (8) and (9)) are satisfied for every fluent .

Let us observe that (8) is equivalent to say that if is true () then is false for all . Moreover, it also states that if all for are false then is true. Namely, (8) is equivalent to the conjunction, for of:

Let us start by looking at the action occurrence. Let be the action executed in state , thus . Hence, (8) is satisfied by .

Similarly, since the semantics require that actions are executed only if the executability conditions are satisfied, it holds that (for at least one , corresponding to a condition in ). This quickly leads to is true, and this allows us to conclude that (9) is satisfied by .

Let us now consider the constraints dealing with fluents. We recall that is a set of fluent literals that is consistent, complete, and closed w.r.t. . Let us consider a fluent and let us prove that constraint of Figure 3 is satisfied. Assume, by contradiction, that and are both true. Four cases must be considered:

  1. and are true. Since these values are determined by , this means that both and belong to . Since the closure under is monotonic this means that is inconsistent, representing a contradiction.

  2. and are true. This means that is in and is added to by the closure operation. This implies that is inconsistent, which represents a contradiction.

  3. and are true. This leads a contradiction as in the previous case.

  4. and are true. This means that and are added to by the closure operation. Thus, is inconsistent, which is a contradiction.

It remains to prove that constraint is satisfied by . Let us assume that . Thus, is true. Three cases must be considered.

  1. . This means that there is a dynamic causal law where . From the definition, this leads to being true and . Thus, constraints and set and both true. As a consequence, constraint is satisfied.

  2. and . This means that . In this case must be false, otherwise would be inconsistent (by closure). Thus, should be true, is true and is false, which satisfy constraint (regardless of the value of ).

  3. and . This means that is inserted in by closure. Thus, there is a static causal law of the form such that . In this case, by , is true and, by , so is . Thus, constraint is satisfied.

If , then and the proof is similar with positive and negative roles interchanged.

Let us observe that the converse of the above theorem does not necessarily hold. The problem arises from the fact that the implicit minimality in the closure operation is not reflected in the computation of solutions to the constraint. Consider the domain description where and , with the following laws:

executable(,[]). caused([],).
causes(,,[]). caused([],).

Let us consider . Then, determines a solution of the constraint with the execution of action , but . However, the following holds:

Theorem 2 (Weak Soundness)

Let . Let identify a solution of the constraint . Then .

It is immediate to see that and uniquely determines two consistent and complete sets of fluent literals and . Let be a positive fluent in . We show now that .

  1. If is in we are done.

  2. If , there is a law such that . Since is determined by , by , we have that is a solution of , which implies that is true, and is true in . Therefore, . Observe also that making true will imply that is true (for some ), which will imply satisfiability of the executability preconditions for .

  3. We are left with the case of and . Since is determined by , and , there is a law such that , and by construction makes true. Thus, is true and therefore is true. Hence, .

The proof proceeds similarly in the case of a negative fluent in .

Let us consider the set of static causal laws . We can introduce a notion of positive dependence graph, following the traditional principle of dependence analysis used in logic programming (e.g., [lin]). The graph is defined as follows:

  • the set of the nodes in corresponds to the set of fluent literals, i.e.,

  • edges are created to denote the dependence of a fluent literal on other literals due to a static causal law, i.e.,

A set of fluent literals is a loop if, for any , we have that there is a path from to in such that all nodes encountered in such path are in . We say that a domain specification is acyclic if the graph does not contain any loops.

1.1

Figure 4: Sets of fluents involved in a state transition and a literal introduced by closure.
Theorem 3 (Acyclic Soundness)

Let . Let be a solution of the constraint . If the dependency graph of is acyclic, then .

Theorem 2 proves that . It remains to prove that for any (positive or negative) fluent , if , then .

If or , then trivially .
Let us prove that (cf., Figure 4):

To this aim, consider the dependence graph . Because of the acyclicity of , there are nodes in without incoming edges—we will refer to them as leaves. For any node of , let denote the length of the longest path from a leaf of to . We prove the property for a positive fluent literal , by induction on .

Base case. If is a positive fluent which is a leaf (the proof is similar for the case of negative literals), then two cases could be possible.

  • There is no law of the form in . In this case, it cannot be that due to constraint (4).

  • There is a law . In this case by closure.

Inductive step. Let be a positive fluent such that there are laws in . By the inductive hypothesis, let us assume that the thesis holds for each fluent literal such that . Since and , we have that is false, is true, and is false under . From the fact that constraint  is satisfied, it follows that is true. Moreover, is false because . On the other hand, because of , we have that , , and are all false. Consequently, constraint  can be rewritten as . Since (i.e., is true), there must exists a such that is verified by . This implies that, for each fluent required to be true (resp., false) in , is set true (resp., false) by . By inductive hypothesis, such fluent literals (either or ) belong to . Since is closed w.r.t. the static laws, it follows that .

The proof in case of a negative fluent is similar.

In order to achieve soundness in cases where the graph contains loops, it is necessary to introduce additional constraints in conjunction with . Intuitively, in the semantics of , cyclic dependencies created by the static causal laws are resolved by the closure operation by minimizing the number of fluent literals that are made true—this derives by the implicit minimality of the closure. Additional constraints can be added to enforce this behavior; these constraints can be derived by following a principle similar to that of loop formulae commonly used in the context of logic programming [lin].

The notion of loop formulae can be developed in our context as follows. Let be a loop in and let us consider the transition from to as studied earlier. Let us define a counter-support for w.r.t. the loop as a set of constraints with the following properties:

  • for each in ,   contains either or for some in ;

  • for each in such that none of is in , for some in contains ;

  • contains either or .

(As usual, we might identify a set of constraint with their conjunction, depending on the need.) Let us denote with the set of all such counter-supports. The loop formulae for w.r.t. is the set of constraints

To take into account all different loops in , let be the constraint

Following the analogous proofs relating answer sets and models of a program completion that satisfies loop formulae (e.g., [lin]) one can show:

Theorem 4 (Soundness)

Let and let be a solution of the constraint . Thus, .

Let the action description meet the conditions of Theorem 4 and let be its underlying transition system. The following can be proved.

Theorem 5

There is a trajectory in the transition system if and only if is closed w.r.t. and there is a solution for the constraint

The result follows directly by application of Theorems 1 and 4 and by observing that for each transition , the satisfaction of constraint implies that the state is closed w.r.t. .

Let be an instance of a planning problem where is an action description and contains any number of axioms of the form and . We can state the following.

Corollary 1

There is a trajectory for the planning problem if and only if is closed w.r.t. the static causal laws of and there is a solution for the constraint

3.3 Mapping the Model to CLP(FD)

The modeling described in Section 3.1 has been translated into a concrete implementation using SICStus Prolog. In this translation, constrained CLP variables directly reflect the Boolean variables modeling fluents and action’s occurrences. Consequently, causal laws and executability conditions are directly translated into CLP constraints (and inherit the corresponding completeness and soundness results). In this section we highlight the main aspects of the implementation—while the complete code can be found at www.dimi.uniud.it/dovier/CLPASP.

A plan with exactly states, fluents, and actions is represented by:

  • A list, called States, containing lists, each composed of terms of the form fluent(fluent_name, Bool_var). The variable of the term in the list is assigned if and only if the fluent is true in the state of the trajectory. For example, if we have and the fluents f, g, and h, we have:

    States = [[fluent(f,X_f_0),fluent(g,X_g_0),fluent(h,X_h_0)],
              [fluent(f,X_f_1),fluent(g,X_g_1),fluent(h,X_h_1)],
              [fluent(f,X_f_2),fluent(g,X_g_2),fluent(h,X_h_2)]]
    
  • A list ActionsOcc, containing lists, each composed of terms of the form action(action_name,Bool_var). The variable of the term of the list is assigned if and only if the action occurs during the transition from state to state . For example, if we have and the actions are a and b, then:

    ActionsOcc = [[action(a,X_a_1),action(b,X_b_1)],
                  [action(a,X_a_2),action(b,X_b_2)]]
    

The planner makes use of these structures in the construction of the plan; appropriate constraints are set between the various Boolean variables to capture their relationships. For each list in ActionsOcc, exactly one action(a,VA) contains a variable that is assigned the value (cf., constraint (8)).

clpplan(N, ActionsOcc, States) :- setof(F, fluent(F), Lf), setof(A, action(A), La), make_states(N, Lf, States), make_action_occurrences(N, La, ActionsOcc), setof(F, initially(F), Init), setof(F, goal(F), Goal), set_initial(Init, States), set_goal(Goal, States), set_transitions(ActionsOcc, States), set_executability(ActionsOcc, States), get_all_actions(ActionsOcc, AllActions), labeling(AllActions).
Figure 5: Main predicate of the CLP(FD) planner.

The CLP implementation of the language assumes that the action description is encoded as Prolog facts—observe that the syntax of is compliant with Prolog’s syntax, allowing us to directly store the domain description as rules and facts in the Prolog database. The entry point of the planner is shown in Figure 5.

The main predicate is clpplan(N, ActionsOcc, States) (line (1)) that computes a plan of length for the action description present in the Prolog database. If such a plan exists, the variables in ActionsOcc and States will be instantiated so as to describe the found trajectory.

Lines (2) and (3) collect the lists of all fluents (Lf) and all actions (La). Lines (4) and (5) are used for the creation of the lists States and ActionsOcc. In particular, all the variables for fluents and actions are declared as Boolean variables. Furthermore, a constraint is added to enforce that in every state transition, exactly one action can be fired.

Lines (6) and (7) collect the description of the initial state (Init) and the required content of the final state (Goal). These information are then added to the Boolean variables related to the first and last state, respectively, by the predicates in lines (8) and (9).

Lines (10) and (11) impose the constraints on state transitions and action executability, as described in Section 3.1. We will give more details on this part below.

Line (12) gathers all variables denoting action occurrences, in preparation for the labeling phase (line (13)). Note that the labeling is focused on the selection of the action to be executed at each time step. Some details on the labeling strategy are discussed in Section 8. Please observe that in the code of Figure 5 we omit the parts concerning delivering the results to the user.

The main constraints are added by the predicate set_transitions. The process is based on a recursion across fluents and consecutive states. The predicate set_one_fluent is called (see Figure 6) at the core of the recursion. Its parameters are the fluent F, the starting state FromState, the next state ToState, the list Occ of action variables, and finally the variables IV and EV, related to the value of the fluent F in FromState and ToState, respectively (see also Figure 2).

set_one_fluent(F, IV, EV, Occ, FromState, ToState) :- findall([X,L], causes(X,F,L), DynPos), findall([Y,M], causes(Y,neg(F),M), DynNeg), dynamic(DynPos, Occ, FromState, DynP, EV), dynamic(DynNeg, Occ, FromState, DynN, EV), findall(P, caused(P,F), StatPos), findall(N, caused(N,neg(F)), StatNeg), static(StatPos, ToState, StatP, EV), static(StatNeg, ToState, StatN, EV), bool_disj(DynP, StatP, PosFired), bool_disj(DynN, StatN, NegFired), PosFired*NegFired #= 0, EV #<=> PosFired #\/ (#\ NegFired #/\ IV). dynamic([], _, _, [], _). dynamic([[Action,Precondition]|R], Occ, FromState, [Flag|Flags], EV) :- member(action(Action,VA), Occ), get_precondition_vars(Precondition, FromState, ListPV), length(ListPV, NPrec), sum(ListPV, SumPrec), (VA #/\ (SumPrec #= NPrec)) #<=> Flag, dynamic(R, Occ, FromState, Flags, EV). static([], _, [], _). static([Cond|Others], ToState, [Flag|Flags], EV) :- get_precondition_vars(Cond, ToState, ListPV), length(ListPV, NPrec), sum(ListPV, SumPV), (SumPV #= NPrec) #<=> Flag, static(Others, ToState, Flags, EV).
Figure 6: Transition from state to state.

For a given fluent F, the predicate set_one_fluent collects the list DynPos (respectively DynNeg) of all the pairs [Action,Preconditions] such that the dynamic action Action makes F true (respectively false) in the state transition (lines (15) and (16)). The variables involved are then constrained by the procedure dynamic (lines (17) and (18)).

Similarly, the static causal laws are handled by collecting the lists of conditions that affect the truth value of a fluent F (i.e., the variables StatPos and StatNeg, in lines (19)–(20)) and constraining them through the procedure static (lines (21) and (22)). The disjunctions of all the positive and negative conditions are collected in lines (23) and (24) and stored in PosFired and NegFired, respectively.

Finally, lines (25) and (26) take care of the relationships between all these variables. Line (25) implements the constraint (6) for the state ToState of Figure 3, stating that we do not want inconsistent action theories. If PosFired and NegFired are both false, then (inertia). Precisely, a fluent is true in the next state (EV) if and only if there is an action or a static causal law making it true (PosFired) or it was true in the previous state (IV) and no causal law makes it false.

Let us consider the predicate dynamic (see line (27) in Figure 6). It recursively processes a list of pairs [Action,Preconditions]. The variable VA associated to the execution of action Action is retrieved in line (29). The variables associated to its preconditions are retrieved from state FromState and collected in ListPV in line (30). A precondition holds if and only if all the variables in the list ListPV are assigned value 1, i.e., when their sum is equal to the length, NPrec, of the list ListPV. If (and only if) the action variable VA is true and the preconditions holds, then there is an action effect (line (33)).

Similarly, the predicate static (line (35) in Figure 6) recursively processes a list of preconditions. The variables involved in each of such precondition Cond are retrieved from the state ToState and collected in ListPV (line (37)). A precondition holds if and only if all the variables in the list ListPV have value 1, i.e., when their sum is equal to the length, NPrec, of ListPV. This happens if and only if there is a static action effect (see line (40)).

set_executability_sub([], _, _). set_executability_sub([[Act,C]|CA], ActionsOcc, State) :- member(action(Act,VA), ActionsOcc), preconditions_flags(C, State, Flags), bool_disj(Flags, F), VA #==> F, set_executability_sub(CA, ActionsOcc, State). preconditions_flags([], _, []). preconditions_flags([C|R], State, [Flag|Flags]) :- get_precondition_vars(C, State, Cs), length(Cs, NCs), sum(Cs, SumCs), (NCs #= SumCs) #<=> Flag, preconditions_flags(R, State, Flags).
Figure 7: Executability conditions.

Executability conditions are handled as follows. For each state transition and for each action Act, the predicate set_executability_sub is called (see Figure 7). The variable VA, encoding the application of an action Act is collected in line (44). A precondition hold if and only if the sum of the (Boolean) values of its fluent literals equals their number (lines (52)-(54)). The variable Flags stores the list of these conditions and the variable F their disjunction. If the action is executed (VA = 1, see line (47)), then at least one of the executability conditions must hold.

4 The Action Language with Constraints on Multi-valued Fluents

As a matter of fact, constraints represent a very declarative notation to express relationships between unknowns. As such, the ability to use them directly in an action language greatly enhances the declarative and expressive power of the language, facilitating the encoding of complex action domains, such as those involving multi-valued fluents. Furthermore, the encoding of an action theory using multi-valued fluents leads to more concise and more efficient representations and better exposing non-determinism (that could be exploited, for example, by a parallel planner). Let us consider some representative examples.

Example 2 (Maintenance Goals)

It is not uncommon to encounter planning problems where along with the type of goals described earlier (known as achievement goals), there are also maintenance goals, representing properties that must persist throughout the trajectory. Constraints are a natural way of encoding maintenance properties, and can be introduced along with simple temporal operators. E.g., if the fluent represents the amount of fuel available, then the maintenance goal which guarantees that we will not be left stranded could be encoded as: always().    

Example 3 (Control Knowledge)

Domain-specific control knowledge can be formalized as constraints that we expect to be satisfied by all the trajectories. For example, we may know that if a certain action occurs at a given time step (e.g., ) then at the next time step we will always perform the same action (e.g., ). This could be encoded as

caused([occ()], occ())

where is a fluent describing the occurrence of the action and indicates that the fluent should hold at the next time step.    

Example 4 (Delayed Effect)

Let us assume that the action has a delayed effect (e.g., the increase by $50 of after 30 time units). This could be expressed as a dynamic causal law:

causes(,incr(,),[])

where incr is a constraint introduced to deal with additive computations—in a way closer to ’s syntax we should write:

causes(, = ,[]).

This is a particular case of additive fluents [additive].    

In what follows we introduce the action description language  in which multi-valued fluents are admitted and constraints are first-class components in the description of planning problems. The availability of multi-valued constraints enables a number of immediate language extensions and improves the expressive power of the overall framework.

Action description languages such as rely on the common assumption, traditionally referred to as Markovian property in the context of systems and control theory: the executability of an action and its effects depend exclusively on the current state of the world [gabaldon, elephant]. Nevertheless, it is not uncommon to encounter real world situations where such property is not satisfied, i.e., situations where the executability and/or the effects of an action depend not only on what holds in the current situation, but also on whether some conditions were satisfied at a previous point in time. For example, an agent controlling access to a database should forbid access if in the recent past three failed password submission attempts have been performed by the user.

Although non-Markovian preconditions and effects can be expressed in a Markovian theory through the introduction of additional fluents (and a correct handling of inertia), the resulting theory can become significantly larger and less intuitive. An alternative solution consists of admitting past references in modeling such kind of situations. In this frame of mind,  allows timed references to past points in time within constraints, i.e., non-Markovian expressions that might involve fluents’ values. Effects of dynamic laws that involves future references might also be specified. As a further feature the  language admits the specification of global constraints (involving absolutely specified points in time) and costs for actions and plans.

The resulting description language supports all the kind of modeling and reasoning outlined in the above Examples 24.

In the next sections, we first introduce the syntax of the full-blown action description language (Section 5). In Section 6 we will develop the semantics and the constraint-based abstract implementation of this new language. In doing this, for the sake of readability, we proceed incrementally in order to focus on the main points and features of the framework. We first consider the sub-language  obtained from  by disallowing timed references (Section 6.1); in Section 6.2, we treat the general case dealing with past and future references. The abstract implementation is provided in Section 6.3. Finally, we give the semantics to the complete language involving cost and global constraints (Section 6.4).

5 The Language

As for , the action signature consists of a set of fluent names, a set of action names, and a set of values for fluents in . In the following we assume that .

In an action domain description, an assertion (domain declaration) of the type

declares that is a fluent and that its set of values is