Writing and debugging programs

Size: px

Start display at page:

Download "Writing and debugging programs"

Abel Nelson
5 years ago
Views:

1 Writing and debugging programs Programs should be designed top-down and built bottom-up. Style and presentation are aids to producing correct programs. Once written, programs should be tested analytically.

2 This lecture is about: designing programs top-down; building the code for a program bottom-up; using a good style to make programs more easily understood; testing programs systematically and analytically so you can be as certain as possible each part works as intended Writing and debugging programs 1

3 Designing programs - 1 Consider the following: Write a program that separates a list of letters into a list of vowels and a list of non-vowels. It might be run as follows:?- classify([a,b,c], Vowels,NonVowels). Vowels = [a], Non_Vowels = [b,c]? ; no 10 - Writing and debugging programs 2

4 First thoughts: Designing programs - 2 This is a list processing problem. It is a terminate at the end of list problem. We need to be able to distinguish between vowels and consonants Writing and debugging programs 3

5 In more detail: Designing programs - 3 There are three conditions and actions: the list of letters is empty terminate; the head of the list is a vowel add to the list of vowels and process the tail; the head of the list is not a vowel add to the list of consonants and process the tail Writing and debugging programs 4

6 Arguments: Designing programs - 4 We have to decide what arguments we need to pass in and out of the procedure: list of letters input ; list of vowels found output ; list of consonants found output Writing and debugging programs 5

7 Detailed design - 1 As this is a simple problem, we can quickly move to turning our thoughts into code: the list of letters is empty terminate In this problem, we can say that when there are no letters, then there are no vowels or consonants % 1 terminating classify([], [], []) Writing and debugging programs 6

8 Detailed design - 2 Having coded the terminating condition, we can move to the recursive clauses: the head of the list is a vowel add to the list of vowels and process the tail % 2 - recursive: letter is a vowel classify([vowel Tail],[Vowel Vowel_Tail], Non_Vls) :- vowel(vowel), classify(tail, Vowel_Tail, Non_Vls) Writing and debugging programs 7

9 Detailed design - 3 We can process vowels, so we need to be able to process consonants: the head of the list is not a vowel add to the list of consonants and process the tail % 3 - recursive: letter is not a vowel classify([non_vowel Tail], Vowels, [Non_Vowel Non_Vl_Tail]) :- classify(tail, Vowels, Non_Vl_Tail) Writing and debugging programs 8

10 Detailed design - 4 We are left with one piece of code to be written vowel/1. vowel(a). vowel(e). vowel(i). vowel(o). vowel(u) Writing and debugging programs 9

11 Building the program By the end of detailed design, the program will be just about complete. The next stage is to type the program into an editor and test that it works one procedure at a time. Within each procedure, test one clause at a time. The first procedure to be tested is the deepest in this case vowel/ Writing and debugging programs 10

12 Presentation of your programs Layout is a quick guide to the structure of your program. Until you are an expert Prolog programmer, follow the usual conventions. Always add one block comment per procedure. Add single line comments where needed Writing and debugging programs 11

13 Comments - 1 Prolog has two kinds of comments /* This starts a comment that can go on for many lines until it reaches */ % starts an in-line comment 10 - Writing and debugging programs 12

14 Comments - 2 It is conventional to include a block comment for each procedure that includes: /* *********************************** */ /* functor/arity */ /* details of each argument */ /* summary of what the procedure does */ /* author */ /* date */ /* *********************************** */ 10 - Writing and debugging programs 13

15 Testing a program - 1 Try to test individual clauses in a procedure then test the whole procedure. Test schedule: vowel(letter) classify([], Vowels, Non_Vowels) classify([b,c,d],vowels,non_vls) classify([a,e,i,o],vowels,non_vls) classify([a,c,e,g],vowels,non_vls) Demo Writing and debugging programs 14

16 Testing a program - 2 Clearly something is wrong. Consonants are processed OK but vowels aren t. Perhaps vowels are also being processed by the consonants rule? 10 - Writing and debugging programs 15

