41
Search CSC 358/458 5.22.2006

Search

Embed Size (px)

DESCRIPTION

Search. CSC 358/458 5.22.2006. Outline. Homework #6 Game search States and operators Issues Search techniques DFS, BFS Beam search A* search Alpha-beta search. Homework #7. #C with-list-iterator doiter. Game Playing. How can we automate game playing? - PowerPoint PPT Presentation

Citation preview

Search

CSC 358/458

5.22.2006

Outline

Homework #6 Game search

States and operators Issues

Search techniques DFS, BFS Beam search A* search Alpha-beta search

Homework #7

#C with-list-iterator doiter

Game Playing

How can we automate game playing? One of the first problems tackled by AI

research Basic idea

represent the "state" of the game• set of cards• board position

moves are changes in game state winning means reaching a particular state

• defined by the rules

Game tree

Think of each possible position as a nodeeach possible move as an edge

We have a graph structurestarting statesubsequent states

• branching for different possible moves

terminates with winning (or losing)

How to win?

Find a path through the tree to a winning statemake all the moves along that path

But what about the opponent?what about uncertainty?we'll return to these questions in a

minute

Graph search

Game tree search is a special case of graph search lots of other AI problems have been conceptualized

the same way Search domains

Running Prolog programs• each state is an assignment of bindings• links are applying rules to generate new bindings

Planning and scheduling• nodes are states of the world• links are operations that can be performed

Major subfield of AI

Planning

States are combinations of predicates Operators may have conditional

effects Interleaving of planning and execution

replanning

What we need

Start State Goal State Successors Search Strategy

Tree Search

1

2

4 5 6 7

3

Tree Search, cont'd

Main questionHow to order the states?

Tree Search Cont’d

(defun tree-search (states goal-p successors

combiner)

(cond ((null states) fail)

((funcall goal-p (first states))

(first states))

(t (tree-search

(funcall combiner

(funcall successors

(first states))

(rest states))

goal-p successors combiner))))

Tree Search: Depth First Search

Work On The Longest Paths First Backtrack Only When The Current

State Has No More Successors

