Lecture 7
Amortized Analysis
7.1
Overview
In this lecture we discuss a useful form of analysis, called
amortized analysis
, for problems in which
one must perform a series of operations, and our goal is to analyze the time per operation. The
motivation for amortized analysis is that looking at the worstcase time per operation can be too
pessimistic if the only way to produce an expensive operation is to “set it up” with a large number
of cheap operations beforehand.
We also introduce the notion of a
potential function
which can be a useful aid to performing this
type of analysis.
A potential function is much like a bank account:
if we can take our cheap
operations (those whose cost is less than our bound) and put our savings from them in a bank
account, use our savings to pay for expensive operations (those whose cost is greater than our
bound), and somehow guarantee that our account will never go negative, then we will have proven
an
amortized
bound for our procedure.
As in the previous lecture, in this lecture we will avoid use of asymptotic notation as much as
possible, and focus instead on concrete cost models and bounds.
7.2
Introduction
So far we have been looking at static problems where you are given an input (like an array of
n
objects) and the goal is to produce an output with some desired property (e.g., the same objects,
but sorted).
For next few lectures, we’re going to turn to problems where we have a
series
of
operations, and goal is to analyze the time taken per operation. For example, rather than being
given a set of
n
items up front, we might have a series of
n
insert
,
lookup
, and
remove
requests to
some database, and we want these operations to be efficient.
Today, we will talk about a useful kind of analysis, called
amortized analysis
for problems of this
sort. The definition of amortized cost is actually quite simple:
Definition 7.1
The
amortized cost per operation
for a sequence of
n
operations is the total
cost of the operations divided by
n
.
For example, if we have 100 operations at cost 1, followed by one operation at cost 100, the
35
This preview has intentionally blurred sections. Sign up to view the full version.
View Full Document
7.3. EXAMPLE #1: IMPLEMENTING A STACK AS AN ARRAY
36
amortized cost per operation is 200
/
101
<
2. The reason for considering amortized cost is that we
will be interested in data structures that occasionally can incur a large cost as they perform some
kind of rebalancing or improvement of their internal state, but where such operations cannot occur
too frequently. In this case, amortized analysis can give a much tighter bound on the true cost of
using the data structure than a standard worstcaseperoperation bound. Note that even though
the definition of amortized cost is simple, analyzing it will often require some thought.
We will
illustrate how this can be done through several examples.
This is the end of the preview.
Sign up
to
access the rest of the document.
 Fall '10
 Blum
 Array, Analysis of algorithms, bank account, Best, worst and average case

Click to edit the document details