CS 6463: Writing Guidelines

General

An essential component of any course that aims to investigate some topic in a mathematically precise way is to be able to communicate the results of such investigations to others clearly and effectively (an absolutely brilliant proof of an absolutely profound result will nevertheless be useless if it is unintelligible to everyone else, since if people can't understand it they have no reason to believe that it's true). Accordingly, a portion of the grade will be based on the quality of one's writing. This document outlines our expectations in this regard, and offers some guidelines for the ``quality of writing'' component of your homeworks (see Grading Policies for details of how ``quality of writing'' will be graded).

Please note that these guidelines are intended to be of help, but do not claim to be exhaustive : a sufficiently determined person may be able to follow them and still succeed in being entirely unintelligible. To some extent, whether or not a piece of writing ``communicates its ideas clearly'' is a matter of judgement, and one of the goals of this course will be to refine this judgement through practice.

Guidelines

The solution to a problem should, for all but the simplest of problems, have two components:
  1. an informal sketch of the approach to the problem, and perhaps the structure of the solution; and
  2. the mathematically precise solution itself.
In some cases, these components may be intermixed. Usually, the intuition should be presented first; however, there may be some situations where it's hard to give a high-level description of how a solution works without referring to specific pieces of the mathematical development, and in such cases it makes sense to give the informal explanation of the solution after the mathematical development.

For the description of an algorithm the intuition presented should sketch how your algorithm works. It should be accompanied by a more detailed description of the algorithm, for example in pseudo-code. (For example: The first two nested loops sort the numbers. The following loop prints the numbers.) Note that later in class we will describe some parts of the algorithms in lower detail, assuming that it is straight-forward for the reader to fill in the details (for example: later in class we will assume that everybody knows how to sort n numbers in O(n log n) time. So you do not need to write down merge sort in pseudo code each time you use sorting as a subroutine). But never assume too much knowledge from the reader: If we cannot follow your "straight-forward" ideas, you might lose points. Further, every algorithm needs to be accompanied by a proof of correctness (if it is not clear what an algorithm computes, it is worthless). So the description of an algorithm consists of the following three parts:

  1. Informal sketch
  2. Formal description (e.g., in pseudo-code)
  3. Proof of correctness
For problems that require you to write a proof, give a road-map of how you intend to proceed. If it's an induction proof, say what the induction will be on. If the proof involves several steps or requires proving intermediate results (lemmas), briefly mention what they will be, e.g.:
The proof proceeds in three steps. First, we show that ... This is followed by a proof that ... Finally, we put these results together to show that ...
(Note that this example refers to the informal sketch of the solution: the actual mathematical presentation needs to be given as well.)

The textual layout of a proof or a mathematical construction has an important effect on how easy it is to read and understand, just as proper indentation plays a significant role in determining the readability of a piece of code. You should, therefore, pay careful attention to the layout of your solutions on paper.

Last modified by Carola Wenk,   carola @ cs.utsa.edu ,