COS 226, Spring 1998. Course Information

Department of Computer Science, Princeton University

COS 226: Data Structures and Algorithms, Spring 1998

R. Sedgewick


Back to COS 226 home page.

COURSE INFORMATION

General Information

Instructor: Robert Sedgewick, CS 319, 258-4345, rs@cs (Office hours M 12-2).


Course Secretary: Sandy Barbu, CS Bldg. 323, 258-4562, barbu@cs.


Lectures: MW 11:00-11:50 AM, CS Bldg. 104.


Precepts: Monday or Tuesday; all rooms and offices are in the CS Bldg.
Time Room Preceptor Office Phone Office Hours Email
1. M 3:30 103 Aaron Lee 214 8-1793 M 4:30-5:30 wailee@cs
2. M 7:30 105 Geliang Tong 415 8-1798 T 11:00-12:00 tong@cs
3. T 2:30 103 John Hainsworth 216 8-5389 M 3:30-4:30 hains@cs
4. T 4:30 103 Allison Klein 215 8-1794 T 3:00-4:00 awklein@cs

First precepts 2/9 and 2/10.
The textbook is Algorithms, Third Edition, in C, Parts 1-4, Addison-Wesley, 1998. by Robert Sedgewick, ISBN 0-201-31452-5. You also need the course packet, available at Pequod Copy. You may also find a book on C programming useful.

Prerequisites

The prerequisite for this course is COS 126. Students in the course should have an understanding of the basic principles of computer science and computer architecture, significant programming experience with a working knowledge of C and Unix (or some similar programming environment) and familiarity with elementary data structures such as arrays, stacks, queues, and trees. Most students registered for the course have this background; those who do not may have to work harder at the beginning.

The course will cover algorithms from a variety of applications areas, and several mathematical topics will be discussed. The course is intended to be self-contained with respect to such topics, but students are likely to find any mathematical experience helpful.

Attendance at lectures is expected. Copies of lecture notes (transparancies used in lecture) are in the course packet and are available online. Students are fully responsible for all material presented in lectures, even if some of it does not appear in these notes.

Assignments and Exams

There will be ten programming assignments. Generally, they will be handed out on a Wednesday, with electronic submission due eight days later on Thursday (at 11:59 PM). Your submission must include a readme file which should not only provide details about your program, but also exhibit your understanding of performance characteristics and the general approach that you took to solve the problem.

There will also be ten weekly problem sets. These will be handed out on Wednesdays and due at precept the following week. These will consist of short questions on the material in the lectures, notes, and programs.

There will be a midterm exam on the Wednesday before break, which will cover all material up to and including the lecture on the previous Wednesday. The final exam will cover all material in the course.

Grading Policies

You will write some programs for the programming assignments, run them, and submit the code electronically. The code rarely speaks for itself, however, and it is your responsibility to hand in a separate printed writeup that describes what you did. This need not be verbose; indeed, you are better off making it terse. If we ask for a table, provide the table. If we ask to to run the program on some data, do it, then describe what happened. If you do extra credit work or something beyond what we've asked, explain what you did, thoroughly.

Do not refer in the readme file to any programming done after the electronic submission. We will be checking what you have said in your writeup by running your code. Discrepencies will lower your grade dramatically.

Grades on the programming assignments will be: 10(perfect in every way), 9(outstanding), 8(excellent), 7(very good), 6(good), 5(not bad), 4(poor), 3(minimal effort), 2(bad), 1(hopeless), or 0(not handed in). Grades on the problem set questions will be: 4(correct), 3(minor mistake), 2(major mistake), 1(poor try) or 0(all wrong).

The programming assignments, problem sets, and exams all contribute significantly to your grade. Specifically, your final course grade will be calculated as follows:

In calculating your course grade, we will drop the lowest programming assignment score. Thus, you may choose to "punt" one programming assignment, or you may choose to do them all in an attempt to learn more or to maximize your grade. The precise values of these weights are not nearly as important to you as it is to be sure that you hand in all the work assigned. Doing so will help you if your grade is borderline at the end.

