How to write papers with me

Tools

• First learn LaTeX and set up your own pdflatex environment.- When you use a ”.” for abbreviation and it is not a period, put a \ after to protect the space. Otherwise, it puts an extra space after. For example, “Fig.\ 3” will protect the space after the non-period ”.”. In contrast, “Fig. 3” will typeset with two spaces after “Fig. ” because LaTeX thinks “Fig.” ends a sentence.
• Learn to use SVN system on my server.

Practice

• Write a diary or keep a journal, if you need to practice how to express your thoughts in English. Do this exercise every day: sit down in front of your computer for ten minutes a day and type anything that comes into your mind, without stopping. If you can’t think of anything to write, just type I don’t know what I am thinking, or something like that.
• Reading anything that interests you.

Grammar

• Know mass nouns vs. count nouns.- Examples of mass nouns (cannot have plural): equipment, hardware, software, middleware, information, knowledge, paperwork, – Examples of count nouns (can have plurals): approach(es), impact(s), clothes,
• “less” vs. “fewer”: “less” is for mass nouns, whereas “fewer” is for count nouns.
• “each”, “every”, “any” must take a singular noun. It doesn’t make sense to say “every computers.”
• Do not have run-on sentences. That is, don’t have a sentence with more than one verb without connecting them with and/or/but.
• Know your “a” vs “an”. It is “a” university (not “an”, because the “u” sounds like “yu” which is a consonant but not a vowel, even though the letter “u” might be considered a vowel letter.
• hyphenate a compound word if you use it as an adjective. For example, “a news-worthy article”, “a host-assisted parser”, etc
• Know your “the” and “a”/”an” – these are called “articles” (definite article, indefinite article). In English, singular count nouns should almost always have an article in front.
• Know whether your verbs are transitive or intransitive. e.g., “maintain” and “keep” are transitive verbs, whereas “remain” and “stay” are intransitive verbs.
• “cannot” is one word when you mean “is not able to”. “can not” does not mean “cannot”; it means “is able not to”

Semantics

• Abstract vs. concrete: some things are abstract and cannot be manipulated; instead, you can manipulate only its concrete representation. For example, “information” and “knowledge” are abstract. You can’t “send” or “transmit” information; you can transmit “data”, which encodes information. You can’t “show” or “display” information, either; but you can show or display a graph or a chart that conveys the information.
• literal vs figurative use: “big” refers to physical size. Colloquially it is used as modifiers for other abstract nouns such as “a big disadvantage” but it is a figurative use. In technical writing, you should use other verbs that express the magnitude or extent, rather than the physical size, such as “main disadvantage” or “major disadvantage”

Style

• Don’t be verbose. In English, this can be accomplished by picking the right verb, possibly in conjunction with an adverb.
• English prepositions are also very powerful (in, on, at, under, over, above, below, beyond, …), especially in making modifier phrases where a verb might otherwise be needed. Consider a prepositional phrase if your sentence starts getting complicated.
• Do not start a sentence with And, Or, But.
• Eliminate “There is” or “There are” whenever possible.
• Most “in order to” can be rewritten as just “to”
• Avoid making a long phrase with four, five, or more nouns in a row! You would not know what is a modifier, what is being modified, etc. Try to turn some into an adjective or insert prepositions (in, on, for, with, of, …) to make it easier to parse.
• When you have two nouns that are joined together by “and” or “or”, don’t separate them by a comma; but for three or more items, always use a comma, and put “and” or “or” immediately before the last. For example, “apples and oranges” (no comma), “rock, paper, and scissors” (commas).
• Although the comma before the “and” could be skipped, I would like you to always add that comma there for good style. That is, although you can say (“rock, paper and scissors” without comma after “and”), I would request that you say it with a comma right after “and”.
• Know your prepositions. “in” vs. “on” vs. “at” may be very confusing. “for” and “off” are never so clearly distinguished.
• Know the difference between “that” and “which”: “that” is part of the required description, while “which” is more of an optional, add-on piece of info. For example, “The book that I lent you belongs to my father” (not “The book which I lent you, because “that I lent you” is not a “by the way” additional piece of information). In contrast, “The Eco node, which weighs under 2 grams, is the only node light enough to be wearable by an infant.” The “which phrase between the two commas are an optional piece of information that may benefit the reader.
• “only” should be put immediately before the word you want to modify.
• Do not use “a lot” in technical writing. Even “get” is informal and can be ambigous, since it is not clear if it is an active “pull” or a passive “receive” as a result of a push.
• Do not use contractions such as “don’t”, “can’t”, “shouldn’t”, etc. Spell out the full form.
• Don’t overuse “very” unless you mean it, especially for native Chinese speakers.

Editing

• Always check your spelling with a spell checker. This is very mechanical.
• Always go through your bibliography and check people’s names. It is a big faux pas to misspell someone’s name.
• Some names are multi-word or may have unusual capitalization. Protect them in BibTex using { }. For example, {O’Neill}.
• Spell out numbers between 0-10 inclusive when counting. That is, “five pencils” not “5 pencils”; “11 radios” not “eleven radios.”

Content

• Identify your contributions.
• Note that one of your contributions may be to make a new tool available to an application user. That’s nice, but it is not a contribution to Computer Engineering or EE.
• Contributions to Computer Engineering might include – higher level abstraction for describing a system – fastest handoff protocol, fastest remote mass reprogramming – memory buffer minimization
• Who is your competitor? What have they done right? Why is everybody citing their paper? What is one common misconception people have about their paper? (e.g., Deluge spreads code update but the measured completion time is not automatically determined; it is manually inspected, since it does not report back to the user about successful reprogramming)

Paragraphs (5/16/2012)

• Each Chapter or Section should start with an opening paragraph, which serves the purpose of orienting the reader.
• Each paragraph should start with a topic sentence, which defines the scope of the paragraph and should make the main point of your whole paragraph. Everything you say in the rest of the paragraph should be within the scope and support the point you are making with your topic sentence.
• The last sentence of the opening paragraph should provide a roadmap for the rest of the Chapter or Section. You should then start the next level of hierarchy after the roadmap sentence. For instance,

Chapter 3: Problem Statement [Opening paragraph for the chapter, starting with the topic sentence…. Last sentence of the opening paragraph is the roadmap for the rest of this chapter.] Section 3.1 Requirements [Opening paragraph for the section, starting with the topic sentence] [You may have subsections] [Regardless, the last sentence of the opening paragraph should be the roadmap] Section 3.2 Constraints …

• The purpose of the topic sentence is to enable non-linear reading. That is, someone should always be able to look at the first sentence to tell what it is about. This will help them decide whether they want to read the paragraph in more detail or to skip it for now and come back to read it in more detail later. In fact, you should write your paper in a way such that the reader can get a “low-resolution” version of your paper by just reading the topic sentences!
• You can think of your paper as animation. The master animator first draws the “key frames” to sketch out the whole story; then the assistant animators draw the “in-between” frames to fill in the details. When you develop your outline, it’s like you are sketching out the key frames, and you should be able to tell the story (at a low resolution) with just the keyframes (topic sentences). The rest of the paragraph after the topic sentence are the details that support the point you are making with your topic sentence.
• You should always keep in mind the key points with your entire paper. What’s a point? It is the lesson you learned and want to teach others with the paper but summarized in a sentence or two. For example, “Low-complexity maximum power point tracking (MPPT) while charging a supercapacitor is feasible if you pump up the voltage using 0.5mW overhead” or something like that. Then, everything you write for the rest of the paper should support such keypoints in some ways.

Outlines (5/16/2012)

• Always spend your time developing your outline. You can brainstorm by typing the text you want, but don’t expect to keep your brainstorming text. Make sure you have a good outline before you start flushing out the text.
• A typical outline for a paper should have the following chapters or sections.

1. Introduction
   • Write this after you finish writing everything else.
   • It should motivate the reader and tell them
     • importance of the problem (why should they care?)
     • novelty of the approach or solution (why is the solution not obvious?)
     • merit or effectiveness of the solution (why is the solution good?)
   • It should provide a roadmap for the rest of the paper
2. Background and Related Work
   • Background is the domain-specific knowledge that the reader
     should know but might not know in order to understand your work.
     Not all papers need to have a background section, but some might.
   • Related work is your competitors. They might provide alternative
     solutions to the same problem or solutions to related problems.
     You can compare related work at both the problem level
     or solution level.
     That is how you show contributions: are you solving another,
     harder or easier problem? Or are you solving the same problem
     but better?
3. Problem Statement
   • Requirements
     • What is it supposed to do? It can be expressed in terms of the
       input/ouptut characteristics. For example, sorting problem
       statement inputs an array of items, outputs the same items
       but arranged in increasing or decreasing order.
     • Functional Requirements are statements on the functionality
       that the system or algorithm must deliver in order to be called a
       solution.
     • Timing Requirements are those on the time of the action or
       associated with the data item, rather than the data value.
     • There may be other non-functional requirements such as size,
       weight, etc.
   • Objectives
     • Objectives (as in objective functions) are the aspects that
       determine how good a solution is compared to another solution.
       Examples of objectives include “minimize code size”,
       “minimize power consumption”, “maximize data delivery rate”,
       “maximize battery life”, etc.
     • A lot of times, students only care about the “functional
       requirements” (that it works) but not necessarily objectives
       (how well does it work).
     • Objectives are not always explicitly stated but may be
       assumed for certain classes of problems.
       For example, sorting has the objective of minimum runtime
       complexity, with or without space complexity;
       or space might be a secondary objective.
   • Constraints
     • Constraints are the bounds between acceptable and unacceptable
       solutions. For example, there may be a constraint on
       the code size (e.g., 4KB). If the executable does not fit in the
       4KB code memory, then it is unacceptable.
       So, 4KB is the code-size constraint.
     • Common constraints include timing, power, energy, …
     • Note that a constraint does not automatically imply the
       related objective. For example, a real-time system may have
       mininum-timing constraints on pairs of events, or a deadline,
       but it doesn’t mean you must run it “as fast as possible”
4. Technical Approach
   • This is a section on the way you view and solve the problem.
   • One related thing is “Problem Formulation”, which is a way to
     express a problem in terms of some mathematical formulas or data
     structures. That is, it is a mapping process from a problem (with
     domain-specific meaning) to a structure with a known solution (that
     doesn’t necessarily know its domain meaning). For instance, you
     can formulate the problem of solving a system of pairwise difference
     linear constraints in terms of a single-shortest-path problem on a
     graph.
   • Approach may be a bit more general or higher level than formulation.
     For example, you might say that you solve a certain scheduling
     problem by taking a greedy approach. You can also
     solve some other problem by randomization, for example.
5. Implementation
   • This is a description of issues in making your solution a reality.
   • Note that not all papers need an implementation section or chapter.
     For instance, your main contribution might be an algorithm, and the
     implementation of an algorithm is a program, but you usually don’t
     need to have a separate implementation section on how you write the
     program code for the algorithm.
     However, sometimes there are some interesting, non-obvious tricks you
     have to do to make something run efficiently.
6. Evaluation (Experimental Results)
   • All work needs to be evaluated. This is where you show evidence
     that your solution works as promised, or it achieves the objectives
     as defind.
   • You may have one section that describes your experimental setup and benchmarks used.
   • You should try to define your experiments and the points you try to
     make as early as possible, hopefully before you set out to do
     the work, even though that is often very difficult to do.
7. Conclusions
   • The conclusion part needs to first recap the key points of the paper,
     just to make sure the reader has the correct “take-home message.”
   • You should state your take-home messages first followed by a
     brief summary of your work, but with the emphasis on the nuance points
     that the reader might miss easily.
   • You provide a perspective on the contributions of your work in
     advancing the state of knowledge, on how much of the problem you have
     tackled, and how much future work remains to be done.

Principles

• Mean every word you say. Make every word count.
• You always need to have an objective. That is, are you trying to maximize performance? minimize power consumption? maximize determinism? minimize code size or memory? Your work is rarely about if something just works – that is a feasibility study. Getting something working is only a prerequisite; what you need is not only that it works but it works WELL. Always keep the objective functions in mind when not only writing your own paper but also when reading other people’s papers.
• Don’t assume all your readers are experts in your field. Write it in a way that helps them understand your work.
• Spend time developing your outline.
• Do not make points in isolation. Know where in the outline to make a point.
• It is essential you have a good outline before you start writing, and know what you want to say before you write. In fact, it is not so much what you say sentence-by-sentence, but know what POINTS you want to make in the paper! Organize your outline as a way to help you make those points. It’s not just whether you make the point, but you need to motivate the point, provide the background, clearly define your problem statement, explain your solution and its novelty (what is not so obvious), and support your point with experimental data, and don’t forget to compare your results with other people’s to show you are better. Otherwise it is not worth doing.
• What does it mean to be “better” than previous work? You need to clearly define the metric of evaluation.