1b: How to Design Functions

Question 1

What are the learning goals of How to Design Functions (HtDF)?

Answer 1

(1) Be able to use the How to Design Functions (HtDF) recipe to design functions that operate on primitive data.
(2) Be able to read a complete function design and identify its different elements.
(3) Be able to evaluate the different elements for clarity, simplicity and consistency with each other.
(4) Be able to evaluate the entire design for how well it solves the given problem.

Question 2

Why does the HtDF recipe seem like overkill?

Answer 2

Design methods often make simple problems harder to solve. Right now we are using simple problems to learn how to use the design method. This will pay you back later by making really hard problems much easier to solve.

Question 3

What does the HtDF (how to define functions) RECIPE do in terms of design?

Answer 3

The HtDF recipe SYSTEMATIZES the design of a function. It tells us what to DO 1ST, & 2ND, & 3RD, all the way through the design of a function. It helps us know WHAT TO DO, and it also helps us be sure we end up with a HIGH QUALITY function.

Question 4

Why do I ask for your patience here?

Answer 4

It may seems there is a lot going on. It may be overkill for those who have programmed before.

Question 5

What are the steps to the HtDF recipe?

Answer 5

(1) Signature, purpose and stub (states the data type of each argument/parameter (string or number etc.), purpose is what do you want it to do in plain English and a stub as a wireframe scaffolding to run examples before the design is complete.
(2) Define examples, wrap each in (check-expect [function x] [ * 0 2 ] )
(3) Data Driven Template (type of data the function consumes, raw material you have to work with; number, string, boolean, image, etc.) and inventory of constants named properly to be used for easiness of use, clarify of understanding, and modifiability in the future. (define (f-n-for-type-name x) [body] )
(4) Code the function body.
(5) Test and debug until correct. “Run early and run often” should catch a lot of the bugs but if not this step should catch most of the issues.

Question 6

What does the signature do?

Answer 6

It tells us what the input and output is in type.

Question 7

What does the purpose do?

Answer 7

It describes in plain English what we want the function to do.

Question 8

What is the summary of the HtDF recipe?

Answer 8

(1) Signature, purpose and stub.
(2) Define examples, wrap each in (check-expect).
(3) Data Driven Template and inventory of constant names.
(4) Code the function body.
(5) Test and debug until correct.

Question 9

What does the stub do?

Answer 9

(define (double n) 0)

Question 10

What does the check-expect do?

Answer 10

Makes sure the program runs, even if I get an error.

Question 11

Why is the HTDF recipe NOT a waterfall process?

Answer 11

You don’t have to get step #1 exactly perfect before being able to move on to the next step. YOU can always comes BACK to it to clarify/modify if needed.

1) Signature, purpose, stub
2) Check Expect->Examples
3) Data Template and Inventory of Constants
4) Code the function body.
5) Test and debug until correct.

It happens often when you skip step 1 and go to examples to clarify what the signature (data type input and output) may be. It’s not carte blanche but there is some flexibility, structure process but not locked in waterfall.

Question 12

Design a function CALLED image that consumes an image and produces the area of that image.

Answer 12

(require 2htdp/image) ->we need to tell Dr. Racket we want to use the image function.

1) signature: image -> number (natural)
purpose take an image, multiply its width by its height to get its area and print that.

stub (define (image_area a) 0)
[0 is the dummy value here because its a number]
2) check expect (image_area (rectangle 2 3 “solid” “red”)) (* 2 3))
3) data template and constants
(define (image_area a)
(…img))
(define (image_area a)
(* (image-width img) (image-height img)))
4) code the body.
5) Test and debug.

We may realize that images are ALWAYS SIZED in pixels. AND PIXELS are a NATURAL number (no 3.2 just 3).

Question 13

Why should you use the most SPECIFIC correct type?

Answer 13

Saying floating point (i.e. a type of number) or natural is better than just saying number because IT MAKES IT EASIER to think about the function and to DEBUG as well.

Question 14

