The joint movement of pebbles in solving the ($N^2-1$)-puzzle suboptimally and its applications in rule-based cooperative path-finding

Abstract

The present paper deals with the problem of solving the ($n^2 - 1$)-puzzle and cooperative path-finding (CPF) problems sub-optimally by rule-based algorithms. To solve the puzzle, we need to rearrange $n^2 - 1$ pebbles in the $n \times n$-sized square grid using one vacant position to achieve the goal configuration. An improvement to the existing polynomial-time algorithm is proposed and experimentally analyzed. The improved algorithm represents an attempt to move pebbles in a more efficient way compared to the original algorithm by grouping them into so-called snakes and moving them together as part of a snake formation. An experimental evaluation has shown that the snakeenhanced algorithm produces solutions which are 8–9 % shorter than the solutions generated by the original algorithm. Snake-like movement has also been integrated into the rule-based algorithms used in solving CPF problems sub-optimally, which is a closely related task. The task in CPF consists in moving a group of abstract robots on an undirected graph to specific vertices. The robots can move to unoccupied neighboring vertices; no more than one robot can be placed in each vertex. The ($n^2 - 1$)-puzzle is a special case of CPF where the underlying graph is a 4-connected grid and only one vertex is vacant. Two major rule-based algorithms for solving CPF problems were included in our study—BIBOX and PUSH-and-SWAP (PUSH-and-ROTATE). The use of snakes in the BIBOX algorithm led to consistent efficiency gains of around 30 % for the ($n^2 - 1$)-puzzle and up to 50 % in for CPF problems on biconnected graphs with various ear decompositions and multiple vacant vertices. For the PUSH-and-SWAP algorithm, the efficiency gain achieved from the use of snakes was around 5–8 %. However, the efficiency gain was unstable and hardly predictable for PUSH-and-SWAP.

Appendices

Appendix 1: Average case analysis

For average case analysis, we shall assume, in accordance with [17], that every initial pebble configuration may occur with the same probability.¹ We shall first show that the upper bound on the average number of moves produced by Parberry’s algorithm [17] is $4n^{3}-\frac{1}{2}n^{2}+\frac{3}{2}n-70$. We shall then simulate this analysis using our snake-based algorithm. Unfortunately, for the snake-based algorithms it seems impossible to express the average number of moves in any simple formula. However, we can provide some arguments that the average number of steps required by the snake-based version of Parberry’s algorithm to produce a solution is consistently lower than that required by the original algorithm.

Before we start with the proofs of the main propositions, we shall introduce several technical lemmas. The proofs of these lemmas are omitted, as they are straightforward and rather technical (detailed proofs can be found in [14]).

Lemma 4

The average value of $\mu _n \left( \left( {1,1} \right) ;\left( {x,y} \right) \right)$ for $x,y\in \left\{ {1,2,\ldots ,n} \right\}$ (that is, the average Manhattan distance from the position $\left( {1,1} \right)$) is $n-1$.

Lemma 5

The average value of $\mu _n \left( \left( {1,k} \right) ;\left( {x,y} \right) \right)$ for $k,x,y\in \left\{ {1,2,\ldots ,n} \right\}$ such that for $x>k$ or for $y>1$ (that is, for a given k we consider only $\left( {x,y} \right)$ positions that follow the position $\left( {1,k} \right)$ in the top-down/left-right direction) is at maximum $n-\frac{1}{2}$.

A similar result can be obtained for the positions in the first column, but here the estimate of the Manhattan distance is lower – namely $n-1$.

Lemma 6

The number of moves necessary to move a pebble from a position $\left( {i,j} \right)$ to a position $\left( {1,k} \right)$, assuming that the position $\left( {1,k} \right)$ is unoccupied, is at maximum $6\mu _n \left( {\left( {1,k} \right) ;\left( {i,j} \right) } \right) +1$.

Proposition 3

(Average-Case Solution Length–Parberry) The average number of steps in solutions to the$\left( {n^{2}-1} \right)$-puzzle produced by Parberry’s algorithm is at maximum $4n^{3}-\frac{1}{2}n^{2}+\frac{3}{2}n-70$.

Proof sketch

From Lemmas 5 and 6, we can obtain that the expected number of moves necessary to complete the first row of the puzzle is at maximum: $n\cdot \left( {6\cdot \left( {n-\frac{1}{2}} \right) +1} \right) =6n^{2}-2n$. Similarly for the first column: $\left( {n-1} \right) \cdot \left( {6\cdot \left( {n-1} \right) +1} \right) =6n^{2}-11n+5$. Altogether, the upper estimate of the number of moves required to complete the first row and the first column is: $12n^{2}-13n+5$.

