From Arvind.Ranganathan@comlab.oxford.ac.ukWed Jan 17 18:48:53 1996 Date: Wed, 17 Jan 96 16:49:14 0000 From: Arvind Ranganathan To: Arvind.Ranganathan@comlab.oxford.ac.uk Subject: Logic Programming and ILP - Laboratory 1 > > > Logic Programming and ILP - Laboratory 1 > > For help on starting Progol click here > ------------------------------------------------------------------------------- > > Logic Programming: Exercises Week 1 > > Exercise 1. Progol. > > Much of your time in the laboratory will be spent within the > programming environment of the Progol system. In the first 8 > weeks of this course, you will use Progol to execute defini- > tions that you will write as definite-clause statements. In > the weeks after that, you will use Progol to do much more. > For example, you will see how to automatically construct the > definite-clause definitions of functions from partial > specifications of their input-output behaviour. It is impor- > tant that you become familiar with the eccentricities of > Progol early in the course. First make sure you can arouse > Progol. The beast lives in: > > /usr/local/bin/progol > > If you are successful, you should see a prompt that looks > something like: > > CProgol Version 4.2 > > |- > > Ask your demonstrator to help you if find that Progol is be- > ing uncooperative. > > From now on, I will refer to: > > |- > > as the Progol prompt. At this prompt, Progol will accept > commands, almost all of which end with a "?" mark. Try: > > help? > > which should give you something like: > > January 15, 1996 > > - 2 - > > The following system predicates are available: > ! , /2 -> /2 ; /2 > < /2 = /2 =.. /2 =< /2 > == /2 > /2 >= /2 @< /2 > @=< /2 @> /2 @>= /2 + /1 > = /2 == /2 advise/1 any/1 > arg/3 asserta/1 bagof/3 clause/2 > clause/3 commutative/1 commutatives constant/1 > consult/1 determination/2 element/2 float/1 > functor/3 generalise/1 help help/1 > int/1 is/2 length/2 listing > listing/1 modeb/2 modeh/2 modes > name/2 nat/1 nl noreductive > nosplit nospy not/1 notrace > number/1 op/3 ops otherwise > parity read/1 reconsult/1 record/2 > reduce/1 reductive repeat retract/1 > retract/2 see/1 seen set/2 > setof/3 settings sort/2 spies > split spy/1 stats tab/1 > tell/1 test/1 told trace > true var/1 write/1 > Help for system predicates using help(Predicate/Arity) > yes > [:- help? - Time taken 0.02s] > > Most of these commands will make little or no sense at this > stage. For now, you should not worry about them either. > Concentrate instead on typing in, and executing a set of > definite-clause definitions in Progol. > > Definitions can be entered directly at the prompt, or can be > "consulted" from a file. Leave Progol now by depressing the > Control and D keys together (^D). > > Exercise 2. Using Progol > > January 15, 1996 > > - 3 - > > A 1-bit adder circuit looks like this: > > Vo > | > | > | > ____|______ > | | > | | > Carry ___| |_____Carry in > out | | > |__________| > | | | | > | o | o > | /_\ | /_\ > |__| |__| > | | > | | > A B > > The truth-table specification for this adder is > A B Cin Vo Co > 0 0 0 0 0 > 0 0 1 1 0 > 0 1 0 1 0 > 0 1 1 0 1 > 1 0 0 1 0 > 1 0 1 0 1 > 1 1 0 0 1 > 1 1 1 1 1 > > Representing a 1-bit adder as proposition definite clauses > Propositions used to denote input are: > > 1) a, b, c_in: true if A or B or Cin are true, respectively; and > 2) not_a, not_b, not_c_in: true if A or B or Cin are false, respectively. > > Propositions used to denote output are: > > 1) v_o, c_o: true if Vo or Co are true, respectively; and > 2) not_v_o, not_c_o: true if Vo or Co are false, respectively; and > > The following definite-clauses encode the truth table for > the adder. Type these into a file, say adder.pl, using your > favourite editor: emacs, vi or ed (yes, some of us remember > ed). > > January 15, 1996 > > - 4 - > > v_o:- > not_a, not_b, c_in. > v_o:- > not_a, b, not_c_in. > v_o:- > a, not_b, not_c_in. > v_o:- > a, b, c_in. > > not_v_o:- > not_a, not_b, not_c_in. > not_v_o:- > not_a, b, c_in. > not_v_o:- > a, not_b, c_in. > not_v_o:- > a, b, not_c_in. > > c_o:- > not_a, b, c_in. > c_o:- > a, not_b, c_in. > c_o:- > a, b, not_c_in. > c_o:- > a, b, c_in. > > not_c_o:- > not_a, not_b, not_c_in. > not_c_o:- > not_a, not_b, c_in. > not_c_o:- > not_a, b, not_c_in. > not_c_o:- > a, not_b, not_c_in. > > For reasons that you will understand shortly, write defini- > tions for the current state of the inputs A, B, and Cin in a > separate file, say inputs.pl. > > For now, let us say that the switch A is "on" and B, Cin are > "off". The file inputs.pl should then have: > a. > not_b. > not_c_in. > > Now start Progol. At the prompt, consult your definitions > in with the command: > > consult(adder), consult(inputs)? > > Note that the ".pl" extension does not appear as part of the > > January 15, 1996 > > - 5 - > > file names in the command. Here then is the first rule about > files that can consult: > > File names must end in ".pl" > Do not use the ".pl" extension when consulting the file > > If you have not made any errors in typing (emacs users are, > of course, more prone to this than other mortals), then Pro- > gol will respond with something like: > > [:- consult(adder), consult(inputs)? - Time taken 0.02s] > > To check if Progol has the correct definitions, first try > the command: > > listing? > > Progol's response should be something like: > > The following user predicates are defined: > a c_o not_b not_c_in not_c_o not_v_o v_o > [Total number of clauses = 19] > yes > [:- listing? - Time taken 0.00s] > > You can check individual clause definitions by the "listing" > command. For example: > > listing(not_c_o)? > > will list the definitions for the proposition not_c_o. > > You are now in a position to investigate the consequences of > the switch settings. This is done by examining whether which > of the "output" propositions v_o, not_v_o, c_o, not_c_o are > logical consequences of the set of definite-clauses in > adder.pl and inputs.pl. > > Progol can be asked if v_o is a logical consequence by typ- > ing the following at the prompt: > > v_o? > > to which should reply > > yes > > Verify (using the truth-table) that Progol > > gives correct answers for the logical status of each of the > four output propositions. > > January 15, 1996 > > - 6 - > > Can you simplify any of the definitions further. That is, do > you think the adder circuit could be represented with either > fewer, or simpler clauses? > > Exercise 3. Using Progol (contd) > > Now exit from Progol, using control-D, and change the > status of the inputs in the file inputs.pl. > > You will have to consult both adder.pl and inputs.pl > as before. > > Verify that the new input definitions have been consulted. > > Change the status of the inputs to match each line of the > truth table, and verify the consequences of each combina- > tion. > > Exercise 4. The Logical Piano > > The Logical Piano appears to have been the first machine > built to evaluate propositional logic programs. It was built > in 1860 by William Stanley Jevons, and the original machine > still exists in the Museum of the History of Science on > Broad Street. If you are using a Web browser, you should be > able to see a picture of this > > piano. > > For those without a browser, imagine something that could ha- > ve been used as a check-out machine in a 19th Century super- > market. As with its more modern descendants, the machine has: > a) a "keyboard"; and b) an output "screen". The keys are > marked from left to right as follows: > > Finis,|,d,D,c,C,b,B,a,A,Copula,A,a,B,b,C,c,D,d,|,Stop > > Here "Finis" is like a reset button. The "|" stands for > "or", the letters are used to represent individual bits of a > statement; with the lower case letters being used as nega- > tions of their corresponding upper case ones. "Copula" > stands for then implication connective, and "Stop" separates > individual statements. Conjunction or "and" is achieved by > juxtaposition of letters. For example, Groucho Marx's im- > mortal statement: > > Either he is dead or my watch has stopped > > would be entered as: > > A | aB Stop > > January 15, 1996 > > - 7 - > > where: > > A = dead > B = watch stopped > > To enter a rule of the form: > > if P then Q > > involves the following: > > 1. Press keys to the left of the Copula to represent P; > 2. Press the Copula key; > 3. Press keys to the right of the Copula to represent Q; and > 4. Press the Stop key. > > The output from the piano consists of a display on which > there are 16 columns, initially representing all logical > combinations of the 4 variables on the keyboard thus: > > AAAAAAAAaaaaaaaa > BBBBbbbbBBBBbbbb > CCccCCccCCccCCcc > DdDdDdDdDdDdDdDd > > (This display is called abecedarium.) > > You will learn later that each column is called an "in- > terpretation". Whenever a statement, or formula, is entered > and the "Stop" key pressed, all interpretations (i.e. > columns) that are inconsistent with the formula entered are > removed from the display. Thus, what is left are only those > interpretations that make the formula true. You will learn > later that these interpretations are called "models". Thus > the abecedarium shows the models of the statements entered. > > In this exercise, you will be using a simulation (for obvi- > ous reasons) of the Jevons' piano. Start by consulting the > file: > > /ecslab/ilp/Exercises/Exer01/piano.pl > > The simulation starts by typing: > > play? > > You should see a depiction of the abecedarium and the key- > board. Statements are entered almost as described earlier, > with the following syntactic differences: 1) a formula must > be enclosed in single quotes; and 2) every single-quoted > formula must be followed by typing a period (i.e. "."). So > to enter the rule: > > January 15, 1996 > > - 8 - > > All metals are conductors > > you would type: > > 'A Copula B Stop'. > > Typing: > > 'Finis'. > > will reset the piano. > > A sentence for which every interpretation is a model is said > to be "valid". Use the piano to determine if the following > is valid: > > if X is either married or a single man then X is a man > > A sentence is said to be "satisfiable" if it has at least > one model. One way to determine if a statement "s" follows > from others ("S") is to see if S and the negation of s is > unsatisfiable. Use the piano to check the following ancient > truth: > > All greeks are men > All men are mortal > _____________________ > All greeks are mortal > > The following example is described by Jevons as an illustra- > tion of using the piano to perform logical calculations that > took Boole many pages of manual labour. > > Analysis of a particular class of substances has ledd to the > following general properties: > > Whenever properties A and B are combined, either property C > or property D is present, but they are not jointly present. > > Whenever properties B and C are combined, properties A and D > are either both present with them, or both absent. > > Whenever properties A and B are both absent, properties C > and D are both absent also; and vice versa, where properties > C and D are absent properties A and B are absent also. > > Use the piano to show the following: > > Whenever property A is present, either C is present and B > absent, or C is absent. > > Whenever property C is present and property B is absent, > then property A is present. > > January 15, 1996 > > - 9 - > > Exercise 5. Negation > > Let us return to the 1-bit adder. Recall that separate pro- > positions were needed for both an output and its negation > (for example, v_o and not_v_o). Why did we have to be so > clumsy? If v_o is a logical consequence of the clauses, then > should we not be able to state confidently that not_v_o can- > not possibly be a consequnce as well? If so, we could > dispense with the definitions for "not_c_o" and "not_v_o". > The answer is yes, provided one assumption holds. This is > that the definitions we use are not just correct, but com- > plete. In other words, we have not left out any condition(s) > which are true. This assumption is called the closed world > assumption or CWA. > > Are the definite-clause definitions for v_o and c_o in your > file adder.pl complete? > > Once you have complete and correct definitions for v_o and > c_o, you can dispense with the definitions for not_v_o and > not_c_o. Instead, you can use a predicate called not. > > The complete set of definitions for the adder is now as fol- > lows: > > v_o:- > not(a), not(b), c_in. > v_o:- > not(a), b, not(c_in). > v_o:- > a, not(b), not(c_in). > v_o:- > a, b, c_in. > > c_o:- > not(a), b, c_in. > c_o:- > a, not(b), c_in. > c_o:- > a, b, not(c_in). > c_o:- > a, b, c_in. > > The new symbol not is a special metalogical predicate > built-in to Progol, that implements negation under the > closed world assumption. > > Try to understand the clauses in this new definition. > > Now the file inputs.pl. Any of the propositions a, b, or > c_in that are known to be true have to be in this file. If > any proposition, say c_in is not in the file, then, by CWA, > > January 15, 1996 > > - 10 - > > not_c_in is true. > > Consult your new (smaller) set of definitions. You can now > examine if not_v_o or not_c_o are logical consequences of > the definitions of your definitions by asking: > > not(v_o)? > > or > > not(c_o)? > > Exercise 5. Using not > > Work through the truth table again, verifying the conse- > quences of your adder definitions and truth value assign- > ments to a, b, and c_in. > > Finally a warning: The built-in not predicate has some curi- > ous behavioural traits if used incorrectly. > > Exercise 6. > > The problem is to control the traffic signal at an intersec- > tion of 2 roads. An E-W road meets a major N-S road. The > traffic signal has lights in all directions, and a timer and > car-detector for cars in the E-W lane. > > | N | > | | > | | > | | > | | > ________| |________ > W + E > ________ ________ > | | > | | > | | > | | > | S | > > Lights cycle as follows: Red->Green->Yellow->Red A yellow > light lasts for 5 seconds A green light lasts for 30 seconds > Colour and direction of traffic lights are to be represented > by propositions like: > > January 15, 1996 > > - 11 - > > 1) green_ns; > 2) green_ew; > 3) yellow_ns; etc... > > Time is represented by 3 propositions: > 1) timer_lt_5: less than 5 seconds have elapsed since last reset > 2) timer_5_30: 5 seconds <= time since last reset <= 30 seconds > 3) timer_gt_30: more than 30 seconds have elapsed since last reset > > Actions are: > 1) Turn lights on or off; and > 2) Reset timer > > Action of turning a light on or off is represented by propo- > sitions like: > 1) green_ns_on; or > 2) green_ns_off. > > The timer is reset before measuring the time for any event: > this is represented by a proposition reset_timer. > > Input conditions are current state of lights and timer The > exercise is to write definite clauses to state which ac- > tions are implied by input conditions > > Part A: > no detectors on E-W road > > To get you started, here are some initial clauses. > > If E-W light has been green for > 30 seconds, turn it off > and turn on yellow light > > green_ew_off:- > green_ew, > timer_gt_30. > yellow_ew_on:- > green_ew, > timer_gt_30. > reset_timer:- > green_ew, > timer_gt_30. > > The clauses look better structured if we have the following > intermediate proposition > > January 15, 1996 > > - 12 - > > warn_ew:- > green_ew, > timer_gt_30. > > green_ew_off:- > warn_ew. > > yellow_ew_on:- > warn_ew. > > reset_timer:- > warn_ew. > > Now write clauses to state yellow turns to red if it has > been on for at seconds. Again, you may find it good to have > another intermediate proposition > > stop_ew:- > ... > > Now complete the following: > > yellow_ew_off:- > ... > > red_ew_on:- > ... > > red_ns_off:- > ... > > green_ns_on:- > ... > > reset_timer:- > ... > > Write similar rules for N-S lights as above > > January 15, 1996 > > - 13 - > > warn_ns:- > ... > > green_ns_off:- > ... > > yellow_ns_on:- > ... > > reset_timer:- > ... > > stop_ns:- > ... > > yellow_ns_off:- > ... > > red_ns_on:- > ... > > red_ew_off:- > ... > > green_ew_on:- > ... > > reset_timer:- > ... > > January 15, 1996 > > ------------------------------------------------------------------------------- > Please report any dificulties to Steve Moyle - email: sam@comlab.ox.ac.uk > ------------------------------------------------------------------------------- > Logic Programming and Inductive Logic Programming > > ------------------------------------------------------------------------------- > www@comlab.ox.ac.uk file:/ecslab/ilp/HTTP/lab01.html