3/08 lecture sketch Announcements + P3 scores sent out tonight + rough draft of P4 solutions later today + E10 posted by weekend; due tuesday + complete P5 write-up early next week, but P5.1 = rewrite our P4.2 write-up Reminder + T2 review session: kimball b11, 3pm, this sunday Topics + debugging (coping with programming problems) [re-read ML/C 3.6] + analyzing performance _______________________________________________________________________________ debugging techniques press -c to stop execution of code ! clearly document your code, e.g. precisely define each major variable: ! + help *you* keep track of its purpose when writing code ! + help *you* keep track of its purpose when reading code ! (possibly as part of the process of writing and modifying code) ! + help *us* understand your code: clarity counts! ! + we may deduct points for code we find hard to understand ! + more partial credit if we better understand your code/ideas look at the line that matlab claims contains the error comment out (or cut out and save) portions of code to locate error + if error goes away when you remove code + then error is probably in removed code (at least connected to it) + approach: + start by removing big pieces to locate general region + then cut out smaller pieces to narrow down region containing error simple tracing + idea: compare results of trace (hand or computer) with what you want: + if there is a discrepancy, you've found a problem + trace by hand, e.g. using tabular format or box scope diagrams + trace the *actual* code, not what you *want* the code to be! + trace by computer + make matlab display values: omit semicolons at ends of lines of code + $echo on$: make matlab show ("echo") each line of code before running it + works for command window and scripts + does not work for functions, so: + temporarily convert function to script (comment out line with $function$) + assign values to parameters + run script ! + $pause$ -- tell matlab to wait for key press (e.g. used by $boxfib$) + helpful to slow down the computer! set a breakpoint + a *breakpoint* is a point (line of code) in the program where you've told the computer to "wait", to take a break from execution + at a breakpoint, you can type commands into the Command Window to look at and modify variables (and even invoke scripts and functions) + use $continue$ matlab statement or the Continue command in the Debug menu to tell matlab to resume execution + if you modified variables, the modified values are used + 2 ways to insert/make a breakpoint + $keyboard$ matlab statement + click on a line of code in the matlab Editor and choose Set Breakpoint command in Debug menu + annoyance, especially when processing input: can be tricky to tell difference between reaching a breakpoint (e.g. $keyboard$) and reaching an $input$ statement example: debug code below function x = readmode tracker = zeros(1,3); numval = 0; % any number value numval1 = 0; % number entered before $numval$ while numval ~= -1 numval = input('Enter an input value: '); if numval == numval1 tracker(2) = tracker(2)+1; tracker(1) ~ numval; else tracker(3) = tracker(3)+1; if tracker(3) > tracker(2) tracker(1) = numval; tracker(2) = tracker(3); tracker(3) = 0; end numval1 = numval; end x = tracker(1) _______________________________________________________________________________ analyzing performance: see [3/06] monster lecture sketch for details! let n = size of input data. key ideas: 1. "small" $n$ usually not a problem 2. primary concern is *rate of growth* as $n$ grows large 3. ignore "details" (lesser concerns): a. low order terms b. constant factors _______________________________________________________________________________ example: + suppose a program takes f(n) = n^3/6 + 100n^2 steps for an input of size $n$ + suppose computer can execute 10^9 steps per second #steps f(n) + #seconds = ---------- = ---- #steps/sec 10^9 _______________________________________________________________________________ 1. clearly, #seconds is not a problem for small $n$. (see [3/06] lecture sketch for numbers) _______________________________________________________________________________ f(10n) 2. rate of growth: ------ = about 10^3 = 1000 f(n) so program gets much much slower as $n$ gets large. (see [3/06] lecture sketch for numbers) _______________________________________________________________________________ 3a. lower order terms don't matter relative error from omitting low order terms essentially vanishes as $n$ grows large: relative error of $n^3/6$ from $f(n)$: |f(n) - n^3/6| 100 n^2 600 -------------- = --------------- = about --- = about 0 for large $n$ f(n) n^3/6 + 100 n^2 n so $n^3/6$ is a good approximation to $f(n)$. _______________________________________________________________________________ 3b. constant factors don't matter: they cancel out! f(10n) (10n)^3 / 6 (10n)^3 ------ = about ----------- = ------- f(10) n^3 / 6 n^3 the $1/6$ constant factor has disappeared. _______________________________________________________________________________ example of analyzing a program: see section 2.4 of [3/06] monster lecture sketch _______________________________________________________________________________ questions asked in/about lecture: Q: can you continue to post lecture sketches before lecture? A: sorry, i won't always have time to do that. Q: what does the big "O" signify in big-oh notation? A: it stands for "order", as in "rank" or "category" or "degree". A: we want to compare different rates of growth: A: we want to put similar ones into the same group or category or class. A: we want to be able to rank them from smaller/better to bigger/worse. A: the "order" or "rank" of a polynomial is its degree, e.g. A: $3x^2+7x+5$ is a 2nd order polynomial and A: $10x^6 - x^3 + 100$ is a 6th order polynomial. A: A: this concept includes things besides polynomials, e.g. $n log(n)$, $2^n$. Q: in the analysis example (sec 2.4 of monster sketch), Q: why is the loop guard executed $n+1$ instead of $n$ times? Q: after all, is executed only $n$ times. A: the guard is tested for $i=0..n$: A: it is true $n$ times (i=0..n-1), which is why the body runs $n$ times. A: it is then tested one more time (i=n), when it is false, which is why A: the loop stops instead of running forever; the loop body does not run A: when the loop guard is false, which is why there is the difference of A: $1$ between $n+1$ and $1$.