combining front-to-end perimeter search and pattern databases cmput 652 eddie rafols

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?