CS 380 2024fall ibarland

home—lectures—recipe—hws—exams—D2L—zoom (snow day)

defining functions
hw02

Due Sep.10 (Tue) 12:30 at the start of class, on D2L and hardcopy.
Your submitted file should be named “hw02.rkt”.

handy helpers: You'll also want to right-click-and-download student-extras.rkt to the same directory as your hw02.rkt. Do not paste it into an empty DrRacket window, else you might end up with an error about `#lang` not enabled. This file gives you functions like real>0?, which are handy for signatures, not to mention define/contract itself.

Standard instructions for all homeworks:

• Your name, the assignment-number, and the URL of this assignment-page must be in a comment at the start of the file.
• Any code which results in syntax errors will generally not earn more than 50% of the points-possible. For grading, I will ignore any commented-out code, including commented-out tests So you'll get more points for including a test-that-fails, than commenting it out).
• If your hardcopy is more than 1page, please staple them. Find a stapler before class. I know that many printers don't have a stapler sitting next to them, even though that's the only place I ever want a stapler.
• Format well. (In particular, each open-paren should be preceded by a space or start-of-line, for now. E.g. (+ 2 (* 3 4 5)), not ( + 2(* 3 4
  5)
  ).) Typing TAB will re-indent the line as DrRacket thinks it should be. (See also, Racket » Reindent All.)
