How to Think about Prolog - 1

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

2. Ideal Evolution of Prolog Programs • View the problem as a relationship between “things” • Find simple examples of that relationship • Define the relationship in English • Translate it into FOL • Devise representation of “things” where relationship becomes “definable” • Translate that into a correct Prolog program • Arrange clauses/preds so program terminates • Arrange clauses/preds so program efficient

3. 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.

4. 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

5. Step 1: See problem as relationship • View the problem as a relationship between “things”, what relationship?

6. 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

7. Step 1: See problem as relationship • View the problem as a relationship between “things”, what things?

8. 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

9. 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

10. Step 2: Find examples • Find simple examples of that relationship

11. Step 3: Define relationship in English • fullySpecifiedGoalState(InitialState, PartiallySpecifiedGoalState, FullySpecifiedGoalState) :- • FullySpecifiedGoalStatesatisfies PartiallySpecifiedGoalState • FullySpecifiedGoalStatereachable from InitialState

12. Step 3: Define relationship in English • FullySpecifiedGoalStatesatisfies PartiallySpecifiedGoalStatemeans that the red car is in its exit location • FullySpecifiedGoalStatereachable from InitialState means there is some sequence of “actions” that transforms InitialState into FullySpecifiedGoalState

13. Step 4: Translate it into FOL • fullySpecifiedGoalState(InitialState, PartiallySpecifiedGoalState, FullySpecifiedGoalState) :- • FullySpecifiedGoalState|= PartiallySpecifiedGoalState • exists(<a0, a1, ..., an>) | • an(...(a1(a0(InitialState))...) = FullySpecifiedGoalState

14. 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??

15. Next best • If the exact answer is too expensive then use approximations. • What does that mean in this situation?

16. 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?

17. 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

18. 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.

19. 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?

20. 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

21. 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?

22. 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????

23. 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.

24. Hunting for invariants • What is in our initial state that is preserved by the actions?

25. 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

26. Modifying our defintion • fullySpecifiedGoalState(InitialState, PartiallySpecifiedGoalState, FullySpecifiedGoalState) :- • FullySpecifiedGoalState|= PartiallySpecifiedGoalState • exists(<a0, a1, ..., an>) | • an(...(a1(a0(InitialState))...) = FullySpecifiedGoalState • satisfies(Constraints, FullySpecifiedGoalState)

27. 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.