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? 600Sc6.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?