Debuggers

No matter how careful you are when you write program code, your programs are likely to have errors, or bugs, that prevent them from running the way you intended. Debugging is the process of locating and fixing errors in your programs, and programs to help you do this are called "debuggers".

The amount of debugging help provided with a program language varies widely from language to language. Interpreted languages, such as BASIC and COMAL, are executed line-by-line from the source code. This means that errors will usually stop the program at, or near, the statement which caused the error, and allow you to examine the code straight away so as to find the error quickly. Because of this, they often don't need separate debugger modules. UniCOMAL, for example, doesn't have one.

A trace table is a table used to record changes to the values of variables during the progress of a program. Trace tables can be prepared by hand during desk-checking or dry-running. A trace table is prepared by listing all the variables used in the program in columns of the table. The rows of the table simulate the execution of a statement in the program. Actual results, indicated by the values of the variables in the trace table, are compared with pre-calculated expected results. The differences will reveal any flaws in the logic of the algorithm.

Syntax errors are simple mistakes in "putting together" program statements, like "PTINT 54.3" instead of "PRINT 54.3" for example. Modern program languages detect these errors before the program is compiled or interpreted, by putting the statements through a syntax checker at a very early stage, often while the code is being typed in. UniCOMAL's syntax checker is second to none in its ability to detect mistakes on entry.

Run-time errors occur when your program contains valid statements, but the statements cause errors when they are executed. For example, your program might try to open a nonexistent file, or it might try to divide a number by zero. The operating system detects run-time errors and stops program execution when they occur.

Logic errors occur when your program statements are valid, but the actions they perform are not the actions you intended. For example, logic errors occur when variables contain the wrong values, when graphic images are the wrong shape, or when the output of the program is wrong in some way.

Logic errors are often difficult to find because they can show up in unexpected places. You need to thoroughly test your program to ensure that it works as designed. A debugger can help you locate logic errors by displaying the values of variables etc. as your program executes.

Breakpoints pause program execution during a debugging session at places that you specify in the source code.

You can set breakpoints into your source code at positions before potential problem areas, then run your program. Your program will pause when it encounters a breakpoint, and display the line containing the breakpoint. You can then use the debugger to view the state of your program, or to step over or trace into your code one line at a time.

The required algorithms: frequency count, binary search, sorting and list operations

There is little precise detail about these four algorithms given in the statement of standards for outcome 1, except the evidence requirement "written or diagrammatic evidence that the student has designed and described the algorithms detailed in performance criterion (d) for all classes in the range." In the "guidance on content" section, p. 7, the arrangements further state that "list operations include inserting, deleting and appending items in lists", and, later on "the comparison of internal sorting algorithms would illustrate efficiency of memory usage and processing time".

That gives a total of seven algorithms to be covered, (frequency count, binary search, internal sort 1, internal sort 2, insert in list, delete from list and append to list) from which the student would require to provide evidence of designing and describing four. In outcome 3, the student is required to provide evidence of implementation of four of these.

Binary Search

There is a very neat example of the use of a binary search in the UniCOMAL reference manual, Appendix H ("Structures"), pp. 497 - 498. This example uses a UniCOMAL STRUC to store a warehouse stock record, then searches a small database of these records using a binary search. In outcome 2 of the unit (see p. 8), the student is required to give comprehensive definitions of various data structures, including records, so this example is doubly appropriate.

Frequency Counting, Sequential Files and Efficiency

The arrangements document does not go into any detail about the required "Frequency Count" algorithm. "Frequency count" could mean:

in increasing complexity of algorithm. Here is an algorithm for the simplest case:

  intialise frequency_counter to 0
  OPEN a data file for reading
  WHILE there are data items left
    get a data item from the file
    IF data item matches target THEN 
      increment frequency_counter
    ENDIF
  END WHILE
  CLOSE the data file

Here is a UniCOMAL function, based on this algorithm, to work out the number of occurrences of a given letter in a text file:

  FUNC letter_frequency(target$, filename$)
    OPEN FILE 1, filename$, READ
    frequency_counter#=0
    WHILE NOT EOF(1) DO
      data_item$ := GET$(1,1)  // Get a single ASCII character from the file
      IF data_item$ = target$ THEN frequency_counter# :+ 1
    ENDWHILE
    CLOSE FILE 1
    RETURN frequency_counter#
  ENDFUNC letter_frequency

