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.
- 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.
- 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).
- 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.
- 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.