CS 624: Analysis of Algorithms

Carl Offner

Spring 2008

office: 75
email: offner "at" cs.umb.edu
home phone: (978) 443-4697

All the on line material for this course will be found on the web at http://www.cs.umb.edu/~offner/cs624.


Assignments:


Prerequisite:

This prerequisite is important. If you have not had it, and done well in it, you should not be enrolled in this course.

Class meetings: M/W 7:00-8:15 PM in room M-1-420

Office hours: Before class: M/W 6:00-6:45 PM


Texts:

The first text is required:
Introduction to Algorithms, Second Edition
by Cormen, Leiserson, Rivest, and Stein
McGraw-Hill, 2001

The second text is not required, but is highly recommended. It has a lot of good "war stories" in it, and gives a good feeling for the subject:
Algorithm Design Manual (with CD)
by Steve S. Skiena
Springer-Verlag, 1998


Syllabus:

At a minimum, I plan to cover the following material this term:

  1. Introductory material. What do we mean by analysis of algorithms? Why do we care? Some simple examples.

  2. Mathematical background and some useful mathematical techniques. Orders of growth of functions. Solving and estimating solutions of recursions. Generating functions. Probabilistic notions and techniques.

  3. Heapsort and Quicksort. v

  4. Hashing.

  5. Binary search trees.

  6. Dynamic programming.

  7. Greedy algorithms.

  8. Amortized analysis.

  9. Graph algorithms; in particular, depth-first search and some of its remarkable applications.

  10. The theory of NP-completeness.

There are many other topics that I'd really like to cover as well. This is just a fascinating field. We'll see…


Course Work:

There will be one homework assignment each week. I will not accept assignments handed in late.

There will be one or two in-class "mid-term" exams, and one final exam.

All the exams will be "closed-book" exams.


Writing Proofs:

This course does not involve any programming per se, although without a doubt your experiences in building serious programs will help you understand many of the issues we deal with.

In fact, the course could well be regarded as a mathematics course. I will be proving things in class, and you will be expected to write formal proofs in your assignments and on exams. If this is something you are not ready to come to grips with, you should wait until you are ready to take this class.

There is a style to writing proofs. In fact, there are several styles. Your goal should be to write proofs that are easy to read and that illuminate the reason why something is true. This is not easy to do. Good writing of any kind is difficult, and we will work hard at it all term.

Probably the single most important proof technique in this area is mathematical induction. I will assume not only that you are familiar with this, but are comfortable using it. I will not teach it, but I will expect to see inductive proofs written out clearly and well.

I also expect you to be familiar with standard mathematical notations such as summations (and of course, integrals). Some of this is reviewed in Appendix A of the text. I will not review this in class. I expect you to know it, and we will be using it a lot.

One thing is very important to bear in mind: like any other kind of writing, a proof must be understandable. If I can't understand what you are writing, then it can't be correct. And I'm not going to try to guess what you had in mind. If you are uncertain how to express something, please just talk to me or send me email, and I'll try to help. But don't even bother writing something that can't be understood.

Think of this like you would when writing a computer program. If the compiler or interpreter can't understand it, it's wrong. And you have to be really careful with your use of language and terms. For instance, one thing beginning programmers often get mixed up about is the correct use of "or" and "and". The meaning in computer languages is not the same as in English (or any other natural language, so far as I know). The same is true in proofs. We use language in very precise and fixed ways in proofs, and we do this so that what we write can be understood in its exact meaning by anyone at any time, anywhere in the world.

Just for a simple example: the sentence "All horses are not white." does not mean the same as "Not all horses are white." At least, not when writing proofs. In ordinary English, these two sentences are generally regarded as equivalent. But for our purposes they are not. You have to be careful about this.


Collaborating with Others

I encourage you to talk with other students—in fact, with anyone—about the topics we are covering. And I also enourage you to send me email with questions; I'll be happy to get back to you as quickly as I can. However, the writeups you hand in must be entirely your own. You may not copy proofs, or algorithms, or parts of proofs or algorithms, or anything else, from anyone else's paper, or from the web, or from books, or from anywhere else. And you must be able to explain to me what you have written.

Please do take this seriously. I'm very happy to try to help you out in person or by email. I really do want every one of you to succeed, and I'll try hard to make that happen. But I have no tolerance at all for plagiarism. If I find evidence of it, you will receive an F for the course. And I don't give "second chances".


Some University Policies: