Describing algorithms requires a notation for expressing a sequence of steps to be performed. The three most common options are (1) English, (2) pseudocode, or (3) a real programming language. Pseudocode is perhaps the most mysterious of the bunch, but it is best defined as a programming language that never complains about syntax errors. All three methods can be useful in certain circumstances, since there is a natural tradeoff between greater ease of expression and precision. English is the most natural but least precise language, while C and Pascal are precise but difficult to write and understand. Pseudocode is useful because it is a happy medium.

The correct choice of which notation is best depends upon which of
the three methods you are most comfortable with.
I prefer to describe the *ideas* of an algorithm in English,
moving onto a more formal, programming-language-like pseudocode to clarify
sufficiently tricky details of the algorithm.
A common mistake among my students is to use pseudocode to take
an ill-defined idea and dress it up so that it looks more formal.
In the real world, you only fool yourself when you pull this
kind of stunt.

The *implementation complexity* of an algorithm is usually
why the fastest algorithm known for a problem may not be the most
appropriate for a given application.
An algorithm's implementation complexity is often a function of
how it has been described.
Fast algorithms often make use of very complicated data structures, or
use other complicated algorithms as subroutines.
Turning these algorithms into programs requires building implementations of
every substructure.
Each catalog entry in Section
points out available
implementations of algorithms to solve the given problem.
Hopefully, these can be used as building blocks
to reduce the implementation complexity of
algorithms that use them, thus making more complicated algorithms worthy
of consideration in practice.

Mon Jun 2 23:33:50 EDT 1997