6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 7.2.9 This is where having good test cases is important. For example, when testing a recursive procedure, it is valuable to Evaluation and verification try it using the base case values of the parameters, to ensure that the procedure is terminating at the right place, and Choosing good test cases returning the right value. It is also valuable to select input Pick values for input parameters at limits of parameter values that sample or span the range of legal values legal range does it work with small values, with large values, does Pick values that span legal range of parameters hanging the input value by a small increment cause the Retest prior cases after making code changes expected change in output value? Slide 7.2.10 Debugging tools And what do we do if we find we have one of these structure 6? Well, our goal is to isolate the location of our The ubiquitous print/display expression misconception within the code, and to do this, there are two Tracing standard tools Stepping The most common one is to use a print or display expression that is, to insert into our code, expressions that will print out for us useful information at different stages of the computation For example, we might insert a display expression within the recursive loop of a procedure, which will print out information 6001 SICP about the values of parameters. This will allow us to check that parameters are being updated correctly, and that end cases are correctly seeking the right termination point. We might similarly print out the values of intermediate computations within recursive loops, again to ascertain that the computation is operating with the values we expect, and is computing the values we expect A related tool, supplied for example with Scheme, is a tracer This allows us to ask the evaluator to inform us about the calling conventions of procedures-that is, to print out the values of the parameters supplied before each application of the procedure we designate, and the value returned by each such procedure call. This is similar to our use of display expressions, but is handled automatically for us. It applies only to parameters of procedure calls however, so that if we want to examine for detailed states of the computation, we need to fall back on the display tactIc In some cases, it may help to actually walk through the substitution model, that is, to see each step of the evaluation. Many languages, including Scheme, provide a means for doing this -in our case called the stepper obviously tedious, but works best when we need to isolate a very specific spot at which an error is occurring, and t This is a mechanism that lets us control each step of the substitution model in the evaluation of the expression. It we don't want to insert a ton of display expressions Perhaps the best way to see the role of these tools is to look at an example, which we do next 6.001 Notes: Section 7.36.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 7.2.9 This is where having good test cases is important. For example, when testing a recursive procedure, it is valuable to try it using the base case values of the parameters, to ensure that the procedure is terminating at the right place, and returning the right value. It is also valuable to select input parameter values that sample or span the range of legal values – does it work with small values, with large values; does changing the input value by a small increment cause the expected change in output value? Slide 7.2.10 And what do we do if we find we have one of these structure errors? Well, our goal is to isolate the location of our misconception within the code, and to do this, there are two standard tools. The most common one is to use a print or display expression – that is, to insert into our code, expressions that will print out for us useful information at different stages of the computation. For example, we might insert a display expression within the recursive loop of a procedure, which will print out information about the values of parameters. This will allow us to check that parameters are being updated correctly, and that end cases are correctly seeking the right termination point. We might similarly print out the values of intermediate computations within recursive loops, again to ascertain that the computation is operating with the values we expect, and is computing the values we expect. A related tool, supplied for example with Scheme, is a tracer. This allows us to ask the evaluator to inform us about the calling conventions of procedures – that is, to print out the values of the parameters supplied before each application of the procedure we designate, and the value returned by each such procedure call. This is similar to our use of display expressions, but is handled automatically for us. It applies only to parameters of procedure calls, however, so that if we want to examine for detailed states of the computation, we need to fall back on the display tactic. In some cases, it may help to actually walk through the substitution model, that is, to see each step of the evaluation. Many languages, including Scheme, provide a means for doing this – in our case called the stepper. This is a mechanism that lets us control each step of the substitution model in the evaluation of the expression. It is obviously tedious, but works best when we need to isolate a very specific spot at which an error is occurring, and we don’t want to insert a ton of display expressions. Perhaps the best way to see the role of these tools is to look at an example, which we do next. 6.001 Notes: Section 7.3