Assume that the position $\left( {1,1} \right)$ is unoccupied and the estimate of the number of moves required to complete the entire $\left( {n^{2}-1} \right)$-puzzle is $S\left( n \right)$. It is true then that: $S\left( n \right) =S\left( {n-1} \right) +12n^{2}-13n+5$, where $S\left( 3 \right) =34$ (calculated as the upper limit of the average number of steps in optimal solutions). After solving the recurrent equation, we obtain that: $S\left( n \right) =4n^{3}-\frac{1}{2}n^{2}+\frac{3}{2}n-70$. $\square$

Note that the original result for Parberry’s algorithm shown in [17] is worst-case upper bound of $5n^{3}+\mathcal {O}\left( {n^{2}} \right)$ while lower bounds were given.

Observation 1

(Average-Case Solution Length—Snake-based) The average number of steps in solutions to the $\left( {n^{2}-1} \right)$-puzzle generated by the snake-based algorithm is consistently lower than the number of steps generated by Parberry’s algorithm.

Proof sketch

The average solution length on random instances for the snake-based algorithm can be expressed as the average number of moves necessary to place the first two pebbles (top-down/left-right direction) plus the average number of steps in solutions to instances in which the first two pebbles have already been placed. Note that the average number of moves required to place the first two pebbles is consistently lower for the snake-based algorithm. Hence, if we unfold the recurrence for the average solution length, the result will be consistently lower than the average solution length for Parberry’s algorithm. $\square$

Although we don’t provide an explicit formula for the average length of the solutions generated by our snake-base algorithm, we know that it is lower than $4n^{3}-\frac{1}{2}n^{2}+\frac{3}{2}n-70$.

Appendix 2: The BIBOX algorithm with snakes

In this appendix, we provide commented pseudo-code of the snake-enhanced BIBOX algorithm. The original BIBOX algorithm arranges robots into ears. The problem inductively reduces on a smaller biconnected graph whenever robots are placed in an ear—once placed, the robots do not move any more. The algorithm is provided below as Algorithm 1.

The algorithm uses several auxiliary functions to deal with sub-tasks. The pseudo-code of these auxiliary functions is given in [38]—here, we shall describe them only briefly.

The algorithm starts by constructing the ear decomposition (line 1). It is assumed that a cycle denoted as $C\left( {L_i } \right)$ is associated with each ear; $C\left( {L_i } \right)$ can be constructed by adding a path connecting the ear’s connection vertices u and v. The target configuration of the robots is then transformed, so that the vacant vertices end up in the initial cycle of the decomposition (line 2). The algorithm then proceeds to solve this modified instance. A solution of the original instance is obtained by moving the vacant vertices from the initial cycle to their original goal locations (line 8). This transformation is executed by the auxiliary functions Transform-Goal and Finish-Solution, which move the vacant vertices along two vertex disjoint paths. The main loop (lines 4–6) processes the ears, from the last cycle to the initial. The robots are arranged by another auxiliary procedure, Solve-Original-Cycle, in the initial cycle (line 7).

The individual ears are processed by the Solve-Regular-Ear procedure, which places robots in ears in a stack-like manner. First, the unoccupied vertices are moved out of the ear that is being processed as they will be needed elsewhere (lines 10–14). Then the robots whose target positions are in the ear are processed. Two cases can be distinguished based on whether the robot that is being processed is located outside the ear (lines 17–25) or inside the ear (lines 27–51).

The situation is less complex when the robot is outside—in this case, the robot is moved to the connection vertex u using by either the Move-Robot or Move-Robot-Snake auxiliary procedure. The other connection vertex v is vacated by the Make-Unoccupied procedure. If a vertex is vacated in a cycle $C(L_c )$, the cycle can be rotated. One rotation in the positive direction is executed by the Rotate-Cycle $^{+}$ function. The rotation moves the robot into the ear. Throughout the robots’ movement, vertex locking is applied (the functions Lock and Unlock) to lock a robot in a certain vertex and to allow other robots or a vacant vertex to be moved.

The situation is more complex when the robot is inside the ear. In this case, the robot must be rotated out of the ear to the main section of the graph (lines 30–32). The rotations in the positive direction required to move the robot out of the ear are counted (lines 27–32). The number of rotations is used to reinstate the initial situation by a corresponding number of rotations in the negative direction (lines 42–44). At this point, the situation is the same as in the previous case. The robot is then stacked in the ear in the same way.

The difference between the snake-enhanced BIBOX algorithm and the original BIBOX algorithm lies in the addition of the Move-Robot-Snake procedure to the former. When robots are moved towards an ear, the snake logic considers pairs of consecutive robots whenever possible (lines 18–19 and 35–36). While in the original algorithm, it was always a single robot that was moved, in the snake-enhanced version, the robot that is to be placed next is considered as well. If two consecutive robots are located close enough to each other, they are moved towards their target ear together (the joint movement process is implemented into the Move-Robot-Snake procedure).

