6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology be able to get out the coordinates when needed but in many cases, one thinks naturally of manipulating a vector as a unit. Similarly, one can imagine aggregating together a set of vectors, to form a polygon, and again one can think of manipulating the polygon as a unit. Thus, a key stage in designing a computational system is determining the natural data structures of the system Slide 7. 1. 4 Code layout and design A second stage in designing a computational system is deciding how best to break the computation into modules or pieces. This is often as much art as science but there are some general Data structures guidelines that help us separate out modules in our design. For Procedural modules example, is there part of the problem that defines a computation Computation to be reused Suppression of detail from use of procedure that is likely to be used many times? Are there parts of the problem that can be conceptualized in terms of their behavior, e.g. how they convert certain inputs into certain types of outputs, without worry ing about the details of how that is done I Does this help us focus on other parts of the computation? Or said a bit differently, can one identify parts of the computation in terms of their role, and think about that role in the overall computation, without having to know details of the computation? If one can, these parts of the computation are good candidates for separate modules, since we can focus on their use while ignoring the details of how they achieve that computation Slide 7.1.5 Finally, given that one can identify data structures, whose information is to be manipulated; and stages of computation, in Code layout and design which that information is transformed: one wants to decide the Design of overall flow of information between the modules. What types Data structures of inputs does each module need? What types of data does each Procedural modules module return? How does one ensure that the correct types are Interfaces provided, in the correct order "types"of inputs and outputs These kinds of questions need to be addressed in designing the overall flow between the computational modules 48m0 601h Slide 7.1.6 An example of code modules This is perhaps more easily seen by thinking about an example and in fact you have already seen one such example, our Finding the sqrt of X Make a guess, G implementation ofs grt. When we implemented our If it is good enough, stop Otherwise, get a new guess by averaging G and method for square roots, we actually engaged in many of these stages. We didn t worry about data structures, since we were simply interested in numbers. We did, however, spend some Good-enur effort in separating out modules. Remember our basic Average computation: we start with a guess; if it is good enough, we 6 001 SICP I guess, and the ratio of the target number and the guess, and r guess by averaging the curren continue To design this system, we separated out several modules: the notion of averaging, the notion of measuring enough". We saw that some of these modules might themselves rely on other procedural abstractions; for6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. be able to get out the coordinates when needed, but in many cases, one thinks naturally of manipulating a vector as a unit. Similarly, one can imagine aggregating together a set of vectors, to form a polygon, and again one can think of manipulating the polygon as a unit. Thus, a key stage in designing a computational system is determining the natural data structures of the system. Slide 7.1.4 A second stage in designing a computational system is deciding how best to break the computation into modules or pieces. This is often as much art as science, but there are some general guidelines that help us separate out modules in our design. For example, is there part of the problem that defines a computation that is likely to be used many times? Are there parts of the problem that can be conceptualized in terms of their behavior, e.g. how they convert certain inputs into certain types of outputs, without worrying about the details of how that is done. Does this help us focus on other parts of the computation? Or said a bit differently, can one identify parts of the computation in terms of their role, and think about that role in the overall computation, without having to know details of the computation? If one can, these parts of the computation are good candidates for separate modules, since we can focus on their use while ignoring the details of how they achieve that computation. Slide 7.1.5 Finally, given that one can identify data structures, whose information is to be manipulated; and stages of computation, in which that information is transformed; one wants to decide the overall flow of information between the modules. What types of inputs does each module need? What types of data does each module return? How does one ensure that the correct types are provided, in the correct order? These kinds of questions need to be addressed in designing the overall flow between the computational modules. Slide 7.1.6 This is perhaps more easily seen by thinking about an example – and in fact you have already seen one such example, our implementation ofsqrt. When we implemented our method for square roots, we actually engaged in many of these stages. We didn’t worry about data structures, since we were simply interested in numbers. We did, however, spend some effort in separating out modules. Remember our basic computation: we start with a guess; if it is good enough, we stop; otherwise we make a new guess by averaging the current guess, and the ratio of the target number and the guess, and continue. To design this system, we separated out several modules: the notion of averaging, the notion of measuring “good enough”. We saw that some of these modules might themselves rely on other procedural abstractions; for example