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(n-1);
    }

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*(n-1)! 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.

Stack-trace 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(N-1);
            retval = N * fact;
        }
        Console.WriteLine("factorial3({0}) returns {1}", N, retval);
        return retval;
    }

factorial tail-recursion

Mathematical Induction

Postage-stamp problem, p 98

• optimum for N-44, plus one additional 44-cent stamp
• optimum for N-28, plus one additional 28-cent stamp
• optimum for N-1, plus one additional 1-cent stamp

Expressions

         *
       /   \
      2     +
          /   \
         3     5

         expr
       /  |  \
      2   *  expr   
               |
         ┌──┬──┼──┬──┐
         |  |  |  |  |
         3  +  5  +  7

expr_eval

• 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
• try-catch clause in Main()
• throw in accept() and in factorEval()

We also catch the pre-declared 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