CS Project 9
	Baking Some Cookies... OK, Writing a Function. (Following a Design Recipe)
Concepts	Activity	Homework

Review

We learned what a constant expression was.

We reviewed function definitions in mathematics.

We reviewed function applications in mathematics, also.

We saw a function definition, and some function applications in Scheme.

We executed, or ran, a program.

We saw a purpose statement.

We saw examples and verifications.

We saw a contract.

We saw a function header.

We saw a function body.

We learned that a function is a rule for performing operations on data.

But we haven't really designed our own program yet.

We are going to learn a recipe for designing our own functions. We are going to learn some steps, and practice these steps. Finally we are going to actually apply the recipe to a real problem.

No, not baking cookies...

Computer Science, and computer programming, is a mathematical discipline. Computer Science is also a design discipline.

To keep programmers and other designers from making a mess out of their projects, people have studied how to proceed, and developed lists of steps to follow.

We're going to call these lists of steps design recipes. (The $9 word for a recipe is methodology. No, that won't be on the test.)

We will use slightly different design recipes as we go along.

The design recipes will all pretty similar, but they will change according to the kind of data we work with.

For now, we are working with simple data. Simple data is "atomic" rather than "composite." "Atomic" means they're generally considered a single irreducible piece. I think of things like ball bearings, electrons, the number 23, the letter K, etc.

Composite data is made up of pieces. I think of things like a telephone book, the current position of a chess game, a list of the first 100 prime numbers, and a stamp collection.

Some examples of kinds of simple data are numbers, and booleans. We generally don't break them down further.

Here is the first design recipe:

This is the exact order to follow this recipe.

Now if you are being obeservant, you will see that some of the steps above are not in quite the same order as they are in the resulting program below.Programs are almost never written from top to bottom. You have to jump around. (Is this a big problem?)

Here's a copy of the program from the last lesson:

;; purpose: to double a number
;; contract: double : num -> num
(define (double x)
    (* x 2))

;; verifying double
(double 12) = 24
(double -1) = -2
(double 0) = 0

Now let's follow the design recipe, and put your finger on the part that I wrote with each step.

• Where is the purpose statement?
• Where is the contract?
• Where are the examples and verification?
• Where is the function header?
• Where is the function body?

And I'm going to say what I said last time about the order of the tasks again:

The purpose statement is written first.

The contract is written next. It shows what your function consumes and produces. The purpose statement helps you write it.

The examples and verifications are written next, even though they go below the definition.

The examples and verifications show what correct applications of your function will look like, and what they ought to produce.The contract helps you write them. (Actually, sometimes these also show you that the contract you wrote was a dud, and that you have to fix it. )

The header of the definition is written next. This is a model for what the function application will look like, so seeing the example data in the previous step helps you write this.

The body of the definition is written last. Having the header and the example data helps you write this.

Activity

(You will create 2 files for this lesson. P9A.scm, and P9B.scm)

This first activity is in the Scheme editor, but you won't write the whole program.

It is about how to read problem statements.

Open a new file. Call it P9A.scm.

Put a big comment, as if it was a program with your name, the date, and the title

Put all the fuscia-colored vocabulary items in the big comment as usual. If there are any that you can't understand from context, use the glossary, then ask your neighbor, and then if that doesn't help, ask your teacher.

"Examples of Purpose statements and Contracts" .

These are just practice writing purpose statments and contracts.

We will NOT write these 10 programs.

For each of the problem statements below, write the purpose statements and the contracts only.

Here are hints about reading problem statements .

Here are some hints about purpose statements and contracts.

1. Write a program which consumes two numbers and produces the larger of the two.
2. Write a program which consumes a temperature in Fahrenheit and produces the temperature in Celsius.
3. Write a program which consumes a number and performs a boolean test that tells if the number is even. (Remember how boolean tests are named? Do that.)
4. Write a program which finds the square of a number.
5. Write a program that finds the average of two numbers.
6. Write a program that finds the volume of a sphere given a certain radius.
7. Write a program that tells the interest payment, given the principal, the rate, and the number of years.
8. Write a program that produces the mass of a planet given the density and the diameter.
9. Write a program that does a boolean test and tests if a number is greater than pi.
10. Write a program that takes an integer and finds how many digits long it is.

The programming assignment.

Review design recipe #1.

Now make a new file named P9B.scm.

Make a big comment at the top with name, date, title, all the vocabulary words in today's lesson.

Write a program which consumes a temperature in Fahrenheit, and converts it to Centigrade. (Okay, so we are coding up one of 'em.)

I wonder where we can find the formula (expression) for this conversion. Hmmmmm...

Follow the design recipe completely, and do the steps in order.