Preprocesamiento de los diccionarios

Now that we have the basic ingredients to define a classic planning problem, we will see how we can combine them. The basic idea is that we need an agent and a state. In case the :typing requirement is present, the first thing to do is to define types. The definition of types is given directly by the classical problem. We just introduce a basic type called Object, representing the topmost element of the type hierarchy, with an integer member called id. Consider, for example, the 4 Op-blocks world domain in which the only type is block, we can define it as

c l a s s O b j e c t { i n t i d ; O b j e c t ( i n t i d ) : i d ( i d ) {} } c l a s s B l o c k : O b j e c t { B l o c k ( i n t i d ) : O b j e c t ( i d ) {} }

The second step is to define the state. Since we need to assign goals to the agent, the state needs a reference to the agent. We will exploit the forward declaration capabilities and will use the agent reference before defining it. So, farther on with the 4 Op-blocks world domain, we have

c l a s s B l o c k s S t a t e : P r o p o s i t i o n a l S t a t e { B l o c k s A g e n t a g e n t ; B l o c k s S t a t e ( B l o c k s A g e n t a g e n t ) : a g e n t ( a g e n t ) {} . . }

Analogously, since the agent needs to assign goals to the state, it needs a reference to the state. So, continuing with our 4 Op-blocks world domain, we have

c l a s s B l o c k s A g e n t : P r o p o s i t i o n a l A g e n t { B l o c k s S t a t e p r o p o s i t i o n a l _ s t a t e ; P r o p o s i t i o n a l A g e n t ( ) : p r o p o s i t i o n a l _ s t a t e ( new B l o c k s S t a t e ( t h i s ) ) {} . . }

We can now define predicates for our state and for our agent. As already mentioned, the rules for the predicates relative to the state should contain goals on the agent rep- resenting the possible actions, properly constrained, for achieving a given goal. On the other hand, the rules for the predicates relative to the agent should contain goals for the preconditions and facts for the effects. We show an example 4 Op-blocks world domain: c l a s s B l o c k s S t a t e : P r o p o s i t i o n a l S t a t e { B l o c k s A g e n t a g e n t ; B l o c k s S t a t e ( B l o c k s A g e n t a g e n t ) : a g e n t ( a g e n t ) {} p r e d i c a t e C l e a r ( B l o c k x ) { d u r a t i o n >= 1 ; {

g o a l put_down = new a g e n t . Put_down ( a t : s t a r t , x : x ) ; } or { g o a l s t a c k = new a g e n t . S t a c k ( a t : s t a r t , x : x ) ; } or { g o a l u n s t a c k = new a g e n t . U n s t a c k ( a t : s t a r t , y : x ) ; } } . . }

This, on the other hand, is an example, still in the 4 Op-blocks world domain, of a predicate defined for the agent:

