University of Wisconsin - Madison | CS 540 Lecture Notes | C. R. Dyer |
Could describe a situation we want to achieve, a set of properties that we want to hold, etc. Requires defining a "goal test" so that we know what it means to have achieved/satisfied our goal.
This is a hard part that is rarely tackled in AI, usually assuming that the system designer or user will specify the goal to be achieved. Certainly psychologists and motivational speakers always stress the importance of people establishing clear goals for themselves as the first step towards solving a problem. What are your goals???
Quantify all of the primitive actions or events that are sufficient to describe all necessary changes in solving a task/goal. No uncertainty associated with what an action does to the world. That is, given an action (also called an operator or move) and a description of the current state of the world, the action completely specifies (1) if that action CAN be applied to the current world (i.e., is it applicable and legal), and (2) what the exact state of the world will be after the action is performed in the current world (i.e., we don't need any "history" information to be able to compute what the new world looks like).
Note also that actions can all be considered as discrete events that can be thought of as occurring at an instant of time. That is, the world is in one situation, then an action occurs and the world is now in a new situation. For example, if "Mary is in class" and then performs the action "go home," then in the next situation she is "at home." There is no representation of a point in time where she is neither in class nor at home (i.e., in the state of "going home").
The number of operators needed depends on the representation used in describing a state (see below). For example, in the 8-puzzle, we could specify 4 possible moves for each of the 8 tiles, resulting in a total of 4*8=32 operators. On the other hand, we could specify four moves for the "blank" square and there would need to be only 4 operators.
The size of a problem is usually described in terms of the number of states that are possible. For example, in Tic-Tac-Toe there are about 3^9 states. In Checkers there are about 10^40 states. Rubik's Cube has about 10^19 states. Chess has about 10^120 states in a typical game.
We will use the Closed World Assumption: All necessary information about a problem domain is available in each percept so that each state is a complete description of the world. There is no incomplete information at any point in time.
What's in a state is the knowledge representation problem. That is, we must decide what information from the raw percept data is relevant to keep, and what form the data should be represented in so as to make explicit the most important features of the data for solving the goal. Is the color of the boat relevant to solving the Missionaries and Cannibals problem? Is sunspot activity relevant to predicting the stock market? What to represent is a very hard problem that is usually left to the system designer to specify. How to represent domain knowledge is a topic that will be treated later in the course.
Related to this is the issue of what level of abstraction or detail to describe the world. Too fine-grained and we'll "miss the forest for the trees." Too coarse-grained and we'll miss critical details for solving the problem.
The number of states depends on the representation and level of abstraction chosen. For example, in the Remove-5-Sticks problem, if we represent the individual sticks, then there are 17-choose-5 possible ways of removing 5 sticks. On the other hand, if we represent the "squares" defined by 4 sticks, then there are 6 squares initially and we must remove 3 squares, so only 6-choose-3 ways of removing 3 squares.
- - | | | - - | | | - - | | | - -
(5,0) = Start / \ (3,2) (0,0) / \ (3,0) (0,2) / (1,2) / (1,0) / (0,1) = Goal
function general-search(problem, QUEUEING-FUNCTION) ;; problem describes the start state, operators, goal test, and ;; operator costs ;; queueing-function is a comparator function that ranks two states ;; general-search returns either a goal node or "failure" nodes = MAKE-QUEUE(MAKE-NODE(problem.INITIAL-STATE)) loop if EMPTY(nodes) then return "failure" node = REMOVE-FRONT(nodes) if problem.GOAL-TEST(node.STATE) succeeds then return node nodes = QUEUEING-FUNCTION(nodes, EXPAND(node, problem.OPERATORS)) ;; Note: The goal test is NOT done when nodes are generated ;; Note: This algorithm does not detect loops end
c=1 until solution found do DFS with depth bound (aka cutoff) c c = c+1
S ... Initial State /|\ 1/ 5 \8 / | \ A B C /|\ | / 3/ 7 9 4 /5 / | \|/ D E G .... Goal StateNodes expanded by:
return GENERAL-SEARCH(problem, ENQUEUE-AT-FRONT)
return GENERAL-SEARCH(problem, ENQUEUE-AT-END)
return GENERAL-SEARCH(problem, ENQUEUE-BY-PATH-COST)
Copyright © 1996-2003 by Charles R. Dyer. All rights reserved.