{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

# 38 - 18:30:17 CS61B Lecture 38 Monday AMORTIZED ANALYSIS =...

This preview shows pages 1–2. Sign up to view the full content.

04/27/09 18:30:17 1 38 CS61B: Lecture 38 Monday, April 27, 2009 AMORTIZED ANALYSIS ================== We’ve seen several data structures for which I claimed that the average time for certain operations is always better than the worst-case time. These data structures include hash tables, tree-based disjoint sets, and splay trees. The analysis technique that proves these claims is called _amortized_analysis_. Amortized analysis is a way of proving that even if an operation is occasionally expensive, its cost is made up for by other, cheaper occurrences of the same operation. The Averaging Method -------------------- Let’s look at the average-case time for inserting an item into a hash table. Assume that the chains don’t grow longer than O(1), and any operation that doesn’t resize the table takes O(1) time--more precisely, suppose it takes at most one second. The hash table has N buckets and n items. Suppose the insert operation doubles the size of the table (before adding the new item) if n = N. That way, the new item won’t cause the load factor to exceed one. Suppose this resizing operation takes at most 2n seconds. When resizing is done, N doubles, the new item is inserted, and n increases by one. We construct an empty hash table with just one bucket. After we perform i insert operations, n = i and N is the smallest power of two >= n. The total seconds for _all_ the resizing operations is 2 + 4 + 8 + ... + N/4 + N/2 + N = 2N - 2. So the cost of i insert operations is at most i + 2N - 2 seconds. Because N < 2n = 2i, the i insert operations take O(5i - 2) = O(i) time, and so the _average_ running time of an insertion operation is in O(i)/i = O(1). We say that the _amortized_running_time_ of insertion is in O(1), even though the worst-case running time is in Theta(n). For almost any application, the amortized running time is more important than the worst-case running time, because the amortized running time determines the total running time of the application. The main exceptions are some applications that require fast interaction (like video games), for which one really slow operation might cause a noticeable glitch in response time.

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}