

Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
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
1 / 2
This page cannot be seen from the preview
Don't miss anything!


CS100M Lab Exercise 12
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:
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.
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.