\documentstyle[cprog]{simslide}
\uppercorners{Data Structures in C++}{\thepage}
\lowercorners{Algorithms Descriptions of Behavior}{Chapter 3}
\begin{document}

\slide{}

{\Huge \bf
\begin{center}
$\;$ \\ $\;$ \\
Data Structures \\
in C++ \\ $\;$ \\
Chapter 3 \\ $\;$ \\
Tim Budd \\ $\;$ \\
Oregon State University \\
Corvallis, Oregon \\
USA \\
\end{center}
}

\slide{Outline -- Chapter 3}

{\bf Analytical Tools}

\begin{itemize}
\item
Introduction to Algorithms
\item
Recipes as Algorithms
\item
Analyzing Computer Algorithms
\item
Specification of Input
\item
Describing Result
\item
Proving Termination
\end{itemize}

\slide{Algorithms}

An {\em algorithm} is a set of instructions used to solve a specific
problem.

Synonyms 

\begin{itemize}
\item
{\em process} 
\item
{\em method} 
\item
{\em technique} 
\item
{\em procedure} 
\item
{\em routine} 
\item
{\em recipe}
\end{itemize}

\slide{Properties of Algorithms}

In order to be useful, an algorithm must have the following properties.

\begin{itemize}
\item
{\bf accurate specification of the input}.  

Under what conditions is the algorithm expected to give the correct
answers.
\item
{\bf definiteness of each instruction}

Each instruction must be clear and unambiguous.

\item
{\bf correctness}.

The algorithm must correctly solve a problem.

\item
{\bf termination}

The algorithm must eventually halt for all legal input values.

\item
{\bf description of the result or effect}

It must be clear what the algorithm is intended to do.
\end{itemize}

\slide{Recipes as Algorithms}

Probably the most common form of algorithm is the recipe.

\begin{center}
{\Large \bf Lemon Souffl\'e }
\end{center}
\begin{verse}
1 envelope unflavored gelatin \\
$\frac{1}{4}$ Cup cold water \\
6 Egg yolks \\
1 Cup sugar \\
$\frac{2}{3}$ Cup Lemon juice \\
1 Tablespoon grated Lemon rind \\
4 Egg whites \\
$1\frac{1}{2}$ Cup heavy cream \\
\end{verse}
\begin{enumerate}
\item
Soften the gelatin in water.  Beat egg yokes and sugar until thick and
light.  Stir in lemon juice and cook over low heat, beating steadily with a
wisk until thickened and hot but not boiling (10-15 minutes).
\item
Pour mixture into large bowl, mix in gelatin until dissolved then add lemon
rind.  Stir occasionally until cool.
\item
Beat egg whites until stiff but not dry.  Fold into lemon mixture, then
whip the cream and fold in.  Pour into a two-quart souffl\'e dish (or large
bowl) and refrigerate at least 12 hours.
\end{enumerate}

\slide{Evaluation of Recipe as Algorithm}

\begin{itemize}
\item
{\bf input}.

Ingredients are listed.

\item
{\bf result}.

Indicated by the name.

\item
{\bf correctness}.

The proof of the pudding is in the eating.

\item
{\bf termination}.

What if it never boils?  or never becomes light?

\item
{\bf definiteness}.

What is ``light''?   How long should it be whipped?
\end{itemize}

\slide{Computer Algorithms}

How do computer algorithms differ from instructions for human beings
with regards to
\begin{itemize}
\item
description of input
\item
specification of result
\item
time to execute (some here, more in Chapter 4)
\item
correctness (more in Chapter 5)
\item
instruction precision
\end{itemize}

\slide{Specification of Input}

Two most widely used techniques
\begin{itemize}
\item
Type declarations for argument values
\item
comments associated with procedure heading
\end{itemize}

\begin{cprog}

int min (int a, int b)
	// return smaller of two integer arguments
{
	int smallest;

	if (a < b)
		smallest = a;
	else
		smallest = b;
	return smallest;
}

\end{cprog}

\slide{Conditions that are not types}

Occasionally input conditions are not types, but can nevertheless be checked
at run-time, using an {\tt assert} statement.

\begin{cprog}

char digitChar (unsigned int val)
	// return the character equivalent for
	// the integer argument value
	// which must be between zero and nine
{
		// make sure value is in proper range
	assert (val < 10);

	switch (val) {
		case 0: return '0';
		case 1: return '1';
			...
		case 9: return '9';
		}
}
\end{cprog}

\slide{Simpler Version}

By noting some characteristics of ASCII and the fact that characters are
just small integers, we can simplify to the following:

\begin{cprog}


char digitChar (unsigned int val)
	// return the character equivalent for
	// the integer argument value
	// which must be between zero and nine
{
	assert (val < 10);
	return '0' + val;
}

\end{cprog}

