lecture1 - Agenda: * Who am I? * What is this course about?...

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? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Course Manifesto: Mathematics--especially as used by physics--is the formalism we use to describe "what is" 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. Program: concrete set of *program statements* which *implement* some algorithm. The task of programming: 1) Given a (possibly incomplete/imprecise) specification 2) Design an *effective* algorithm An algorithm is *effective* if: - it correctly satisfies the specification - it is efficient in its (asymptotic) usage of *space* and *time* 3) Implement that algorithm *correctly* and *efficiently* An implementation of an algorithm is *correct* if it behaves as the algorithm 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. - 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)
Background image of page 1

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

View Full DocumentRight Arrow Icon
write the implementation in the first place (simplicity) or (b) improve/adapt the implementation to more general/closely related algorithms. (elegance) This doesn't seem that difficult. What's the big deal? Several big problems: - Engineering: faster, better, cheaper: pick two Unfortunately, our goals are often in conflict. The easiest programs to understand/modify are often not the simplest to write. Programs that are simple to write/understand are often not the absolute fastest possible solution to a problem. The most efficient algorithms for a given problem are often subtle and difficult to implement correctly. - the *languages* in which we program have only a small number of relatively simple elements from which all programs must be composed. Luckily for us, these elements are "complete" in some interesting formal sense (to be defined in 376). But, any interesting program must necessarily be large and complex. - it is impossible to test programs for correctness in all cases. So, we need *specifications* of behavior and *invariants* describing the rules to meet them - human brains (i.e.: those of the programmers) are notoriously bad at coping with complexity. this is bad news for our ability to construct larger and more
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 04/04/2008 for the course EECS 215 taught by Professor Phillips during the Winter '08 term at University of Michigan.

Page1 / 7

lecture1 - Agenda: * Who am I? * What is this course about?...

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