c l a s s B l o c k s A g e n t : P r o p o s i t i o n a l A g e n t { B l o c k s S t a t e p r o p o s i t i o n a l _ s t a t e ; B l o c k s A g e n t ( ) : p r o p o s i t i o n a l _ s t a t e ( new B l o c k s S t a t e ( t h i s ) ) {} p r e d i c a t e P i c k _ u p ( B l o c k x ) : I m p u l s i v e P r e d i c a t e { g o a l c l e a r _ x = new p r o p o s i t i o n a l _ s t a t e . C l e a r ( p o l a r i t y : t r u e , x : x ) ; c l e a r _ x . s t a r t <= a t − 1 ; c l e a r _ x . end >= a t ; g o a l o n t a b l e _ x = new p r o p o s i t i o n a l _ s t a t e . O n t a b l e ( p o l a r i t y : t r u e , x : x ) ; o n t a b l e _ x . s t a r t <= a t − 1 ; o n t a b l e _ x . end >= a t ; g o a l h a n d e m p t y = new p r o p o s i t i o n a l _ s t a t e . Handempty ( p o l a r i t y : t r u e ) ; h a n d e m p t y . s t a r t <= a t − 1 ; h a n d e m p t y . end >= a t ; f a c t n o t _ o n t a b l e _ x = new p r o p o s i t i o n a l _ s t a t e . O n t a b l e ( p o l a r i t y : f a l s e , x : x , s t a r t : a t ) ; n o t _ o n t a b l e _ x . d u r a t i o n >= 1 ; f a c t n o t _ c l e a r _ x = new p r o p o s i t i o n a l _ s t a t e . C l e a r ( p o l a r i t y : f a l s e , x : x ,

s t a r t : a t ) ; n o t _ c l e a r _ x . d u r a t i o n >= 1 ; f a c t n o t _ h a n d e m p t y = new p r o p o s i t i o n a l _ s t a t e . Handempty ( p o l a r i t y : f a l s e , s t a r t : a t ) ; n o t _ h a n d e m p t y . d u r a t i o n >= 1 ; f a c t h o l d i n g _ x = new p r o p o s i t i o n a l _ s t a t e . H o l d i n g ( p o l a r i t y : t r u e , x : x , s t a r t : a t ) ; h o l d i n g _ x . d u r a t i o n >= 1 ; } . . }

Now that we have defined all the types, the predicates and rules associated to them, we can define the type instances

B l o c k a = new B l o c k ( 1 ) ; B l o c k b = new B l o c k ( 2 ) ;

B l o c k s A g e n t a g e n t = new B l o c k s A g e n t ( ) ;

as well as the facts and the goals for our planning problem.

f a c t c l e a r _ a = new a g e n t . p r o p o s i t i o n a l _ s t a t e . C l e a r ( p o l a r i t y : t r u e , x : a , s t a r t : o r i g i n ) ; c l e a r _ a . d u r a t i o n >= 1 ; f a c t c l e a r _ b = new a g e n t . p r o p o s i t i o n a l _ s t a t e . C l e a r ( p o l a r i t y : t r u e , x : b , s t a r t : o r i g i n ) ; c l e a r _ b . d u r a t i o n >= 1 ; f a c t o n t a b l e _ a = new a g e n t . p r o p o s i t i o n a l _ s t a t e . O n t a b l e ( p o l a r i t y : t r u e , x : a , s t a r t : o r i g i n ) ; o n t a b l e _ a . d u r a t i o n >= 1 ; f a c t o n t a b l e _ b = new a g e n t . p r o p o s i t i o n a l _ s t a t e . O n t a b l e ( p o l a r i t y : t r u e , x : b , s t a r t : o r i g i n ) ; o n t a b l e _ b . d u r a t i o n >= 1 ; f a c t h a n d e m p t y = new a g e n t . p r o p o s i t i o n a l _ s t a t e . Handempty ( p o l a r i t y : t r u e , s t a r t : o r i g i n ) ; h a n d e m p t y . d u r a t i o n >= 1 ; g o a l o n _ b _ a = new a g e n t . p r o p o s i t i o n a l _ s t a t e . On ( p o l a r i t y : t r u e , x : b , y : a , end : h o r i z o n ) ;

Notice that the translation from a classical planning problem to a timeline-based planning problem is pretty straightforward, and, as such, can be easily automated.

7

Conclusions

The reorganization of the timeline-based formalism, already pursued by ILOC and presented in Chapter 3, pushes toward the direction of solving more general problems which might be not strictly related to timelines. The atom concept, for example, being able to not necessarily represent temporal variables, constitutes a more general concept respect to the previously concept of token. Similarly, the type concept represents a superset of the possible timeline types. If on the one hand this increase in generality directly translates into an increase in computational complexity, the solver becomes, indeed, definitely non-decidable, on the other hand, defining heuristics for those prob- lem instances which are decidable becomes a work that can be done, once and for all, for any problem.

