Automated Planning
Complexity of Classical Planning
Jonas Kvarnström
Automated Planning Group
Department of Computer and Information Science
Linköping University
jonas.kvarnstrom@liu.se – 2016

2
What is the complexity of plan generation?
 How much time and space (memory) do we need, in the worst case?

Vague question – let’s try to be more specific…
 Assume an infinite set of <domain,problem> instances
▪ For example, “all classical planning problems”
▪ Otherwise someone could create a lookup table!
 Define a size measure for <domain,problem> instances
▪ Larger problems can use more time and space
 Prove bounds on time given problem size for all possible algorithms
(that give correct results for all instances)
jonkv@ida
Complexity 1

3
An illustrating example: sorting lists
 Problem instances: All possible lists of integers
 Size measure:
 Operations:
Number of elements in the list
Compare two elements; swap two elements
 Analysis would show: Sorting is in O(n log n), meaning:
▪ There exists a sorting algorithm
Constant c:
for which there is a fixed constant c
Depends on CPU, memory
such that for all problem sizes n,
performance, unit of time, …
the time to execute the algorithm
is at most c * n log n
n log n:
Depends on the algorithm
jonkv@ida
Complexity 2: Example

4
Approximate meaning:
 25 ln 25 = 80.5
 50 ln 50 = 195.6
25 lg 25 = 34.9
50 lg 50 = 84.9
 100 ln 100 = 460.5
 200 ln 200 = 1059.7
 Increase list length from 25 to 50 
upper bound on time requirements increases by a factor
195.6/80.5 = 84.9/34.9 = 2.43
 Increase list length from 50 to 100 
upper bound increases by a factor 460.5/195.6 = 2.35
 Increase list length from 100 to 200 
upper bound increases by a factor 1059.7 / 460.5 = 2.30
Base of logarithm
(e, 10, …)
does not matter!
jonkv@ida
Complexity 3: Example
5
n log n
45000
40000
35000
30000
25000
20000
15000
10000
5000
0
0
500
1000
1500
2000
2500
n log n
3000
3500
4000
4500
5000
jonkv@ida
Example: n log n
6
n log n / n^2
25000000
n^2 grows much faster
than n log n
20000000
15000000
10000000
5000000
0
0
500
1000
1500
2000
2500
n log n
3000
n^2
3500
4000
4500
5000
jonkv@ida
Example: n log n vs. n^2
n log n vs.
7
n^2/1000
45000
n^2 / 1000 may seem less
than n log n…
40000
35000
30000
25000
20000
15000
10000
5000
0
0
500
1000
1500
2000
n log n
2500
3000
n^2/1000
3500
4000
4500
5000
jonkv@ida
Example: n log n vs. 0.001 n^2
n log n vs.
jonkv@ida
Example: n log n vs. 0.001 n^2, zoomed out
8
n^2/1000
120000
But if we "zoom out",
we see that n^2 catches up
for sufficiently large n
100000
This happens regardless of the
value of c!
80000
60000
40000
20000
0
0
2000
4000
6000
n log n
n^2/1000
8000
10000
12000
9
Three complexities
1E+11
Even more clear in log/log scale:
1E+10
The factor 0.001 moves the line down,
but n log n still has a lower
(and decreasing) slope
1E+09
0000000
0000000
1000000
100000
10000
1000
100
10
1
1
10
100
1000
10000
0,1
0,01
0,001
n log n
n^2
n^2/1000
100000
1000000
jonkv@ida
Example: log/log scale

General concept: asymptotic complexity
 A problem is in O(f(n)) if there exists an algorithm
for which there exists a fixed constant c
such that for all n,
the time to solve an instance of size n
is at most c * f(n)

Because sorting is in O(n log n):
 It is also in O(n2), in O(2n), and so on.
 If we can do it in “at most n log n”, we can do it in “at most n2”.
