Since part of the goal of these projects is to teach you how to write
papers, here are some pointers. Some of the problems with the
writeups stem from the fact that this is both a project writeup and a
(simulated) paper submission. These are fundamentally different
beasts, and you had to make some hard choices.
Be kind to your reader
Remember, your goal in writing a paper is to make people want to read
it, the two ways to do this are (1) do interesting research and (2)
make the reader's life as easy as possible. Very often, someone is
doing a lit. search and needs to decide quickly if the paper is
pertinent to their needs. It's common to read an abstract and then
decide if the paper is worth reading, so put enough information in the
abstract for someone to make that judgement, while keeping it short.
It's also common to read the introduction, and then the conclusion to
confirm that topic of the paper is what the reader wants to learn
about. So the introduction should tell enough to understand the basic
idea of the paper, and the conclusion should summarize the major
contributions. Next the reader may skim through the figures
(particularly the evaluation) to determine if the results are strong
enough to be worthwhile, so the figures should stand on their own.
Captions should entirely explain how to read the figure. (While
analysis of what the figure "means" goes in the paper.) Finally, the
paper is read in full. Pay close attention to organization and level
of detail to make the paper easy to read.
Think carefully about how to organize your paper. It should flow so
that each section leads naturally to the next. Your reader should not
need to go back and forth looking for information that is used
together but presented separately. Even more importantly, you should
avoid forward references, that is, references to terms or concepts
which have not yet been introduced. To help with the flow of your
paper, think about the storyline. E.g. Present a problem, present an
existing solution, show that the solution is lacking in some way, give
some intution about why the solution is lacking, perhaps support the
intution with experimental results, use the intuition to derive a
proposed improvement, show the proposed improvement really is an
improvement." Typically, you'll break out your sections as follows:
- Should say what problem you're solving, and, in
broad terms, what your solution is.
- Should state the problem, briefly describe
current approaches (if appropriate), describe problems with these
approaches that are addressed by the research (if appropriate) and
briefly describe the proposed solution. It should also contain a
roadmap to the rest of the paper.
- Following section(s)
- Should further describe the problem and
current approaches in just enough detail to make the proposed solution
understandable, and then present the research.
- Show that the solution works, or investigate why
it doesn't. You need to describe your methodology, unless you're
using something really standard (and you still need to say what you're
- Related work section
- Should describe other similar methods,
and how each differs with the proposed solution.
- Should recap, summarize the
contributions of the paper and possibly propose further extensions.
Figure and Table Captions
Tables and figures should have explanatory captions. The reader
should be able to look at the figure and its caption and know exactly
how to read it. This also means all axes on graphs should be labeled,
including units. If something isn't obvious (e.g. "c/v ratio"),
explain it in the caption (e.g. "The x axis is the ratio of clauses to
variables in the formula.") Of course, the analysis of the figure or
table belongs in the paper.
Concise, complete explanations
Take a few moments to step back and read your paper with the eyes of
an outside reader. Make sure you're not using concepts or terminology
which aren't explained. Make sure you aren't needlessly describing
things in more detail than is needed. For example, when describing an
algorithm you're extending, present the psuedo-code and describe how
it works briefly, then cite the original work so the reader can find
out more if they want to.
You should have complete and correct references and consistent
citations. Citations should appear:
- The first time you mention an algorithm from another paper
- You make a non-trivial claim supported by another paper
- You mention a result from another paper
What to include/exclude
This is one of the areas where paper submissions differ most from
project writeups. First of all, in a paper submission, you don't
always write about everything you did.
One of the big mistakes many groups did was to spend a lot of time
talking about the work they did to reproduce previous results
(e.g. finding a critical value near 4.3 - "here are several pages of
graphs showing our findings about the critical value") and not much
time talking about what they did that was different or involved making
choices ("we came up with a novel way of tuning the algorithm which
resulted in a p value of .6, here's a two line table to show that that
value works well.") The reasoning behind design decisions should be
explained (either by reference to another paper, by experimentation or
This is where it's important to keep your target audience in mind.
Don't be overly verbose about things they can be expected to know, and
do explain things they might not know.
Back up your statements. Any time you make a claim, be prepared to
back it up. You can do this either with data, with a citation to
previous research, or by arguing from first principles. The last
strategy is fine, if the arguement holds, but remember, an intuition
isn't an argument.
Many of the papers had language which is fine for a project report but
just doesn't work in a paper submission. The only way to really get a
feel for what type of language is expected is to read, read, read.
Also, plan to do revisions and rewrites. A good paper doesn't happen
on the first try.