[Index of Problem Sets]

Problem Set 01—Notes and link to solution

Here are some general comments about Problem Set 1. The lab and midterm graders will be looking for additional elements beyond what the autograder can look for so please read these notes carefully and download and review our sample solution carefully.

To get the 80 character width guide:

  DrRacket (mac)/Edit (windows) > Settings
  [Editing]
  [General Editing]
  select "Maximum character width guide" and change 102 to 80
      

You can also find Settings using ctrl/cmd + ;

Problem 1:

While there are many answers that evaluate to 1, the autograder accepts only four answers as correct. Here are the original arithmetic expression as well as the four answers accepted.

  3^2 + 6 * (6 - 10) / 3
  
  (+ (sqr 3) (/ (* 6 (- 6 10)) 3))
  (+ (* 3 3) (/ (* 6 (- 6 10)) 3))
  (+ (sqr 3)    (* 6 (/ (- 6 10) 3)))
  (+ (expt 3 2) (* 6 (/ (- 6 10) 3)))

What we wanted was an answer that clearly reflected the structure of the equation being computed. Remember that programs are written to be read by humans! Writing for reader clarity is critically important.

ASIDE: Some of you may object that our expressions are less efficient than just writing 1. But that isn't true, and it almost certainly wouldn't matter even if it was. It isn't true because of something called constant folding. It wouldn't matter because except for small parts of programs it is almost never worth making the program less clear for small performance gains like this.

Problem 2:

Being able to produce the step-by-step evaluation for BSL code is critically important. You need this skill to debug programs. More prosaically you will probably need it on exams. You should practice to be sure you can get it exactly right. You can use the DrRacket stepper to check your practice work.

Problems 3 - 5:

When we write programs we almost never get them right on the first try. This is true of beginners, it is true of experts, and it is true of everyone in between. Getting all the details right on the first try is hard. To cope with this you need to learn how to find bugs in your code. You also want to learn to organize your programs in ways that help find the bugs quickly - the check-expects you learn in 110 are one such approach.

Problem 6:

This problem required you to discover the triangle function and work out how to use it to form the desired image. You also needed rotate, rectangle, and above, but all of those were covered in lecture and/or lab. Disovering new primitives you will need to use is something you will continue to see—there are so many that no one can remember them all, so we end up having to look up primitives all the time.

Problem 7:

This problem is deliberately underspecified. We didn't say exactly what we meant by taller. The design recipe helps you deal with underspecified problems in that there are a couple of different points during the design where you can notice the problem is underspecified and resolve it. For this problem you might notice while writing the purpose or while writing the check-expects. What you needed to do in this case was notice the lack of specificity, make a reasonable design choice, and clearly capture that in the program. We accepted both reasonable resolutions to the lack of specificity.

Also remember that a purpose can be at most 1 line long. That means that it can not be over 80 characters and must be all on one line. The purpose should explain what the function does, not how it does it. The purpose does not need to repeat the signature. So the first of these purpose statements is the kind of thing you want to write, not the second:

  ;; Produce image with greater height; or first image if same height

  ;; Consume two images, compare their heights, if first is taller produce it, otherwise produce second.

Remember to run your stub with your check-expects, it is the easiest way to find errors in both. Your design should be consistent throughout the whole of the question so the result type should be consistent in the signature, stub, check-expects, and function definition.

Finally please remember that details matter. Consider the following solution in which many of the hard parts of this problem are correct.

  (@htdf taller-image) ;Uncomment this line when you start the problem.
  ;Image-> Image)
  ;Consume two images and produce the one that has the taller height                                  
  
  (check-expect(taller-image (rectangle 10 20 "solid" "red")
                             (rectangle 10 15 "solid" "red"))
               (rectangle 10 20 "solid" "red"))
  (check-expect(taller-image (rectangle 10 20 "solid" "red")
                             (rectangle 10 25 "solid" "red"))
               (rectangle 10 25 "solid" "red"))
  (check-expect(taller-image (rectangle 10 20 "solid" "red")
                             (rectangle 10 20 "solid" "red"))
               "images are the same height")
  ;(define (taller-image i1 i2) (rectangle 10 40 "solid" "blue"));stub                                                                                  
  (define (taller-image i1 i2)
    (cond [(>(image-height i1)(image-height i2)) i1]
          [(=(image-height i1)(image-height i2)) "images are the same height"]
          [else i2]))

  (taller-image (rectangle 20 30 "solid" "blue")(rectangle 20 40 "solid" "red"))
  (taller-image (rectangle 20 40 "solid" "blue")(rectangle 20 40 "solid" "red"))
  (taller-image (rectangle 20 50 "solid" "blue")(rectangle 20 40 "solid" "red"))

Unfortunately there are a number of problems here that keep this from being a perfect solution. Some of them are:

The solution for this problem set is: