How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

27
How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011

Transcript of How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Page 1: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

How to Think about Prolog - 1

Mike’s Prolog Tutorial29 Sept 2011

Page 2: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Ideal Evolution of Prolog Programs

1. View the problem as a relationship between “things”2. Find simple examples of that relationship3. Define the relationship in English4. Translate it into FOL5. Devise representation of “things” where relationship

becomes “definable”6. Translate that into a correct Prolog program7. Arrange clauses/preds so program terminates8. Arrange clauses/preds so program efficient

Page 3: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Evolution Never Ideal

• Real development never goes this directly

• Then why talk about the ideal?

• Because when things go wrong, you can use it to diagnose which stage to go to.

Page 4: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Example Problem

• Rush Hour domain• Forward search (at least for IDA*) is too

inefficient• Would like to do bidirectional search• Need fully specified goal state but only have

partially specified goal state• Want to create the set of possible fully

specified goal end states

Page 5: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Step 1: See problem as relationship

• View the problem as a relationship between “things”, what relationship?

Page 6: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Step 1: See problem as relationship

• View the problem as a relationship between “things”, what relationship?

• Informally, in English, we want states that :– Satisfy the goal– Are reachable from the initial state

Page 7: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Step 1: See problem as relationship

• View the problem as a relationship between “things”, what things?

Page 8: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Step 1: See problem as relationship

• View the problem as a relationship between “things”, what things?– Fully specified goal state– Given partially specified goal state

Page 9: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Step 1: See problem as relationship

• View the problem as a relationship between “things”, what things?– Fully specified goal state– Given partially specified goal state– Initial state– Rules of Rush Hour

• Initial state and rules of Rush Hour define reachability for us

• Rush Hour rules are only implicitly defined

Page 10: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Step 2: Find examples

• Find simple examples of that relationship

Page 11: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Step 3: Define relationship in English

• fullySpecifiedGoalState(InitialState, PartiallySpecifiedGoalState, FullySpecifiedGoalState) :-

• FullySpecifiedGoalState satisfies PartiallySpecifiedGoalState

• FullySpecifiedGoalState reachable from InitialState

Page 12: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Step 3: Define relationship in English

• FullySpecifiedGoalState satisfies PartiallySpecifiedGoalState means that the red car is in its exit location

• FullySpecifiedGoalState reachable from InitialState means there is some sequence of “actions” that transforms InitialState into FullySpecifiedGoalState

Page 13: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Step 4: Translate it into FOL

• fullySpecifiedGoalState(InitialState, PartiallySpecifiedGoalState, FullySpecifiedGoalState) :-– FullySpecifiedGoalState |= PartiallySpecifiedGoalState– exists(<a0, a1, ..., an>) |

• an(...(a1(a0(InitialState))...) = FullySpecifiedGoalState

Page 14: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

An obstacle

• reachable looks like it will be very expensive to compute and we would have to solve our problem (many times over) to compute it

• if exact relationship is too expensive to compute then what can we do??

Page 15: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Next best

• If the exact answer is too expensive then use approximations.

• What does that mean in this situation?

Page 16: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Next best

• If the exact answer is too expensive then use approximations.

• What does that mean in this situation?– Upper bounds– Lower bounds

• What does that mean?

Page 17: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Next best

• If the exact answer is too expensive then use approximations.

• What does that mean in this situation?– Upper bounds• Every state in the exact solution is also a state in the

approximation

– Lower bounds• Every state in the approximation is also in the exact

solution

Page 18: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Upper & Lower Bounds

• Note that the set of all states is an upper bound for our problem and that the empty set is a lower bound.

• Obviously not all bounds are equally useful.• The closer the bound is to the exact solution

the better and the cheaper the computation of that approximation the better.

• There is a tradeoff between cost and fineness of approximation.

Page 19: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Which type of bound do we want?

• What we want is the set of all reachable states that satisfy the goal condition so that we can use it to search backwards.

• What is the worst case if we use a lower bound?

• What is the worst case if we use an upper bound?

Page 20: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Which type of bound do we want?

• What we want is the set of all reachable states that satisfy the goal condition so that we can use it to search backwards.

• What is the worst case if we use a lower bound?– Incompleteness

• What is the worst case if we use an upper bound? – Too costly

Page 21: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Which type of bound do we want?

• We want an upper bound– But we want one that is small and cheap to

compute• How do we do this?

Page 22: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Which type of bound do we want?

• We want an upper bound– But we want one that is small and cheap to

compute• How do we do this?– Given our initial state and our rules, we try to find

invariants, i.e., conditions that are true in our initial state which are preserved by our rules.

– Why????

Page 23: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Invariants => Upper Bounds

• We use the invariant as a filter.• If we know all states reachable from I satisfy

some condition then we can filter out all those states that don’t satisfy that condition.– The most obvious of these conditions are

invariants.

Page 24: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Hunting for invariants

• What is in our initial state that is preserved by the actions?

Page 25: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Hunting for invariants

• What is in our initial state that is preserved by the actions?– All vehicles on board– No two vehicles in same location– Vehicles cannot change orientation– Horizontal vehicles cannot change row– Vertical vehicle cannot change column

• These invariants can be viewed as constraints

Page 26: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Modifying our defintion

• fullySpecifiedGoalState(InitialState, PartiallySpecifiedGoalState, FullySpecifiedGoalState) :-– FullySpecifiedGoalState |= PartiallySpecifiedGoalState– exists(<a0, a1, ..., an>) |

• an(...(a1(a0(InitialState))...) = FullySpecifiedGoalState

– satisfies(Constraints, FullySpecifiedGoalState)

Page 27: How to Think about Prolog - 1 Mike’s Prolog Tutorial 29 Sept 2011.

Refining Problem Type

• Given: satisfies(Constraints, FullySpecifiedGoalState)

it seems obvious that our problem is a constraint satisfaction problem.

• This means we should use our knowledge of CSPs to help formulate this problem.

• This is where we will start next time.