Common Mistakes Found in Students' Technical Reports in Previous Semesters

Technical Writing

  1. Do not use the first person singular pronoun "I" even if a paper was written by a single author. Similarly, don't use "my" and use "our" instead. It is also very unusual to use the second person singular/plural pronoun "you" in a technical article.
      Bad:    I present the time complexity of an algorithm in this paper.
      OK:     We present the time complexity of an algorithm in this paper.
      Better: The time complexity of an algorithm is presented in this paper.   [traditional style:  passive voice]
              This paper presents the time complexity of an algorithm.          [modern style: active voice]
    
    If the subject of a sentence is truly an author or authors, the first person plural pronoun "we" is OK. Otherwise, it is recommended to write the subject explicitly and avoid a pronoun unless what the pronoun refers to is definitely obvious to the readers, where the subject is an agent of the action (i.e., verb) mentioned in a sentence.
      Bad:    We first sort points in the nondecreasing order of their x-coordinate values.
              Then, we find a closest pair of points.
      Good:   An algorithm first sorts points in the nondecreasing order of their x-coordinate values.
              Then, the algorithm finds a closest pair of points.
    

  2. Write sentences in the simple present tense unless another tense is definitely needed (e.g., in the last section "Conclusions", sentences summarizing a paper are written in the past tense).

    Examples:

      "This paper models a problem of finding
      shortest paths from a single source to
      all other vertices in a digraph."
    
      "This paper presents an algorithm for
      determining whether a given positive integer
      is prime."
    

    Examples of Exceptions:

      "In 1883, the puzzle called the Towers of Hanoi was invented
      by the French mathematician Édouard Lucas."
    
      "E. W. Dijkstra proposed a greedy algorithm
      for finding single-source shortest paths in
      1959."
    
      "Although we have presented an O(n log n)
      algorithm for MPT, it remains unknown whether
      the algorithm has an optimum time complexity.
      That will be one of our future research topics."
    

  3. Keep sentences simple and short. Avoid to write a lengthy sentence that connects clauses one after another.

  4. Do not use contractions of two words such as "isn't", "can't", "we've", and "haven't".

  5. Organize a paper hierarchically with sections that may be decomposed into subsections which are further broken down to paragraphs. To begin writing a paper, design "Table of Contents" first as an outline of the paper. Then, for each section or subsection, try to list important phrases or sentences that will turn into paragraphs by elaborating them.

    → Step-wise Refinement in Top-Down Design

    One Paragraph ←→ One Issue (Modularity)

  6. "Abstract" summarizes a paper, typically within 100 ~ 200 words. An abstract of a paper should be written in order to attract potential readers to its main content. It is often used to advertise the paper in research indexes and databases for article search.

    "Keywords and Phrases" are sometimes given next to the abstract.

  7. The first section (typically entitled "Introduction") commonly describes some of the following (but not limited to):

  8. Sections are serially numbered (The first section is "Introduction" and the last section is "Conclusion"). "Acknowledgments" and "References" following the last section are not regarded as sections and hence their headings are not numbered.

  9. Make a paper "self-contained" as much as possible in the sense that everything is written in the paper and the paper can be understood by reading it. Only exceptions are the knowledge expected to readers (such as knowledge covered in discrete math textbooks) and citations from references listed at the end of the paper.

  10. The template of a technical report that I've posted is just an example. No need to stick to a section heading in the template.
    Customize the template for what you intend to write. Organize your paper by yourself.

  11. List references in the IEEE Style: Refer to pp.5-13 of IEEE Editorial Style Manual

    Each reference should be referred to in the main text at least once by using its label (usually, a serial number).

    Example:

      "It is widely known that NP-complete problems
      are difficult to solve [2,5].
      .
      .
      .
      References
      [1] E. W. Dijkstra, "A note on two problems
          in connexion with graphs," Numerische
          Mathematik, vol. 1, pp.269-271, 1959.
      [2] M. R. Garey and D. S. Johnson, Computers
          and Intractability:  A Guide to the Theory
          of NP-Completeness, W. H. Freeman and Co.,
          1979.
      .
      .
      .
    

    The IEEE Style requires to list references in the order of occurrences of their citations in the main text, although it is also common to list references in the alphabetical order of last names of their first authors with tiebreaking by the chronological order of their publication dates.

  12. Be careful to use online documents as references. They are not always reliable source of information. Double check authoritative source of information such as books and journals specialized to the relevant topic.

  13. Fully justify text to the both sides.

  14. Do not use the notations of the textbook that I told you are unsual.

  15. A "technical article" unlikely has a table of contents (probably because it's not lengthy) unless it is a thesis or dissertation. In contrast, a book usually has a table of contents.

  16. A page number starts from the first page of the first section (or chapter in case of a book). A page number is an arabic number and printed typically in the center of the bottom margin, although the IEEE class and style file IEEEtran.cls layouts a page number at the upper right or upper left in the top margin for an odd or even page number, respectively.
    If a paper has a cover page, no page number is given to the cover page.
    If there are pages between the cover page and the first page of p.1, you can put a "roman number" as a page number.

  17. "p." stands for a page number and "pp." stands for page-to-page.

  18. Place a symbol just next to the word defining the semantics of the symbol, e.g.,
      A nonempty set F of n factories fi (1 ≤ i ≤ n)
    
    where F denotes a set and fi denotes a factory.

  19. Pay attention to capitalization of words.
    Examples:

  20. Revise a paper several times. Do proofreading.

Algorithm Design & Analysis

Pseudocode

  1. Write pseudocode in the syntax written in BNF.

  2. Write syntactically correct pseudocode.
    → Unable to discuss the correctness of pseudocode if there are many syntax errors

  3. Make sure everything is defined. Example:
    ...
    for each edge (u,v) in E {
      x ← 0;
      for each vertex w in V that is adjacent to v {
        x ← x + 1
      }
    }
    y ← x; // this assignment can cause a fatal error (when? and how?)
    ...
    

  4. Avoid to use a global variable. → Improve the readability
    A pseudocode of a procedure should be self-contained in the sense that all variables of the procedure are declared within the procedure.

  5. Use the notations common in the field of computer science.
    Example: { u ∈ V : u is adjacent to v ∈ V} is not common in CS, but maybe in Math.

Verification

You need to play a different role (called an adversary) other than a designer who believes the correctness [wishful thinking].
→ Adversary who doubts the correctness [distrustful thinking]

It's common for a designer to find a flaw in an algorithm while trying to verify it. The designer learns how to avoid design flaws through such mistakes. Thus, verification is very helpful to design a correct algorithm.

  1. Write every sentence in a proof to be very rigorous and unambiguous.

  2. A correctness proof is NOT an explanation of a procedure (that's pseudocode).
    Do not rephrase what/how pseudocode executes in verification of an algorithm. Instead, you must logically deduce a reason why every execution of pseudocode is correct.
    In case of Assignment 2 in Fall 2008, it consists of proofs for the following two assertions.
    1. An output of the algorithm described in pseudocode is always a pair of a spanning tree T and a root r whose objective function value f(T,r) is minimum among all possible T and r no matter what input is given.
    2. The algorithm always terminates within a finite amount of time no matter what input is given.

  3. Express logical steps in your reasoning precisely.

Modeling

  1. Consider ONLY "what to be solved". → Do not consider "how to solve" (i.e., an algorithm) at all.

  2. Describe a problem formulation declaratively. → Do not write anything procedural.

  3. In a problem formulation, describe all input parameters and output parameters explicitly.
    In case of an optimization problem, a value of an objective function is NOT an output.
    An optimization problem is to find a solution whose value of an objective function is minimized (or maximized). It is NOT to find the minimum (or maximum) value of the objective function.

  4. An objective function in an optimization problem must be a declarative description of a numerical function whose arguments are ONLY input parameters and output parameters. It must be evaluated only from the input & output parameters.
    Typically, an objective function is a formula consisting of input & output parameters with math operators, functions, and expressions.

  5. Define every symbol before using it except it is defined in the same sentence.

Side Notes