lect_20 - Big O Margaret M. Fleck 8 March 2010 This lecture...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon

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

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Big O Margaret M. Fleck 8 March 2010 This lecture introduces asymptotic analysis of function growth and big-O notation. 1 Announcements There’s a quiz coming up a week from Wednesday (17 March) Similar in format to the first quiz. Expect study materials later this week. Tell me about conflicts and/or need for special arrangements (email me your schedule in these cases). No class this Friday due to Engineering Open House. This week and next week, we’ll be talking about how analyze how fast simple computer programs run. This week, we’ll be doing some of the basic techniques required (big-O analysis and solving recurrences). Next week, we’ll get to the actual programs. 2 Running times of programs An important aspect of designing a computer programs is figuring out how well it runs, in a range of likely situations. Designers need to estimate how fast it will run, how much memory it will require, how reliable it will be, and so forth. In this class, we’ll concentrate on speed issues. Designers for certain small platforms sometimes develop very detailed models of running time, because this is critical for making complex appli- cations work with limited resources. E.g. making God of War run on your Iphone. However, such programming design is increasingly rare, because 1 computers are getting fast enough to run most programs without hand opti- mization. More typically, the designer has to analyze the behavior of a large C or Java program. It’s not feasible to figure out exactly how long such a pro- gram will take. The transformation from standard programming languages to machine code is way too complicated. Only rare programmers have a clear grasp of what happens within the C or Java compiler. Moreover, a very detailed analysis for one computer system won’t translate to another pro- gramming language, another hardware platform, or a computer purchased a couple years in the future. It’s more useful to develop an analysis that abstracts away from unimportant details, so that it will be portable and durable. This abstraction process has two key components: • Ignore multiplicative constants • Ignore behavior on small inputs, concentrating on how well programs handle large inputs. (Aka asymptotic analysis.) Multiplicative constants are extremely sensitive to details of the imple- mentation, hardware platform, etc. Behavior on small inputs is ignored, because programs typically run fast enough on small test cases. Or will do so soon, as computers become faster and faster. Hard-to-address problems more often arise when a program’s use expands to larger examples. For example, a small database program developed for a community college might have trouble coping if deployed to handle (say) all registration records for U. Illinois....
View Full Document

This note was uploaded on 09/21/2011 for the course CS 173 taught by Professor Erickson during the Spring '08 term at University of Illinois, Urbana Champaign.

Page1 / 6

lect_20 - Big O Margaret M. Fleck 8 March 2010 This lecture...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online