17 Testing a program - 3 We can test this easily by adding a write/1 subgoal to the rule: % 3 - recursive: letter is not a vowel classify([non_vl Tail], Vowels, [Non_Vl Non_Vl_Tail]) :- write(non_vl), nl, classify(tail, Vowels, Non_Vl_Tail). Demo Writing and debugging programs 16

18 When this is run, we get: Testing a program - 4?- classify([a,e,i,o,u], Vowels, Non_Vls). Vowels = [a,e,i,o], Non_Vls = []? ; o Vowels = [a,e,i], Non_Vls = [o]? 10 - Writing and debugging programs 17

19 Testing a program - 5 So, we need to stop both recursive clauses processing vowels: % 3 - recursive: letter is not a vowel classify([non_vowel Tail], Vowels, [Non_Vowel Non_Vl_Tail]) :- \+ vowel(non_vowel), classify(tail, Vowels, Non_Vl_Tail). Demo Writing and debugging programs 18

20 Three useful things Singleton variables Look at the error messages when consulting a program: member(head, [Heda _]). [Head,Heda] - singleton variables in user:member/2* Approximate lines: 22-26, 10 - Writing and debugging programs 19

21 Three useful things trace/notrace Prolog includes some debugging goals. To see what is happening in detail, use trace/notrace. % 2 - recursive: letter is a vowel classify([vowel Tail], [Vowel Tail], Non_Vls) :- trace, vowel(vowel), notrace, classify(tail, Vl_Tail, Non_Vls) Writing and debugging programs 20

22 Three useful things write/nl You can also add write/1 subgoals into rules to see what is going on, eg: % 2 - recursive: letter is a vowel classify([vowel Tail], [Vowel Vl_Tail], Non_Vls) :- vowel(vowel), write(classify(tail, Vl_Tail, Non_Vls)), nl, classify(tail, Vl_Tail, Non_Vls) Writing and debugging programs 21

23 Consolidation moment Design your program top-down divide the problem into smaller parts until you get down to code. Build your program bottom-up start with the lowest-level procedures and build into larger units. Test as you go test individual clauses as you write them, not when you ve typed the whole program Writing and debugging programs 22

24 Software Workshop Prolog Consider the following puzzle How could this puzzle be: represented solved in Prolog? 10 - Writing and debugging programs 23

25 General technique of search Prolog can be described as using a: generate and test search technique. This means: generate a possible solution to a problem test to see if the possible solution is acceptable Writing and debugging programs 24

26 Search Writing and debugging programs 25

27 Search Writing and debugging programs 26

28 How can this be programmed? We need to design: a representation of the board a solver consisting of: a possible solution generator a tester 10 - Writing and debugging programs 27

29 Representation - 1 We can code the board itself as a structured object: board(square(a1, A2, A3, A4, A5, A6, B1, B2, B3, B4, B5, B6, C1, C2, C3, C4, C5, C6, D1, D2, D3, D4, D5, D6, E1, E2, E3, E4, E5, E6, F1, F2, F3, F4, F5, F6), but we only use this for display 10 - Writing and debugging programs 28

30 Representation - 2 The square is also represented as a list with shared variables: square([a1, A2, A3, A4, A5, A6, B1, B2, B3, B4, B5, B6, C1, C2, C3, C4, C5, C6, D1, D2, D3, D4, D5, D6, E1, E2, E3, E4, E5, E6, F1, F2, F3, F4, F5, F6]), 10 - Writing and debugging programs 29

31 Representation - 3 Rows, columns and groups are represented as structured objects of six cells: sixes([six(a1, A2, A3, A4, B2, C2), six(a5, A6, B3, B4, B5, C3), six(b1, C1, D1, D2, D3, E2), six(b6, C4, C5, C6, D6, E6), six(d4, D5, E5, F4, F5, F6), six(e1, E3, E4, F1, F2, F3), etc. ])) :- Note the use of shared variables again Writing and debugging programs 30

32 Representation - 4 We need to be able to represent that individual squares are instantiated: A1 = 1, B3 = 1, B6 = 3, C3 = 2, D6 = 2, E1 = 3, E2 = 6, F3 = 4, F5 = Writing and debugging programs 31