Some problem instances might be solved faster!
If the list happens to be sorted already, we might finish in linear time: O(n)
But for the entire set of problems, our guarantee is O(n log n)
10
jonkv@ida
Complexity continued
12
So: In planning what is a “problem of size n”?
Real World
+ current
problem
Abstraction
Approximation
Planning Problem
P = (Σ, s0, Sg)
Equivalence
The input to a planner
is a problem statement
The size of the problem statement
depends on the representation!
PDDL: How many symbols are there
in the domain and problem files?
Language L
Problem
Statement
P=(O,s0,g)
Planner
Plan
⟨a1, a2, …, an⟩
jonkv@ida
Size of a Planning Problem

Now: The complexity of PLAN-EXISTENCE
 The problem of finding out whether there exists a solution
(Finding a solution has to be at least this difficult…)

We will be satisfied with a “rough” classification
 Example: P = PTIME = polynomial time: Includes n, n2, n10, n1000000, …
 Example: EXPTIME = exponential time: Includes 1.001n, 2n, 10000n, …
▪ Note: Even 1.001n will catch up with (and exceed) n1000000
 Some common complexity classes:
▪ NLOGSPACE
⊆P
= the algorithms that only require polynomial time
⊆ NP
⊆ PSPACE
= the algorithms that only require polynomial space
⊆ EXPTIME
(we know P ⊊ EXPTIME)
⊆ NEXPTIME
(we know NP ⊊ NEXPTIME)
⊆ EXPSPACE
(we know PSPACE ⊊ EXPSPACE)
⊆…
▪ Sorting is in P, and therefore also in NP, PSPACE, …
13
jonkv@ida
Complexity of Planning

14
Most representations use:
 Operators that have parameters and many instances (called actions)
 Predicates that have parameters and many instances
 Consider an untyped problem of size 1000, with 100 constants (objects)
▪ One operator:
DoIt(?a,?b) – 10,000 instances (actions)
▪ One predicate:
pred(?a,?b) – 10,000 instances (ground atoms)
 Now add more parameters to the operator / predicate:
▪ DoIt(?a,?b,?c)
– 1,000,000 instances, problem size 1003
▪ DoIt(?a,?b,?c,?d) – 100,000,000 instances, problem size 1006
 Adding 3 characters multiplies the number of instances by 100
In the worst case, the number of actions and ground atoms
is exponential in the size of the domain definition!
jonkv@ida
Complexity Analysis: Observations
15
First Problem Set:
All planning problem statements in the classical representation

How can we analyze this case?
 Counting the number of available actions?
 Doesn't help:
Each action may have to appear multiple times…
NLOGSPACE
⊆P
⊆ NP
⊆ PSPACE
⊆ EXPTIME
⊆ NEXPTIME
⊆ EXPSPACE
jonkv@ida
Complexity Analysis: Classical 1
16
First Problem Set:
All planning problem statements in the classical representation

How can we analyze this case?
 Visiting all states reachable from s0 would be sufficient
 A state has at most an exponential number of facts
▪ Even if our enemies use every increase in
problem size to make the problem harder
  The size of a state is at most exponential
  …  We require at most exponential space
▪ Plan existence is in EXPSPACE
▪ In fact, EXPSPACE-complete – harder than just NP-complete!
(Won’t prove it here…)
NLOGSPACE
⊆P
⊆ NP
⊆ PSPACE
⊆ EXPTIME
⊆ NEXPTIME
⊆ EXPSPACE
jonkv@ida
Complexity Analysis: Classical 2
17
Second Problem Set:
All planning problem statements in the classical representation
that only have positive effects (but pos+neg preconditions allowed)
 Only positive effects
▪  The set of true facts increases monotonically as new actions are added
▪  There can be no point in applying the same action twice!
▪ (But action order matters, due to negative preconditions)
 Checking every sequence of unique actions would be sufficient
▪ We have at most an exponential number of actions
▪  A plan can be at most exponentially long, tested in exp. time
 Non-deterministic algorithms can (conceptually)
