Representing Actions with PDDL
States as sets of ground positive fluents under the closed-world assumption, actions as lifted schemas with an add list and a delete list, and the frame problem sidestepped by mentioning only what changes.
Search treated a state as a black box you could only test for goalhood. Logic could look inside a state but had to reason with ground sentences, and drowned. Planning takes the middle path: a state is a collection of variables, and that structure is what makes automatic heuristics possible.
States as sets of fluents
A state is a conjunction of fluents that are ground, function-free atoms. For the spare-tire problem the initial state is
Three restrictions make this tractable rather than merely expressive.
- Ground. is not a state fluent; it has a variable in it.
- Positive. is not allowed. Under the closed-world assumption any fluent not mentioned is false, so negation is free and implicit rather than written down.
- Function-free. is out; the unique names assumption then makes distinct constants distinct objects.
The payoff is that a state can be read two ways at once: as a logical conjunction to be reasoned with, or as a set of fluents to be manipulated with set operations. Most planning algorithms take the second reading, and it is why the code below is so short.
Actions as schemas
The frame problem is the difficulty of saying what stays the same when something changes. Classical planning sidesteps it by concentrating on problems where most actions leave most things alone, and then describing an action purely by what changes. Everything unmentioned persists.
An action schema is a lifted description standing for many ground actions:
The effect splits into an add list, the positive literals, and a delete list, the negated ones. Applying a ground action to a state is then one line of set arithmetic:
and is applicable when .
This lifting is the whole economy of the representation. In the wumpus world the logical agent needed a separate sentence for moving forward at each of four orientations, time steps and locations. One schema replaces all of them.
Grounding, and counting
A schema is a promise; a planner works with the ground actions it expands into. The air cargo domain has three schemas, and with two cargos, two planes and two airports they expand to twenty ground actions.
Runs in your browser. The first run downloads the Python runtime (~10 MB), then it is cached.
Note the guard. Without it the schema also produces , whose effect would be - a contradiction. The fix is an inequality precondition requiring the two airports to differ.
Grounding also scales badly, which is the point of keeping schemas around as long as possible. Ten planes and five airports give alone ground actions, and the count grows as the product of every domain in the schema.
Move the three domains below and watch the product. At two of everything it is the twenty above; push the planes to ten and the airports to five and Fly alone contributes two hundred, before any other schema is counted. Load and Unload grow with the cargo and Fly does not, because a schema only multiplies out over the arguments it actually mentions.
The guard is worth turning off once. Without the inequality precondition the schema produces one Fly(p, a, a) per plane per airport, and the figure counts them. It is not a tidying-up detail: without it the schema describes actions whose effect both asserts and denies that the plane is where it is.
Interactive: what grounding costs
Three schemas, and the product of every domain they mention.
- Load, and Unload each
- 8
- Fly, as grounded
- 4
- Ground actions in all
- 20
- Contradictory without the guard
- 4
Three schemas become 20 ground actions here, which at two of everything is the lesson’s 20. Each schema multiplies out over its own arguments, so Load and Unload grow as cargo times planes times airports while Fly does not touch cargo at all; push the planes to ten and the airports to five and Fly alone contributes 200, before any other schema is counted. That is why a planner keeps schemas around as long as it can. The guard is currently on, and it is removing 4 actions: one Fly(p, a, a) per plane per airport, whose effect would both assert and deny that the plane is at a. Turn it off to count them.
A goal is a precondition
A goal is written like a precondition: a conjunction of literals, possibly with variables, which are read existentially. So means some plane is at San Francisco. A state satisfies a goal when it entails it, which under the closed-world assumption is just a subset test on the positive literals.
This is not a weaker logic, it is a chosen fragment. Every restriction - ground, positive, function-free, effects-only - exists so that the structure of an action is open to inspection. The next lesson turns that structure into search, and the one after into heuristics derived automatically from the schemas themselves. None of that is available when a state is an atom.
Before the quiz
Be able to say what a factored representation is and what it buys, list the three restrictions on state fluents and what the closed-world assumption does, write an action schema and apply it as set arithmetic, count the ground actions a schema expands into, and explain why an inequality precondition is sometimes needed.
References & further reading
- Stuart Russell, Peter Norvig, Artificial Intelligence: A Modern Approach, Pearson (3rd edition), 2010· Kudos AI reference library
Copyrighted works are cited for reference only and are not hosted here; please consult the publisher for access.
Unlock the full path
This first lesson is free. Enrol to take the mastery quiz, earn XP, and unlock every module, with more interactive, runnable examples throughout.