
## Move(Roomb, Rooma)

at-robby(roomB) −→ ADD at-robby(roomA) DEL at-robby(roomB). of the move(?from,?to) operator schema invert each other. Similarly, in towers of hanoi, where there is only the single move operator schema, an inverse instance can be found for each ground instance of the schema, and the add effects are always FALSE when the preconditions are true.

Only very rarely, non-invertible actions can be found in benchmark domains.  If they occur, their role in the domain is often quite limited as for example the operators cuss and inflate in Russel's Tyreworld.

## Cuss

---> DEL annoyed().

## Inflate(?X:W Heel)

have(pump) not-inflated(?x) intact(?x) −→ ADD inflated(?x) DEL not-inflated(?x).

Obviously, there is not much point in defining something like a decuss or a deflate operator.  More formally speaking, none of the ground actions to these operators destroys a goal or a precondition of any other action in the domain. Therefore, it does not matter that their effects cannot be inverted. In particular, no forced goal ordering can be derived wrt. these actions. 5 The importance of inverse actions in real-world domains has also been discussed by Nayak and Williams (1997), who describe the planner BURTON controlling the Cassini spacecraft. In contrast to these domains, problems such as those for example used by Barrett et al. in (1994) almost never contain inverse actions.  Consequently, in these domains plenty of forced goal orderings could be discovered and used by a planner to avoid deadlock situations. The widespread, although perhaps unconscious use of invertible problems for benchmarking is a current phenomenon related to STRIPS descending planning systems.  As one of the anonymous reviewers pointed out to us, quite a number of non-invertible planning problems have also been proposed in the planning literature, e.g., the register assignment problem (Nilsson, 1980), the robot crossing a road problem (Sanborn & Hendler, 1988), some instances of manufacturing problems (Regli, Gupta, & Nau, 1995), and the Yale Shooting problem (McDermott & Hanks, 1987). For these problems, i.e., for problems that are not invertible, one could—in the spirit of argument 1 at the very beginning of this sectionsimply use < e and < h to approximate forced orderings if one is interested in finding at least those. More precisely, < e and < h are methods that might detect forced orderings—as those are also reasonable—but that might also find more, not necessarily forced, orderings. If one is not interested in finding only the forced orderings, this is a possible way to go. For example, in a simple blocks world modification where blocks cannot be unstacked anymore once they are stacked—which forces the planner to build the stacks bottom up—both ≤ e and <h are still capable of finding the correct goal orderings.