CS 170 – INTRO TO SCIENTIFIC AND ENGINEERING PROGRAMMING

Software Engineering Goals: Understand difficulties in solving large programming problems Develop effective methods for writing large programs How do we define a good program? What is a bug? Why is SW Engineering important?

Top-Down Design Should we start solving a problem by coding the solution immediately? CASE: Computer Aided SW Engineering Decomposition: divide problem to sub problems Stepwise refinement: repeated application of decomposition

Top-Down Design 1. State the problem 2. Define the inputs and outputs 3. Design the algorithm a) Decompose into subproblems b) Perform stepwise refinement 4. Convert the algorithm into a Matlab program 5. Test the program Which step is the most difficult and why? What is an iterative process?

Script Files Script files text files (created with a text editor) contain many lines of MATLAB expressions and assignments. You can execute all of the lines of the file (sequentially) by typing the filename at the MATLAB prompt. If filename is computetraj.m, then >> computetraj causes the instructions (ie., the MATLAB commands) in the file to be run.

Debugging your programs Is it possible to have errors in your program? Three different types of errors are Syntax errors: you simply have typed an illegal expression, independent of the values of the variables in the expression. Run-time errors: logic errors that result in an illegal expression for specific values of the data (harder to fix). Logic errors that result in the program executing completely, but the answer that they return is incorrect (hardest to fix).

Finding run-time errors (bugs) The most primitive way to debug a program is to Work out (by “hand”) Remove the trailing semicolons ; Call your program, and compare the printouts (your program) to your hand-calculations

Finding run-time errors (bugs) A better (but ultimately the same) way is to Work out (by “hand”) Insert the command keyboard at some point in your program. This is called “setting a breakpoint” Run the program When execution gets to the keyboard line program execution is temporarily stopped the Command window appears, the prompt is K>> control it at the keyboard (ie., you can type) Type expressions at the K>> prompt You are a detective at this point. Type K>> return (resume execution) or K>> dbquit (exit)

Single-line stepping through an m-file Use dbstep to step through an M-file a line-at-a-time To execute the next line of code, type K>> dbstep To execute the next 6 lines of code, type K>> dbstep 6 To execute code until another m-file function is called, and then to “stop inside” that function at its first line, type K>> dbstep in To execute code until the m-file function exits, and then to stop inside the m-file function that called it, type K>> dbstep out After any of these, the “instruction pointer” moves to the next line of code which has not executed.

Stopping in an M-file Use dbstop to stop in an M-file at a certain line if a condition is true. To stop in loancalc at line 11 if the variable G is less than 1 K>> dbstop in loancalc at 11 if G<1 This sets a conditional breakpoint.

Clearing breakpoints All breakpoints can be cleared with the command >> dbclear all You can also selectively clear breakpoints that were created with dbstop. See >> help dbstop >> help dbclear for more information.

Using dbup and dbdown Normally at a breakpoint execution is temporarily stopped the K>> prompt appears in the command window the variables in the function’s workspace can be examined. The command dbup changes the scope of visible variables to the caller’s workspace. K>> % examine variables in function’s workspace K>> dbup K>> % examine variables in caller’s workspace K>> dbdown K>> % examine variables in function’s workspace

Seeing all of the function instances Use dbstack to see the list of all function instances that are running. The top line gives the function instance where the dbstack command occurred. The (n+1)’th line is the function instance of the function which called the function instance listed on the n’th line.

Profiling your code When running a program, Matlab can keep track of How many times a single line is executed How many times a function is called How much total time is spent executing a specific line of code How much time is spent running a specific function Why is this information useful? >> profile on >> myprogram >> profile report

QUESTIONS??

Resources “Introduction to Programming with Matlab”, J. Michael Fitzpatrick and John D. Crocetti Lecture slides E77, Andy Packard,