simplicity hides complexity

Size: px

Start display at page:

Download "simplicity hides complexity"

Ethan Clarence Wilson
8 years ago
Views:

1 flow of control backtracking reasoning in logic and in Prolog 1 simplicity hides complexity simple and/or connections of goals conceal very complex control patterns Prolog programs are not easily represented by traditional flowcharts this is the way it should be: flowcharts immerse the programmer in unproductive complexity we want: access to useful complexity presented simply 2

not easily represented by traditional flowcharts this is the way it should be: flowcharts

2 and & or as in Lisp, the logic operations (,, ;) are not pure logic programmer has to take into account the order of computation 3 avoid generating unbounded values (p. 197) example of tricky 'and' ordering sublist(s, L) :- append(s, _, L1), append(_, L1, L). sublist(s, [a, b, c, d]) produces infinite sequence of S = []. Why? let + = instantiated, - = not completely instantiated sublist(-, +) :- append(-,-, -), append(-, -, +) * sublist([c, b], [a, b, c, d]). works fine in SWI Prolog. 4

197) example of tricky 'and' ordering sublist(s, L) :- append(s, _, L1), append(_, L1, L).

3 OR as a 'factoring' tool (Ch. 24) (p. 173) minmax5(cmin, Cmax, [], Cmin, Cmax). minmax5(min, Max, [X L], Cmin, Cmax) :- order(x, Cmin), minmax5(min, Max, L, X, Cmax). minmax5(min, Max, [X L], Cmin, Cmax) :- order(cmax, X), minmax5(min, Max, L, Cmin, X). minmax5(min, Max, [X L], Cmin, Cmax) :- minmax5(min, Max, L, Cmin, Cmax). minmax5(min, Max, [X L], Cmin, Cmax) :- order(x, Cmin), minmax5(min, Max, L, X, Cmax) ; order(cmax, X), minmax5(min, Max, L, Cmin, X) ; minmax5(min, Max, L, Cmin, Cmax). 5 guarding the "else" can't rely on implicit negation in predicates which can be "redone" predicates with alternatives should be logically valid; unless never called preceding a subgoal that can fail (never "backed-into") safest: negate explicitly 6

minmax5(min, Max, [X L], Cmin, Cmax) :- order(x, Cmin), minmax5(min, Max, L, X, Cmax) ; order(cmax, X), minmax5(min, Max, L, Cmin, X) ; minmax5(min, Max, L, Cmin, Cmax).

4 negation p. 204 example: set intersection intersect([], _, []). intersect([x L ], Y, [X I]) :- member(x, Y), intersect(l, Y, I). intersect([x L], Y, I) :- \+ member(x, Y), intersect(l, Y, I). use \+ for precision \+ = not provable \+ P = ~P only if P is instantiated. 7 negation by failure \+ works correctly if its argument is instantiated so intersect([x L], Y, I) :- \+ member(x, Y), intersect(l, Y, I). requires that X, Y be instantiated. 8

$intersect([x L], Y, I) :- \+ member(x, Y), intersect(l, Y, I).$

5 instantiate before negating p. 205: assume animal(cat). vegetable(turnip).?- not(animal(x)), vegetable(x). fails to find X=turnip. Why? Why does?-vegetable(x), not(animal(x)). work? 9 don't rely on a faulty premise why not just intersect([], _, []). intersect([x L ], Y, [X I]) :- member(x, Y), intersect(l, Y, I). intersect([_ L], Y, I) :- intersect(l, Y, I).?-intersect([a,b,c, d], [a, c], []) succeeds! why? because premise that X is not in Y fails. 2nd rule fails because 3rd arg = []. A guard on the "fall-through" rule avoids this. 10

intersect([x L ], Y, [X I]) :- member(x, Y), intersect(l, Y, I). intersect([_ L], Y, I) :- intersect(l, Y, I).

