Grading

Projects will be graded by the instructor. However, there is no predefined grading scheme. A grade will be given based on the approach used to solving the given problem, including

• the novelty of the approach
• the thoroughness of the project report
• the clarity of the report presentation
• the quality of the code
• the correctness and generality of the proposed solution
• the efficiency of the proposed solution

Several of the projects may have competitions to see whose program ``wins'' against other programs. The outcome of these competitions is not a factor in the project grades. The competitions are intended to stimulate the development of new ideas, and it is the ideas that are important. The competition rankings are for fun and pride only.

There is no restriction on communication between different groups. However, if a certain idea X is proposed by group A, and group B thinks the idea is so cool that they want to use it too, then group B can do so as long as group B explicitly cites group A's contribution in their report. So, for example, suppose that during the second class discussing project 1, a student Jane Smith reports to the class that she has discovered that a certain algorithm in the literature applies to the problem. Then other groups are still free to use that algorithm too, but in their report they must include an ``acknowledgements'' section with text something like

We acknowledge the contribution of Jane Smith who observed that the 17-starving-philosophers-named-Josephus algorithm applies to this problem.

Any information supplied by the instructor or teaching assistant need not be acknowledged in this way. Published sources and Web sources should be formally cited using a bibliography.

If a group develops a tool that is potentially useful to other groups, then you are encouraged to share it (and it's use should be acknowledged). However, this sharing should be limited to tools that aid the development of solutions (eg., visualizers, compilers, etc.) and not the solutions themselves. Similarly, external data that might be useful should be shared. For example, if we had a map-drawing project, then if somebody downloaded from the Web some datasets describing real-world maps that could be used to test project code, that data should be shared and used with acknowledgement. (For the purposes of this course, the use of other people's contributions without acknowledgement is considered cheating.)

Outside people may be consulted for general references, but shouldn't be asked to contribute to solving the problems themselves. This is a course whose primary purpose is to give you the opportunity to tackle challenging problems yourselves. If you consult outside people, they should also be acknowledged.

While groups are permitted to communicate with each other, they are not encouraged to work so closely together that they really could be described as an 8-person group. Groups must submit their own reports, and the reports should be written independently of other groups.

A report must also include a section titled ``Summary of Contributions'' that describes (in one or two sentences per person) what each member of the team contributed to the project.

Reports should also contain (where applicable) a paragraph documenting the substantive use of your code in the submissions from other groups. After the final code deliverable, you have the opportunity to browse through the other groups' submitted code to identify such use. Remember that this kind of use is encouraged, and hopefully in most cases the other groups will have told you directly that they are working with your code. The purpose of including this paragraph is to make sure that the instructor can see where groups have had influence on other groups.

Reports should be submitted electronically, as well as in hardcopy on the day of the group presentation. If you don't have access to a color printer, you can ask the TA to print out the report for you. The electronic reports will be made readable by all members of the class after the submission deadline.

Here are the grading proportions:

Project Reports and Presentations	60%
Class Participation	40%

There will be four separate participation grades, one for each project.

All members of a group will, by default, get the same grade for their project report. In rare circumstances, the professor will adjust the grade of an individual member of a project team if there is clear evidence that this member did not make a genuine effort to work on the project.

In addition, you are required to attend all classes. You can miss two classes without penalty. However, the third class missed will result in a drop in the final grade of one fractional grade (eg., B+ to B, or A to A-). If you miss four classes, you will drop a full grade (eg., A- to B-). If you miss five or more classes, you will fail the course. Arriving in class more than 15 minutes late counts as missing the class. (In the event of a medical or other emergency, or religious observance, consult the instructor.)

Tips for writing reports. Focus on the solution of the problem at hand. It is better to say something meaningful about one aspect of the problem than to say something vague about many aspects of the problem. Programs that solve the problems themselves are important, and the component algorithms should be described thoroughly. Tools constructed to aid the development of a solution (e.g., a compiler, simulator etc.) are valuable, but don't waste space and time describing how well such code was written.

See the Computing Science column of the American Scientist for a great presentation worth emulating in this class. For example, see the column from November-December 2000 on Dividing the Continent.