Copyright © 1999-2007 Steven J. Zeil, Old Dominion University
Table of Contents
In theory, we have all the tools we really need to analyze an algorithm. The rules from the prior lesson allow us to analyze individual statements and to deal with combinations of statements. But applying this to larger algorithms can still be unwieldy.
Your textbook gives an intuitive definition of big-O, and arrives at most of its conclusions about the performance of algorithms by intution. Now, intuition is a good thing, and many practicing programmers will do most of their complexity analysis intuitively. But the problem with intuition is that, until you have actually acquired som experience doing this kind of analysis, there's no reason for anyone (including yourself) to regard your intuition as particularly trustworthy.
A worst-case analysis is really a kind of mathematical proof, and people's styles of writing mathematical proofs vary so much that the results are often unreadable by anyone other than the author.
So in this lesson I am going to show you my own technique for conducting and documenting a worst-case analysis. This is the technique that I will use through this course whenever I am giving an analysis. And it is also the technique that I would expect you to use when you do assignments in which I ask you to do the algorithm analysis.
This technique takes advantage of the fact that these days we don't usually write down our algorithms using paper and pencil. Instead we use text editors which are very good in doing copy and paste. Consequently the technique relies on your ability to make copies of an algorithm over and over again, making small changes to the algorithm at each stage that reflect the analysis that you have actually done.