6 control predicates true (really "success") Goal :- condition1 ; condition2; true. fail (opposite of true) repeat (always succeeds, infinite number of choice points.) loopuntilnomore :- repeat, dostuff, checknomore. (tail-recursion is 'cleaner' - it has a clear denotation.) loop :- dostuff, (checknomore ; loop). 11 forcing all solutions test :- member(x, [1,2,3]), nl, print(x), fail. % no alternative solutions for print(x) or for nl % but member has alternative solutions?- test no 12

) loopuntilnomore :- repeat, dostuff, checknomore. (tail-recursion is 'cleaner' - it has a clear denotation.

7 backtracking example text, p. 209 multiple_elements(e, L) :- append(_, [E M], L), append(_, [E _], M). 13 trace?- trace, multiple_elements(e, [a, b, c, b]). Call: (8) multiple_elements(_g325, [a, b, c, b])? creep Call: (9) lists:append(_l255, [_G325 _G400], [a, b, c, b])? creep Exit: (9) lists:append([], [a, b, c, b], [a, b, c, b])? creep Call: (9) lists:append(_l273, [a _G403], [b, c, b])? creep Fail: (9) lists:append(_l273, [a _G403], [b, c, b])? creep Redo: (9) lists:append(_l255, [_G325 _G400], [a, b, c, b])? creep Exit: (9) lists:append([a], [b, c, b], [a, b, c, b])? creep Call: (9) lists:append(_l294, [b _G406], [c, b])? creep Exit: (9) lists:append([c], [b], [c, b])? creep Exit: (8) multiple_elements(b, [a, b, c, b])? creep E = b 14

creep Call: (9) lists:append(_l273, [a _G403], [b, c, b])? creep Fail: (9) lists:append(_l273, [a _G403], [b, c, b])? creep Redo: (9) lists:append(_l255, [_G325 _G400], [a, b, c, b])?

8 entering and leaving trace steps are labelled: Call: enter the procedure Exit: exit successfully with bindings for variables Fail: exit unsuccessfully Redo: look for an alternate solution 15 4 port model Call Fail goal Exit (success) Redo (backtrack) 16

Fail: exit unsuccessfully Redo: look for an alternate solution

9 conjoined goals Call Exit Fail goal 1 goal 2 Redo goal 1, goal 2 17 disjoined goals Call goal 1 Exit (if untried alternatives in goal 1 ) Fail goal 2 Redo (if no untried alternatives in goal 1 ) goal 1 ; goal 2 18

(if untried alternatives in goal 1 ) Fail goal 2 Redo

10 negation Call goal Exit Fail Redo \+ goal 19 reasoning in logic and in Prolog 20

11 facts & rules how different are facts and rules? rule: goal :- body. goal if body body implies goal (not body) or goal fact: goal. goal if true. (not true) or goal. 21 queries what does?- goals. mean in logic? verbose form of :- goals. looks like a rule with no head. P implies Q = (not P) or Q if no Q, we get not P :- goals. = not (goals) a query = an assertion that the goal is false! the interpreter attempts a refutation. 22

21 queries what does?- goals. mean in logic? verbose form of :- goals. looks like a rule with no head.

12 yes means no answering a query?- goals. means refuting the assertion that the goals can't be satisfied, by unifying the goals with "truths". The answer "Yes" means "no, the assertion :- goals. is false." 23 proving propositions we can use the refutation strategy to construct a simple "theorem prover" in Prolog for the propositional calculus. it can tell us whether a propositional formula such as (P implies ~P) or P is a logical truth (tautology) or not. tautology = Boolean function with constant value true 24

The answer "Yes" means "no, the assertion :- goals. is false.

13 implementation strategy try to show that a formula can be made false using facts and rules involving the logical operators false(proposition) succeeds if there is an assignment of truth-values to the logical variables in the Proposition which makes it false essentially the truth-table method 25 testing for tautology formulae :- read(t), (T==end_of_file, halt ; theorem(t), formulae). theorem(t) :- nl, nl, write(t), nl, (false(t), write('* Not valid.'), ; nl, write('* Counter-example: '), write(t) write('* Valid.') ), nl. 26

false essentially the truth-table method 25 testing for tautology formulae :- read(t), (T==end_of_file, halt ; theorem(t),

14 the refutation rules false('false'). false(not 'true') :-!. false( P iff Q) :- false( (P implies Q) and (Q implies P)). false( P implies Q) :- false( not P or Q). false( P or Q ) :- false(p), false(q). false( P and Q) :- false(p) ; false(q). false(p xor Q) :- false(not(p iff Q)). false( not not P) :- false(p). false( not(p iff Q)) :- false( not(p implies Q) or not(q implies P)). false( not(p implies Q)) :- false( not( not P or Q)). false( not(p or Q)) :- false( not P and not Q). false( not(p and Q)) :- false( not P or not Q). false( not(p xor Q)) :- false(p iff Q). 27

false(p xor Q) :- false(not(p iff Q)). false( not not P) :- false(p). false( not(p iff Q)) :- false( not(p implies Q) or not(q implies P)).

Debugging Prolog Programs. Contents The basic Prolog debugger Tracing program execution Spying on problem predicates

Debugging Prolog Programs. Contents The basic Prolog debugger Tracing program execution Spying on problem predicates Debugging Prolog Programs Prof. Geraint A. Wiggins Centre for Cognition, Computation and Culture Goldsmiths College, University of London Contents The basic Prolog debugger Tracing program execution Spying