We find block deordering useful for maximizing the deordering, found by the con- ventional deordering algorithm, that helps to achieve greater execution flexibility of a plan. However, in this thesis, the ultimate significance of block deordering is deter- mined by how much we can exploit the additional structural information it provides to improve two post-plan generation tasks – (1) continuing plan quality optimisation (described in Chapter 4) and (2) macro generation for improving planners efficiency (described in Chapter 6). As a simple example, we can observe from Figure 2.3 that
§2.6 Experimental Results and Discussion 31
Figure 2.8: An example of a block deordering a p.o. plan that decreases the flex value of the plan. A normal p.o. plan (left) having an ordering a≺ e for the reason Re(a≺e) ={CD(x)}, and a block deordering (right) of this plan after capturing the block {e, f}. This deordering removes two orderings: a ≺ e and a ≺ f from the p.o. plan, and introduces three new orderings: f≺b, f≺c, and f≺d (even though there is no necessary reason for those orderings) due to the requirement that the block {e, f} not be interleaved. Thus, this block deordering of the p.o. plan decreases its flex
value.
if b2 is ordered before b1, then b1 can be optimised by removing step s3.
This section describes the results of an experiment that was conducted to com- pare the “amount of deordering” done by the step-wise and block-structured plan deordering. In other words, we ran this experiment to investigate the usefulness of block deordering in achieving greater execution flexibility of a plan. To observe the other benefits of block deordering (i.e., usefulness in plan optimisation and macro generation), we ran other experiments that are described in the relevant chapters. We measure the flexibility 1, or “flex”, of plans, after the standard deordering (de- scribed in Section 2.2.3) and also after block deordering to compare the amount of deordering. The flex of a p.o. plan is defined as the fraction of pairs of steps that are not (transitively) ordered. Thus, a higher flex value indicates a less strictly ordered plan, with a fully sequential plan having a flex of zero. We apply the same definition to block deordered plans. Recall that in a block deordered plan, all steps belonging to two ordered blocks are ordered by the requirement that blocks not be interleaved, even when there is no ordering between an individual pair of steps. This is taken into account when calculating the flex of a block deordered plan. Because of this, in fact, it is possible for block deordering of a partially ordered plan to decrease its flex value in some cases. Figure 2.8 shows an example of how a block deordering can decrease the flexibility.
The experimental setup is as follows. We took all domains from the sequential satisficing tracks of the past editions of the International Planning Competition (IPC), IPC 2000-2014, except for the “CaveDiving” and “CityCar” domains. (These two domains have conditional effects, which our implementation does not handle.) We also took the Alarm Processing for Power Networks (APPN) [Haslum and Grastien, 2011] and data set 2-nd of the Genome Edit Distance (GED) domain [Haslum, 2011]. The plans (7324 in total) used in this experiment as inputs to plan deordering are the plans produced by different planners participating in the IPC 2000-2014. We impose
1The term “flexibility” is used with different meanings by different authors. Nguyen and Kambham-
pati [2001]’s definition is equivalent to ours. Muise et al. [2012] use it for the number of linearisations of a p.o. plan.
a 1800 second time limit on the block deordering procedure. All experiments were run on 6-Core, 3.1GHz AMD CPUs with 6M L2 cache, with an 8 GB memory limit for every system.
Results are summarised by domain in Table 2.1. For each domain, we report the number of plans analysed, the number of plans for which block deordering led to an increase in flex, and the average (over all analysed plans) flex values after step-based deordering and after block deordering. In cases where the limit of 1800 seconds was reached (∼ 0.83% of all plans), we take the flex of the plan after the last completed iteration. The plans that reach the deordering time limit are mostly from the Visitall, Openstacks, and Hiking domains; the length of plans in those domains is often a couple of thousand actions. Longer plans from the BlocksWorld, Barman, Openstacks, and GED domains often experience a high number of iterations of Algorithm 1, mostly because of performing a high degree of deordering.
Note that several domains are purely sequential, and do not permit any deorder- ing of individual steps. (These have an average flex of zero after step deorder- ing.) Yet, even in these domains, it is often possible to block deorder plans. The BlocksWorld, Pegsol, Sokoban, and Visitall domains belong to this category. As an example, Figure 2.9 visualises the execution of part of a plan from the Sokoban do- main (the reference plan for problem #11 from the IPC6 satisficing track). Sokoban is a puzzle game, involving a man who must push boxes around on a grid, one at a time, to reach a goal configuration. This domain is purely sequential because actions in the planning encoding of the game move the man from one square to another; thus, every step has a causal link from the step immediately before, and no deorder- ing of individual steps is possible. Block deordering, however, is: In the example plan, the blocks consisting of steps 3–4 and steps 5–28 are independent and can be unordered. As can be seen clearly from the visualisation, moving steps 3–4, as a block, to after step 28 does not invalidate the plan. There are also two blocks, con- sisting of steps 10–21 and 22–23, within the larger block 5–28, that can be deordered. Our algorithm found all these possibilities.