CS 61B: Lecture 20 Monday, March 10, 2014 Today's reading: Goodrich & Tamassia, Chapter 4 (especially 4.2 and 4.3). ASYMPTOTIC ANALYSIS (bounds on running time or memory) =================== Suppose an algorithm for processing a retail store's inventory takes: - 10,000 milliseconds to read the initial inventory from disk, and then - 10 milliseconds to process each transaction (items acquired or sold). Processing n transactions takes (10,000 + 10 n) ms. Even though 10,000 >> 10, we sense that the "10 n" term will be more important if the number of transactions is very large. We also know that these coefficients will change if we buy a faster computer or disk drive, or use a different language or compiler. We want a way to express the speed of an algorithm independently of a specific implementation on a specific machine--specifically, we want to ignore constant factors (which get smaller and smaller as technology improves). Big-Oh Notation (upper bounds on a function's growth) --------------- Big-Oh notation compares how quickly two functions grow as n -> infinity. Let n be the size of a program's _input_ (in bits or data words or whatever). Let T(n) be a function. For now, T(n) is the algorithm's precise running time in milliseconds, given an input of size n (usually a complicated expression). Let f(n) be another function--preferably a simple function like f(n) = n. We say that T(n) is in O( f(n) ) IF AND ONLY IF T(n) <= c f(n) WHENEVER n IS BIG, FOR SOME LARGE CONSTANT c. * HOW BIG IS "BIG"? Big enough to make T(n) fit under c f(n). * HOW LARGE IS c? Large enough to make T(n) fit under c f(n). EXAMPLE: Inventory ------------------- Let's consider the function T(n) = 10,000 + 10 n, from our example above. Let's try out f(n) = n, because it's simple. We can choose c as large as we want, and we're trying to make T(n) fit underneath c f(n), so pick c = 20. c f(n) = 20 n ** ^ / ** | | / ** | | / ** | | / ** | | / ** T(n) = 10,000 + 10 n 30,000 + | / ** | | / ** | | / ** | |/** 20,000 + ** | **| | **/ | | ** / | 10,000 ** / | | / | | / | |/ | O-------+------------------------> n 1,000 As these functions extend forever to the right, their asymptotes will never cross again. For large n--any n bigger than 1,000, in fact--T(n) <= c f(n). *** THEREFORE, T(n) is in O(f(n)). *** Next, you must learn how to express this idea rigorously. Here is the central lesson of today's lecture, which will bear on your entire career as a professional computer scientist, however abstruse it may seem now: |=============================================================================| | FORMALLY: O(f(n)) is the SET of ALL functions T(n) that satisfy: | | | | There exist positive constants c and N such that, for all n >= N, | | T(n) <= c f(n) | |=============================================================================| Pay close attention to c and N. In the graph above, c = 20, and N = 1,000. Think of it this way: if you're trying to prove that one function is asymptotically bounded by another [f(n) is in O(g(n))], you're allowed to multiply them by positive constants in an attempt to stuff one underneath the other. You're also allowed to move the vertical line (N) as far to the right as you like (to get all the crossings onto the left side). We're only interested in how the functions behave as n shoots off toward infinity. EXAMPLES: Some Important Corollaries ------------------------------------- [1] 1,000,000 n is in O(n). Proof: set c = 1,000,000, N = 0. -> Therefore, Big-Oh notation doesn't care about (most) constant factors. We generally leave constants out; it's unnecessary to write O(2n), because O(2n) = O(n). (The 2 is not wrong; just unnecessary.) [2] n is in O(n^3). [That's n cubed]. Proof: set c = 1, N = 1. -> Therefore, Big-Oh notation can be misleading. Just because an algorithm's running time is in O(n^3) doesn't mean it's slow; it might also be in O(n). Big-Oh notation only gives us an UPPER BOUND on a function. c f(n) = n^3 ^ * / | * / | * / T(n) = n | * / | * / | * / | * / | */ 1 + * | /* | / * | / *| | / *| | / *| | / * | |/ ** | O***----+------------------------> n N = 1 [3] n^3 + n^2 + n is in O(n^3). Proof: set c = 3, N = 1. -> Big-Oh notation is usually used only to indicate the dominating (largest and most displeasing) term in the function. The other terms become insignificant when n is really big. Here's a table to help you figure out the dominating term. Table of Important Big-Oh Sets ------------------------------ Arranged from smallest to largest, happiest to saddest, in order of increasing domination: function common name -------- ----------- O( 1 ) :: constant is a subset of O( log n ) :: logarithmic is a subset of O( log^2 n ) :: log-squared [that's (log n)^2 ] is a subset of O( root(n) ) :: root-n [that's the square root] is a subset of O( n ) :: linear is a subset of O( n log n ) :: n log n is a subset of O( n^2 ) :: quadratic is a subset of O( n^3 ) :: cubic is a subset of O( n^4 ) :: quartic is a subset of O( 2^n ) :: exponential is a subset of O( e^n ) :: exponential (but more so) Algorithms that run in O(n log n) time or faster are considered efficient. Algorithms that take n^7 time or more are usually considered useless. In the region between n log n and n^7, the usefulness of an algorithm depends on the typical input sizes and the associated constants hidden by the Big-Oh notation. If you're not thoroughly comfortable with logarithms, read Sections 4.1.2 and 4.1.7 of Goodrich & Tamassia carefully. Computer scientists need to know logarithms in their bones. Warnings -------- [1] Here's a fallacious proof: n^2 is in O(n), because if we choose c = n, we get n^2 <= n^2. -> WRONG! c must be a constant; it cannot depend on n. [2] The big-Oh notation expresses a relationship between functions. IT DOES NOT SAY WHAT THE FUNCTIONS MEAN. In particular, the function on the left does not need to be the worst-case running time, though it often is. The number of emails you send to your Mom as a function of time might be in O(t^2). In that case, not only are you a very good child; you're an increasingly good child. In binary search on an array, - the worst-case running time is in O(log n), - the best-case running time is in O(1), - the memory use is in O(n), and - 47 + 18 log n - 3/n is in O(the worst-case running time). Every semester, a few students get the wrong idea that "big-Oh" always means "worst-case running time." Their brains short out when an exam question uses it some other way. [3] "e^3n is in O(e^n) because constant factors don't matter." "10^n is in O(2^n) because constant factors don't matter." -> WRONG! I said that Big-Oh notation doesn't care about (most) constant factors. Here are some of the exceptions. A constant factor in an exponent is not the same as a constant factor in front of a term. e^3n is not bigger than e^n by a constant factor; it's bigger by a factor of e^2n, which is damn big. Likewise, 10^n is bigger than 2^n by a factor of 5^n. [4] Big-Oh notation doesn't tell the whole story, because it leaves out the constants. If one algorithm runs in time T(n) = n log_2 n, and another algorithm runs in time U(n) = 100 n, then Big-Oh notation suggests you should use U(n), because T(n) dominates U(n) asymptotically. However, U(n) is only faster than T(n) in practice if your input size is greater than current estimates of the number of subatomic particles in the universe. The base-two logarithm log_2 n < 50 for any input size n you are ever likely to encounter. Nevertheless, Big-Oh notation is still a good rule of thumb, because the hidden constants in real-world algorithms usually aren't that big.