Why are we going to start being LESS and LESS specific about the FUNCTION we design?

Answer 14

This is because design is the PROCESS of GOING from a poorly formed problem to a WELL structured solution. SO making the problem more specific is PART OF THE DESIGN process.

Question 15

Design a function that consumes an image and determines whether the image is tall.

Answer 15

1) signature, purpose, stub
; image -> boolean (true/false yes/no)
; compare and image to another and see if it’s tall then produce a true
(require htdp2/image)
; (define (image_tall? img) True)
2) check expect examples (This function needs three examples).
(check-expect (image_tall? (rectangle 2 3 “solid” “red”) ) true)
(check-expect (image_tall? (rectangle 3 2 “solid” “red”) ) false)
(check-expect (image_tall? (rectangle 3 3 “solid” “red”) ) false)

3) data template and inventory of constants
(define (image_tall? img)
(if (…img) (…img) (…img)))

(define (image_tall? img)
(if (> (image-height img) (image-width img)) true false))

Dr. Racket highlights CODE COVERAGE and test coverage by highlighting False if you haven’t tested it.

4) code the body
5) test and debug

Question 16

How do you name a function that produces a boolean (answer to a yes/no true/false question)?

Answer 16

We always have a name that ends in a question mark.

define (tall? img) false

Question 17

What is the concept of CODE coverage for a test, or TEST COVERAGE?

Answer 17

Given all of my tests, how much of the code is actually being evaluated? (If the answer is not all of the code then you don’t have enough tests). What if the piece of code that isn’t evaluated is wrong?

Question 18

How much test coverage (code coverage for a test) should you have?

Answer 18

At MINIMUM, your tests should have complete code coverage.

Question 19

What is a BOUNDARY CONDITION, or a CORNER CASE that happens in function and program design all the time?

Answer 19

Once example is it happens when you have a case that does not answer true or false. So if our function answers as true if the heights it longer than it’s width. What if both height and width are the same length?

Question 20

What should you do once you realize there is a boundary condition (corner case)?

Answer 20

Once you realize this FIRST, you should (1) WRITE an example (2) write the expected result unambiguosly (3) UPDATE all affected areas, purpose, function definition, tests, and signature.

Question 21

What function can you REPLACE the (if then else) function?

Answer 21

Whenever there is a if question WITH TRUE/FALSE answer you can just replace the function with the QUESTION itself.

Question 22

What’s the best way to learn this kind of material?

Answer 22

Start with a BLANK file and work through them WITHOUT looking at the answers. If you don’t then you’ll cheat/lie to yourself and say you get it when you don’t really. It will be re-cognition vs. re-collection.

Question 23

Define a function that adds an s to the end of a word, pluralizes it.

Answer 23

(define (pluralize str) “”)

(check-expect (pluralize “dog”) “dogs”)

(define (pluralize str)
(string-append str “s”))

Question 24

Design a function that consumes two images and produces true if the first is larger than the second.

Answer 24

(require htdp2/image)
;1)
;Signature: Image -> Boolean
;Purpose: check if area of image 1 > image 2 by ;multiplying image-width by image-height for each ;image and then answer True or False.
;stub: (define (Larger? img) True)
;2) Examples
(check-expect (Larger? (rectangle 10 20 “solid” “red”) (rectangle 5 20 “solid” “red”)) true))
(check-expect (Larger? (rectangle 10 20 “solid” “red”) (rectangle 5 20 “solid” “red”)) false))
(check-expect (Larger? (rectangle 10 20 “solid” “red”) (rectangle 10 20 “solid” “red”)) false))

;3) Data Template and Inventory of Constants

(define (Larger? img1 img2)
(….img1 img2)
(….img1 img2)
(….img1 img2))

;4) Code the body
(define (Larger? img1 img2)
(> (* (image-height img1) (image-width img1) (* (image-height img2) (image-width img2) true false)

(define img1 (rectangle 10 20 “solid” “red”)
(define img2 (rectangle 20 10 “solid” “blue”)

(Larger? (img1 img2))