Debugging Techniques for CS100M Lab: Testing, Debugging Code, Sound File Segmentation, Lab Reports of Computer Science

Instructions for debugging code in cs100m lab exercises. It covers testing individual functions and the final program, debugging techniques such as displaying intermediate values and checking variable types, and debugging functions using print statements. Additionally, it includes an exercise on segmenting a sound file using the function segmentbyclicks.m and reducing its 'spikiness' with the function reducespikes.

Typology: Lab Reports

Pre 2010

Uploaded on 08/30/2009

koofers-user-qh2
koofers-user-qh2 🇺🇸

1

(1)

10 documents

1 / 2

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CS100M Lab Exercise 12
1 “Debugging” code
As you begin to write longer and more complicated programs, you need to get organized about testing and
“debugging” your code. To debug a program is to rid the program of bugs, i.e., errors. You need to come up
with a set of tests to make sure that all the individual functions and the final program are correct.
Testing. The general principle is to exercise every line of code. For example, your code has this structure:
function out = foo(a, b, c, d)
if a<0 % && blah blah blah, some other conditions
% some code here
elseif b>a % && other conditions
% some code here
elseif c>0 % && other conditions
for k= c:2:d
% k-loop. Some code here
end
r = rand(1,d);
end
Then you want to make test cases that cover all branches of the if-statement to make sure that every branch of
the program works. Furthermore, you should have test cases where d<c to make sure that skipping the k-loop
doesn’t cause any problem. Test the general case and the boundary cases.Ifrand or some other randomization
is involved, be sure to run tests multiple times. Sometimes it is possible to set the random variable to some fixed
values for the purpose of testing the other parts of the program. (Remember to remove the fixed values used for
testing afterwards.) Choosing test cases is very important! Take the time necessary to test thoroughly.
Debugging. If you identify problems during testing, then you have to debug. Read any Matlab-produced
error messages carefully. If your program runs without Matlab-generated error messages but the result isn’t
correct, then your test case has identified errors—good job! Do (some of ) the following to debug your code:
1. Display intermediate values. This is really easy to doin Matlab: just remove a few semi-colons! Sometimes
you may need to actually add a print statement.
2. Check variable types and dimensions. Look at the Workspace pane; is the variable of the type and dimen-
sions you expect?
3. What if there is a non-specific error message and you’re not sure where the problem is?
Add print statements to indicate which parts of the program has been “successfully” executed. An incomplete
program is shown below; look at the print statements:
docTitles = {}; termList = {}; tdm = [];
fid = fopen(dataFile, ’r’);
docTitles = split(fgetl(fid));
disp(’... MADE IT THROUGH DocTitles ...’)
r= 0; maxLen=0;
while ~feof(fid)
items = split(fgetl(fid)); r= r+1;
termCellArray{r} = items{1}; termLength(r)= length(items{1});
if termLength(r)>maxLen
maxLen= termLength(r);
end
disp(’... MADE IT THROUGH THE TERM ...’)
for c=2:length(items)
tdm(r,c-1)= str2double(items{c});
end
end
This is very similar to printing intermediate values in (1) above, but is more specific to finding the location
of where the program terminates abnormally.
1
pf2

Partial preview of the text

Download Debugging Techniques for CS100M Lab: Testing, Debugging Code, Sound File Segmentation and more Lab Reports Computer Science in PDF only on Docsity!

CS100M Lab Exercise 12

1 “Debugging” code

As you begin to write longer and more complicated programs, you need to get organized about testing and “debugging” your code. To debug a program is to rid the program of bugs, i.e., errors. You need to come up with a set of tests to make sure that all the individual functions and the final program are correct.

Testing. The general principle is to exercise every line of code. For example, your code has this structure:

function out = foo(a, b, c, d)

if a<0 % && blah blah blah, some other conditions % some code here elseif b>a % && other conditions % some code here elseif c>0 % && other conditions for k= c:2:d % k-loop. Some code here end r = rand(1,d); end