• Your programs should be racket’s intermediate-student-with-lambda language, or beginning-student (for this week only -- but it'll give you better error-messages).

• For every functions you write, follow the steps of the design recipe that we've covered in class (currently 4,5,7,8). (You don’t need to label each step; just turn in the final result.) When grading, there are points for having a good purpose-statement, good tests, etc. In general, test cases alone can be worth nearly half the points.

• Avoid repeated code!
  For example: If you find yourself repeating similar calculations to what’s already in pizza-area, see if you can avoid the repeated calculations by calling pizza-area as a helper-function (perhaps a couple of times).

1. (10pts) Recall from lecture, we demo’d the steps of writing a simple function, pizza-area, which computed the area of a pizza given diameter. Copy that function to use in writing some other pizza-related functions (while avoiding repeated-code).

   Of course, pizzas have topping in the middle, and crust all the way around the rim. (You can think of the full pizza being a disc, with a smaller pure-topping-covered disc inside of it.)

   1. Define a named-constant CRUST-WIDTH, defined to be 2 (inches).
      Our favorite pizza place has this much crust all the way around the edge.
      (Or at least, as close to that much crust as possible. It follows that a pizza could be all-crust, if its diameter is less than twice the crust-width.)
   2. Some people ignore the crust of a pizza, and only care about how much topping-covered area they'll be getting when they order a pizza. Write topping-area, which returns the amount of pizza covered in topping (in square-inches), for a given diameter (in inches).
   3. Other people love the crust, and only care about how much crust¹ is on their pizza! Write crust-area, which returns the amount of exposed crust (in square-inches) for a pizza of a given diameter (in inches).

   For now, your code does not need to give a correct answer for pizzas whose diameter is less than twice the CRUST-WIDTH. However, you should still have test-cases for sensible pizza-diameters which contain the true, expected answer in the check-expect. even if those tests don’t pass.

   Terminology: Perhaps “desired answer” would be a better term than “expected answer”.

   Optional: If you really want to get your code passing such tests for diameters less than twice CRUST-WIDTH – again, this is NOT required – you can either read about cond or if, or be clever in using the function max.

2. (10pts) Write the function has-suffix?, which takes in any two strings and returns whether or not the first string ends in the characters of the second string.

   Note that this is a computer-sciency definition of “suffix”. It has nothing to do with syllables or English. More precisely: we say that string a has b as a suffix, iff: there exists a string x such that (string=? a (string-append x b))².

   Hint: You remember to include tests with strings of length 0, 1, and many, of course. Since we have two string inputs, you can try up to all combinations. (Admittedly, many of those combinations are perhaps redundant, if we think about the white-box testing — but such knee-jerk test cases do help provide a routine, non-clever way to be sure all reasonable cases do get tested.)

   Hint: You can certainly use cond or if if you like, but they're not strictly necessary; you can instead use a min or max in a clever (but standard) way.

   No library required: Don’t use the built-in string-suffix? or similar functions for this problem. (They aren’t in the intermediatej-student language, so you’d have to use a require to get them anyway). Do use substring.

Images in racket

To experiment with functions-which-create-and-handle-images in DrRacket, include (require 2htdp/image) near the top of your file. Then you should be be able to evaluate each of the following:

(rectangle 80 20 'solid 'blue)
(circle 20 'solid 'red)
(ellipse 80 20 'outline 'orange)

(beside (rectangle 80 20 'outline 'blue)
        (circle 20 'solid 'red))
(underlay (rectangle 80 20 'outline 'blue)
         (circle 20 'solid 'red))
; Think of 'underlay' and 'beside' as being "addition for images"

; underlay with an offset:
(underlay/offset (rectangle 80 20 'outline 'blue)
                0
                10
                (circle 20 'solid 'red))


; If you want to explore documentation:
;   In DrRacket, position the caret on a function-name
;   like 'underlay', and hit F1.

Test cases for images

For functions that return an image, your expected-value should either be (a) an expression involving calls to: the image primitives and/or previously-tested functions, OR (b) an image-literal (but, show the expressions you used to create that image-literal).

For example, if the problem were create a function hdtv-screen which takes in a width and returns a solid purple rectangle with the given width and a 16:9 aspect ratio, then the expected-result could be created by directly calling the image-library's functions like rectangle:

(check-expect (hdtv-screen 32) (rectangle 32 18 'solid 'purple))
(check-expect (hdtv-screen 16) (rectangle 16 9 'solid 'purple))
(check-expect (hdtv-screen  0) (rectangle 0 0 'solid 'purple))
  ; Note: for the expected 0x0 rectangle, I could equally well write:
(check-expect (hdtv-screen  0) empty-image)

3. 
   1. (3pts) Write a function which takes in a size, and returns an image of a brown donut.
      on a white background — that is, just create a white circle on top of a brown one. (Mmmm, doughnut.)
      Note that image? is the type-name to use in signatures/contracts; you can see it used in the documentation for 2htdp/image.
   2. (3pts) Write a function eyes which takes a size and a color, and returns two colored rings side-by-side.
   3. (4pts) As needed, refactor the above functions so that there is little-to-no repeated code. (If the underlying helper function has a solid set of tests, the final function might get by with fewer tests — perhaps even just one.) Only turn in your refactored versions.

   You only need steps 4,5,7,8 of the design recipe (once you decide what how you'll represent "size", which is a straightforward choice), and we're only using existing, simple datatypes (so no steps 1-3 or 6).

4. (0pts — optional!) Write the function scale-to-width, which takes in two images and returns the first image, scaled so that it has the same image-width as the second image.

   For example:

   • 

   • (check-expect (scale-to-width (rectangle 50 20 'solid 'blue) (square 30 'solid 'red)) (rectangle 30 12 'solid 'blue))

     .
   Observe that scale-to-width needs the second image only for determining its image-width.

5. (10pts) Consider functions that create memes, such as:

   (check-expect (super-cool-ski-instructor-meme "spend all semester making memes") )

   That expected-result was created from the expression:
   
   This code uses a helper scale-to-width; if you didn’t just write it yourself, you can copy/paste that function from here; you’ll want to open that file in DrRacket then copy/paste it near the top of your own hw02.rkt. (Just cite the URL, as you do for any code taken from the web.) Note that running this function requires internet access.
   1. Give one more test-case for super-cool-ski-instructor-meme.

      correct meme-usage: Note that the words If you and you're gonna have a bad time. are not provided by the caller, since they are part of the supercool ski instructor memes, by definition. Put differently: Your function will enforce correct meme usage.

   2. Write the code for super-cool-ski-instructor-meme.
      (No additional test-cases required.)
   3. Write a test case for futurama-fry-meme in addition to the one shown here:

      (check-expect (futurama-fry-meme "the image-library is easy" "Java's GUI library is hard") )

   4. Write the code for futurama-fry-meme.
      (No additional test-cases required, beyond the one you created above.)
   5. Write one additional meme-making function based on some established meme (e.g. one from imgflip.com/memetemplates). Include 2 unit-tests.

   6. We notice that there is a lot of repeated code in our functions — very ugly.
      We will refactor it out.

      Task: Write a more general function make-meme, and change your preceding three functions so that they are EACH very-short calls to make-meme. You should not change their behavior at all, nor change any of the existing test cases.

      It is up to you to decide how many parameters (and their type) to provide to make-meme. It should be general enough so that it can create almost all standard memes with text at the top and bottom (but don’t worry about having multiple-lines of text, nor about having the font size or color work exactly like the examples I provided).

      Only submit your refactored versions of the functions for (b),(d),(e) — you don’t need to (and, shouldn’t) keep the original versions around.

To save toner/ink: Ideally your hardcopy would include the entire source file, including any image-literals. But since that can be pricy for this homework, feel free to do any or all:

• Print in black-and-white.
• Replace some/all image-literals in your source with code-which-generates-the-image.
• Just before printing, replace some/all image-literals with (say) empty-image or -999 (causing your code to break), then Edit » Undo this change just after printing.

In all cases, your D2L-submitted version should still run.

home—lectures—recipe—hws—exams—D2L—zoom (snow day)

This page licensed CC-BY 4.0 Ian Barland Page last generated

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu