CS152: Details

Prerequisites

You must grasp basic algorithms, data structures, and good programming practice. You should have substantial programming experience. Those without such experience will have difficulty keeping up with the homework. Proficiency in C is needed for some homework assignments. You must have some basic mathematics (e.g., simple propositional calculus, elementary set theory) and must be able to prove a theorem, including proofs by induction.

You need some Unix experience. You must understand the basics of files, directories, creating and editing files, printing, compiling and loading programs, and using make. You will be much, much happier if you also can write a simple shell script (sh) and use Awk and grep effectively. Kernighan and Pike cover these topics at the appropriate level. (Or as an alternative, you could become proficient with Perl.)

You must be able to send electronic mail and browse course materials using a World-Wide Web browser.

Your programming experience should include work with dynamically allocated data structures and with recursive functions. You should be very comfortable writing recursive functions in the language of your choice, as well as proving that such functions terminate. You should have implemented some of the basic data structures and algorithms used in computer science, like stacks, queues, lists, tables, search trees, standard sorts (quick, insertion, merge, heap), topological sort, and graph algorithms. Prior exposure to exhaustive search (backtracking) will be helpful.

Some students spend many, many hours thrashing out homework assignments. This course uses unusual programming paradigms, and the techniques you are accustomed to may not be much help. Although this material is not a formal prerequisite for this course, you will be happier if you have a nodding acquaintance with formal methods, including the following intellectual tools:

You can brush up on this material by looking at the article by Bentley on the reading list. Chapter 4 of Liskov and Guttag has a nice tutorial on reasoning about data, which you will find helpful in several assignments.

You must have taken CS 121. If not, you must produce some other evidence that you can reason precisely about computational objects. You should be able to write an informal mathematical proof. For example, you should be able to prove that a sort routine returns the same set of elements that it was passed. You should be comfortable using basic mathematical formulas with ``forall'' and ``exists'' quantifiers, i.e., the propositional and predicate calculi, although it will not be necessary to write formal proofs using these calculi. You should know basic set theory, e.g., the mathematical definition of functions as sets of ordered pairs. You should be comfortable reading and writing formal mathematical notation, or at least not run screaming from the room.

The most important prerequisites for this course cannot be taught. To do well in this or any other systems course, develop these habits:

If you have these habits, the other prerequisites are almost irrelevant. If you don't, you can expect to have trouble no matter what your background.

Homework and Grading Policies

Most homework for this course involves short programming assignments. Many of them will be based on the text by
Ramsey and Kamin. There will be also be some larger programming assignments. There will be some theory homework, involving more proving and less programming. The course will have two exams: a one-hour midterm and a three-hour final. To reduce the element of time pressure, the midterm will be given in the evening (thereby taking more than an hour).

Your course grade is based on my judgment of the quality of your work and the degree of mastery you demonstrate, as outlined in Information for Faculty Offering Instruction in Arts and Sciences. The primary tool I use in forming this judgment is your overall course average, which is determined by combining your individual grades with approximately the following weights:

This weighting may be adjusted at my discretion.

The heavy weight given to the homework reflects its importance in the course. Many students get stuck on homework, particularly when first learning to program with first-class functions. If you get stuck, seek help early. In a small course, each student can get individual attention—take advantage of it. A short conversation during office hours can save hours of aimless frustration.

Format

Your written work must carry your name, and it must be neat and well organized. Use a computer to prepare your written work if you can. Any work that cannot easily be read will score zero points. Clear English expression is required; grammar and spelling count. The same requirements apply to exams.

When you submit work on paper, it must be accompanied by a cover sheet stating your name, computer login-id, the assignment, and the date. Programming assignments must begin with a comment sheet, README file, or introductory section, which describes the project. This description must

Extra Credit

Most homework assignments will offer opportunities to earn extra credit. Extra credit on homework has no particular point value. (Were it otherwise, giving extra credit would amount to nothing more than a sneaky way of assigning more homework.) I use extra credit to adjust final letter grades. For example, if your grade average falls in the borderline between A- and B+, I will assign you the higher grade at my discretion if you have done extra-credit work. I will also mention extra credit if I write you a letter of recommendation.

Extra credit is just that: extra. It is possible to earn an A without doing any extra credit.

Different rules apply to extra-credit problems on examinations, if any.

Readability of programming assignments