\slide{Some input conditions cannot be checked}

Some input conditions cannot be checked, even with assert.

\begin{cprog}

double power (double base, unsigned int n)
	// return the value yielded by
	// raising the double precision base to
	// the integer exponent
	// assumes floating point 
	// overflow does not occur
{
		// initial result to base raised to zero
	double result = 1.0;

		// raise base to new powers 
	for (unsigned int i = 0; i < n; i++) {
		result *= base;
		}
	return result;
}
\end{cprog}

\slide{Describing the Result}

Similarly, the result of executing an algorithm is often provided 
\begin{itemize}
\item
by the return type of a function
\item
by comments
\end{itemize}

\begin{cprog}

int min (int a, int b)
	// return the smaller of two arguments
{
	...
}

\end{cprog}

\slide{Side Effects}

Sometimes algorithms are not executed for their result, but for
a {\em side effect}.  Common side effects:

\begin{itemize}
\item
Printing a result
\item
Setting or modifying a value in a variable (global variable, instance 
variable)
\item
Copying information to a file
\item
Many others
\end{itemize}

These should always be documented in a comment, since they are not 
immediately obvious.

\slide{Printing Integers}

Problem - print a positive integer value on the output stream.

General problem solving techniques
\begin{itemize}
\item
Reduce task to a sequence of steps (we saw this in the Lemon Souffl\'e
recipe), or
\item
Reduce a task by considering various cases
\end{itemize}

Can write a recursive procedure to handle this.

\slide{Printing Integer Code}

\begin{cprog}

void printUnsigned (unsigned int val)
	// print the character representation of
	// the unsigned argument value
{
	if (val < 10)
		printChar (digitChar(val));
	else {
			// print high order part
		printUnsigned (val / 10);
			// print last character
		printChar (digitChar(val % 10));
		}
}

\end{cprog}

It is relatively easy to see the input conditions, the fact that the
algorithm is definite.  What remains is showing termination, correctness,
and execution time.

\slide{General Picture}

The following illustrates the steps involved in printing the integer value
456.

\setlength{\unitlength}{7mm}
\begin{center}
\begin{picture}(12,7)
\put(4,4){\makebox(1,1){\tt print 456}}
\put(4.5,4){\vector(0,-1){1}}
\put(4,2){\makebox(1,1){\tt print 45, then print 6}}
\put(1.5,2){\vector(0,-1){1}}
\put(4,0){\makebox(1,1){\tt print 4, then print 5}}
\put(9,0.5){\vector(1,0){1}}
\put(11,0){\makebox(1,1){\tt 4}}
\put(11.5,1){\vector(0,1){1}}
\put(11,2){\makebox(1,1){\tt 45}}
\put(11.5,3){\vector(0,1){1}}
\put(11,4){\makebox(1,1){\tt 456}}
\end{picture}
\end{center}


\slide{Allocating space for Parameters}

When pass by value is used as a parameter passing mechanism, each
new recursive call gets a {\em different} copy of each parameter value and
each local variables.  

The sequence of function returns is the inverse of the sequence of function
calls.  Each invocation uses its own values.

\slide{Instruction Precision}

Note difference in level of precision required for instructions to be given
to a human being and instructions to be given to a computer:

``go to the store and buy me something to make lunch''

For a human, emphasis on the objective (the what), for a computer,
emphasis on the process (the how).  Must be specified in great detail.

\slide{Time to Execute}

We will divide the discussion of 
analyzing execution time into two parts:

\begin{itemize}
\item
Proving termination at all
\item
Characterizing running time (more in next chapter).
\end{itemize}

\slide{Proving Termination}

In order to prove termination, find a property or value that possesses the
following three characteristics:

\begin{itemize}
\item
Can be placed in one-to-one correspondence with the integers.

\item
Is non-negative.

\item
Decreases as the algorithm executes.
\end{itemize}

Note we need all three characteristics.

\slide{Loops are usually easy}

\begin{cprog}

double power (double base, unsigned int n)
	// return the value yielded by
	// raising the double precision base to
	// the integer exponent
	// assumes floating point 
	// overflow does not occur
{
		// initial result to base raised to zero
	double result = 1.0;

		// raise base to new powers 
	for (unsigned int i = 0; i < n; i++) {
		result *= base;
		}

	return result;
}

\end{cprog}

We can consider the quantity $n-i$, which decreases as $i$ increases.


\slide{The value need not be in the algorithm}

What value can we use to prove the termination of the following:

\begin{cprog}

unsigned int gcd (unsigned int n, unsigned int m)
	// compute the greatest common divisor
	// of two positive integer values
{
	assert (n > 0 && m > 0);

	while (m != n) {
		if (n > m)
			n = n - m;
		else
			m = m - n;
		}
	return n;
}
	
\end{cprog}

