Menu

- Chapter 1 Distilled
- Introduction
- 1.1 - The Elements Of Programming
- Expressions
- Naming and the Environment
- Evaluating Combinations
- Defining New Functions
- The Substitution Model
- Exercises
- Predicates
- Conditional Expressions
- Example: Newton’s Method
- Functions as Black-Box Abstractions
- 1.2 - Procedures and the Processes They Generate
- Linear Recursion and Iteration
- Tree Recursion
- Orders of Growth
- Exponentiation
- Example: Testing For Primality
- 1.3 Higher Order Functions
- Project - Blackjack

- Chapter 2 Distilled
- Introduction
- Data Abstraction
- Everything From Nothing
- Abstractions In Clojure
- Clojure's Data Structures
- Data Abstraction, Revisited
- Escher
- Project - Escher
- Symbolic Data
- Representing Sets
- Huffman Encoding Trees
- Zippers

Functions, as introduced above, are much like ordinary mathematical functions. They specify a value that is determined by one or more parameters. But there is an important difference between mathematical functions and computer functions. In programming, functions must be effective.

As a case in point, consider the problem of computing square roots. We can define the square-root function as

$$ \sqrt{x} = \text{the } y \text{ such that } y \ge 0 \text{ and } y^2 = x $$

This describes a perfectly legitimate mathematical function. We could use it to recognize whether one number is the square root of another, or to derive facts about square roots in general. On the other hand, the definition does not describe a procedure. Indeed, it tells us almost nothing about how to actually find the square root of a given number.

It will not help matters to rephrase this definition in pseudo-Lisp:

```
(defn sqrt [x]
(the y (and (>= y 0)
(= (square y) x))))
```

This contrast with mathematical functions is a reflection of the
general distinction between describing properties of things and
describing how to do things, or, as it is sometimes referred to, the
distinction between *declarative* (*what is*) and *imperative* (*how
to*) knowledge. In mathematics we are usually concerned with
declarative or descriptions, whereas in computer science we are
usually concerned with imperative descriptions.

How does one compute square roots? The most common way is to use Newton’s method of successive approximations, which says that whenever we have a guess $y$ for the value of the square root of a number $x$ , we can perform a simple manipulation to get a better guess (one closer to the actual square root) by averaging $y$ with $ \frac{x}{y} $

For example, we can compute the square root of 2 as follows. Suppose our initial guess is 1:

```
| Guess | Quotient | Average |
|-------|-----------------------|---------|
| 1 | (/ 2 1) = 2 | 1.5 |
| 1.5 | (/ 2 1.5) = 1.33 | 1.4167 |
| 1.4167| (/ 2 1.4167) = 1.4118 | 1.4142 |
| 1.4142| ... | ... |
```

Continuing this process, we obtain better and better approximations to the square root.

Now let’s formalize the process as Clojure code. We start with a value for the radicand (the number whose square root we are trying to compute) and a value for the guess. If the guess is good enough for our purposes, we are done; if not, we must repeat the process with an improved guess. We write this basic strategy as a function:

```
(defn sqrt-iter [guess x]
(if (good-enough? guess x)
guess
(sqrt-iter (improve guess x) x)))
```

A guess is improved by averaging it with the quotient of the radicand and the old guess:

```
(defn improve [guess x]
(average guess (/ x guess)))
(defn average [x y]
(/ (+ x y) 2))
```

We also have to say what we mean by “good enough.” The following will do for illustration, but it is not really a very good test. The idea is to improve the answer until it is close enough so that its square differs from the radicand by less than a predetermined tolerance (here 0.001)

```
(defn good-enough? [guess x]
(< (abs (- (square guess) x)) 0.001))
```

```
(defn abs [n]
(max n (- n)))
```

Finally, we need a way to get started. For instance, we can always guess that the square root of any number is 1

```
(defn sqrt [x]
(sqrt-iter 1.0 x))
```

If we type these definitions to the interpreter, we can use sqrt just as we can use any function:

```
> (sqrt 9)
3.00009155413138
> (sqrt (+ 100 37))
11.704699917758145
> (sqrt (+ (sqrt 2) (sqrt 3)))
1.7739279023207892
> (square (sqrt 1000))
1000.000369924366
```

The sqrt `program`

also illustrates that the simple procedural
language we have introduced so far is sufficient for writing any
purely numerical program that one could write in, say, C or
Pascal. This might seem surprising, since we have not included in our
language any iterative (looping) constructs that direct the computer
to do something over and over again.

`sqrt-iter`

, on the other hand, demonstrates how iteration can be
accomplished using no special construct other than the ordinary
ability to call a function.

Readers who are worried about the efficiency issues involved in using function calls to implement iteration should note the remarks on “tail recursion” later.

Alyssa P. Hacker doesn’t see why if needs to be provided as a special form. “Why can’t I just define it as an ordinary function in terms of cond ?” she asks. Alyssa’s friend Eva Lu Ator claims this can indeed be done, and she defines a new version of if :

```
(defn new-if [predicate then-clause else-clause]
(cond predicate then-clause
:else else-clause))
```

Eva demonstrates the program for Alyssa:

```
> (new-if (= 2 3) 0 5)
5
> (new-if (= 1 1) 0 5)
0
```

Delighted, Alyssa uses new-if to rewrite the squareroot program:

```
(defn sqrt-iter [guess x]
(new-if (good-enough? guess x)
guess
(recur (improve guess x) x)))
```

What happens when Alyssa attempts to use this to compute square roots? Explain.

The `good-enough?`

test used in computing square roots will not be
very effective for finding the square roots of very small
numbers. Also, in real computers, arithmetic operations are almost
always performed with limited precision. This makes our test
inadequate for very large numbers. Explain these statements, with
examples showing how the test fails for small and large numbers. An
alternative strategy for implementing `good-enough?`

is to watch how
guess changes from one iteration to the next and to stop when the
change is a very small fraction of the guess.

Design a square-root function that uses this kind of end test.

Does this work better for small and large numbers?