Combining Front-to-End Perimeter Search and Pattern Databases CMPUT 652 Eddie 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 B i We know the optimal path from B i 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(b d ) Perimeter Search O(b r +b d-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, B i ), where B i is a perimeter node

A Digression… Among other things, the Max method requires:  h(Start, A), where A is a search node  h(Start, B i ), where B i 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

A Digression... However, this technique may provide inconsistent heuristics ϕ1ϕ1 ϕ2ϕ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, B i ) = h*(B i, Start) We can map the Start state to the Goal state In this case, when we do alternate lookups on A and B i, we are using the same mapping! Our heuristic is now consistent!

A Digression... ϕ ϕ ϕ

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)=min i (h(B i,start) +g*(B i,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

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

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?