Appendix 3: The simplified snake-enhanced PUSH-and-SWAP algorithm

Commented pseudo-code of the simplified snake-enhanced PUSH-and-SWAP algorithm is given in this appendix. The original PUSH-and-SWAP algorithm [13] was designed to solve CPF problems on arbitrary graphs containing at least two unoccupied vertices. Our simplification omits several special cases, which ensured the completeness of the algorithm on arbitrary graphs. These cases did not occur in the puzzle or the random biconnected graph instances used in the present experimental evaluation. Furthermore, the simplification has no impact on the movement of robots in pairs.

Though the PUSH-and-SWAP algorithm has been further corrected in [4, 5] (the corrected algorithm being called PUSH-and-ROTATE), we follow the original algorithm, because the cases addressed by the corrected version were omitted in our simplification.

The algorithm distinguishes between locked and unlocked vertices, as does the BIBOX algorithm. Another similarity to the BIBOX algorithm is that the robots are moved to their target positions one by one. When a robot reaches its target vertex, the goal vertex is locked. Robots can move freely in and out unlocked vertices; however, robots in locked vertices cannot regularly move; they can be temporarily moved out of their target vertex provided they return.

The snake-based enhancement of the PUSH-and-SWAP algorithm described here represents the additions of two major operations, Twin-Push and Twin-Swap, and several auxiliary operations. These operations are analogous to the Push and Swap operations in the original algorithm. The two new operations move a pair of robots together towards the target position of the first one. In addition to the Twin-Push and Twin-Swap operations, Twin-Multipush, Twin-Exchange, and a few others have been introduced.

The main loop of the simplified algorithm (lines 2–8) moves robots, one by one, to their target positions. If more than one robot remains, a pair of consecutive robots are moved together (3–5); otherwise, the last robot is moved individually. In placing two consecutive robots—say, robots r and s—the algorithm first decides if it is better to movesnext to the neighborhood of r (line 14) or vice versa (line 20) or not move the two together at all (line 13). Not using joint movement is an option, too. The decision in the present pseudo-code is based upon the lengths of the shortest paths between the current positions of the robots; however, it can be based on other criteria, too. We used a simulation to calculate the number of moves necessary in each of the two options in the actual C++ implementation used in experiments (this being the main reason why the snake-enhanced PUSH-and-SWAP takes an order of magnitude longer than the original version to produce a solution). The option which requires the fewest moves is chosen.

Once the two consecutive robots r and s are located next to each other, they are moved together towards the target of the first robot r (lines 24–27). If the robots are ordered topologically with respect to their target positions—that is, if the target positions of robots which are close to each other in the sequence are close to each other on the graph—the second robot s should end up close to its target position after the pair has been moved. If the second robot is not in its target position after the joint movement, the final single-robot movement corrects this (lines 28–29). Considering the order of robots chosen, it is optimistically assumed that the final single-robot movement does not require too many moves.

Moving the pair of robots together relies on the Twin-Push and Twin-Swap operations. When a path has been found connecting the current positions of the pair of robots with the target position of the first one, the pair of robots is moved along this path. It is assumed that robot r is the leader of the snake and robot s follows.

The Twin-Push operation is applied if the vertex on the path in front of the leading robot r can be freed by placing robots in the yet-unlocked vertices (line 40). After vacating the vertex in front of r, the pair moves one step forward. If the Twin-Push operation fails, that is, if the next vertex on the path is occupied and cannot be freed by placing robots in unlocked vertices, the Twin-Swap operation is applied.

Assume that robot t resides in the next vertex on the path, so the task forr and sis to jump over t. This can be done of we find a vertex with at least 4 neighbors v to which the triad is moved in the Twin-Multipush auxiliary operation (line 50) and where the order of the three robots is changed from $\left[ {t,r,s} \right]$ to $\left[ {r,s,t} \right]$ (the change of the order is illustrated in Fig. 11). The movement of the triad of robots to vin the Twin-Multipush operation and the subsequent freeing of the neighbors of v by the Make-Unoccupied-3 operation (line 44) to enable the order change overrides vertex locking.

Hence, robots in locked vertices may move out of their target positions. They are moved back to their target positions by undoing all the moves (supported by the auxiliary operations Start-Undo, Stop-Undo, Cancel-Undo, and Execute-Undo) in which the triad of robots were moved to v and its neighbors were vacated (the moves involving the change of order are not undone). Undoing the moves (lines 48–56) which preceded the change of order of the triad results in a situation in which the order of the three robots is changed in their current positions, while all other robots reside in their positions as well.

Regarding the rearrangement of vertices of a degree of at least 4 which is necessary to perform the Twin-Swap operation, the vertices nearest to the triad being rearranged are attempted first in our implementation. The same implementation is used in the Swap operation in which a vertex of a degree of at least 3 is searched.