





Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Main points of this lecture are: Planning, Motivation, Problem, Language, Condition, Goal, POP, Predicates.
Typology: Study notes
1 / 9
This page cannot be seen from the preview
Don't miss anything!






We started study of AI with the classical approach of problem solving that founders of AI used to exhibit intelligence in programs. If you look at problem solving again you might now be able to imagine that for realistically complex problems too problem solving could work. But when you think more you might guess that there might be some limitation to this old approach.
Lets take an example. I have just landed on Lahore airport as a cricket-loving tourist. I have to hear cricket commentary live on radio at night at a hotel where I have to reserve a room. For doing that, I have to find the hotel to get my room reserved before its too late, and also I have to find the market to buy the radio from. Now this is a more realistic problem. Is this a tougher problem? Let’s see.
One thing easily visible is that this problem can be broken into multiple problems i.e. is composed of small problems like finding market and finding the hotel. Another observation is that different things are dependent on others like listening to radio is dependent upon the sub-problem of buying the radio or finding the market.
Ignore the observations made above for a moment. If we start formulating this problem as usual, be assured that the state design will have more information in it. There will be more operators. Consequently, the search tree we generate will be much bigger. The poor system that will run this search will have much more load than any of the examples we have studied so far. The search tree will consume more space and it will take more calculations in the process.
A state design and operators for the sample problem formulation could be as shown in figure.
Turn right Turn left Move forward Buy radio Get reservation Listen radio Sleep And maybe more…
Initial state Operators
Figure – Sample problem formulation
Location Has radio? Sells radio? IsHotel? IsMarket? Reservation done? And maybe more…
If we apply say, BFS in this problem the tree can easily become something huge like this rough illustration.
Figure – Search space of a moderate problem
Although this tree is just a depiction of how a search space grows for realistic problems, yet after seeing this tree we can very well imagine for even more complex problems that the search tree could be too big, big enough to trouble us. So the question is, can we make such inefficient problem solving any better?
Good news is that the answer is yes. How? Simply speaking, this ‘search’ technique could be improved by acting a bit logically instead of blindly. For example not using operators at a state where their usage is illogical. Like operator ‘sleeping’ should not be even tried to generate children nodes from a state where I am not at the hotel, or even haven’t reserved the room.
Location=Airport Has radio?=No Sells radio?=No IsHotel?=No IsMarket?=No ReservationDone?= No . . .
Location=AirportHas radio?=No Sells radio?=NoIsHotel?=No IsMarket?=NoReservationDone?=No .. .
BuyRadio
XX XX
XX XX
XX XX
XX XX
XX XX
XX XX
XX XX
XX XX
XX XX
TurnRight TurnLeft
State is a conjunction of predicates represented in well-known form, for example, a state where we are at the hotel and do not have either cash or radio is represented as,
at(hotel) ∧ ¬have(cash) ∧ ¬have(radio)
Goal is also represented in the same manner as a state. For example, if the goal of a planning problem is to be at the hotel with radio, it is represented as,
at(hotel) ∧ have(radio)
Action is a predicate used to change states. It has three components namely, the predicate itself, the pre-condition, and post-condition predicates. For example, the action to buy something item can be represented as,
Action: buy(X)
Pre-conditions: at(Place) ∧ sells(Place, X)
Post-conditions/Effect: have(X)
What this example action says is that to buy any item ‘X’, you have to be (pre- conditions) at a place ‘Place’ where ‘X’ is sold. And when you apply this operator i.e. buy ‘X’, then the consequence would be that you have item ‘X’ (post-conditions).
Now that we know what planning is and how states and actions are represented, let us see a basic planning algorithm POP.
POP(initial_state, goal, actions) returns plan Begin Initialize plan ‘p’ with initial_state linked to goal state with two special actions, start and finish Loop until there is not unsatisfied pre-condition Find an action ‘a’ which satisfies an unachieved pre-condition of some action ‘b’ in the plan Insert ‘a’ in plan linked with ‘b’ Reorder actions to resolve any threats End
If you think over this algorithm, it is quite simple. You just start with an empty plan in which naturally, no condition predicate of goal state is met i.e. pre-conditions of finish action are not met. You backtrack by adding actions that meet these unsatisfied pre-condition predicates. New unsatisfied preconditions will be generated for each newly added action. Then you try to satisfy those by using appropriate actions in the same way as was done for goal state initially. You keep on doing that until there is no unsatisfied precondition.
Now, at some time there might be two actions at the same level of ordering of them one action’s effect conflicts with other action’s pre-condition. This is called a threat and should be resolved. Threats are resolved by simply reordering such actions such that you see no threat.
Because this algorithm does not order actions unless absolutely necessary it is known as a partial-order planning algorithm.
Let us understand it more by means of the example we discussed in the lecture from [??].
The problem to solve is of shopping a banana, milk and drill from the market and coming back to home. Before going into the dry-run of POP let us reproduce the predicates.
The condition predicates are: At(x) Has (x) Sells (s, g) Path (s, d)
The initial state and the goal state for our algorithm are formally specified as under.
Initial State: At(Home) ∧ Sells (HWS, Drill) ∧ Sells (SM, Banana) ∧ Sells (SM, Milk) ∧ Path (home, SM) ∧ path (SM, HWS) ∧ Path (home, HWS)
Goal State: At (Home) ∧ Has (Banana) ∧ Has (Milk) ∧ Has (Drill)
The actions for this problem are only two i.e. buy and go. We have added the special actions start and finish for our POP algorithm to work. The definitions for these four actions are.
Go (x) Preconditions: at(y) ∧ path(y,x) Postconditions: at(x) ∧ ~at(y)
Buy (x)
Figure – Plan scene B
There is no threat visible in the current plan, so no re-ordering is required.
The algorithm moves forward. Now if you see the Sells() pre-conditions of the three new actions, they are satisfied with the post-conditions Sells(HWS,Drill), Sells(SM,Banana), and Sells(SM,Milk) of the Start() action with the exact values as shown.
Figure – Plan scene C
We now move forward and see what other pre-conditions are not satisfied. At(HWS) is not satisfied in action Buy(Drill). Similarly At(SM) is not satisfied in actions Buy(Milk) and Buy(Banana). Only action Go() has post-conditions that can satisfy these pre-conditions. Adding them one-by-one to satisfy all these pre-conditions our plan becomes,
Start
At(s) Sells(s, Drill) At(s) Sells(s, Milk) At(s), Sells(s, Bananas)
Finish
Have(Drill), Have(Milk), Have(Bananas) At(Home)
Buy(Drill) Buy(Milk)^ Buy(Bananas)
Start
At(HWS), Sells(HWS, Drill) At(SM), Sells(SM, Milk) At(SM), Sells(SM, Bananas)
Finish
Have(Drill), Have(Milk), Have(Bananas) At(Home)
Buy(Drill) Buy(Milk)^ Buy(Bananas)
Figure – Plan scene D
Now if we check for threats we find that if we go to HWS from Home we cannot go to SM from Home. Meaning, post-condition of Go(HWS) threats the pre-condition At(Home) of Go(SM) and vice versa. So as given in our POP algorithm, we have to resolve the threat by reordering these actions such that no action threat pre- conditions of other action.
That is how POP proceeds by adding actions to satisfy preconditions and reordering actions to resolve any threat in the plan. The final plan using this algorithm becomes.
Figure – Plan scene E
Start
At(HWS), Sells(HWS, Drill) At(SM), Sells(SM, Milk) At(SM), Sells(SM, Bananas)
Finish
Have(Drill), Have(Milk), Have(Bananas) At(Home)
Buy(Drill) Buy(Milk)^ Buy(Bananas)
Go(HWS) Go(SM)
At(Home) At(Home)
Start
At(HWS), Sells(HWS, Drill) At(SM), Sells(SM, Milk) At(SM), Sells(SM, Bananas)
Finish
Have(Drill), Have(Milk), Have(Bananas) At(Home)
Buy(Drill) Buy(Milk)^ Buy(Bananas)
Go(HWS) Go(SM)
At(Home) At(Home)
Go(Home)