Introduction
To talk about classical planning we first have to introduce some terminologies:
- deterministic → for each action there is only one outcome
- stochastic → the effects of the actions can be uncertain or probabilistic
- single-agent → just one agent plans his actions
- multi-agent → multiple agents interact with the environment
And classical planning is deterministic, stochastic, fully-observable (you can acknowledge at every moment in which state it is), static (the changes can only by applied by us) and discrete (usually finite. It is indeed the simplest form of sequential decision making and the plan is the path from the unique initial state to a goal state.
Furthermore we can consider this kind of problems “relatively” simple (their general formulation is PSPACE-complete) but relevant. In further pages there will be stochastic multi-agent settings, which require (much) more complex plans prescribing how to act in every possible state (i.e. how to reach to every possible event/opponent move).
The search in this case consists of exploring the state space, even if there are many other search paradigms (encoding into constrains satisfaction, BDD representation) that we won’t consider.
Some example of classical planning problems
Finding a route in a map
- starting from an initial state → departure city
- apply actions → using a road segment
- reach a goal state → destination city
- performance measure → shortest time, shortest path, etc.
The “15-puzzle”
TODO: foto slide 6
- starting from an initial state → left
- apply actions → moving a tile
- reach a goal state → right
- performance measure: minimize summed-up action costs → each move has cost , so we minimize the number of moves
FreeCell
- starting from an initial state → cards on table
- apply actions → moving a card
- reach a goal state → all cards “home”
- performance measure: minimize summed-up action costs → each move has cost , so we minimize the number of moves
Finding bugs (in automata network)
TODO: foto slide 8
- starting from an initial state → both idle
- apply actions → automaton transitions
- reach a goal state → error (both in critical section )
- performance measure: minimize summed-up action costs → each move has cost , so we minimize the length of the error path
Classical planning terminology
We need to distinguish between satisficing planning and optimcal planning:
- satisficing planning
- input → a planning task
- output → a plan for , or unsolvable if no plans for exists
- optimal planning
- input → a planning task
- output → a cost-optimal plan for , or unsolvable if no plan for exists
State spaces
Every problem specifies a state space .
Def. state spaces
A state space is a tuple :
- → finite set of states
- → finite set of actions
- → cost function
- → transition relation. We require that is deterministic (i.e. there is at most one state such that ). If such exists, then is applicable to and results in state . We denote by the set of actions applicable to
- → initial state
- → set of goal states
We say that has the transition if . We also write , or when not interested in .
We say that has unit cost if, . We will often give each action a name, and identify with that name.
Terminology
successor of if , predecessor of if
reachable from if there exists a sequence of transition
→ is the path from to
→ is also called path from to
the cost of that path
reachable (without reference state) means reachable from
is solvable if some is reachable from , else is a dead end
Def. plans
Let be a state space, and let . A plan for is a path from to some . The plan is optimal if its cost is minimal among all plans for . A plan for is called plan for . If a plan exists then is solvable
Directed graph
Directed graph + mark-up for initial state and goal states
TODO: foto slide 16Question
- Does this have unit cost? No
- Which actions are applicable to the initial state? actA, actB, actC
- Is deterministic? No, on and , actG induces more than one outgoing transition
- What for do we allow -cost actions? Negligible cost (e.g. switch light on)
- Are all states in reachable? No, is not reachable
- Are all states in solvable? No, is not solvable
- What are the optimal plans for ? Any path that starts with actB, applies actE times, then applies actC then actE and then no actions other than actG
Find a route to Bucharest (formalization)
- maps each to the length of the road segment
Koalas and gorillas
TODO: foto slide 22
Starting with everybody on the right bank we need to use the boat which carries animals to get everybody to the left bank. If koalas are outnumbered by gorillas on either bank is game over.
We consider only the states at the end of each boat ride, not the situation during the boat ride. At the end of each move, everybody leaves the boat (in other words, the animals in the boat count as being on the target river bank); and the game is over in case that results in more gorillas than koalas on either bank. Moves after which the game would be over are disallowed (i.e. these action are not applicable).
Formalization
- where respectively represent the number of koalas, gorillas and boats currently in the bank
- if , subtract or from and set , if , add or to and set . Both subject to having, after the move, as well as if , and if
- accordingly
However in some problems state spaces may be huge. In particular, the state spaces is typically exponentially large in the size of its specification via the problem ; indeed huge space are (almost always) specified by small and so we wouldn’t be able to easily represent them. For this reason we need some specifications.
Specifications
Specifications are formal descriptions of what a system must do or the properties it must satisfy, necessary in order to solve a problem.
Let’s present the three possible ones.
Simulator specification
A simulator for a problem implements the procedures necessary to generate paths in the state space (we don’t need to represent the whole state space in advance, we generate successor states on demand by applying actions to the current state using the simulator).
Problem simulator API
InitialState()→ returns the initial state of the problemGoalTest(s)→ returns a Boolean,trueiff state is a goal stateCost(a)→ returns the cost of actionActions(s)→ returns the set of actions that are applicable to stateChildState(s,a)→ requires that action is applicable to state (i.e., there is a transition ). Returns the outcome stateIn this case “specifying the problem” means programming the simulator.
A problem simulator provides procedures allowing to explore the state space incrementally and to determine goal states and plan cost. For this reason it’s required to respect the minimal functionality (i.e., only implement essential operations), but often is much easier to obtain than symbolic specification.
Symbolic (aka declarative) specification
A symbolic specification of comes from a declarative language.
Symbolic specification of a problem
There are many ways to do this. Here’s one:
- → set of Boolean variables (prepositions)
- → indicating which propositions are true in the initial state
- → where is a goal state iff (all prepositions are satisfied)
- → set of actions , each with precondition , add list , and delete list ; applicable to iff , outcome state is
- → maps each to its cost
This language is called “STRIPS”. In this case “specifying the problem” means writing STRIPS
This specification is strictly more powerful than simulator, as it allows to implement the simulator and allows to analyze the problem however often is more difficult to obtain than a simulator.
Furthermore symbolic specification enable general planning, but is not used for search algorithms.
TODO: foto slide 29
Example
Azione PRE ADD DEL obs
I don’t actually need , and then neither .
Starting from , I apply :
Closed-world assumption
We assume that what is inside is true, what is outside is false
The plan is : is applicable because .
Enumerative specification
The enumerative specification describes simply in terms of its state space.
Enumerative specification of a problem
We simply input the state space graph (in some implementation).
In this case “specifying the problem” means writing down the state space, but it’s impossible for large state spaces. However it can be solved easily in the size of the state space (Dijkstra’s algorithm).
Enumerative specifications do not, in difference to simulator and symbolic specification, compactly describe large state spaces. They are used if the state spaces are “small” (only 100.000s of states) and the runtime is very limited. This is typically the case in route planning.