combining front-to-end perimeter search and pattern databases cmput 652 eddie rafols
Post on 21-Dec-2015
214 views
TRANSCRIPT
Combining Front-to-End Perimeter Search and
Pattern Databases
CMPUT 652Eddie Rafols
Motivation
From Russell, 1992
Allocating Memory
• More memory for Open/Closed Lists• Caching• Perimeter Search• Pattern Databases
Allocating Memory
• More memory for Open/Closed Lists• Caching• Perimeter Search• Pattern Databases
Perimeter Search
• Generate a perimeter around the Goal
• Any path to Goal must pass through a perimeter node Bi
• We know the optimal path from Bi to Goal
• Stopping condition for IDA* is now: If A is a perimeter node and g(Start,A)
+g*(A,Goal) Bound
Perimeter Search
• Traditional Search O(bd)• Perimeter Search O(br+bd-r)
• Large potential savings!
Perimeter Search
• Can be used to improve our heuristic• Kaindl & Kainz, 1997
Add Method Max Method
Pattern Databases
• Provide us with a consistent estimate of the distance from any given state to the goal*
*This point will become relevant in a few slides
Approach
• Generate a pattern database to provide a heuristic
• Use Kaindl & Kainz’s techniques to improve on heuristic values (Add,Max)
• Determine how perimeter search and PDBs can most effectively be combined via empirical testing
A Digression…
• Among other things, the Max method requires: h(Start, A), where A is a search node h(Start, Bi), where Bi is a perimeter node
A Digression…
• Among other things, the Max method requires: h(Start, A), where A is a search node h(Start, Bi), where Bi is a perimeter node
• We are not explicitly given this information in a PDB.
A Digression...
• Recall: Alternate PDB lookups
• If we are dealing with a state space where distances are symmetric and ‘tile’-independant, we can use this technique
A Digression...
• ex. Pancake Problem
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
A Digression...
• However, this technique may provide inconsistent heuristics
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
ϕ1
ϕ2
ϕ1 ϕ2
A Digression...
• Kaindl’s proof of the max method relies on a consistent heuristic
• ...but we can still use our pattern database
• We just have to use it correctly
A Digression...
• Distances are symmetric, therefore h*(Start, A) = h*(A, Start) h*(Start, Bi) = h*(Bi, Start)
• We can map the Start state to the Goal state
• In this case, when we do alternate lookups on A and Bi, we are using the same mapping!
• Our heuristic is now consistent!
A Digression...
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
ϕ
ϕ
ϕ
A Third Heuristic?
• Since we have the mechanisms in place, why not use alternate lookup to get h’(Goal, A)?
• Turns out that this is the exact same lookup as h(A,Goal)
Combining the Heuristics
• The Add method lets us adjust our normal PDB estimate: h’1(A,goal) = h(A,goal) +
• The Max method gives us another heuristic: h’2(A,goal)=mini(h(Bi,start) +g*(Bi,goal))-h(A, start)
• Our final heuristic: H(A,goal)=max(h’1(A,goal),h’2(A,goal))
Hypotheses
All memory used on perimeter, expect poor performance
All memory used on PDB, expect good performance, but not the best possible
Small perimeters combined with large PDBs should outperform large perimeters with small PDBs
Method
• Do a binary search in the memory space. Test ‘pure’ perimeter search and ‘pure’
PDB search Give half the memory to the winner,
compare whether a PDB or a perimeter would be a more effective use of the remaining memory
Repeat until perimeter search becomes a more effective use of memory
Results
100% Perimeter
1
10
100
1000
10000
100000
1000000
10000000
1 2 3 4 5 6 7 8 9 10
Start State
Nodes Generated
100% PDB
1
10
100
1000
10000
100000
1000000
10000000
1 2 3 4 5 6 7 8 9 10
Start State
log(Nodes Generated)
Results
50% PDB, 50% PDB
1
10
100
1000
10000
100000
1000000
10000000
1 2 3 4 5 6 7 8 9 10
Start State
log(Nodes Generated)
50% PDB, 50% Perimeter
1
10
100
1000
10000
100000
1000000
10000000
1 2 3 4 5 6 7 8 9 10
Start State
log(Nodes Generated)
Results
75% PDB, 25% PDB
1
10
100
1000
10000
100000
1000000
10000000
1 2 3 4 5 6 7 8 9 10
Start State
log(Nodes Generated)
75% PDB, 25% Perimeter
1
10
100
1000
10000
100000
1000000
10000000
1 2 3 4 5 6 7 8 9 10
Start States
log(Nodes Generated)
Results
87% PDB, 13% PDB
1
10
100
1000
10000
100000
1000000
10000000
1 2 3 4 5 6 7 8 9 10
Start State
log(Nodes Generated)
87% PDB, 13% Perimeter
1
10
100
1000
10000
100000
1000000
10000000
1 2 3 4 5 6 7 8 9 10
Start State
log(Nodes Generated)
Results
92% PDB, 8% Perimeter
1
10
100
1000
10000
100000
1000000
10000000
1 2 3 4 5 6 7 8 9 10
Start State
log(Nodes Generated)
92% PDB, 8% PDB
1
10
100
1000
10000
100000
1000000
10000000
1 2 3 4 5 6 7 8 9 10
Start State
log(Nodes Generated)
Discussion
• Discouraging results• Using “extra” space for a PDB seems
to provide better results across the board
Discussion
• Adding a perimeter does not appear to have a significant effect
Average Nodes Generated
1000
10000
100000
1000000
0 2 4 6 8 10 12
100PDB
50PDB-50Perim
75PDB-25 Perim
87PDB-13Perim
92PDB-8Perim
Discussion
• Empirically, the Add method is always returning = 0 A directed strategy for perimeter
creation is likely needed for this method to have any effect
Discussion
• Further experiments show that given a fixed PDB, as perimeters increase in size, there is a negligible performance increase
An Idea
• Is the heuristic effectively causing paths to perimeter nodes to be pruned?
• This means that performance is only being improved along a narrow search path
• Can we generate the perimeter ‘intelligently’ to make it more useful?
Questions?