A solution to a problem is of little value if that solution cannot be understood and modified by others. For that reason, your homework will be graded on your explanation of what you are doing as well as your results. For many homeworks, especially those involving substantial programming, half of your grade will be based on your explanation. For most homework assignments, your explanations should appear in a README file that accompanies the assignment.

Appropriate explanations vary with the size of the problem.

For these kinds of small problems, the best method of explanation is comments in with the source code itself. For these larger problems, you must describe your thinking at least as well as your code. These kinds of long explanation should be in the README file, not in the code itself. It is as bad to write too much explanation for a simple solution as to write too little explanation for a complex solution.

Good programming style and documentation are essential ingredients in a readable assignment. Good style includes the use of functions, modules, and abstract data types where appropriate. Select algorithms appropriate to the task at hand, and make your code structured and easy to read. Good use and placement of documentation is vital. Lots of comment text does not necessarily mean good documentation. Documentation should should focus on high-level issues such as design and organization, data representation, and data invariants. As noted above, even programs that run perfectly will lose points for poor documentation.

Documentation is a deep topic in its own right, which I am not prepared to address here, but here are a few suggestions. Good large-scale documentation should answer such questions as:

Large-scale documentation is usually not a good place to list a lot of information about the names of functions and their arguments and other low-level details that are most easily understood in the context of reading the code.

Small-scale documentation (comments in the code) should say

Please don't use comments to repeat information that is readily available in the code. Here is an example of poor style:
; (example of poor commenting style)
;
;  Function: caar
;  Description: Returns the car of the car of the given element.
;
(define caar (x)
  (car (car x))
)
Everything in the comment is more easily learned just by looking at the code. Here is an example of better style:
; (example of better commenting style)
;
; Visit vertex and every successor of vertex that appears in edges,
; in depth-first order.  Executed for side effects on the global 
; variables output and visited.
; Graph is the complete list of edges in the graph; 
; we use structural recursion on edges.  

(define dfsvisit (vertex edges graph) 
  (if (null? edges) '()
      ( ...  (dfsvisit mumble (cdr edges) graph) ...)))
The comment explains what the function is doing, notes that there is no return value but there are side effects, and explains what the parameters mean. The comment also explains why the function terminates (the key phrase is ``structural recursion''). This comment should be supported by comments on the global variables output and visited, saying what they represent and what the representation invariants are.