\slide{Proving Termination of Recursive Algorithms}

If each step of the recursive algorithm can be proved to terminate,
the proving termination of the entire procedure involves bounding
the number of recursive calls.

In the case of the integer printing algorithm, we note that the
magnitude of the number is reduced on
each step.  Note that the number of recursive calls is equal to the
number of digits of the original value.

\slide{Space Utilization}

Sometimes two or more algorithms differ in the amount of space
(that is, memory) they use.  For example, some sorting algorithms
copy values into a new data structure, then copy them back.
Others work ``in place'' and thus use far less memory.

Sometimes improvements in speed can come at a cost of more
space.  This is termed a time/space tradeoff.  We will
see examples of this later.

\slide{Recursive Algorithms}

A procedure that invokes itself is termed recursive.

Recursive algorithms must always have

\begin{itemize}
\item
A base case, that handles at least one condition without recursion
\item
An inductive case, that ``reduces'' a problem to another problem
of the {\em same form} but {\em smaller} inputs.
\end{itemize}

Difficulty is finding out how to do the reduction.

Sometimes it helps to imagine you have solved the problem a certain
distance, and you are in the middle of execution.

\slide{Towers of Hanoi puzzle}

\setlength{\unitlength}{4mm}
\begin{center}
\begin{picture}(30,8)
\put(0,0){\framebox(8,1){}}
\put(1,1){\framebox(6,1){}}
\put(2,2){\framebox(4,1){}}
\put(3,3){\framebox(2,1){}}
\put(3.7,4){\framebox(0.6,2){}}
\put(3.5,6.2){\makebox(1,1){\sf A}}
\put(13.7,0){\framebox(0.6,6){}}
\put(13.5,6.2){\makebox(1,1){\sf B}}
\put(23.7,0){\framebox(0.6,6){}}
\put(23.5,6.2){\makebox(1,1){\sf C}}
\end{picture}
\end{center}

Only two possible first steps, but which one is the correct one
to use?

\slide{Approaches to Problem Solving we have Seen}

We have seen the following approaches to problem solving:

\begin{itemize}
\item
Determine the first step, then go on.
(Stepwise refinement.  Produces a series of {\em sequential} steps.)
\item
Break down into cases.  Handle each separately (Produces a {\em conditional} statement).
\end{itemize}

Neither seem applicable here.  How about starting in the middle,
and working both forwards and backwards.

\slide{Imagine You have Solved Problem a Bit Already}

Imagine you are in the middle of execution:

\setlength{\unitlength}{4mm}
\begin{center}
\begin{picture}(30,8)
\put(0,0){\framebox(8,1){}}
\put(21,0){\framebox(6,1){}}
\put(22,1){\framebox(4,1){}}
\put(23,2){\framebox(2,1){}}
\put(3.7,1){\framebox(0.6,5){}}
\put(3.5,6.2){\makebox(1,1){\sf A}}
\put(13.7,0){\framebox(0.6,6){}}
\put(13.5,6.2){\makebox(1,1){\sf B}}
\put(23.7,3){\framebox(0.6,3){}}
\put(23.5,6.2){\makebox(1,1){\sf C}}
\end{picture}
\end{center}

\slide{Provides the Key}

This picture gives us the key to figuring out how to
take the task and ``reduce'' it to a similar problem 
with ``smaller'' size.  Let the ``size'' be the
number of disks to move, and let the argument values
represent source pole, target pole, and temporary pole.

To move $N$ disks from $a$ to $b$ using $c$:
\begin{itemize}
\item
Move $N-1$ disks from $a$ to $c$ using $b$
\item
Move 1 disk from $a$ to $b$
\item
Move $N-1$ disks from $c$ to $b$ using $a$
\end{itemize}

\slide{First cut at Solution}

\begin{cprog}

void Hanoi (int n, char a, char b, char c)
	// move n disks from a to b, using c
{
		// first move all but last disk to tower c
	Hanoi (n-1, a, c, b);
		// then move one disk from a to b
	cout << "move disk from tower " << a << " to " << b << endl;
		// then move all disks from c back to b
	Hanoi (n-1, c, b, a);
}

\end{cprog}

Opps.  Never terminates.  Need a base case.

\slide{Solution with Base Case Included}

\begin{cprog}

void Hanoi (int n, char a, char b, char c)
	// move n disks from a to b, using c
{
	if (n == 1) {
			// can move smallest disk directly
		cout << "move disk from tower " << a << " to " << b << endl;
		}
	else {
			// first move all but last disk to tower c
		Hanoi (n-1, a, c, b);
			// then move one disk from a to b
		cout << "move disk from tower " << a << " to " << b << endl;
			// then move all disks from c back to b
		Hanoi (n-1, c, b, a);
		}
}
\end{cprog}
\end{document}