This function could be called from a simple main program like this:

  100 // Counting letter frequency 1
  110 // MacharSoft, 1998: for Higher Still Programming
  120 filename$ := "frequent.txt"
  130 target$ := "a"
  140 PRINT "There are ", letter_frequency(target$, filename$),
  150 PRINT " occurrences of letter ",target$," in the file ",filename$
  160 END

and gives a single line of output like this:

  There are 27 occurrences of letter 'a' in the file frequent.txt

assuming that the file 'frequent.txt' were present in the same directory as the program.

So far, so good. But what if we want a table showing the frequences of all the letters of the alphabet in that text file? We could simply loop round the letters 'a' to 'z', using the 'letter_frequency' function, like this:

  100 // Counting letter frequency 2
  110 // MacharSoft, 1998: for Higher Still Programming Unit
  120 filename$ := "frequent.txt"
  125 FOR letter# := ORD("a") TO ORD("z") DO
  130   target$ := CHR$(letter#)
  140   PRINT "There are ", letter_frequency(target$, filename$),
  150   PRINT " occurrences of letter ",target$," in the file ",filename$
  155 ENDFOR letter#
  160 END

This program will work, and produce output like this:

  There are 27 occurrences of letter 'a' in the file frequent.txt
  There are 5 occurrences of letter 'b' in the file frequent.txt
  There are 6 occurrences of letter 'c' in the file frequent.txt
  :
  :
  There are 0 occurrences of letter 'z' in the file frequent.txt

and the output could be altered to generate a table of values rather than 26 separate lines as shown.

Doing it that way is very processor-inefficient, however. For each letter of the alphabet, the program has to process the entire text file, one character at a time, in order to count the letter's frequency. We can write a different algorithm, using an array to hold the letter frequencies, which will allow us to generate the same result in only one pass through the file:

  set up an array to hold the required number of frequency counters
  intialise all the frequency counters to 0
  OPEN the data file for reading
  WHILE there are data items left
    get a data item from the file
    IF data item matches any of the possible targets THEN 
      increment that target's frequency counter
    ENDIF
  END WHILE
  CLOSE data file

In UniCOMAL, for the letter-frequency exercise, that would look like this:

  100 // Counting letter frequency 3
  110 // MacharSoft, for Higher Still Programming Unit 
  120 DIM letter_frequency#(97:122) // Corresponding to 'a' to 'z' in ASCII
  130 // UniCOMAL automatically initialises integer arrays to 0
  135 filename$ := "frequent.txt"
  140 OPEN FILE 1, filename$, READ
  150 WHILE NOT EOF(1) DO
  160   character# := ORD(GET$(1,1)) // Get the ASCII code of a character from file 1
  170   IF character# > 96 AND character# < 123 THEN
  180      letter_frequency#(character#) :+ 1
  190   ENDIF
  200 ENDWHILE
  210 CLOSE FILE 1
  220 display_results
  230 END
  240 //
  250 PROC display_results
  260  FOR character# := 97 TO 122 DO
  270    PRINT "There are ", letter_frequency#(character#),
  280    PRINT " occurrences of letter ", CHR$(character#),
  290    PRINT " in the file ", filename$
  300  ENDFOR character#
  310 ENDPROC display_results

This program gives exactly the same results as 'letter frequency 2', but just over 27 times more quickly. It is much more processor-efficient than 'letter frequency 2', but rather less memory-efficient, since it needs memory space for the array of frequencies, whereas 'letter frequency 2' did not.

Queues and buffers

Outcome 3: Implement features and use facilities of a Software Development Environment (10 hours)

The same features are identified as for Outcome 2, data structures and file handling. The Support Notes, P.10, state:

"This outcome allows students to put into practice what they have learned about the features of a software development environment and about algorithms in Outcome 2. Therefore, this outcome is likely to be delivered in parallel with Outcome 2 with practical activity being used to consolidate understanding."

HSOPU - Alphabetic Index