For each project you must be part of a team of two or three students. Each team must hand in a single project report.  For each project, the three members of a team will all receive the same score.  It is your responsibility to find good project partners.  You may stay with the same team for all projects, or switch after one project and before the next.  You may not switch halfway through a project.

Part of the purpose of the team projects is to help you develop your ability to work well with other people.  To help you learn from each project, each team should staple a single copy of this team self-evaluation form to each project report.  Your team should discuss the questions on this form before starting each project.  At the end of each project, you should write consensus answers to the questions on the form.

For most projects you will have a choice of programming languages.  The project descriptions will provide suggestions, but it is your responsibility to choose the best language(s) for each project, to find useful libraries and programming environments, and to install any software that you need.

If you do not have access to sufficient computing resources for the projects, contact the instructor immediately.  You are encouraged to install Linux or some other free version of Unix on a home computer and to use that for most of your software development.  Note that Linux runs well even on the oldest 75 MHz Pentium personal computers, and that you can have Linux and Windows on the same computer, so you do not need to buy a new computer in order to have Unix at home.
 
 

REPORT GUIDELINES

The single report submitted by each team should be well-organized and well-written.  Reports should be as long as necessary to be complete and easy to read, but they should be concise.  The maximum length permitted is 5000 words.

Reports should be formatted very carefully.  Word is not recommended because LaTeX is still far superior for writing technical papers.  Reports should be printed on standard 8.5 inch by 11 inch paper using a laser printer or a high-quality inkjet printer, and stapled together securely.  Reports assembled with paper clips or other insecure bindings will be rejected.  Do not use any plastic or cardboard binders or sleeves.

You may follow either the AAAI Formatting Instructions for Authors or the NIPS*2000 formatting nstructions.  In both cases macros and templates for LaTeX are available.

The main part of a report should not include raw printouts.  Instead, each report should have two appendices, which are not counted in the length limit.  The first appendix should be a printout of the programs written by your team for the assignment (i.e. listings), and the second appendix should be a printout of sample executions of your programs (i.e. a transcript).  A transcript should show sample inputs and the corresponding outputs produced by your programs.  Under Unix, the tee command is useful for producing transcripts.

Organize your report clearly, with sections, subsections, and paragraphs.  Each section and subsection should have a title that is informative about what the section or subsection contains.  For footnotes, citations, and all other questions of style, follow the NIPS or AAAI Instructions for Authors.

Use diagrams, charts, and tables when useful, with full labels and legends.  Microsoft Excel is not recommended for producing graphs that are readable and concise.  Instead, gnuplot under Unix is recommended.  If you are using Linux, Xgfe is a good graphical frontend for gnuplot; try version 2.1-141.  See here for how to output gnuplot charts in eps format for inclusion in LaTeX documents.  Note that Xgfe generates command line input that you can capture and edit and run directly inside gnuplot.  Doing so is useful for fine-tuning figures and for overcoming minor bugs in Xgfe such as xlabel mis-spelled as xlable.  When generating output files with gnuplot, you must delete by hand an existing file with the same name as the desired gnuplot output file, to overcome a gnuplot file-handling bug.
 
 

HELP WITH WRITING

If you are not confident that you know how to write good technical papers, then you should seek help and advice.  The instructor is available to assist you.  However you should also use other resources.  In particular you should use the UCSD Office of Academic Support and Instructional Services for help with writing.  According to their web page:

"The Writing Center offers the UCSD community FREE one-to-one conferences on any kind of writing project ... Various workshops are offered, including ... essay writing ... The OASIS writing test assesses your strengths and weaknesses in writing and editing academic papers. ... Individual tutorial services are available to students whose first language is not English."

USEFUL LINKS ON WRITING

The following report contains everything that a computer scientist needs to know about technical writing. Although the report is protected by copyright law, it is available for viewing on the web.

Technical Writing for Computer Engineers and Computer Scientists by Kevin Karplus and Dan Scripture.

From the report: "This document contains course notes and exercises for a course in technical writing. The course is intended for third-year computer engineering majors, and emphasizes technical documentation directed to engineers, engineering managers, technical writers, and other specialized audiences. Exercises include job applications and résumés, memos, electronic correspondence, algorithm description, in-program documentation, naive-user documentation, survey articles, recommendation letters, proposal writing, document specification, progress reports, formal technical reports, and an oral presentation."