The detachment from the strictly related timeline-based problem, for example, could be exploited for the definition of problems for which it does not make sense to reason in terms of temporal evolutions like those related to troubleshooting or to diagnosis systems. Suppose, for example, we have a scooter ignition problem and we want to troubleshoot it. In order to ignite, a scooter needs the gasoline tank to be not empty, the fuel valve to be open and the carburetor to be clean. Additionally, we might know that the probabilities of an empty tank are higher than the probabilities of a closed valve which, in turn, are higher than the probabilities of a dirty carbu- retor. Finally, we do not initially know whether the tank is empty, the fuel valve is open and the carburetor is clean. We might solve the scooter ignition problem through

ORATIOby defining a rule which would explain the system failure as the one repre- sented graphically through a graph in Figure 7.1. Since we do not have information about the state of the system, we introduce three facts with lifted parameters, i.e., EmptyTank(?x), FuelValveClose (?y) and DirtyCarburetor (?z). Finally, we intro- duce the EngineWontStart () goal and start theORATIOsolving procedure. The graph building procedure would expand the EngineWontStart () goal introducing a disjunc- tion flaw. Since one of the disjuncts contains a EmptyTank (True) subgoal which might unify with the EmptyTank (?x) fact, the graph building procedure terminates, the prun- ing procedure sets the EmptyTank (False) subgoal at False resulting in a solution in

Figure 7.1: Scooter ignition troubleshooting.

which the active disjunct is the one containing the EmptyTank (True) subgoal, suggest- ing the most probable of the causes as the main issue of the scooter ignition problem. Notice that, in case we knew the gasoline tank is not empty, the initial problem would contain a EmptyTank (False) fact, the graph building procedure would have reached the FuelValveClose (True) subgoal suggesting a different, yet still the most probable, cause.

7.1

A heuristic for solving constraint logic program-

ming problems

More in general, the proposed critical path heuristic can be exploited, among other things, for solving Constraint Logic Programming (CLP) problems. To the best of the author’s knowledge, indeed, all of the logic programming implementations produce demonstrations (i.e., the analogous of partial plans) in a specific deterministic manner: (a) the next goal to be achieved is chosen according to the order goals arise by fol- lowing a First-In-First-Out strategy; (b) goals are achieved by applying rules according to the order they are defined. If on the one hand this deterministic behavior can be a great help in debugging programs, on the other it can be an exceptional source of inef- ficiency. Consider, as an example, the following CLP recursive program for calculating the factorial function.

f a c t o r i a l ( N , F ) :− N1 i s N−1 ,

f a c t o r i a l ( N1 , F1 ) , F i s N ∗ F1 . f a c t o r i a l ( 0 , 1 ) .

Specifically, the above code snippet is aimed at computing the factorial of a num- ber, let us say n, as n times the factorial of n − 1 until the factorial of 0 is asked and 1 is returned. To the best of the author knowledge, there is no CLP implementation which is able to solve the above problem. The main issue with the above implementation, indeed, consists in having defined the base case after the recursive case, resulting in an infinite loop for any query1. The graph building procedure, as described in Chap-

ter 5, would, on the contrary, introduce n atoms until a unification would be consid- ered as feasible, introducing a single branching for deciding whether to unify with the f actorial(0, 1) fact, with an estimated cost of 0, or to apply once again the recursive rule, with an estimated cost of +∞. Clearly, the former choice would be chosen from the solving algorithm which would have no problem in returning a solution.

Although the previous case can be solved, trivially, by inverting the definitions of the rules, applying the rules according to the order of definition, in general, could easily result in insurmountable inefficiencies. It would be like, in the case of classical planning, to establish an initial order for the selection of those operators to be applied in order to achieve a given objective (e.g., in case of the blocks world, always choose to put the block on the table before trying to put the block on another block, whenever you want the hand to be empty). Despite the inefficiency, nonetheless, it is worth noting that similar approaches are still applied in some recent works like FAPE [39, 38] or CHIMP [104, 105].