5.5 -- Writing a Paper

(from [H] Ch. 6)

"Go straight to the point, rather than begin with an historical reference or resounding banality..."

Audience

Identify a typical reader.

What background does the reader have?

specialist versus non-specialist
undergraduate versus seasoned researcher

Does the work build on past works that the reader is likely to have read, or is it a novel approach?

Does the work combine two distinct fields (inter-disciplinary)?

Extremes:

A survey paper that must motivate a work and be self-contained for the non-specialist.
A paper proving new theorems on interconnection networks, that builds on hundreds of past papers.

From "Guidelines for Authors" in SIAM Review:

"In their introductory sections, all papers must be accessible to the full breadth of SIAM's membership through the motivation, formulation, and exposition of basic ideas. The importance and intellectual excitement of the subject of the paper must be plainly evident to the reader.... The primary threads of the intellectual fabric of the paper can never be hidden by jargon, notation, or technical detail."

Organization and Structure

I personally try to identify a strong "theme" for a paper before doing any writing or outlining.
Examples of alternate themes for a paper I am now writing: (ranked from weakest to strongest)
1. An Overview of Chitra, a System for Modeling
2. Visualizing Categorical Data, and its Applications to Modeling
3. A New Model of Transient Behaivor
The theme I choose is guided by our technical results to date.
Higham suggests ranking your contributions, to identify the most important. Use the rankings to decide where to put the emphasis. The rankings also help you to write the title and abstract.
You should aim to
- minimize the length
- avoid repetition
- be concise
- state the general problem or solution, then lead to the specific result
Design the paper both for sequential and random acess. For random access, be sure definitions, equations, algorithms, and results are clearly displayed.

Title

For every person that reads the whole text, 500 read only the title!
The title must balance two objectives:
1. catch the attention of the browser
2. provide a terse summary of the content to help someone carefully scanning the table of contents of a journal
Give preference for short titles:
"A decomposition of compact continua and related results on fixed sets under continuous mappings"
versus:
"Simple links and fixed sets"
Avoid vague titles: "Parallel Programming Notes"

Examples of good titles...

Computing the eigenvalues and eigenvectors of symmetric arrowhead matrices

[lively and informative]

How and how not to check Gaussian quadrature formulae

