cmput 651: front to front perimeter search & pattern databases johnny huynh
Post on 19-Dec-2015
212 views
TRANSCRIPT
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
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|
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?)