When we design recursive functions, we don't think about the context of their use. Whether they are applied for the first time or whether they are called for the hundredth time in a recursive manner doesn't matter. They are to work according to their purpose statement, and that's all we need to know as we design the bodies of the functions.
Altough this principle of context-independence greatly facilitates the development of functions, it also causes occasional problems. In this section, we illustrate the most important problem with two examples. Both concern the loss of knowledge that occurs during a recursive evaluation. The first subsection shows how this loss makes a structurally recursive function more complicated and less efficient than necessary; the second one shows how the loss of knowledge causes a fatal flaw in an algorithm.
Suppose we are given the relative distances between a series of points, starting at the origin, and suppose we are to compute the absolute distances from the origin. For example, we might be given a line such as this:
Each number specifies the distance between two dots. What we need is the following picture, where each dot is annotated with the distance to the left-most dot:
Developing a program that performs this calculation is at this point an
exercise in structural function design. Figure 83
contains the complete Scheme program. When the given list is not
empty, the natural recursion computes the absolute distance of the
remainder of the dots to the first item on
(rest alon). Because
the first item is not the actual origin and has a distance of
(first alon) to the origin, we must add
(first alon) to
each and every item on the result of the recursive application. This second
step, adding a number to each item on a list of numbers, requires an
While the development of the program is straightforward, using it on larger and larger lists reveals a problem. Consider the evaluation of the following definition:64
(define x (relative-2-absolute (list 0 ... N)))
As we increase
N, the time needed grows even
Determine the abstract running time of
Hint: Evaluate the expression
(relative-2-absolute (list 0 ... N))
by hand. Start by replacing
N with 1, 2, and 3. How many natural
required each time?
Considering the simplicity of the problem, the amount of ``work'' that the two functions perform is surprising. If we were to convert the same list by hand, we would tally up the total distance and just add it to the relative distances as we take another step along the line.
Let's attempt to design a second version of the function that is closer to our hand method. The new function is still a list-processing function, so we start from the appropriate template:
(define (rel-2-abs alon) (cond [(empty? alon) ...] [else ... (first alon) ... (rel-2-abs (rest alon)) ...]))
Now imagine an ``evaluation'' of
(rel-2-abs (list 3 2 7)):
(rel-2-abs (list 3 2 7)) = (cons ... 3 ... (convert (list 2 7))) = (cons ... 3 ... (cons ... 2 ... (convert (list 7)))) = (cons ... 3 ... (cons ... 2 ... (cons ... 7 ... (convert empty))))
The first item of the result list should obviously be
3, and it is
easy to construct this list. But, the second one should be
2), yet the second instance of
rel-2-abs has no way of
``knowing'' that the first item of the original list is
3. The ``knowledge'' is lost.
Put differently, the problem is that recursive functions are independent of
their context. A function processes the list
L) in the exact same manner as
(cons K L). Indeed,
it would also process
L in that manner if it were given
by itself. While this property makes structurally recursive functions easy
to design, it also means that solutions are, on occasion, more complicated
than necessary, and this complication may affect the performance of the
To make up for the loss of ``knowledge,'' we equip the function with an
accu-dist. The new parameter represents
the accumulated distance, which is the tally that we keep when we convert a
list of relative distances to a list of absolute distances. Its initial
value must be
0. As the function processes the numbers on the list,
it must add them to the tally.
Here is the revised definition:
(define (rel-2-abs alon accu-dist) (cond [(empty? alon) empty] [else (cons (+ (first alon) accu-dist) (rel-2-abs (rest alon) (+ (first alon) accu-dist)))]))
The recursive application consumes the rest of the list and the new absolute distance of the current point to the origin. Although this means that two arguments are changing simultaneously, the change in the second one strictly depends on the first argument. The function is still a plain list-processing procedure.
Evaluating our running example with
rel-2-abs shows how much the
use of an accumulator simplifies the conversion process:
= (rel-2-abs (list 3 2 7) 0) = (cons 3 (rel-2-abs (list 2 7) 3)) = (cons 3 (cons 5 (rel-2-abs (list 7) 5))) = (cons 3 (cons 5 (cons 12 (rel-2-abs empty 12)))) = (cons 3 (cons 5 (cons 12 empty)))
Each item in the list is processed once. When
the end of the argument list, the result is completely determined and no
further work is needed. In general, the function performs on the order of
N natural recursion steps for a list with N items.
One minor problem with the new definition is that the function consumes two
arguments and is thus not equivalent to
function of one argument. Worse, someone might accidentally misuse
rel-2-abs by applying it to a list of numbers and a number that
0. We can solve both problems with a function definition
rel-2-abs in a
local definition: see
relative-2-absolute2 are indistinguishable.
Let us revisit the problem of finding a path in a graph from
section 28. Recall that we are given a collection of nodes
and connections between nodes, and that we need to determine whether there
is a route from a node labeled
orig to one called
dest. Here we study the slightly simpler version of the problem of
where each node has exactly one (one-directional)
connection to another node.
Consider the example in figure 85. There are six nodes: A through F, and six connections. To get from A to E, we go through B, C, and E. It is impossible, though, to reach F from A or from any other node (besides F itself).
The right part of figure 85 contains a Scheme definition that represents the graph. Each node is represented by a list of two symbols. The first symbol is the label of the node; the second one is the reachable node. Here are the relevant data definitions:
A node is a symbol.
A pair is a list of two
(cons S (cons T empty))
A simple-graph is a list of
They are straightforward translations of our informal descriptions.
Finding a route in a graph is a problem of generative recursion.
We have data definitions, we have (informal) examples, and the header material is standard:
route-exists? : node node simple-graph -> boolean;; to determine whether there is a route from
sg(define (route-exists? orig dest sg) ...)
What we need are answers to the four basic questions of the recipe for generative recursion:
destare the same.
origis not the same as
dest, there is only one thing we can do, namely, go to the node to which
origis connected and determine whether a route exists between it and
orig's neighbor is connected to
dest, then so is
From here we just need to express these answers in Scheme, and we get an algorithm. Figure 86 contains the complete function, including a function for looking up the neighbor of a node in a simple graph.
Even a casual look at the function suggests that we have a
problem. Although the function is supposed to produce
false if there
is no route from
dest, the function definition
false anywhere. Conversely, we need to ask what the
function actually does when there is no route between two nodes.
Take another look at figure 85. In this simple graph there
is no route from C to D. The connection that leaves C
passes right by D and instead goes to E. So let's look at how
route-exists? deals with the inputs
(route-exists? 'C 'D '((A B) (B C) (C E) (D E) (E B) (F F))) = (route-exists? 'E 'D '((A B) (B C) (C E) (D E) (E B) (F F))) = (route-exists? 'B 'D '((A B) (B C) (C E) (D E) (E B) (F F))) = (route-exists? 'C 'D '((A B) (B C) (C E) (D E) (E B) (F F)))
The hand-evaluation confirms that as the function recurs, it calls itself with the exact same arguments again and again. In other words, the evaluation never stops.
Our problem with
route-exists? is again a loss of ``knowledge,''
similar to that of
relative-2-absolute in the preceding section.
route-exists? was developed
according to the recipe and is independent of its context. That is, it
doesn't ``know'' whether some application is the first or the hundredth of
a recursive chain. In the case of
route-exists? this means, in
particular, that the function doesn't ``know'' whether a previous
application in the current chain of recursions received the exact same
The solution follows the pattern of the preceding section. We add a
parameter, which we call
accu-seen and which represents the
accumulated list of origination nodes that the function has encountered,
starting with the original application. Its initial value must be
empty. As the function checks on a specific
moves to its neighbors,
orig is added to
Here is a first revision of
route-exists-accu? : node node simple-graph (listof node) -> boolean;; to determine whether there is a route from
sg, ;; assuming the nodes in
accu-seenhave already been inspected ;; and failed to deliver a solution (define (route-exists-accu? orig dest sg accu-seen) (cond [(symbol=? orig dest) true] [else (route-exists-accu? (neighbor orig sg) dest sg (cons orig accu-seen))]))
The addition of the new parameter alone does not solve our problem, but, as the following hand-evaluation shows, provides the foundation for one:
(route-exists-accu? 'C 'D '((A B) (B C) (C E) (D E) (E B) (F F)) empty) = (route-exists-accu? 'E 'D '((A B) (B C) (C E) (D E) (E B) (F F)) '(C)) = (route-exists-accu? 'B 'D '((A B) (B C) (C E) (D E) (E B) (F F)) '(E C)) = (route-exists-accu? 'C 'D '((A B) (B C) (C E) (D E) (E B) (F F)) '(B E C))
In contrast to the original function, the revised function no longer calls
itself with the exact same arguments. While the three arguments proper are
again the same for the third recursive application, the accumulator
argument is different from that of the first application. Instead of
empty, it is now
'(B E C). The new value represents the
fact that during the search of a route from
function has inspected
'C as starting
All we need to do at this point is exploit the accumulated knowledge in
the function definition. Specifically, we determine whether the given
orig is already an item on
accu-seen. If so, the problem
is trivially solvable with
false. Figure 87
contains the definition of
route-exists2?, which is the revision
route-exists?. The definition refers to
first recursive function (see part II), which determines
whether a specific symbol is on a list of symbols.
The definition of
route-exists2? also eliminates the two minor
problems with the first revision. By
localizing the definition of
the accumulating function, we can ensure that the first call to
re-accu? always uses
empty as the initial value for
route-exists2? satisfies the exact same
contract and purpose statement as
Still, there is a significant difference between
relative-to-absolute2. Whereas the latter was equivalent to
the original function,
route-exists2? is an improvement over the
route-exists? function. After all, it corrects a fundamental flaw
route-exists?, which completely failed to find an answer for
Exercise 30.2.1. Complete the definition in figure 87 and test it with the running example. Use the strategy of section 17.8 to formulate the tests as boolean-valued expressions.
Check with a hand-evaluation that this function computes the proper result
Exercise 30.2.2. Edit the function in figure 87 so that the locally defined function consumes only those arguments that change during an evaluation. Solution
Exercise 30.2.3. Develop a vector-based representation of simple graphs. Adapt the function in figure 87 so that it works on a vector-based representation of simple graphs. Solution
Modify the definitions of
in figure 77 so that they produce
if they encounter the same starting point
64 The most convenient way to construct this
list is to evaluate
(build-list (add1 N) identity).
65 The time of evaluation will differ from computer to computer. These measurements were conducted on a Pentium 166Mhz running Linux. Measuring timings is also difficult. At a minimum, each evaluation should be repeated several times, and the time reported should be the average of those measurements.