211 F '03
Ofc Hrs

Review Homework

This homework is a review homework. Like the exams, it covers all topics from the beginning of the semester to the last topic (accumulator style programming). Please re-read the sections on design recipes in HtDP before you work on the problem set.

The problem set consists of two parts; each part consists of a preamble, which we recommend you copy into a DrScheme window, and five problems. You must turn in two files per pair, one per part.


For this homework, you must not collaborate with anyone else but your partner. We will consider every other form of collaborations as cheating and will take action on it.


  • For each of the two parts, read the entire part before you attempt to develop the programs.
  • For each problem, decide which design recipe you wish to follow. Stick to it. Open the page in HtDP and use the recipe as a guideline. Just do it.
  • In addition, you must use the guideline "one task, one function." Make a wish-list on which you write down, which function you still need to solve a problem. Define all functions at the top-level. Then make sure you test these helper functions before you test those that use the helper functions.
  • You may use loops, if you want to do so. You don't have to. If you use loops with lambda, we will not look for test cases for this lambda function, but will give you the test points if it is correct.
  • Write down as a single comment, which design recipe you used for each define'd function:
    • domain knowledge: the problem specifies all the actions of the function or the function relies on knowledge from arithmetic and geometry. (We don't use anything else here.)
    • structural: using one of the structural design recipes from the book (parts i through iv)
    • generative: using the generative design recipe from the book
    • structural with accumulator: using the accumulator "adjective" for one of the structural design recipes
    • generative with accumulator: using the accumulator "adjective" for the generative design recipes
    Just because there are five options here does not mean you have to use all five options. But these are the available design recipes that you know. We will give one point per comment.

Part I: Worm

#| Worm:

The worm game is one of the oldest computer games around. The purpose of the game 
is to navigate a growing worm across a canvas and to make it eat food piles that 
pop up at random places. 

A worm consists of worm elements. Every time the worm eats a food pile, it grows 
by one element. 

The worm can move around freely on the screen but it must not touch the walls and 
itself. If it does, the game is over. 

Data Definitions: 
   A Food is: 
      (make-posn Number Number)
   A Worm is one of: 
   -- (cons Segment empty)
   -- (cons Segment Worm)
   An Segment is: 
      (make-posn Number Number)
   An Segment i is presented as represented as a disk with radius 3 at position i.



  • Problem:Design the function move, which computes a worm's movement on the canvas. In reality, the first segment of the worm moves into a new position and all the other segments of the worm move into the position of their respective predecessor. The function simulates this behavior by adding a new segment to the front--as if the existing first segment had moved--and by removing the last segment from the worm. The function consumes three inputs: a worm and two numbers (delta-x and delta-y). The numbers specify how far the first segment of the worm moves into the x and the y direction, respectively.
  • Problem:Design the function overlap?, which checks whether some given worm segment overlaps with a given worm. Hint: the function consumes two inputs: a segment and a worm.
  • Problem:Design the function can-eat?. The function consumes a worm (pun intended) and a food pile; it checks whether the worm can eat the food. A worm can eat the food if the distance between the food and the head of the worm is less than SEGMENT-RADIUS.
  • Problem:Every worm starts out as a single worm element. When it moves, it moves either in the up/down direction or in the left/right direction, but not in both. It also always moves one Segment diameter. When it eats something, it just acts as if it had moved without losing its last segment. Hence, a legitimate worm has an interesting property: the distance between two adjacent segments is always the diameter of one worm segment. Design the function legitimate-worm?. It consumes a worm and determines whether or not it is a legitimate worm.
  • Problem:Design the function driver. The function consumes a worm and moves it until the worm runs into itself. If it does, the function produces false. Constraint: the worm moves either up/down or left/right. Randomly generate a move for each "step" that the worm takes. Generate one direction first; the generate the other one from that value. Hint: you need to reuse the function move from Problem 1. We will assume that it is correct when we grade this problem.

Part II: Keeping Track of Patients

#| Keeping Track of Patients
 A PDB is one of: 
 -- empty
 -- (cons Patient PDB)
 A Patient is: 
 (make-patient String MeasurementList)
A MeasurementList is one of: 
   -- empty 
   -- (cons Measurement MeasurementList)
   A Measurement is: 

   The measurements represent pulse counts. A good pulse count for patients
   is between 50 and 80. 

(define-struct patient (name pulses))

(define LOWER 50)
(define UPPER 80)


  • Problem:Design the function create-patient, which consumes a name and creates a patient for whom we do not have any measurements.
  • Problem:Design the function add-measurement. The function consumes a patient and a Measurement; it produces a patient record that contains all the given patient information and the new Measurement.
  • Problem:Design the function alert. The function consumes a patient and produces the string "red" if the last measurement has been outside the range [LOWER,UPPER]. Otherwise it issues the string "green".
  • Problem:Design the function stable?. The function consumes a patient and determines whether a patient is stable. A patient is considered stable if any three consecutive measurements are withing 3 units of their average.
  • Problem:Design the function check. It consumes a Patient and produces true, if any three of the measurements have been over UPPER.

last updated on Wed Jan 21 11:15:50 EST 2004generated with PLT Scheme