Here are two examples of very poor commenting style:

   ++i;   /* Use the prefix autoincrement operator to increase i by one. */

   for (;;) {   /* Infinite loop. */

You may write documentation using appropriate comments and a README file, or you may wish to use the noweb tool for ``literate programming.'' Literate programming provides a way to mix code and documentation freely, then extract the code automatically. If you use a literate-programming tool, you can combine everything you submit into a single source file and dispense with a separate README file.

Guidelines for coding style

Code you submit should be accepted by the appropriate compiler without errors or warnings.

Your code must not wrap when displayed in 80 columns.

Your ML code must not have redundant parentheses, as described in the relevant section of the ML supplement.

We emphasize readability and clarity, but we do not enforce any particular coding style. TFs will, however, deduct points for things that are obscure or difficult to read.

Collaboration

Programming is a creative process. Individuals must reach their own understanding of problems and discover paths to their solutions. During this time, discussions with friends and colleagues are encouraged—you will do much better in the course, and at Harvard, if you find people with whom you regularly discuss problems. When the time comes to write code, however, group discussions are no longer appropriate. Each program must be entirely your own work.

Do not, under any circumstances, permit any other student to see any part of your program, and do not permit yourself to see any part of another student's program. In particular, you may not test or debug another student's code, nor may you have another student test or debug your code. (If you can't get code to work, consult a TF or the instructor.) Using another's code in any form or writing code for use by another violates the University's academic regulations.

The standard penalty for violating these rules on one part of one assignment is to receive a zero for the entire assignment and in addition to receive a reduction of one letter grade for the course. This penalty may be adjusted at the instructor's discretion, up to and including the assessment of a failing grade for the course. Repeat offenses will be dealt with harshly. Serious cases, in which the instructor believes there is intent to deceive, will be dealt with by the Administrative Board of Harvard College.

The same standards apply to other homework assignments; work you submit under your name must be entirely your own work. Always acknowledge those with whom you discuss problems!

Use of the library

You may look in the library (including the Internet, etc.) for ideas on how to solve homework problems, just as you may discuss problems with your classmates. Library sources must be acknowledged when you submit your homework, even if you find little or nothing useful.

Some students rely heavily on the library. Although this is permitted within the letter of the rules, I discourage it. I assign homework problems not because I want to know the answers, but because doing homework is the best way for you to learn. While library skills are important in our profession, the homework in this course is designed to develop other skills that are even more important. Remember, you will not have the library with you when you write your exams or go on job interviews!

Late Policy

Homework that is submitted electronically (most homework) will be due at the 11:59 PM on the due date. We will grant an automatic extension of ten minutes at no cost to you, so the real deadline is 12:09 AM the following day. If you plan on submitting your work at midnight, you will have nine minutes for last-minute changes.

Homework that is submitted as ink on paper will be due at 5:00 PM on the due date, also with an automatic ten-minute extension.

Late policy is roughly consistent with other CS classes. Each student has a budget of fourteen ``late days'' to be spent as follows:

Special arrangements can be made for late homework in the event of a medical or family emergency. Please ask your Senior Tutor to get in touch with the instructor.

Solutions to homeworks will not be placed on the Web until the last assignment is turned in or until the 48-hour deadline has passed. Students turning in homework on time may have solutions sent to them by sending a request to the course staff.

Regrading

If we have makde a mistake in grading a homework assignment, you have seven days after the return of the assignment to call the mistake to the attention of your TF or instructor. In such cases, we will reassess the entire assignment and assign a new grade. The new grade may be higher or lower than the original grade.

Submission

To submit an assignment
  1. Log onto nice.
  2. cd into the directory you wish to submit.
  3. Type the command submit-assignment, where assignment may be intro, scheme, etc., as listed on the homework page.
If you get a warning while submitting, fix the errors (i.e. missing files or non-compiling code) and resubmit. The submit commands are in ~cs152/bin, which must be part of your path.

Questions and discussion

Questions should be emailed to cs152@fas. Please do not email the course staff directly to their personal accounts.

We make every effort to answer questions once a day, even on weekends. In the last two days before an assignment is due, we strive for even quicker turnaround. Answers to questions and other useful information will be posted to the harvard.course.cs152 newsgroup. You can read this newsgroup using your favorite news reader (e.g. rn, xrn, emacs rnews) or via a browser such as Internet Explorer, Mozilla Thunderbird, or Lynx. For example:

  setenv NNTPSERVER news.fas.harvard.edu
  lynx nntp:harvard.course.cs152
If you prefer GUI-land, Thunderbird will ask for the NNTP server (nntp.fas.harvard.edu) at startup time. You can then browse to the Harvard groups and subscribe.

It is also possible to use PINE to read news:

  1. Start PINE.
  2. Hit 'S' for setup.
  3. Hit 'C' for config.
  4. Scroll to 'nntp-server'.
  5. Hit 'C' to change value.
  6. Type news.fas.harvard.edu and press enter.
  7. 'E' to exit and save changes.
After that, you will see your news groups under the "Folder list":
     Mail
         Local folders in mail/

     News on news.fas.harvard.edu/nntp
         News groups on news.fas.harvard.edu/nntp
You will need to scroll to 'News' and then use 'A' to add the newsgroup harvard.course.cs152.

If none of these alternatives work for you, you can always run tin on the nice servers, although I find tin rather complicated and difficult to use:

  setenv NNTPSERVER news.fas.harvard.edu
  tin -r harvard.course.cs152

Sections

Sections are devoted working on problems that are related to the homework. They are recommended but not required. Section exists only to help you; you are not being evaluated on your performance in section.

Handouts

Copies of all class handouts should be available in the file cabinet across from Professor Ramsey's office (Maxwell Dworkin 231).

Computer software and accounts

Software for the course is available on the the FAS New Instructional Computing Environment (nice.fas.harvard.edu). Students not already having accounts should call FAS for assistance.

Source code is available for all of the software used in the course. It is not, therefore, a requirement that you do your development work on the FAS servers. If, however, we provide test binaries or other tools for you to compare your work against, they will probably be available on the FAS servers only. When possible, we will link these binaries statically so you can use them on other Intel Linux systems.

Stupid software tricks

The nice servers have the wonderful ledit program, which is extremely handy for interacting with our interpreters. Try typing, e.g., ledit impcore, and you will be able to get an interactive editing loop with the impcore interpreter.