["How to" titles immediately arouse the reader's interest]

Gaussian elimination is not optimal

[A short, one sentence paper summary can make a great title]

How near is a stable matrix to an unstable matrix?

[A title that asks a question is direct and enticing]

ALGOL68 with fewer tears

[One can't help be curious enough to read the abstract!]

The art of programming

[Knuth's provocative title has inspired similar titles on other papers]

The ubiquitous B-tree

[An unusual but apt word catches the browser's attention]

Breaking long titles across lines...

Rules of thumb

a phrase should not be split between lines:

     Bad:

          Numerically Stable Parallel Algorithms for
          Interpolation
     Better:

          Numerically Stable Parallel Algorithms
          for Interpolation

the lines should not differ too much in length:

     Bad:

          An Iteration Method for the Solution of
          the Eigenvalue Problem
          of Linear Differential and Integral Operators
     Better:

          An Iteration Method for the Solution
          of the Eigenvalue Problem
          of Linear Differential and Integral Operators

a line should not start with a weak work such as a conjunction:

Bad: A Method for Cutting and Pasting Text Segments Better: A Method for Cutting and Pasting Text Segments

Author List

There is no universal rule of how to order authors in a multiply authored paper. Some conventions are:
- authors are listed in order of decreasing amount of work
- authors are listed alphabetically
- the senior person (such as the director of a lab) is listed last
Sometimes two authors that frequently publish together may swap orders on each paper (e.g., Hennessy and Patterson).
Be sure to chose the name that you wish to be recognized by in your career, and use only this name on all works: Ernie Page versus Ernest H. Page This can pose a problem if you change your name after marriage.

Date

Always date your work.

Even if you do not publish the work, dates are essential if you

patent an idea or copyright the text, or
give a copy to someone else so they know when it was written.

Dating helps to avoid confusing drafts. I usually put the date into the header or footer to avoid confusing sheets of paper on my desk.

Put the date on a line by itself, usually after the author's name, on the first page of the document.

Abstract

The abstract summarizes the paper's content.
The abstract must be self-contained.
The reader must be able to decide whether to read the paper based on the abstract.
There are often length limits on abstracts (e.g., 200-300 words) -- obey them.
Be sure to highlight the paper's main contributions in the abstract.
The abstract is usually one paragraph.
Avoid mathematical equations in the abstract, particularly displayed equations. (These may cause problems for abstract services.)
Do not cite references by number in the abstract. If a paper must be mentioned, spell it out in full:
An algorithm given by Boyd [Linear Algebra Appl., 9 (1974), pp. 95-101] is extended in this paper.
Make the abstract easy to understand for those readers whose first language is not English. Abstracts are sometimes translated to other languages.
Some journals disallow the word we, preferring the passive voice.
The abstract should convey the paper's conclusions.
Avoid starting an abstract with common phrases (e.g., "This paper..." or "In this paper...")

Variations on abstracts:

Some conferences request submission of extended abstracts -- typically 50% the length of a full paper.

Conferences often publish poster abstracts -- typically one or two page summaries.

If you give a talk or serve on a conference panel, you may be asked to abstract your presentation for publication in a proceedings.

Key Words and Subject Classifications

Journals may ask for one or both of the following:

Keywords
Computing Reviews subject classifications

Keywords:

Five to ten author-chosen words that best characterize the paper. Words are used in computer searches, therefore anticipate words a reader might search.

Subject Classifications:

The Computing Reviews Classification System is a four-level tree that has three numbered levels and an unnumbered level of descriptors. The top level consists of eleven nodes, denoted by letters A (General Literature) to K (Computing Milieux).
Example:
G.1.3 [Numerical Analysis]: Numerical Linear Algebra - sparse and very large systems.

The Introduction

The first sentence of a paper should

be the best in the paper
suggest the problem under consideration
capture the reader's interest
gently translate the reader into the body of the article

Example:

Formation of models of physical behavior underlies science. Yet our ability to construct behavioral models of parallel and distributed programs is very limited.

These opening sentences had enough impact on one reader that he quoted them to start his paper!

What Goes Into an Introduction?

Motivate why you're examining a problem area.
Define the problem (which may first require some notation).
Outline your solution to the problem:
- Summarize the results achieved.
- Give the punch-line or the reader may stop reading!
Summarize contributions in a thesis or dissertation.
Summarize the organization of the rest of the paper, if the paper is long.

Length of Introduction

Keep the introduction short: a few hundred words.

Try deleting the first one or more sentences of your introduction, and see if it still makes sense:

To understand the central challenge in distributed and parallel processing, one only needs to read the popular press. Recent Sunday editions of The Washington Post contain articles querying business and academic leaders on whether parallel processing will fulfill its touted benefits. A common theme emerges in each: although we can manufacture parallel computers, can we program them?

versus:

Electronics technology has reached the point today where we can manufacture parallel computers -- but can we program them?

Computational Experiments

Rarely do Computer Science "experiments" follow the classic science model: hypothesis, experiment design, results, conclusions.

More often, computer scientists report results of program measurements, referring to these as experiments.

Often papers report data collected from execution of programs to

test a hypothesis
compare competing methods
verify theoretical predictions
characterize empirically the error in a method
characterize the rate of convergence of an algorithm
characterize the dynamic behavior of a program or system
characterize empirically the performance (e.g., speedup) of a parallel algorithm
tune parameters in a code or a system
demonstrate "proof of concept" (e.g., virtual memory can be implemented on a message passing system with reasonable performance)

"One editor of a numerical analysis journal commented that his primary reason for rejecting papers is that the computational experiments are unsound." [H, pp. 78-79]

Be sure to state clearly:

the hypothesis tested or the experiment objective
the experimental method with sufficient detail so that a reader can replicate the experiment
all required parameters
all necessary algorithms
the type of random numbers (e.g., Normal (0,1)) and the type of random number generator used (e.g., LCG)
the machine model, processor speed, memory size, OS version...

When showing convergence or accuracy of a method, tabulate errors rather than the values themselves.

Report normalized errors.

[H] suggests that for an approximate solution X to Ax=b, report |b-AX| / (|A||X|+|b|)).

Repeat the experiment at least three times, and report at least the sample variance of three observations, or even better the confidence interval. Why repeat the experiment?

Factors such as cache-warmup can cause variation on a single-user machine.
Background traffic in a network or a multi-user system necessitates tens or hundreds of observations

Tables

Please review the examples on pp. 81-82 of [H].
If a reader should compare like quantities in a table, arrange those quantities in columns.
Do not state numerical results to more significant figures than are known for the data.
Carefully choose between a table and a graph. Use a graph:
- when you wish to show a trend
- when there are more than 20 numbers [Tufte, p. 56]
Avoid tables with too much detail -- consider using an Appendix if you must show many details.
Use a table design that is as simple as possible to improve readability. For example, omit unnecessary rules (lines).
Summarize the table in words when you first refer to it in the paper.

Citations

Style of citations

Styles:

See Abrams (1).
See Abrams [1].
See Abrams [ABR94a].
See Abrams 1. (Symbol "1" should be a superscript.)
See Abrams (1994a).

The organization for which you work or the journal in which your work is published will set the style for citations.
Avoid using a citation as a noun, especially at the beginning of a sentence:
Awkward: [1] proves the theorem.

Better: Jones [1] proves the theorem.
When citing a specific item in a book, use a chapter number or page numbers.
Example: ...several variations exist [2, Chap. 7].
Order citations that appear together in ascending order (citation number or explicit date).

Examples:
Several variations exist [1,3,9].
Variations have been developed by Smith (1974) [9],
Barnes (1982) [3] , and Jackson (1989) [1].
Incorrect: Several variations exist [3,9,1].
Include the author's name unless the citation is more than just a passing one. This is more informative and "has an enlivening effect because of the human interest it introduces" [H, p. 83].

When to Cite

Add a citation when:

you are referring to someone else's ideas or results
you do not want to define a term (e.g., virtual reality ), but want to use the definition of an expert in the field.
you want to support an argument that you are making (e.g., why formal methods are important to software engineering)

But be careful not to overuse citations. Do not cite the same paper five times in one paragraph!

Be sure to clearly identify what part of a paper is your own creative idea and what is existing literature. I suggest using words such as

We propose...
Our use of geometry to solve the problem is, to our knowledge, novel.

Location of citations

Locate the citation in a place that does not intrude on a sentence.

     Awkward: The method was found [17] to be unstable.
     Better:  The method was found to be unstable [17].

Be sure that the sentence reads properly when the citation is deleted.

     Incorrect:  This question has been addressed by [5].
     Correct:  This question has been addressed by Ott [5].

Reference lists

Carefully choose what to include and exclude from your reference list!

Some readers read the reference list after the title, and ignore the paper if the references are unfamiliar.
Editors often choose reviewers from the reference list.
You may wish to include a key paper in the reference list.
Sometimes you must balance making the list comprehensive and consuming too many pages when there is a page limitation for a paper.
Keep the reference list timely -- even while the paper undergoes years of referee delay.

Conclusions

A conclusions section is optional. (You may simply make conclusions in the introduction.)

The conclusions section should not:

repeat sentences that appeared earlier in the paper
summarize the paper, unless accompanied by new insights

The conclusions can:

draw broad inferences from the data or methods given earlier
speculate on or posit facts or explanations that might hold true but are unsupported
list open problems
list directions for future research
mention work in progress
significance

It is dangerous to refer to works in progress -- they may never materialize! It is safer to put intermediate results into a technical report, and then cite the technical report.

Acknowledgements

You should acknowledge

financial support for your work
"This research was supported by the National Science Foundation under grant DCR-1234567."
[Some funding agencies tell you the exact words to use!]
"This work was supported by an SERC Fellowship."
individuals that read the manuscript in draft form
"I thank X for helpful comments on the manuscript."
[Note: X may be the anonymous referees.]
individuals with whom you discussed the ideas
"I thank X for discussions during the development of this work."
facilities or software systems essential to your work
"X provided the database traces used in this paper."
"The experiments were performed using the computer facilities of the Argonne National Laboratory."
"The illustrations were drawn using Jane Ott's pic software.

Appendix

An appendix can be used to provide essential information that would distract the reader if it were placed in the paper body.

Examples:

detailed algorithms
proofs that do not enlighten the reader, but are needed to convince the reader that a theorem is true
detailed results of a computational experiment
a computer program listing (in a technical report, thesis, or dissertation)
a formal specification of something (i.e., a protocol)
a table of values (e.g., the values of the Chi-squared distribution in a statistics text)

Reference List

If I were paid based on the number of errors that I found in a manuscript, I would always start with the reference list!

Correct example:

J. H. Wilkinson, Error analysis of floating-point computation, Numer. Math., Vol. 39, No. 5, Nov. 1983, pp. 639-648.

I highly recommend use of an automated tool to maintain a bibliography for everything you write, and to automatically generate a reference list using a consistent style.

Every journal has its own style of references. Usually the copy editor will change your style to fit that of the journal.

Hence

You do not need to carefully follow the journal's style (unless the editor explicity instructs you to do so)
You must, however, put all essential information in your reference list, including:
- page numbers (for serials)
- issue number (for serials)
- volume number (for serials)
- publisher (for books)
- year of publication (for a book, the latest year)
- edition, for a book with more than one edition
- month of publication (for technical reports or conferences)
Higham suggests that an address can be ommitted with well-known publishers

Specific suggestions on reference lists

Do not cite a work A that is referenced in paper B until you personally find A in the library!
- Sometimes B contains an error in the reference list.
  Higham describes a paper by Vieira and Messing, cited as Viera only by one author. Afterwards subsequent authors ignored rule (1). As a result, the paper was placed too low in a list of most-cited papers.
- Sometimes the author of B did not carefully read A, and misinterprets A. You do not want to look as ignorant as the authors of B!
Always give all initials of an author -- not just the first or first and middle. It is not unusual for multiple researchers to have the similar initials!
M. Abrams (that's me)
M. A. Abrams (another person who works in simulation)
Be consistent -- always use the first name or always abbreviate the first name.
Prof. Balci argues that you can inadvertently insult someone by failing to use their first name when you use the first name for other authors in a reference list.
Copy bibliographic information from the first page of a journal paper, not the title page of the journal.
Before citing a technical report, ask the author if it has appeared in a conference or journal. Also
- the title may have changed
- the content may have changed
In book titles, add a colon to separate a title from a subtitle, even if the colon does not appear in the book.
K. M. Chandy and J. Misra, Parallel Program Design: a Foundation, Addison-Wesley, 1988.
Use italics for the name of a separately published work (e.g., book, conference proceedings name, video tape, technical report). Use quotations (or lower case letters) for works published within another work (e.g., papers).
You may want to give the International Standard Book Number (ISBN) for more obscure sources:
0-89871-314-5
0 = Publisher from English speaking country
89871 = Publisher (SIAM)
314 = book's individual number (Book 314 from SIAM)
5 = checksum

There is also an International Standard Serial Number (ISSN) for serial publications.
Be sure that all references are actually cited in the paper! Some copy editors will ask you to do this on the paper proofs.

Specifics and Deprecated Practices

Dangling Theorems

Avoid this construct, which tries to avoid repeating the word "theorem":
The result is proved in the following Theorem 3.13. If f is ...
Do not use a section title as the antecedent of a pronoun:
5.1. Accuracy of the Computed Solution.
It depends on the machine precision....

Naming Mathematical and Other Objects

Number only those equations that are referrence elsewhere in the text or which are likely to be cited by other authors.
Refer to an equation as follows: "Now we solve (3.9)."
LaTeX will automatically number equations, theorems, lemmas, definitions, ...
Give all algorithms a name.
Consider giving the problem that you are solving a name, especially so that subsequent authors can refer to it:
Example: The synonym problem in memory addressing is solved by ...

Footnotes

Use footnotes sparingly. Consider using parentheses instead.
Some journals do not allow footnotes.
The correct use is to "add a note or comment that would deflect from the main message of the sentence." [H, p. 91]
Be careful not to put critical information or definitions into footnotes that a reader may overlook.

Captialization

References to proper nouns should be capitalized:

See Theorem 1.5, the proof of Lemma 3.5, and the discussion in Section 6.
See the last theorem, the last lemma, and the next section.

"This Paper Proves..."

Awkward:

This paper proves....
Section 3 shows....

Better:

We prove ....
We show ....
Theorem 2 states....