Motivation: Writing readable and error-free code often depends on the length of the code and its complexity [37]. It is much easier to write simple code and later it is also easier to dis- cover problems in such code compared to some more complex implementation. Furthermore, complex code is difficult to reuse as it is specialised for a given problem and needs changes to be done before being applicable for different kinds of problems. In such cases abstract reusable actions can be used. They reduce the code needed for describing the different action variations and are easily reusable due to their general implementation. Such actions can be applicable
when one type of action is applied to situations, such as moving from or to different places or manipulating different objects. Here we discuss how such actions are implemented and how they affect the model compared to specialised actions.
Structure and implementation: An abstract action is implemented by defining one action for all variations of a given situation with preconditions and effects that allow the action to be grounded with the parameters for all variations. This is equivalent to implementing several specialised actions, each of them representing just one situation and parameterisable with the elements for just this situation. Fig. 4.2 shows the structure of an abstract action that can be
$EVWUDFW $ *URXQGHG $ *URXQGHG $ *URXQGHG $ 6SHFLDOLVHG $ 6SHFLDOLVHG $ 6SHFLDOLVHG $ *URXQGHG $ *URXQGHG $ *URXQGHG $ $EVWUDFW 6SHFLDOLVHG
Figure 4.2: Structure of abstract and specialised action implementation. To the left the abstract action implementation is shown where one action template is grounded into three action instances. To the right, three specialised action templates are grounded in the same three instances as in the first case.
grounded into three specialised actions (to the left), and which is equivalent to three specialised actions’ descriptions which after parameterisation result in the same grounded actions as the first case. The advantage in this case is that the implementation of the abstract description is usually shorter, as only one action is defined. This can be seen in Appendix E where Fig. E.3 on page 221 shows an example implementation of an abstract action, while Fig. E.4 (page 222) shows the implementation of the same problem with specialised actions. It can be seen that the specialised implementation requires the definition of three separate actions, while in the abstract implementation, only one action is needed. Additionally, the specialised actions need to make use of the type system. Otherwise each action description will be grounded with all available constants resulting in 15 grounded actions instead of only 5 in the current case.
Consequences: Although the two implementations of the problem have different structure, Table 4.1: Parameters of abstract action implementation. The values for the abstract model are calculated based on the model implementation in Fig. E.3 on page 221 while, those for the specialised are based on the implementation of specialised actions in Fig. E.4 on page 222.
Parameter Value (abstract) Value (specialised) Description
# operators 5 5 grounded actions after the model compilation
# predicates 5 5 grounded predicates after the model compilation
# objects 5 5 objects in the model
# states 32 32 state-space of the model
# valid plans 120 120 valid plans leading from the initial to the goal state goal distance 5 5 distance from the initial to the goal state
max. branching factor 5 5 maximum number of possible actions from a state final log likelihood -4.78749 -4.78749 final log likelihood of the execution sequence
they have the same consequences to the model. Table 4.1 shows the parameters for the abstract and for the specialised implementations of the problem. It can be seen that regardless of the different structure, both implementations result in the same number of grounded operators (5),
If we assume that in the best case there is one object per action instance, namely the object with which the instance is grounded, then the number of objects will be n3.
ObB1 = n. (4.4)
The length of the goal distance will be equal to the length of the shortest execution plan, namely
GB1 = n. (4.5)
The state-space will then be computed based on the number of predicates. In this case, if we have P rB1 with n predicates, then the number of all subsets of P rB1 will give us the number
of possible states , or with other words
SB1 = 2
n. (4.6)
The branching factor then in the worst possible case will be equal to the number of available actions at a time,
BrB1= n. (4.7)
Now assume there is a second model B2with actions am, where m :={1,...,n} and where to each action a different object is assigned as a parameter. Assuming once again that the actions can be executed sequentially in any order without repetition of any action, then the number of plans will be n! as shown in Equation 4.1; the number of operators will be represented by the number of available actions, namely n (Equation 4.2). If we assume that in the best possible case, the same predicate but with a different parameter will be used in all actions, this will result in n grounded predicates (Equation 4.3). In the case when one different object is assigned to each action, then the number of objects will also be n (Equation 4.4), as well as the goal distance and the maximum branching factor. Assuming all actions have to be executed, the state-space will once again contain all subset of the set of predicates, namely 2n(Equation 4.6). Comparing the parameters of B1and B2it can be seen that they have the same values. From this it could be concluded, that if the models have the assumptions described above, they will also exhibit the same model behaviour in both cases. The models’ behaviour for increasing number of actions is visualised in Fig. 4.4.
Applicability: The abstract reusable actions can be used interchangeably with the spe- cialised actions with the additional advantage that they take less time for implementing and produce less code. For that reason they are often preferred to the specialised actions especially in cases where there are no other modelling mechanisms that can be influenced by the abstract actions. However, in more complex models like the cooking problem, specialised actions could be preferable as they allow the control of only a given subset of the more general action in a given phase of the model. On the other hand, in situations like the meeting scenario and the office scenario the abstract actions come in handy as they reduce the model implementation effort. For that reason the implementation of the remaining patterns in this chapter is done with abstract action templates instead with specific actions, as this reduces the number of action templates that have to be modelled. This results in the need of introduction of objects that have to ground the templates in order to produce the needed number of variable-free actions.
3For the sake of fairness we have to admit that in the casen specialised action templates are implemented, we
can achieve the same effect when we introducen variable-free predicates, each corresponding to one specialised action. However, that means the model designer has to introduce each of then variable-free predicates, which could be omitted in the other case, when just one predicate with variable is introduced, and which later is grounded with the corresponding object assigned to the specialised action.
Hí H H Q 1XPEHURISODQV ORJ DEVWUDFW VSHFLDOLVHG Q 1XPEHURIRSHU DWRUV Q 1XPEHURISUHGLFDWHV Q 1XPEHURIREMHFWV Q *RDOGLVWDQFH H H H Q 1XPEHURIVWDWHV ORJ Q %U DQFKLQJI DFWRU
Figure 4.4: General model dynamics for abstract actions. The dashed red line represents the behaviour of specialised actions, while the blue solid line – of an abstract one. The model complexity for increasing number of actions was plotted starting with one action and increasing until 100 actions are reached. The number of states and number of plans are plotted on logarithmic scale.