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 relationship
3. Define the relationship in English
4. Translate it into FOL
5. Devise representation of “things” where
relationship becomes “definable”
6. Translate that into a correct Prolog program
7. Arrange clauses/preds so program terminates
8. Arrange clauses/preds so program efficient
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.
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
Step 1: See problem as relationship
• View the problem as a relationship between
“things”, what relationship?
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
Step 1: See problem as relationship
• View the problem as a relationship between
“things”, what things?
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
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
Step 2: Find examples
• Find simple examples of that relationship
Step 3: Define relationship in English
• fullySpecifiedGoalState(InitialState,
PartiallySpecifiedGoalState,
FullySpecifiedGoalState) :• FullySpecifiedGoalState satisfies
PartiallySpecifiedGoalState
• FullySpecifiedGoalState reachable from
InitialState
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
Step 4: Translate it into FOL
• fullySpecifiedGoalState(InitialState,
PartiallySpecifiedGoalState,
FullySpecifiedGoalState) :– FullySpecifiedGoalState |= PartiallySpecifiedGoalState
– exists(<a0, a1, ..., an>) |
• an(...(a1(a0(InitialState))...) = FullySpecifiedGoalState
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??
Next best
• If the exact answer is too expensive then use
approximations.
• What does that mean in this situation?
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?
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
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.
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?
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
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?
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????
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.
Hunting for invariants
• What is in our initial state that is preserved by
the actions?
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
Modifying our defintion
• fullySpecifiedGoalState(InitialState,
PartiallySpecifiedGoalState,
FullySpecifiedGoalState) :– FullySpecifiedGoalState |= PartiallySpecifiedGoalState
– exists(<a0, a1, ..., an>) |
• an(...(a1(a0(InitialState))...) = FullySpecifiedGoalState
– satisfies(Constraints, FullySpecifiedGoalState)
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.