“test all alternatives at once”,
▪  in NEXPTIME
▪ (Actually, NEXPTIME-complete)
NLOGSPACE
⊆P
⊆ NP
⊆ PSPACE
⊆ EXPTIME
⊆ NEXPTIME
⊆ EXPSPACE
jonkv@ida
Complexity Analysis: Classical 3
18
Third Problem Set:
All planning problem statements in the classical representation
that only have positive effects and positive preconditions
 Only positive effects
▪  The set of true facts increases monotonically as new actions are added
 Only positive effects and only positive preconditions
▪  The set of applicable actions increases monotonically
  Action order does not matter!
▪ If you can apply A1 now, you can apply A1 after any other actions as well
▪ Could just apply all actions until we reach a fixpoint
NLOGSPACE
▪ There is a solution iff the goal is satisfied in the final state
⊆P
⊆ NP
▪ Exponential number of actions  in EXPTIME
⊆ PSPACE
▪ (Actually, it is EXPTIME-complete! )
⊆ EXPTIME
⊆ NEXPTIME
⊆ EXPSPACE
jonkv@ida
Complexity Analysis: Classical 4

19
One reason for high complexity:
 As n (problem size) increases, we can construct more complex operators
  Number of actions can increase exponentially in n

Suppose operators are fixed / given in advance!
 They are part of a "fixed" domain
 Only the problem instance changes as n grows
▪ Objects
▪ Initial state
▪ Goal
 Number of potential actions will grow polynomially
▪ DoIt(?a,?b) has |Objects|2 instances
jonkv@ida
Complexity Analysis: Classical 5

20
Can the predicates still vary?
 No (more or less)…
 If a predicate is modified, it can never be used in any action
(because the operators were not modified)
  Must be static
▪ Not used in the goal  useless predicate; discard it
▪ Used in the goal  test goal satisfaction before planning begins; then discard it
jonkv@ida
Complexity Analysis: Classical 6

21
For the classical representation:
 Arbitrary classical problem:
▪ EXPSPACE-complete  PSPACE
 Only positive effects:
▪ NEXPTIME-complete  NP or NP-complete, depending on the operators
 Only positive effects, only positive preconditions:
▪ EXPTIME-complete
P
These results are generally more important in practice!
We are usually interested in what happens with more objects,
not if we change operators in the “worst” way possible
NLOGSPACE
⊆P
⊆ NP
⊆ PSPACE
⊆ EXPTIME
⊆ NEXPTIME
⊆ EXPSPACE
jonkv@ida
Complexity Analysis: Classical 7

22
Note: This complexity applies to the worst case
 We saw that restricting the set of problems
gives us tighter time bounds
Handle all planning problem statements in the classical representation
(with pos+neg effects and pos+neg preconditions)
 EXPSPACE-complete
Handle all planning problem statements in the classical representation
that only have positive effects and positive preconditions
 EXPTIME-complete
Handle all planning problem statements for
the standard blocks world
 P (polynomial time given an optimal algorithm)
jonkv@ida
Complexity Analysis: Domains
23
Domain
Plan existence (given
"reasonable" initial state)
Bounded plan existence
("plan with at most n actions")
Logistics
P
NP-complete
Gripper
P (always solvable!)
P
Grid
P
NP-complete
Miconic-10-STRIPS
P
NP-complete
Miconic-10-Simple
P (always solvable!)
NP-complete
Miconic-10
NP-complete
NP-complete
Movie
P
P
Assembly
(Plans can have exponential length;
might determine existence faster)
(Plans can have exponential length; might
determine existence faster)
Blocks World
P
NP-complete
Schedule
P
P
FreeCell
NP-complete
NP-complete
Complexity results for standard benchmark domains in planning.
Malte Helmert, Artificial Intelligence 153(2003):219-262.
jonkv@ida
Complexity Analysis: Domains