3.1.5 · D5Complexity Analysis

Question bank — Amortized analysis — aggregate, accounting, potential methods

1,976 words9 min readBack to topic

Two of the traps below reference pictures. Here is the resizing schedule and the credit-flow they point at.

Figure — Amortized analysis — aggregate, accounting, potential methods
Figure — Amortized analysis — aggregate, accounting, potential methods

True or false — justify

Amortized analysis assumes the input sequence is random.
False. There is no randomness; amortized cost is a guaranteed worst-case average over any sequence — see Big-O, Big-Omega, Big-Theta for the asymptotic bound it produces.
If every operation is amortized, then every single operation runs in actual time.
False. One operation may cost actually (e.g. a doubling copy); "amortized " only bounds the total across the sequence.
Amortized cost and average-case cost are the same thing.
False. Average-case is an expectation over a random distribution of inputs; amortized is a deterministic guarantee with no probability at all.
The aggregate, accounting, and potential methods can give different total-cost bounds for the same structure.
False. All three upper-bound the same real total ; they differ only in how you account, not in the answer.
For the potential method to be valid you must have for all .
False. You need and typically ; the potential is supposed to grow and shrink, just never go negative below the start.
Charging per push (instead of ) for a dynamic array is still a valid amortized bound.
True. Any with is honest; overcharges but never lies. It is just looser (a weaker constant).
In the accounting method the credit stored can temporarily go negative if it recovers later.
False. The bank must stay at all times; a moment of negative credit means some operation was undercharged and the bound is invalid.
A stack with a multipop operation multipop(k) (pop up to items, where is a non-negative integer chosen per call, capped at the current stack size) has amortized cost per operation.
True. Whatever is, each element is pushed once and popped at most once, so summed pops summed pushes; aggregate cost over ops is , i.e. amortized.
The potential function must always be an integer.
False. maps a state to any real number; only (and telescoping) matters, not integrality.
Doubling the array on resize and halving on shrink at the same threshold (shrink when ) is fine amortized.
False. That causes thrashing (see figure s01): sitting exactly at and alternating push/pop retriggers an resize every operation, breaking amortized — you must shrink at a lower threshold (shrink when ) to leave slack.

Spot the error

"The doubling copy touches elements, so amortized push is ."
The expensive copy happens only once every pushes (see the resizing schedule, figure s01); those geometrically-spaced copies sum to total (a Geometric Series), giving amortized — see Dynamic Arrays / Table Doubling.
"Master equation: ."
Sign flip. It is — actual cost plus the change in potential, so cheap ops that raise get charged more.
"Telescoping gives , so we need ."
Both wrong. The telescope leaves (final minus initial), and validity needs so that .
"For the binary counter, charge $1 per increment: $1 sets the new bit."
Undercharge. A single set needs $1 to act and $1 saved on that bit to later pay its own carry-flip, so you must charge $2 (walked step-by-step in the box below).
"With , a non-resizing push has because nothing is copied."
Missing the . Push raises by 1 so rises by 2; . That extra 2 is exactly the savings that later pays the copy.
"Amortized per operation means the whole sequence runs in ."
The sequence of operations runs in , not ; amortized cost is per operation, and there are of them.
"Since can be negative when , the potential method fails for dynamic arrays."
The formula is only used in the load regime ; below it we switch to the explicit piecewise form (valid for ). Both pieces are , agree at the join (both give ), and each is engineered to rise toward its own resize so it can pay for that resize.

Why questions

Why do we add rather than subtract it in ?
So that when we sum over all operations the middle terms cancel (telescope), leaving only ; the sign is what makes cheap ops "prepay" by banking potential.
Why must cheap operations increase the potential?
They bank energy so that a later rare expensive op can drop sharply and cancel its large actual cost, keeping every small — see the Fibonacci Heaps and Splay Trees analyses which rely on exactly this.
Why is amortized analysis stronger than just saying "the average input is cheap"?
Because it needs no assumption about inputs; it holds against an adversary who picks the worst possible sequence, giving a guarantee not an expectation.
Why does the geometric spacing of resizes matter so much?
If resizes happened every constant number of pushes instead of doubling, the copy costs would sum to ; doubling makes the cost of the -th resize but spaces them so the sum is a Geometric Series .
Why is shrinking at (not ) enough to kill thrashing?
After a shrink or grow you always land at near , so the array is half full either way. To force the next resize you must change by about (either fill up to , or drain down to ). That means at least cheap operations must happen between any two resizes — their banked potential prepays the resize, giving amortized. Any threshold with a constant gap works; is the simplest.
Why does path compression in Disjoint Set Union (Union-Find) need amortized (not per-op) analysis?
A single find can be or worse, but each such traversal flattens the tree, cheapening all future finds — the cost is only reasonable when averaged over the sequence (giving near-).
Why can two valid potential functions give different amortized per-op costs but the same total bound?
Different distribute the same total work differently across operations; the sum still upper-bounds the fixed , so the total guarantee is identical.
Why does the accounting method store credit on individual elements rather than in one global pot?
To make the invariant checkable: each element carries the exact credit needed to pay for its own future expensive event (its move or its bit-flip), so you can prove locally that the payment is always available.

Edge cases

What is the amortized cost when (a single push into a fresh array)?
Just for one op (); with one operation the "average over a sequence" is simply that one operation's charge, and no resize savings are needed yet.
What happens to the aggregate bound if you never insert anything ()?
and is undefined at ; the amortized claim is vacuous — there is no operation to charge.
If the initial structure is not empty, is still required?
Not strictly; you only need . But a nonzero adds a one-time slack to the bound, so setting it to 0 keeps the accounting clean.
Binary counter that only ever increments when the low bit is (no carry chain ever fires) — is amortized still guaranteed?
Yes; each such increment does exactly one set, costs $1 real and $2 charged, so it is even below budget. The bound holds for any sequence, easy or pathological.
A dynamic array that grows by a fixed +10 slots instead of doubling — amortized push cost?
, not : resizes now occur every 10 pushes and the -th copies elements, an arithmetic series summing to , so per-push cost is — geometric growth is essential.
Degenerate potential for all states — what does the master equation collapse to?
; amortized equals actual, so you gain nothing — it is a valid but useless choice that just re-derives worst-case per op.
Recall One-line self-test

Cover this: "Amortized per op over ops means total time is ___, and this is a ___ (not probabilistic) guarantee against ___ inputs." Answer ::: ; deterministic/guaranteed; adversarial (worst-case).


Connections