Paper Guidelines for CS 97

Here are a few guidelines to keep in mind when writing up your project. The paper deadline is 5:00pm Friday, May 14.
  1. There is no specific length requirement for your paper. It should be as long as is necessary to clearly and thoroughly explain what you did. For a semester-long project, I would expect that something like 10-15 pages at the very minimum would be necessary.

  2. You should include a bibliography at the end of your paper listing your references (books, articles, Web sites, software, or any other sources of information or inspiration that you used).

  3. You should turn in a complete listing of your project source code, but separately---not as part of your paper. Please print out your code in a nice format using a smallish font size. I'd recommend the Unix command

    psf -2xn [text-file] | lp

    which generates nice source code listings while keeping paper usage at a minimum. If for some reason you feel that it's crucial to discuss details of your code in your paper, then put the relevant code in an appendix. In general, though, it's almost never necessary to include actual source code as part of a research paper.

  4. The overall organization of your paper should look something like this:

I. Introduction and background

Your introductory section should set the stage for explaining what you did. Here you should summarize the background information that the reader will need in order to understand the relevance of your work. You may assume a general familiarity on the part of your reader with GAs and evolutionary computation, so you don't need to re-explain the basics of GAs, crossover, mutation, and so on. But don't assume the reader has any prior knowledge of your particular project.

II. Experimental design and methods

In this section, you should describe the actual details of your project. You should explain clearly what questions you were trying to answer, as well as how you decided to go about finding the answers. If you designed a GA to perform some task, you should describe in detail the genome encoding method(s) you used, exactly how your fitness function worked, the various GA parameters you used such as population size, crossover and mutation rates, and the precise way your evolutionary algorithm worked (since "GA" means many things to many people). Giving concrete examples will especially help here! In short, you should describe your project in sufficient detail so that (1) the reader has a crystal-clear picture of what exactly you did, and (2) the reader could re-create your experiments if desired.

III. Experimental results

This section should thoroughly describe the results you obtained. Whenever possible or appropriate, you should try to present your results pictorially using, say, graphs or histograms. Pictures will usually convey the gist of your results more effectively than, say, large tables of numbers or symbols. Of course, how to best present your results depends on the particulars of your data, and is a judgment call that you'll have to make. If you use graphs, they should be clearly labeled, and the body of your paper should describe exactly what quantities are being graphed.

IV. Interpretation and discussion of results

Here you should tell your reader what all this stuff means. How should the results just described actually be interpreted? Don't leave it up to the reader to draw their own conclusions from your data---spell it all out explicitly for us. How do your results translate into answers to the questions you posed at the outset of your project? If your experiments "failed" (your GA never converged, for example), is this because your experiments were not well designed, or is the failure telling you something more interesting about the problem? If your experiments "succeeded", what exactly have you learned that you didn't know before?

V. Conclusions and future work

This section doesn't have to be very long, or you could combine it with the previous section if you wish. Now that the reader has a detailed picture of what you did, this section should simply reiterate and sum up the overall conclusions you were able to draw from your project work. Furthermore, if you have ideas about where the research could go from here (even though you yourself might not have any plans to continue working on it), you should outline those ideas. Perhaps you have a hunch or two about why you got the particular results you did, though you didn't have time to follow them up, or perhaps there were other things you wanted to try but never got around to it. Some readers might be interested enough to continue the work on their own, so pointing out a few directions in which to go would be helpful.
This is a pretty generic outline of a research paper, and you'll have to adapt it to fit the particulars of your project, of course. But keep the main points in mind as you write up your project results. Finally, it may seem nit-picky, but using correct grammar and spelling is very important! Don't give me a sloppily-written paper containing lots of spelling or punctuation errors or tortured grammar. You want people to be impressed with the ideas in your paper and to take you seriously, not to be amused by the level of your English. Nothing puts your work in a bad light faster than sloppy writing, so make the effort to proofread what you've written. If you have other questions about your project writeups, feel free to email me or come by my office.