Then you want to make test cases that cover all branches of the if-statement to make sure that every branch of the program works. Furthermore, you should have test cases where d < c to make sure that skipping the k-loop doesn’t cause any problem. Test the general case and the boundary cases. If rand or some other randomization is involved, be sure to run tests multiple times. Sometimes it is possible to set the random variable to some fixed values for the purpose of testing the other parts of the program. (Remember to remove the fixed values used for testing afterwards.) Choosing test cases is very important! Take the time necessary to test thoroughly.

Debugging. If you identify problems during testing, then you have to debug. Read any Matlab-produced error messages carefully. If your program runs without Matlab-generated error messages but the result isn’t correct, then your test case has identified errors—good job! Do (some of) the following to debug your code:

  1. Display intermediate values. This is really easy to do in Matlab: just remove a few semi-colons! Sometimes you may need to actually add a print statement.
  2. Check variable types and dimensions. Look at the Workspace pane; is the variable of the type and dimen- sions you expect?
  3. What if there is a non-specific error message and you’re not sure where the problem is? Add print statements to indicate which parts of the program has been “successfully” executed. An incomplete program is shown below; look at the print statements: docTitles = {}; termList = {}; tdm = []; fid = fopen(dataFile, ’r’); docTitles = split(fgetl(fid)); disp(’... MADE IT THROUGH DocTitles ...’) r= 0; maxLen=0; while ~feof(fid) items = split(fgetl(fid)); r= r+1; termCellArray{r} = items{1}; termLength(r)= length(items{1}); if termLength(r)>maxLen maxLen= termLength(r); end disp(’... MADE IT THROUGH THE TERM ...’) for c=2:length(items) tdm(r,c-1)= str2double(items{c}); end end

This is very similar to printing intermediate values in (1) above, but is more specific to finding the location of where the program terminates abnormally.

Debug some functions

Download function readData from the Exercises page. This function is incorrectly implemented and need to be corrected. The point here is not to change the function/algorithm to what you did for Project 5 but to correct the given code. Use the strategies—design test cases and debug—as discussed on the previous page.

Our main debugging tool is the print statement, strategically placed. If you want to learn about the simple debugging tool in Matlab, ask your section instructors. The files my strmatch and my lower posted on Exercises page also contain error. Debug these outside section.

2 Segmenting a sound file

If you have headphones, you can listen to the sound files in the lab. However, you can just write the code now and listen to the results later.

Download the file segmentByClicks.m from the Exercises page. Several sound files are available from the Lecture 22 (11/13) posting. Read and run the function to make sure that you understand it. The function segments the sound file into n − 1 parts (stored in a cell array) based on n user-selected “breakpoints.” Notice that when you use function ginput without an argument, during execution the program accepts user mouse clicks until the Enter key is pressed.

You will modify function segmentByClicks to remove the noise during the lulls from the sound data (or store only sound data above a certain threshold) in the cell array. Also indicate on the plot the user-selected breakpoints and the beginning and end of each sound segment with a red line and a green line, respectively. (See the plot in color on-line.)

0 0.5 1 1.5 2 2.5 3 3.5 4 x 10^4

−0.

−0.

−0.

−0.

0

1

Enter n breakpoints left to right

To do this, first reduce the “spikiness” of the data by writing and using the following function:

function d = reduceSpikes(data) % Replace each value in data (a vector of length n) with the average of % the values in the 5-point neighborhood and store the result in d.

Choose an appropriate way to deal with the data points at the beginning and end of the array.

In function segmentByClicks.m, call function reduceSpikes to reduce the “spikiness” of the data. Modify the code so that given a breakpoint b, the function sets the end of the sound segment to the left of b and the beginning of the segment to the right of b to be the nearest values that are greater than some pre-determined threshold. A reasonable sound threshold is 0.1 and you can experiment with different values. We will assume that a user will select the breakpoints in a reasonable way. Add markers to the plot to indicate the user-selected breakpoints. Add lines to the plot to mark the beginning of a sound segment with a red line and the end of a sound segment with a green line. The above plot is based on austin.wav (with the spikes reduced).

Please delete your files from the computer before you leave the lab.