Assignments submitted late will be graded according to the following formula: S = .9 R exp(-t/3), where S is the grade given, R is the grade the work would have gotten if turned in on time and t is the amount of time (in days) the work was late. Thus, the value of a late assignment decays exponentially, with a half-life of just over two days. Examples: work turned in five minutes late gets 89.9% credit, one hour late gets 88.7% credit, six hours late gets 82.8% credit, one day late gets 71.7% credit, three days late gets 33.1%, and one week late gets 8.7%.

Assignments submitted more than a week late, or after the Dean's date, will receive no credit.

There will no extensions due to scheduling conflicts, computer downtime, or other such factors, except under truly extraordinary circumstances. Extensions will be granted only for university-sanctioned excuses such as illness, and then only with the proper documentation. You are responsible for planning ahead and managing your time so that you can complete the assignments on time. You must either finish on time or accept the consequences of doing otherwise.

Unless prior arrangements are made, a grade of zero will be recorded for missed exams.

Computers

You may develop your programs on any machine that you like. However, your finished programs must run on one of CIT's SparcServers (phoenix, tucson, flagstaff) or on the SparcStations located in room 101 of the CS building. Programs may be written in any programming language, except that you may not use assembly language unless the assignment explicitly permits it. (Of course, your program cannot run on the Sparcs if the language you use isn't supported on the Sparcs.) Students who have already registered for this course should already have their accounts. Students who had accounts in past semesters will have the same login (userid) and password. Other students must go to the CIT Clinic at 87 Prospect to set their password.

Students taking several courses using CIT facilities will have one account and their disk quota will be the sum of the disk quotas for all courses.

Do not allow anyone else to use your accounts for any purpose. They are for your use alone, and you are responsible for any misuse. Your passwords control access to your accounts and should be kept secret.

Rights and Responsibilities

Exams are open book.

Problem sets should reflect your own work. Collaboration is inapproriate for the specific problems in the problem sets, though working with course assistants and other students in the class on similar problems is encouraged.

Programming, like composition, is an individual creative process. Individuals must reach their own understanding of the problem and discover a path to its solution. During this time, discussions with friends are encouraged. However, when the time comes to write the code that solves the problem, such discussions are no longer appropriate -- the program must be your own work (although you may ask teaching assistants or lab assistants for help in debugging). If you have a question about how to use some feature of C, UNIX, etc., then you can certainly ask your friends or the lab assistants or teaching assistants.

Do not, under any circumstances, copy another person's program. Writing code for use by another or using another's code in any form violates the University's academic regulations and will be dealt with harshly.

Submitting Programming Assignments

Submit your solutions to the programming assignments electronically using the following command.
/u/cs226/bin/submit number files
number is the assignment number and files is the list of files for that assignment. For example,
/u/cs226/bin/submit 31 readme makefile main.c strings.c
submits the files readme, makefile, main.c, and strings.c for a fictitious assignment 31.

The submit command copies your files to the directory /u/cs226/submit/login/number and lists all the files that you have submitted for assignment number. login is your user account name. If you execute submit after the assignment deadline, your files are placed in directory number-late. You can run submit more than once, and you can submit partial lists of files.

There's also unsubmit, which allows you to `unsubmit' one or more files. For example,

/u/cs226/bin/unsubmit 31 main.c
would remove your main.c from the submission directory.

You can omit the /u/cs226/bin/ prefix if you add /u/cs226/bin/ to your PATH variable. You must execute submit on one of the SparcServers.

When appropriate, submissions may also include a file named makefile, written so that the command `make' builds your program, and the command `make clobber' removes all `derived' files, e.g., object files, executable files, and libraries. For details about make, see its man page.

Keeping in Touch

The best way to contact the instructor and the preceptors is by electronic mail. To get help, you should try sending mail to your preceptor first, but you can also try the instructor or cs226@phoenix.


Copyright (c) 1998 by Robert Sedgewick