{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

search2[1] - CPS 170 Alterna/ve Search Techniques Ron...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: CPS 170 Alterna/ve Search Techniques Ron Parr With thanks to Vince Conitzer for LP,(M)IP examples. Overview •  Memory ­bounded Search •  Local Search and Op/miza/on •  Searching with Incomplete Informa/on 1 Memory ­bounded Search: Why? •  We run out of memory before we run out of /me. •  Problem: Need to remember en/re search horizon •  Solu/on: Remember only a par/al search horizon •  Issue: Maintaining op/mality, completeness •  Issue: How to minimize /me penalty AUempt 1: IDA* •  Itera/ve deepening A* •  Idea: Like IDDFS, but use the f cost as a cutoff –  Cutoff all searches with f > 1, then f > 2, f > 3, etc. –  Mo/va/on: Cut off bad ­looking branches early •  Problems: –  Excessive node regenera/on –  Can s/ll use a lot of memory Cutoff =3 h=1 h=2 h=1 h=1 2 AUempt 2: RBFS •  Recursive best first search •  Objec/ve: Linear space •  Idea: Remember best alterna/ve •  Rewind, try alterna/ves if “best first” path gets too expensive •  Remember costs on the way back up RBFS Assume h=1, ini/ally along this path. alt = 12 alt = 11 alt = 9 Replace with alt = 11 alt = 13 Return to best alternate. alt = 14 alt = 16 alt = 15 Problem: Thrashing! h=3 3 SMA* •  Idea: Use all of available memory •  Discard the worst leaf when memory starts to run out, to make room for new leaves •  Values get backed up to parents •  Op/mal if solu/on fits in memory •  Complete Expand •  Thrashing s/ll possible Painful to implement h=1 Replace with h=3(+1) if we remove h=3 this node h=1 h=4 Op/miza/on •  Solu/on is more important than path •  Interested in minimizing or maximizing some func/on of the problem state –  Find a protein with a desirable property –  Op/mize circuit layout –  Sa/sfy requirements for your major •  History of search steps not worth the trouble 4 State Space Landscape Objec/ve func/on value Local Changes Problem feature Goal: Find values of problem features that maximize objec/ve func/on. Note: This is conceptual. Omen this func/on is not smooth. Hill Climbing •  Idea: Try to climb up the state space landscape to find a senng of the problem features with high value. •  Approaches: –  Steepest ascent –  Stochas/c – pick one of the good ones –  First choice •  This is a greedy procedure 5 Limitations of Hill Climbing •  Local maxima •  Ridges – direction of ascent is at 45 degree angle to any of the local changes •  Plateaux – flat expanses Genng Unstuck •  Random restarts •  Simulated annealing –  Take downhill moves with small probability –  Probability of moving downhill decreases with •  Number of itera/ons •  Steepness of downhill move –  If system is “cooled” slowly enough, will find global op/mal w.p. 1 –  Mo/vated by the annealing of metals and glass 6 Gene/c Algorithms •  GAs are hot in some circles •  Biological metaphors to mo/vate search •  Organism is a word from a finite alphabet (organisms = states) •  Fitness of organism measures its performance on task (fitness = objec/ve) •  Uses mul/ple organisms (parallel search) •  Uses muta/on (random steps) Crossover Crossover is a dis/nguishing feature of GAs: Randomly select organisms for “reproduc/on” in accordance with their fitness. More “fit” individuals are more likely to reproduce. Reproduc/on is sexual and involves crossover: Organism 1: 1 1 0 0 1 0 0 1 0 Organism 2: 0 0 0 1 0 1 1 1 0 Offspring: 1 1 0 0 1 1 1 1 0 7 Is this a good idea? •  Has worked well in some examples •  Can be very briUle –  Representa/ons must be carefully engineered –  Sensi/ve to muta/on rate –  Sensi/ve to details of crossover mechanism •  For the same amount of work, stochas/c variants of hill climbing omen do beUer •  Hard to analyze; needs more rigorous study Con/nuous Spaces •  In con/nuous spaces, we don’t need to “probe” to find the values of local changes •  If we have a closed ­form expression for our objec/ve func/on, we can use the calculus •  Suppose objec/ve func/on is: f ( x1 , y1, x2 , y2 , x3 , y3 ) •  Gradient tells us direc/on and steepness of change ∂f ∂f € ∂f ∂f ∂f ∂f ∇f = ( , , , , , ) ∂ x 1 ∂ y1 ∂ x 2 ∂ y2 ∂ x 3 ∂ y3 € 8 Following the Gradient x = ( x1, y1 , x2 , y2 , x3 , y3 ) x ← x + α∇f ( x ) x € For sufficiently small step sizes, this will converge to a local op/mum. € If gradient is hard to compute: •  Compute empirical gradient •  Compare with classical hill climbing Constrained Op/miza/on •  Don’t forget about the easier cases –  If the objec/ve func/on is linear, things are easier –  If linear constraints, solve as a linear program: –  Maximize (minimize): –  Subject to: f ( x ) Ax ≤ b ( Ax ≥ b) –  Can be done in polynomial /me € –  Can solve some quadra/c programs in poly /me € € 9 Linear programs: example •  Make reproduc/ons of 2 pain/ngs •  Pain/ng 1: •  Sells for $30 •  Requires 4 units of blue, 1 green, 1 red •  Pain/ng 2 •  Sells for $20 •  Requires 2 blue, 2 green, 1 red •  We have 16 units blue, 8 green, 5 red maximize 3x + 2y subject to 4x + 2y ≤ 16 x + 2y ≤ 8 x + y ≤ 5 x ≥ 0 y ≥ 0 Solving the linear program graphically maximize 3x + 2y 8 subject to 4x + 2y ≤ 16 6 x + 2y ≤ 8 x + y ≤ 5 4 x ≥ 0 2 y ≥ 0 0 op/mal solu/on: x=3, y=2 2 4 6 8 10 Modified LP maximize 3x + 2y subject to 4x + 2y ≤ 15 x + 2y ≤ 8 x + y ≤ 5 x ≥ 0 y ≥ 0 Op/mal solu/on: x = 2.5, y = 2.5 Solu/on value = 7.5 + 5 = 12.5 Half pain/ngs? Integer (linear) program maximize 3x + 2y 8 subject to 4x + 2y ≤ 15 6 x + 2y ≤ 8 x + y ≤ 5 4 x ≥ 0, integer y ≥ 0, integer 2 0 op/mal IP solu/on: x=2, y=3 (objec/ve 12) op/mal LP solu/on: x=2.5, y=2.5 (objec/ve 12.5) 2 4 6 8 11 Mixed integer (linear) program maximize 3x + 2y 8 subject to 4x + 2y ≤ 15 6 x + 2y ≤ 8 x + y ≤ 5 4 x ≥ 0 y ≥ 0, integer 2 0 op/mal IP solu/on: x=2, y=3 (objec/ve 12) op/mal LP solu/on: x=2.5, y=2.5 (objec/ve 12.5) op/mal MIP solu/on: x=2.75, y=2 (objec/ve 12.25) 2 4 6 8 Solving linear/integer programs •  Linear programs can be solved efficiently –  Simplex, ellipsoid, interior point methods… •  (Mixed) integer programs are NP ­hard to solve –  Quite easy to model many standard NP ­complete problems as integer programs (try it!) –  Search type algorithms such as branch and bound •  Standard packages for solving these –  GNU Linear Programming Kit, CPLEX, … •  LP relaxa/on of (M)IP: remove integrality constraints –  Gives upper bound on MIP (~admissible heuris/c) 12 Searching with Par/al Informa/on •  Mul/ple state problems –  Several possible ini/al states •  Con/ngency problems –  Several possible outcomes for each ac/on •  Explora/on problems –  Outcomes of ac/ons not known a priori, must be discovered by trying them Example •  Ini/al state may not be detectable –  Suppose sensors for a nuclear reactor fail –  Need safe shutdown sequence despite ignorance of some aspects of state •  This complicates search enormously •  In the worst case, con/ngent solu/on could cover the en/re state space 13 State Sets •  Idea: –  Maintain a set of candidate states –  Each search node represents a set of states –  Can be hard to manage if state sets get large •  If states have probabilis/c outcomes, we maintain a probability distribu/on over states Searching in Unknown Environments •  What if we don’t know the consequences of ac/ons before we try them? •  Omen called on ­line search •  Goal: Minimize compe//ve ra/o –  Actual distance/distance traveled if model known –  Problema/c if ac/ons are irreversible –  Problema/c if links can have unbounded cost 14 Conclusions and Parting Thoughts •  There are search algorithms for almost every situation •  Many problems can be formulated as search •  While search is a very general method, it can sometimes outperform special-purpose methods 15 ...
View Full Document

{[ snackBarMessage ]}