cmput 651: front to front perimeter search & pattern databases johnny huynh

21
CMPUT 651: Front to Front Perimeter Search & Pattern Databases Johnny Huynh

Post on 19-Dec-2015

212 views

Category:

Documents


0 download

TRANSCRIPT

CMPUT 651:Front to Front Perimeter Search

& Pattern Databases

Johnny Huynh

Outline

Introduction to FFPS Problems Improving FFPS itself Perimeters and PDB’s Results Conclusion

Front-to-Front Perimeter Search (FFPS)

Build a perimeter around goal Find shortest path a perimeter state Use a heuristic to find a perimeter state Heuristic can be a pattern database (PDB)

GS

P

Problems with FFPS

Taking the MIN of estimates Checking for |P| Perimeter States Each node expansion requires |P| estimates Perimeter states and PDBs requires memory

GS

P

Problems with FFPS

Taking the MIN of estimates Checking for |P| Perimeter States Each node expansion requires |P| estimates Perimeter states and PDBs requires memory

GS

P

Improving FFPSReducing Perimeter Checks

given a perimeter state, p,

if h(p) = 0

then state, s, needs to be checked only when

h(s) = 0. In the 9-puzzle (2x5), reduced number of goal

comparisons by 92.5%

Problems with FFPS

Taking the MIN of estimates Checking for |P| Perimeter States Each node expansion requires |P| estimates Perimeter states and PDBs requires memory

GS

P

Improving FFPSReducing Heuristic Evaluations

Fraction of Node expansion time required to evaluate heuristic determines speedup.

[Dillenburg ’93]

fraction Optimal Radius Speedup

0.01 6 4.6

0.02 5 3.3

0.05 4 2.2

0.1 3 1.6

0.2 2 1.2

0.3 1 1.1

Improving FFPSReducing Heuristic Evaluations

If heuristic is monotonically non-decreasing.

Estimate distance to all perimeter states

Decrease estimate by edge cost

Re-compute only the minimum estimates

Improving FFPSReducing Heuristic Evaluations

Radius Total PDB Lookups Reduced PDB Lookups

%

1 9,910 427 95.7

2 743,432 46,175 93.8

3 1,556,360 129,770 91.7

4 2,615,490 256,375 90.2

5 3,644,070 405,560 88.9

6 1,529,750 168,845 88.9

Problems with FFPS

Taking the MIN of estimates Checking for |P| Perimeter States Each node expansion requires |P| estimates Perimeter states and PDBs requires memory

GS

P

Memory for Perimeter or PDB?

Distance to each P estimated by a PDB Fixing number of states in memory,

How many Perimeter states? How many PDB entries?

|P| + |P| * |PDB| = c Must remember that |PDB| determined by

level of abstraction

Initial (Poor) Results

Initial (Poor) Results

Mixing Levels of Abstraction

c = |P| + |P| * |PDB| What if |P| > |PDB|? Each Perimeter’s PDB doesn’t have to be the same

c = |P| + ∑(|Pi| * |PDBi|) , Pi є P , PDBi є PDB

Abstraction |PDBi|

P0 011234567 180k

P1 011223456 90k

P2 011123456 60k

P2 011122345 30k

Mixing Levels of Abstraction

Averages Same Level of Abstraction

(|PDB| = 90k)

Different Levels of Abstraction

(avg |PDB| = 90k)

Abstraction0 Look-ups 170 21

Abstraction1 Look-ups 144 156

Abstraction2 Look-ups 109 239

Abstraction3 Look-ups 133 250

Nodes Expanded 56.2 64.5

[8-puzzle with 8 perimeter nodes and ~360K states in memory]

Combining Perimeter PDBs

If each PDB uses same abstraction, then will look up the same key in each PDB. h(s) = min {PDB1 [Φ(s)] … PDBN [Φ(s)] }

Create one PDB with the same keys, and save only the MIN from each perimeter PDB. h(s) = PDBc[Φ(s)]

Reduce memory from:

|P| + |P| * |PDB| to |P| + |PDB|

Combining Perimeter PDBs

Combining Perimeter PDBs

Conclusion

FFPS performance affected by: Number of goal comparisons Number of heuristic evaluations (PDB lookups)

FFPS Perimeter vs PDB: Without combining PDB’s, radius should be kept

small. Combining PDB’s, memory should be allocated

for radius… (up to a certain point?)

Questions?