7.4

### 2 The Design Recipe

Purpose The purpose of this lab is to review and practice the design recipe that you were recently introduced to.

Textbook references Chapter 3: How to Design Programs, Chapter 4: Intervals, Enumerations, and Itemizations

### Pairing Demonstration: Online Average

In this, two TAs will demonstrate pair programming to solve a challenging problem, following the complete design recipe. THIS IS NOT AN EXERCISE, BUT WE DO NOT PROVIDE THE SOLUTION BECAUSE THE POINT IS TO OBSERVE HOW THE TAs INTERACT AS A PAIR TO SOLVE IT.

An "online" algorithm is one that processes data as it receives it, producing results along the way. These are important whenever the amount of data to process may exceed what you can store. For example, consider that we have a embedded computer attached to a temperature sensor in the arctic. The sensor is producing readings every few hundred milliseconds but the embedded computer doesn’t have nearly enough memory to store all of these readings for the months between visits by researchers. That’s okay, because the researchers are okay with just having the average temperature over the entire time between visits. However, we can’t simply store all the values and then compute the average at the end: there isn’t room to store all the values. Instead, we have to compute the average "online".

Our task is to design an online average function that accepts a previously computed current average, a new number, and computes a new current average. We will design a function next-average and an appropriate struct for the current-average.

### Shaping Up

Goals: To design programs over enumerations.

Starter Code: This is a data definition of a Shape.
 ; A Shape is one of: ; - "circle" ; - "square" ; - "triangle" ; and represents a kind of shape

Sample Problem Finish following the design recipe for this data definition (examples and a template).

 ; Examples (define CIRCLE "circle") (define SQUARE "square") (define TRIANGLE "triangle") ; Template (define (shape-temp shape) (cond [(string=? shape "circle")   ...] [(string=? shape "square")   ...] [(string=? shape "triangle") ...]))

Sample Problem Design a function draw which draws a Shape. Make use of your handy template from the past exercise, and don’t forget to follow every step of the design recipe for functions (signature, purpose statement, tests, code).

 ; draw: Shape -> Image ; Draw the shape (define (draw shape) (cond [(string=? shape "circle")   (circle 10 "solid" "red")] [(string=? shape "square")   (square 5 "solid" "blue")] [(string=? shape "triangle") (triangle 7 "solid" "orange")])) (check-expect (draw CIRCLE)   (circle 10 "solid" "red")) (check-expect (draw SQUARE)   (square 5 "solid" "blue")) (check-expect (draw TRIANGLE) (triangle 7 "solid" "orange"))

Exercise 1 Design a function draw/scene which overlays the image of a Shape on an empty-scene of a fixed size. Do you need to follow the Shape template here? How many tests does it need?

Exercise 2 Design a function next-shape which consumes a Shape and outputs the "next" shape (any order is fine, so long as next-shape "cycles through" all the shapes.)

Switch pair programming roles before continuing!

Exercise 3 Compose the draw/scene and next-shape functions in a big-bang animation that cycles through all of the shapes. Ask a member of the course staff for help if you’re stuck on big-bang syntax/usage. Using big-bang takes some practice, which is why we’re here!

Exercise 4 Is your animation headache-inducingly fast? Slow it down by giving your on-tick clause a number that follows next-shape to slow it down to that rate of seconds per frame (the default is 1/28 seconds per frame).

Exercise 5 Wrap your call to big-bang in a main function, which takes a Shape and uses that shape as the initial state. Don’t forget to give it a signature and purpose statement, but you cannot write tests for the main function. Why not?

Exercise 6 Launch your animation by calling your main function from the interactions window.

Switch pair programming roles before continuing!

### Worming as Designed

Consider the following partial data definition:

 (define-struct worm (its-name head body)) (define-struct head (mouth radius)) ; A Worm is (make-worm String Head PositiveNumber). ; A Head is (make-head Mouth PositiveNumber). ; A Mouth is one of: ; – "open" ; – "closed"

Exercise 7 Complete this data definition by finishing the design recipe for data.

Exercise 8 Design the function describe. It accepts a Worm and forms a sentence of the shape

"___'s mouth looks ___."

where the first blank space is replaced by the name of the worm and the second one by either "round" for an open mouth and "like a line" for a closed one.

### Defying Gravity

Goals: To design programs over intervals.

Countless crazes have swept the nation over the course of history. From planking to democracy, America is truly a land of fads. What fad grips us in its promise of adventure, scenic vistas, and defiance of gravity? Climbing, of course!

We’re going to create a game that simulates climbing, with varying difficulty in the vertical terrain. Our worldstate will be represented by the height of the climber, and we will construct a data definition that helps us design a program that simulates this daring climb.

Exercise 9 Define three constants, EASY-UP, MEDIUM-UP, and HARD-UP which will define how many pixels our brave climber can move in a single movement in terrains of varying climbing difficulty. The easier the terrain, the more our climber can move. Also, define the constant HEIGHT which will determine how tall our mountain is.

Exercise 10 Design a data definition Terrain which itemizes three non-overlapping, adjacent intervals. The smallest should start at 0 and the largest should end at whatever you defined HEIGHT to be. Remember to follow all four steps of the design recipe for data (data definition, interpretation, examples, template).

Switch pair programming roles before continuing!

Exercise 11 Design a function place-terrain which takes a Terrain (representing the height of a climber) and draws someone (who can be represented by your favorite shape) on a scene that is HEIGHT tall. If you’re feeling fancy, split your scene into three different-colored rectangles, one for each section of the terrain.

Remember that the coordinate system of images has (0, 0) at the top left and not bottom left!

Exercise 12 Design a function climb, which takes a Terrain (representing the height of the climber) and a KeyEvent and moves a climber up the mountain (move-up) if the key event is "up". Otherwise, they drop back down to 0. Sad!

Switch pair programming roles before continuing!

Exercise 13 Design a function reached-the-top? which takes a Terrain and determines if it is equal to HEIGHT.

Exercise 14 Compose your functions into a big-bang program wrapped in a main/climb function. This function can ignore its input, as the start state should always be 0; when inputs are ignored we name them _ by convention.

Unlike our last program, this one ends when a specific event happens (the climber reaches the top). What big-bang handler stops programs? Again, ask a course staff member if you’re having trouble with big-bang.

### Before You Go...

If you had trouble finishing any of the exercises in the lab or homework, or just feel like you’re struggling with any of the class material, please feel free to come to office hours and talk to a TA or tutor for additional assistance. We love to teach and you will learn. It’s symbiotic!

### Defying Gravity Extension (Optional)

Try this optional exercise if you’re looking to stretch your design skills!

Consider the following data definition:

 (define-struct climbing (terrain)) (define-struct falling (terrain)) ; A Climber is one of: ; - (make-climbing Terrain) ; - (make-falling Terrain)

Exercise 15 Finish the design recipe for this data definition.

Exercise 16 Instead of using a Terrain directly, update your program from ’Defying Gravity’ to use a Climber for your big-bang world.

Instead of dropping back down to 0 immediately when a key other than "up" is pressed, the climber should start falling at some constant rate. They should then begin climbing again when they reach the bottom. The climber should never fall below 0.