01 introduction - Agenda: * Who am I? * What is this course...

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

View Full Document Right Arrow Icon
Agenda: * Who am I? * What is this course about? * What will we be doing in this course? * Describing functions with contracts ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Who am I: Brian Noble bnoble@umich.edu 4753 CSE (upstairs) Office hours: after class, 1:30-2:30 MW or by appointment. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Big ideas: thinking before hacking is important dealing with complexity is the #1 problem in programming. this class is all about that. Course Manifesto: Mathematics--especially as used by physics--is the formalism we use to describe "what is" -> we model the physical world with equations -> solutions to those equations give us insight into the physical reality around us But, classical mathematics does not say anything about how these processes unfold. For that, we need something else. Computer science is the formalism we use to describe "how to". Algorithm: An abstract sequence of actions composed to solve a problem. example: walking put left foot in front of right foot. put right foot in front of left foot. repeat. :) Program: concrete set of *program statements*, expressed in some *formal language*, which *implements* some algorithm. Note: usually we use "program" to mean an executable binary (like "winword" or "ls") but, in this definition, any implementation of an algorithm can be considered a program. The task of programming: 1) Given a (possibly incomplete/imprecise) specification 2) Design an *effective* algorithm 3) Implement that algorithm *correctly* and *efficiently* An algorithm is *effective* if:
Background image of page 1

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

View Full DocumentRight Arrow Icon
- it correctly satisfies the specification - it is efficient in its (asymptotic) usage of *space* and *time* Note: "asymptotic" performance does not prescirbe a particular running time or size. Rather, it tells us how running time/space requirements grow every time we e.g. double the size of the problem to which the algorithm is applied. An implementation of an algorithm is *correct* if it behaves as the alogorithm is intended for all inputs/in all situations. Correctness is never negotiable. There are three notions of *efficient* implementations - the implementation has (concrete) space/time requirements "similar to" the abstract requirements of the corresponding algorithm. (This in the asymptotic sense). - of all of the "asymptotically good" possible implementations, this one is among the better ones in absolute, concrete terms. - it does not take an undue amount of programmer effort to (a) write the implementation in the first place (simplicity) or (b) improve/adapt the implementation to more general/closely related algorithms. (elegance) So, efficient can mean fast, simple and/or elegant. This doesn't seem that difficult. What's the big deal? Several big problems:
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 02/13/2012 for the course EECS 280 taught by Professor Noble during the Winter '08 term at University of Michigan.

Page1 / 8

01 introduction - Agenda: * Who am I? * What is this course...

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