(defun depth-first-search (start goal-p

successors)

(tree-search (list start) goal-p

successors #’append))

Tree Search: DFS Summary

Depth-First Search Is OK In Finite Search Spaces

In Infinite Search Spaces, Depth-First Search May Never Terminate

Tree Search: Breadth-First Search

Search The Tree Layer By Layer

(defun prepend (x y) (append y x))

(defun breadth-first-search (start goal-p

successors)

(tree-search (list start) goal-p successors

#’prepend))

Tree Search: BFS Summary

In Finite Search Spaces, BFS Is Identical To DFS

In Infinite Search Spaces, BFS Will Always Find A Solution If It Exists

BFS Requires More Space Than DFS

Iterative Deepening

Search depth first to level n then increase n

Seems wasteful but actually is the best method for large

spaces of unknown charcteristics the search frontier expands exponentially

• so it doesn't matter that you're sometimes searching the same (small number of) nodes multiple times

Bi-Directional Search

Work forwards from start Work backwards from goal Until the two points meet Doesn't work for many game

problemsHow many different checkmate

positions are there?

Controlling Search

KnowledgeDFS and BFS do not use knowledge

of the domain Distance heuristic

in many domains, possible to estimate how far from the goal

• "stronger" board positionchoose successor (move) that takes

you closest

Example

Problem: Visit too many nodes, some clearly out of the question

Best First Search

(defun sorter (cost-fn)

#’(lambda (new old)

(sort (append new old) #’< :key cost-fn)))

(defun best-first-search (start goal-p successors cost-fn)

(tree-search (list start) goal-p successors

(sorter cost-fn)))

Greedy Search

Best = closest to goal Problem

Isn't guaranteed to find a solution• not complete

Isn't guaranteed to find the best solution

• not optimal

Greedy example

Heuristic: minimize h(n) = “Euclidean distance to destination”

Problem: not optimal (through Rimmici Viicea and Pitesti is shorter)

A* Search

Best = min (path so far + estimated cost to goal)

Restrictionestimate must never overestimate the

cost If so

completeoptimal

Example

A*: minimize f(n) = g(n) + h(n)

Beam Search

Ever-increasing queue of states under consideration Can be very large O(bn) where b is the branch factor and n is the depth

Completeness is required if there is only one solution we don't want to throw out the state that leads to it

What if there are many good solutions many possible checkmate positions discard some unpromising states

Beam search keep no more than k states of the queue if too many, discard the ones with highest f(n)

Beam Search Cont’d

(defun beam-search (start goal-p sucessors

cost-fn beam-width)

(tree-search (list start) goal-p succecssors

#’(lambda (old new)

(let ((sorted (funcall (sorter cost-fn) old new)))

(if (> beam-width (length sorted))

sorted

(subseq sorted 0 beam-width))))))

Improving Beam Search

What if the search fails?try different beam widths

(defun iter-wide-search (start goal-p successors &key (width 1) (max 100)) (unless (> width max) (or (beam-search start goal-p successors cost-fn width) (iter-wide-search start goal-p successors cost-fn :width (+ width 1) :max max))))

(Practically) Infinite Search

What if the goal state is so far away that search won't find it? chess = 1043 states greater than the number of atoms in the universe

Pick a search depth estimate the "value" of the position at that depth treat that as the "result" of the search

Search then becomes finding the best board position after k moves easy enough to store the best node so far and the path (move) to it

What about the opponent?

Obviously, our opponent will not pick moves on the path to our winning game

What move to predict? Worst case scenario

the opponent will do what's best for him To win

we need a strategy that will succeed even if the opponent plays his best

Mini-max assumption

Assume that the opponent values the game state the opposite from youVme(state) = -Vopp(state)

At alternate nodeschoose the state with maximum f

• for me

or, choose the state with minimum f• for the opponent

Mini-max algorithm

Build tree with two types of nodes max nodes

• my move min nodes

• opp move Perform depth-first search, with iterative deepening Evaluate the board position at each node

on a max node, use the max of all children as the value of the parent

on a min node, use the min of all children as the value of the parent when search is complete

• the move that leads to the max child of the current node is the one to take

Anytime this is an "anytime" algorithm you can stop the search at any time and you have a best estimate

of your move (to some depth)

Problem

I may waste time searching nodes that I would never use

A* doesn't helpsince a position may be bad in one

move but better after 3• sacrifice

Alpha-beta pruning

Alpha-beta pruningreduces the size of the search spacewithout changing the answer

Simple ideadon't consider any moves that are

worse than ones you already know about

Animated example

http://sern.ucalgary.ca/courses/CPSC/533/W99/presentations/L2_5B_Lima_Neitz/abpruning.html

What about chance?

In a game of chance there is a random element in the game

process Backgammon

the player can only make moves that use the outcome of the dice roll

How do I know what my opponent will do? I don't but I can have an expectation

Expectiminimax

The ideaGame theoretic utility calculationExpected value = sum of all outcome

values * the likelihood of occurrence The value of a node is not simply

copied from the "best" childbut summed over all possible children

Algorithm

Tree has three types of nodesmax nodesmin nodeschance nodes

Chance nodes calculate the expectation associated with all of the children

http://sern.ucalgary.ca/courses/cpsc/533/W99/presentations/L2_5B_Lima_Neitz/chance.html

Killer heuristic

One additional optimization works well in chess

Often a move that is really good or really bad

Will be really good or bad in multiple board positions Example

a move that captures my queen if my queen is under attack

• the move in which the opponent takes my queen• will be his best move in most board positions• except the positions in which I move the queen out of attack

If a move leads to a really good or really bad position try it first when searching more likely to produce an extreme value that helps alpha-

beta search

No class next week

Progress report due tonight1 or 2 pages of textsaying where you are

Class on 6/5CLOS