Recursion
starts at Bailey page 94
We saw a recursive version of the gcd(m,n) function earlier.
private static int rgcd(int a, int b) {
if (a<0) return gcd(a, b);
if (a==0) {
if (b==0) return 1;
return b;
}
if (b<a) return rgcd(b,a%b);
return rgcd(b%a, a);
}
How about the following recursive version of factorial(n)?
int factorial(int
n) {
if (n==0) return 1;
return n*factorial(n1);
}
See factorial.cs
(Bailey uses a recursive function sum3, p 95, to add the numbers 1..n
instead of multiply them)
Note this mirrors the following definition
of n!:
0! = 1
n! = n*(n1)! for n>0
Demo: factorial(10),
factorial(11) = 39916800
factorial(12) = 479001600
factorial(13) = 1932053504
factorial(14) = 1278945280
factorial(15) = 2004310016
factorial(16) = 2004189184
factorial(17) = 288522240
For that matter, try factorial(34).
What is wrong? Which of these are correct?
We can do a little better by replacing int with long
(including as the type of retval). Then we see factorial(17) =
355687428096000, and factorial(13) = 6227020800.
Then there is factorial(1). What goes wrong here? factorial2() is an
attempted fix, in that it may be important to make sure library methods
never involve infinite looping, but there is only so much that can be done
to deal with library users who do not follow the preconditions.
Stacktrace demo from Console.WriteLine(factorial3(4));
public static long factorial3(int N) {
Console.WriteLine("factorial3 called with N={0}", N);
long retval;
if (N==0) retval = 1;
else {
/*A*/ long fact = factorial3(N1);
retval = N * fact;
}
Console.WriteLine("factorial3({0}) returns {1}", N, retval);
return retval;
}
Calling fact(4) basically amounts to the following:
push(4)
push(3)
push(2)
push(1)
prod = 1;
prod *= pop()
prod *= pop()
prod *= pop()
prod *= pop()
return prod
Stack frames for the above:
N = 4
retval=
return to: WriteLine 
N = 3
retval=
return to /*A*/ 
N = 2
retval=
return to /*A*/ 
N = 1
retval=
return to /*A*/ 
N = 0
retval=1
Atomic case 
This is indeed a stack of "frames": at any one moment,
only the topmost frame is accessible (where the top is at the bottom here).
On return, we pop() the
topmost frame, exposing the one below.
The pattern above works for any recursive function of the form
f(n) = A if n=0; = F(n,f(n1)) otherwise
In this case, f(4) becomes
push(4)
push(3)
push(2)
push(1)
res = A;
res = F(pop(), res)
res = F(pop(), res)
res = F(pop(), res)
res = F(pop(), res)
return res
factorial tailrecursion
Tailrecusion means that, in the recursive case, it is the recursive value
that is returned directly, with no further work done to it. Such recursion
can be converted mechanically to an iterative form.
Here is a tailrecursive version of factorial. tr_factorial(n, prod) returns
n!*prod. Therefore, tr_factorial(n,1) returns n!:
public static long tr_factorial(int n, long
prod) {
if (n==0) return prod;
return tr_factorial(n1, n*prod);
}
That second parameter, prod, acts as "scratch paper". Note
that when the recursive call returns, its value is itself returned, with
absolutely no further multiplication.
Every recursive function has a base case,
or atomic case, that does not lead to further recursion.
Empty base case
example: printing a vector, Bailey p 97.
Fibonacci problem
The fibonacci numbers follow the rule F_{n} = F_{n1} + F_{n2},
for n>2; F_{0} = F_{1} = 1.
The recursive version is in fibonacci.cs.
Note what happens with fibonacci(45). It takes about 13 seconds! Why so
slow? The result here is 1836311903, which is correct.
Problem: each call results in two recursive subcalls.
But this happens with recursive mergesort, too! Except in that case the two
subcalls are each half the size. Here, for N not close to 1, the recursive
subcalls are more comparably sized.
Trace demo: fibonacci3(8)
The number of subcalls for fib(n), in fact, is O(phi^{N}), where phi
= (sqrt(5)+1)/2 (demo with callcount).
(It turns out that the number of subcalls, NC(n), follows the same rule as
fib(n):
fib(n) = fib(n1) + fib(n2)
NC(n) = NC(n1) + NC(n2)
)
How do we fix this? fibonacci2(91) (what happens at fibonacci2(92?)
Mathematical Induction
The principle of mathematical induction is closely related to recursion. In
recursion, we use F(n1) to calculate F(n). In induction, we prove statement
P(n) using statement P(n1) as a hypothesis.
Suppose we want to prove 1+2+...+n = n*(n+1)/2 = P(n).
Or 1^{2} + 2^{2} + 3^{2} + ... + n^{2} =
n*(n+1)*(2n+1)/6 = Q(n) = n^{3}/3 + n^{2}/2 + n/6.
(P(n) and Q(n) are defined to be shorthands for the righthand sides here)
Step 1: verify for n=0, or n=1.
Step 2: assuming the claim for n,
prove it for n+1. That is, assuming
1^{2} + 2^{2} + 3^{2} + ... + n^{2}
= Q(n), CLAIM(n)
prove
1^{2} + 2^{2} + 3^{2} + ... + n^{2}
+ (n+1)^{2} = Q(n+1). CLAIM(n+1)
If we start from our CLAIM(n) and
add (n+1)^{2} to both sides, we get
1^{2} + 2^{2} + 3^{2} + ... + n^{2}
+ (n+1)^{2} = Q(n)+n^{2}+2n+1.
Similarly, Q(n+1) = (n+1)^{3}/3 + (n+1)^{2}/2 + n+1 = (n^{3}/3 + n^{2} + n + 1/3) + (n^{2}/2
+ n + 1/2) + n/6 + 1/6
= n^{3}/3
+ n^{2}/2 + n/6
+ n^{2} + 2n + 1 = Q(n)+n^{2}+2n+1.
Question: where did this formula come
from? The 1+2+3+...+n formula at least has a natural derivation: add it to
itself in reverse order, and you have n columns where each column adds up to
n+1. The doubled total is thus n*(n+1), and the original sum is thus P(n)
above.
Induction is tricky: note exactly where we assume
the nstage hypothesis at the start.
Postagestamp problem, p 98
Suppose you want change in stamps, either 44 cents or 28 cents or 1 cent.
For a given amount, what is the fewest
number of stamps you can receive as change?
Note that the obvious approach of getting as many 44's as possible, then as
many 28's as possible, etc, is not optimal
in
all (or even very many) cases. For example, if you need 60 cents back, that
is either 1 44cent stamp and 16 1cent stamps (total of 17) or two 28's and
four 1's (total of 6).
Strategy: if we have N cents to make change for, then the optimum is one of
the following:
 optimum for N44, plus one additional 44cent stamp
 optimum for N28, plus one additional 28cent stamp
 optimum for N1, plus one additional 1cent stamp
So we calculate stampCount(N44), stampCount(N28), and stampCount(N1),
take the minimum, and add one more stamp (which stamp depends on
which subproblem was the minimum).
simple recursive version: each call
generates three subcalls
efficient version: creating an array of all values so far: an answer
cache, Bailey p 99
Some sample results from first, inefficient,
version:
stampCount(200) = 6: 404061476
calls, 1811 ms
stampCount(201) = 7: 443663991 calls, 1976 ms
stampCount(202) = 8: 487148470 calls, 2196 ms
stampCount(204) = 5: 587322736 calls, 2614 ms
stampCount(206) = 7: 708097261 calls, 3189 ms
stampCount(208) = 9: 853706337 calls, 3856 ms
stampCount(210) = 11: 1029255633 calls, 4699 ms
Note the time/space tradeoff, rather decidedly in favor of less time. The
answers are small, but it takes a long time to get there!
Which version is this?
stampCount(1000) = 26: 2931 calls, 0 ms.
My source code is in stampchange.cs.
Expressions
Expressions involving unary and binary operators can be expressed neatly as
trees:
2*(3+5)
*
/ \
2 +
/ \
3 5
This is a binary tree. Expressions like 2+3+5 can always be made binary with appropriate grouping: (2+3)+5. Sometimes, however, it's convenient to think of this as a multiway tree. Here's such a tree for 2*(3+5+7):
expr
/  \
2 * expr

┌──┬──┼──┬──┐
    
3 + 5 + 7
For the moment, let's treat these kinds of trees just as notation, and not worry about how
we'd actually implement then.
In the binary case, a leaf node holds just a numeric value. A nonleaf node holds an operator,
and two subtrees representing the left and right operands. In the multiway case, a node contains a list of alternating values and operands, with an operand between each pair of consecutive values. Values are either numbers or subtrees (corresponding to subexpressions).
These are recursive definitions of trees. So far we
are not defining this as an actual C# data structure.
expr_eval
Let us write a program to evaluate integer expressions.
Expressions consist of punctuation and numbers; collectively these are
called tokens and will be implemented as strings.
The first step is the Tokenizer class, which in this case takes a oneline
string and returns the tokens after skipping over any whitespace characters.
When the end of the line is reached, null is returned (this turns out to be
a little awkward, because if tok is null, then a call like tok.Equals("+")
is illegal). The Tokenizer class contains a method
public static bool isNumber(string t)
It should conceptually be static, but it's only used in reference to the
existing tokenizer and so this doesn't matter. The Tokenizer object in the
main program will be called t, so t.token() returns the next token. It's
easier to write t.isNumber(s) than Tokenizer.isNumber(s).
The syntax for expressions will be defined by the following grammar,
in which '::=' separates the item defined from its definition, '' separates
alternatives and '{' and '}' enclose parts that can be repeated 0 or more
times:
expr ::= term { addop term }
term ::= factor { mulop factor }
factor ::= number  '(' expr ')'
addop ::= '+'  ''
mulop ::= '*'  '/'  '%'
This is socalled "extended BackusNaur form", or EBNF, where the "extended" refers to the introduction of { } as a repetition mechanism and [ ] as an option mechanism. A slightly more natural grammar is below (in "plain" BackusNaur form), but it makes it harder to tell
what is going on by looking only at the very first token:
expr ::= term  term addop expr
term ::= factor  factor mulop term
factor ::= number  '(' expr ')'
Demo: building parse trees for 2*(3+5).
The EBNF grammar, with the { }, is better suited to use with the multiway trees earlier. Alternatively, we can make all the operators binary by enforcing a rule for grouping, though this gets more complicated than we'd like.
The assumption in parsing is that the next token is always available in
variable theToken; this is known as onesymbol
lookahead. The points where the parser must make a decision
are (for the first grammar):
 expr: deciding whether there is another occurrence of "addop term"
 term: deciding whether there is another occurrence of "mulop factor"
 factor: deciding between the two alternatives
In each case, we can make the decision based only on theToken:
in the first case, if theToken is an addition operator,
we parse "addop term"; the second case is similar except with
multiplication operators. In the third case, we decide based on whether
the token is a number or the '(' string; anything else is an error.
When parsing something that represents a concrete token, eg number
or ), we simply call theToken = t.token(). When we know
exactly what token we are looking for, it is handy to use accept(tok),
which if the current token matches tok advances to the next token, but
otherwise calls an error.
The actual parsing is done by one method corresponding to each grammar
symbol above: exprEval(), termEval() and factorEval(). The idea is that
any grammar symbol on the right side of ::= is replaced with a call to its
method; anything enclosed in { and } is replaced with a while loop that
runs so long as theToken is a legitimate first symbol of
whatever is in the { and }. For the first grammar rule, this is the set of
addition operators. In brief outline, exprEval does this:
termEval()
while (theToken in addops) {
accept(addop);
// not literally right
termEval()
}
Now let's look at the actual code for each one.
The Point: this would be exceedingly difficult to write
without using recursion!
Syntax errors
What if there is a syntax error? We will throw an exception:
SyntaxException. Note:
 Definition of class SyntaxException
 trycatch clause in Main()
 throw in accept() and in factorEval()
We also catch the predeclared exception
System.DivideByZeroException.
There are several advantages to throwing exceptions rather than using
Boolean flags or other parameters to carry error information. Mainly, the
code is simpler.
The source code is in oneline_tokenizer.cs
and expr_eval.cs.
expr_assign
Now let's extend this to allowing variables in factors, which are set with
stmt ::= 'set' ident '=' expr  expr
That is, a line can be either
set foo = 3+2*6
or
foo+1
So stmtEval() can either return a value (the second case) or not (the
first). We have it return something of type int?, which is
an object that is basically an int but which can also be null. Look at the
code to see how this works. Such types are sometimes called Nullable.
Without the set keyword, parsing lines like
these is much more difficult; we have to look ahead to see if the second
token is "=" or not. This is trickier than one might think.
This code is in oneline_tokenizer.cs
and expr_assign.cs.
The next step is the miniJava compiler. See compiler.html.
Virtual machine, stack architecture
minijava syntax
Extended Backus Normal Form (EBNF)
EBNF => recursivedescent parser code
accept()
global variables
local variables (including in main())
expressions
scope
symbol tables
CompileExprN
commonsubexpression handling