ECS 122A - Algorithm Design and Analysis - Fall 1997
Course Information Sheet
September 26, 1997
You are responsible for everything on this handout. Read it.
Lectures
MWF 3:10-4:00 pm in 1150 Hart.
The CRN for this class is 48728.
Discussion Sections
W 6:10 - 7:00 pm in 1150 Hart.
Discussion sections begin next week.
Instructors
This course will be taught in an unusual format;
there are two instructors.
We will take turns lecturing.
Teaching Assistant
- Qi Hongbin.
Goes by the name "Bin" (same sound as the word "bean").
Engineering II, #053.
qi@cs.ucdavis.edu.
Office hours: R 4:30-5:30
Evening Midterm
There will be one midterm in this class. It will
be Thursday, 30 October, 7-9 pm, in 1150 Hart.
Closed book, closed notes.
The exam is given in this format to remove time pressure;
the exam should require well under 120 minutes.
Final
There is a misprint in the schedule of classes on the date.
We are exam group J: 10:30-12:30 on Wednesday, Dec. 10
Closed book, closed notes.
Prerequisites
Minimal prerequisites are ECS 100 and ECS 110.
Mathematics majors might do fine without ECS 100.
You will probably end up failing if you try to take
this class without having acquired a basic
understanding of algorithms and data structures
(ECS 40 and ECS 110 material)
and some basic mathematical maturity.
Textbook
Introduction to Algorithms, by Cormen, Leiserson and Rivest.
Often called "CLR." Reading the book strengthens the mind;
carrying it strengthens the body.
We've been using the same book for 122B and 222A, should you
end up taking either of these classes in the future. It's a good reference for the
practicing computer scientist. Clearly we will
not cover all of its 1000+ pages.
Course Web page
We will maintain useful information on the course
Web page:
http://www.cs.ucdavis.edu/~rogaway/classes/122A/fall97/.
Visit this page regularly to see what's new.
If you miss a handout, get it from here.
Newsgroups
-
ucd.class.ecs122a -
This is for the instructors to communicate
things of general concern to the class. This sometimes includes
important announcements, like
corrections/clarifications to homework problems. Please read
this newsgroup regularly; you are responsible for
anything on it. Don't post to this newsgroup.
Use the following newsgroup instead.
-
ucd.class.ecs122a.d -
This is the discussion newsgroup
which you may use to communicate among yourselves, and also to
ask questions directed to other students at large, or to the instructors or TA.
Read this newsgroup or not; the the choice is yours.
Obviously you should not post anything that amounts to a solution
to a homework problem.
Grading
There will be weekly problem
sets (30%), a midterm (25%), and a final (45%).
Homeworks
If homework is due on a Monday, Wednesday or Friday, it is to be
submitted in class, due at the beginning of lecture.
If homework is due on a Tuesday or Thursday, it is
to be turned in at the marked box in
Engineering II, #2131 by
1:00 pm.
Either way, no late homeworks will be accepted.
Much of what one learns in this course comes from trying to solve
the homework problems, so work hard on them.
Doing a conscientious job on the homeworks is the best preparation
for the exams.
We hope that you will ultimate solve the majority of the problems, but don't
be surprised if some of them stump you;
some of the problems may be quite challenging.
Your solutions should be terse, correct, and legible.
Understandability of the solution is as necessary as correctness.
Expect to lose points if you provide a "correct" solution with a
not-so-good writeup. As with an English paper, you can't
expect to turn in a first draft: it takes refinement to describe something well.
Typeset solutions are always appreciated.
If you can't solve a problem, briefly indicate what you've tried and where
the difficulty lies. Don't try to pull one over on us.
We prefer absent solutions to wrong ones, and will
adopt a grading policy to reflect this:
10 points for a perfect solution;
a few points for good ideas;
0 points for an absent solution;
negative points for work which is
incomprehensible or reflects a significant misunderstanding.
Know what you know and be clear about it.
We have found that some students are willing
to spend long hours in front of a machine but are unwilling to spend
those same hours thinking about a problem.
Don't be that way.
If you think a problem was misgraded, please see the TA first.
Collaboration
Collaboration on the homework problems is discouraged.
In our experience, acquiring the skills that the homeworks are trying
to instill is a quite solitary endeavor.
You need to sit under a big tree and think until the moment of insight
hits you. It might never come, but, even if it doesn't,
the experience may still be of more value
than what often transpires in a discussion group.
That said, it is recognized that different people learn differently,
and so we do not prohibit you from interacting on homeworks.
But: if you get an idea from any source other than lectures or your
textbook,
you must acknowledge the
source of the idea in your writeup. This doesn't affect your grade.
Of course homework solutions must be written up entirely on your own.
Working together to try to understand lecture
material or material in the text is fine.
A Friendly Warning
This will be a difficult class.
We really want you to think.
Don't try to solve the problems by doing some sort of "pattern matching."
It won't work.
You might find any of the following hints helpful.
Do the reading before each lecture.
(We'll always tell you what will be the next appropriate reading.)
Don't get behind.
Be selective in note-taking. (Often it works better to just sit there and really
listen.)
If you feel you need comprehensive notes, team up with someone else so that you
only sometimes have to scribe notes.
Work on your own.
If you do get involved in a some sort of study group, don't let it degenerate into
collective attempts to solve the homework problems.
Syllabus
There is a static list of topics on line,
and a lecture-by-lecture topics list that
will evolve as the course goes on.
Parting Thoughts
Some theorists are lousy programmers,
but a no good programmer can be a lousy theorist.
For to be a good programmer you must
carry in your head a collection of algorithmic ideas that arise again and again;
you must constantly invent new algorithms (or modify old ones);
you need to be able to analyze algorithms (so you don't waste time coding
ineffective solutions or optimizing irrelevant parts of a program); and
you need to be able of read and understand literature which
specifies non-trivial algorithms. If you think that this subject is useless,
you are wrong!