6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 30.1.16 Here is a nice way to build that abstraction. We'll create our Drawing in a rectangle or frame picture within the constraints of a default rectangle, of size 1 That is, our initial set of segments will have the property that their x and y values all lie between 0 and 1. Imagine those segments being attached to a sheet of rubber that fits over a square frame as shown in the lower left Then, if we provide other rectangle, which may be shifted 1,1) over from the first, and which may have a different aspect ratio we want our method for drawing to take that sheet of rubber and stretch it to fit over the new rectangle's fra (0, 0)en/203 Slide 30.1.17 Well that is fine, we just need another data structure. Note that Generating the abstraction of a frame this one is built out of vectors, so we are constructing another define make- rectangle lis abstraction within our system. In particular, a rectangle is now defined to have a vector to its origin or starting point, and two (define horiz cadre vectors that specify the extent of the horizontal and vertical efine vert cadd) Generating the abstraction of a frame Slide 30.1.1 8 And then a picture is just a procedure that takes a rectangle(one Rectangle: (define make-rectangle list) of these abstractions )and does some stuff to draw lines within (define origin car that rectangle. We will return shortly to what this actually (define horiz cadr] oes <draw some stuff in rect> Slide 30.1. 19 Now a key issue in building data abstractions is that it should What happens if we change an abstraction? insulate the details of the abstraction from the actual use of the abstraction. To stress this, suppose we make the following (define xcor car) change to our data structures we change make-vect to (define yor cadr list, and we change ycor to cadr, which is short What else needs to change in our system? for(car (cdr .)) note that is version still satisfies our contract on the abstraction What else has to change inside of our system? 600Sc
6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 30.1.16 Here is a nice way to build that abstraction. We'll create our picture within the constraints of a default rectangle, of size 1. That is, our initial set of segments will have the property that their x and y values all lie between 0 and 1. Imagine those segments being attached to a sheet of rubber that fits over a square frame as shown in the lower left. Then, if we provide some other rectangle, which may be shifted over from the first, and which may have a different aspect ratio, we want our method for drawing to take that sheet of rubber and stretch it to fit over the new rectangle’s frame. Slide 30.1.17 Well that is fine, we just need another data structure. Note that this one is built out of vectors, so we are constructing another abstraction within our system. In particular, a rectangle is now defined to have a vector to its origin or starting point, and two vectors that specify the extent of the horizontal and vertical axes of the frame. Slide 30.1.18 And then a picture is just a procedure that takes a rectangle (one of these abstractions) and does some stuff to draw lines within that rectangle. We will return shortly to what this actually does. Slide 30.1.19 Now a key issue in building data abstractions is that it should insulate the details of the abstraction from the actual use of the abstraction. To stress this, suppose we make the following change to our data structures: we change make-vect to list, and we change ycor to cadr, which is short for (car (cdr .)). Note that is version still satisfies our contract on the abstraction. What else has to change inside of our system?
6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 30.1.20 What happens if we change an abstraction? Absolutely nothing! This is a key point about the data abstractions. The modularity (define make-vect list) of the abstraction isolates changes within the abstraction from (define xcor car) Note that this still atisfies the contract the use of the abstraction hence any code that uses these (define yor cadr) abstractions will still run, even though the details within the abstraction have changed What else needs to change in our system? BUPKIS, NADA NOTHING Slide 30.1.21 Okay, so we can create the pieces of George. But how do we actually draw? What is a a picture? This is where the weird part comes in! We could just create a Could just create a general procedure to draw procedure to draw line segments. But we want the flexibility of collections of line segmen being able to use any frame to draw the same picture But want to have flexibility of using any frame to So we make a picture be a procedure! This definitely sounds weird!! a picture sounds like it should be a data structure, a we make a picture be a procedure! Captures the procedural abstraction of drawing collection of geometric entities, but we are going to make it a data within a frame procedure. Inside the procedure will reside those geometric entities, but that procedure will take as input a rectangle, then e emam scale the elements to fit within that rectangle, and display the result This seems odd, right? In principle, a picture is data, but we are choosing to represent it as a procedural abstraction that captures the process of drawing data in a frame Why? Primarily for flexibility. In this way, we have one procedure with inherent data, but it provides an infinite number of versions of the picture. This abstraction allows for very easy manipulation of a picture structure to get new versions. So let's see how that happens Slide 30.1.22 Manipulating vectors First, we need to manipulate the pieces of a picture, so that means we need ways to manipulate vectors themselves. Let's look at some standard things we would like to do with vectors seale-vec We would like to take two vectors and add them together to get a new vector. And we would like to stretch or scale a vector by scaling its x and y coordinates by the same amount 4 80/2003 1001 SICP
6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 30.1.20 Absolutely nothing! This is a key point about the data abstractions. The modularity of the abstraction isolates changes within the abstraction from the use of the abstraction. Hence any code that uses these abstractions will still run, even though the details within the abstraction have changed. Slide 30.1.21 Okay, so we can create the pieces of George. But how do we actually draw? This is where the weird part comes in! We could just create a procedure to draw line segments. But we want the flexibility of being able to use any frame to draw the same picture. So we make a picture be a procedure!! This definitely sounds weird!! A picture sounds like it should be a data structure, a collection of geometric entities, but we are going to make it a procedure. Inside the procedure will reside those geometric entities, but that procedure will take as input a rectangle, then scale the elements to fit within that rectangle, and display the result. This seems odd, right? In principle, a picture is data, but we are choosing to represent it as a procedural abstraction that captures the process of drawing data in a frame. Why? Primarily for flexibility. In this way, we have one procedure with inherent data, but it provides an infinite number of versions of the picture. This abstraction allows for very easy manipulation of a picture structure to get new versions. So let's see how that happens! Slide 30.1.22 First, we need to manipulate the pieces of a picture, so that means we need ways to manipulate vectors themselves. Let's look at some standard things we would like to do with vectors. We would like to take two vectors and add them together to get a new vector. And we would like to stretch or scale a vector by scaling its x and y coordinates by the same amount