33 Representation - 5 Bringing all of this together in a shortened example: board(square(a1, A2, A3, A4, A5, A6, F1, F2, F3, F4, F5, F6), square([a1, A2, A3, A4, A5, A6, F1, F2, F3, F4, F5, F6]), sixes([six(a1, A2, A3, A4, B2, C2), six(a5, A6, B3, B4, B5, C3), ])) :- A1 = 1, B3 = 1, F5 = Writing and debugging programs 32

34 Generating solutions - 1 In today s version, the program is very short: Step 1: Define the values that can fill a square: candidates([1,2,3,4,5,6]). Step 2: Go through the list of squares and put a candidate number in each square Writing and debugging programs 33

35 Generating solutions - 2 This is the code that puts all the candidates into the list of squares: % 1 - terminating generate([], _Candidates). % 2 - recursive generate([square Squares], Candidates) :- member(square, Candidates), generate(squares, Candidates) Writing and debugging programs 34

36 Testing solutions - 1 This involves testing each row, column and group to ensure that they have 6 unique numerical values. First the individual rows/columns/ groups are selected from the representation: % 1 - terminating test([]). % 2 - recursive test([six Sixes]) :- test_six(six), test(sixes) Writing and debugging programs 35

37 Testing solutions - 2 Then testing each combination of squares to ensure uniqueness: test_six(six(sq1, Sq2, Sq3, Sq4, Sq5, Sq6)) :- Sq1 =\= Sq2, Sq1 =\= Sq3, Sq1 =\= Sq4,, Sq4 =\= Sq6, Sq5 =\= Sq Writing and debugging programs 36

38 Running the program run :- % pick up the board and candidates board(display_square, square(square), sixes(sixes)), candidates(candidates), % generate a solution generate(square, Candidates), % test the solution test(sixes), % display successful solutions display_square(display_square) Writing and debugging programs 37

39 Running the program run :- % pick up the board and candidates board(display_square, square(square), sixes(sixes)), candidates(candidates), % generate a solution generate(square, Candidates), % test the solution test(sixes), % display successful solutions display_square(display_square) Writing and debugging programs 38

40 Running the program run :- % pick up the board and candidates board(display_square, square(square), sixes(sixes)), candidates(candidates), % generate a solution generate(square, Candidates), % test the solution test(sixes), % display successful solutions display_square(display_square) Writing and debugging programs 39

41 Running the program run :- % pick up the board and candidates board(display_square, square(square), sixes(sixes)), candidates(candidates), % generate a solution generate(square, Candidates), % test the solution test(sixes), % display successful solutions display_square(display_square) Writing and debugging programs 40

42 Running the program run :- % pick up the board and candidates board(display_square, square(square), sixes(sixes)), candidates(candidates), % generate a solution generate(square, Candidates), % test the solution test(sixes), % display successful solutions display_square(display_square) Writing and debugging programs 41

43 Running the program run :- % pick up the board and candidates board(display_square, square(square), sixes(sixes)), candidates(candidates), % generate a solution generate(square, Candidates), % test the solution test(sixes), % display successful solutions display_square(display_square) Writing and debugging programs 42

44 Analysing the program This program is correct, but it has to do a lot of work. Why? There are 6 ways of filling the first square, 6 ways of filling the second square,, 6 ways of filling the last square. = 10,314,424,798,490,535,546,171,949,056 possible solutions to be tested (if starting with an empty board) Writing and debugging programs 43

45 What can we do? Simple designs are good but they don t always work. There are two ways in which we can produce a quick program: 1. make the Prolog program more complex by writing heuristics into the code. 2. use one of the specialised extensions of Prolog using constraint processing Writing and debugging programs 44

46 Why should we be bothered with a game? Games are real world problems: on a small scale; with clearly defined rules and outcomes. Similar real-world problems are: automatic timetabling schools, universities, hospitals; resource allocation allocating ships to berths, planes to airport terminal doors; etc Writing and debugging programs 45

Beyond Prolog: Constraint Logic Programming

Beyond Prolog: Constraint Logic Programming This lecture will cover: generate and test as a problem solving approach in Prolog introduction to programming with CLP(FD) using constraints to solve a puzzle