Writing Technical Articles

Posted by admin, November 1st, 2009

Next we introduce the game Tetris as a test problem. A paper should focus on

describing the results in sufficient details to establish their validity;
identifying the novel aspects of the results, i.e., what new knowledge is reported and what makes it non-obvious;
identifying the significance of the results: what improvements and impact do they suggest. When presenting simulation results, provide insight into the statistical confidence. (Craig Partridge)

A performance evaluation: obtained through analyses, simulation or measurements;
A theory: consisting of a collection of theorems. Provide real or simulated performance metrics, end-user studies, mention external technology adoptors, if any, etc. This has now moved to the IEEE PSPB Operations Manual, Section 8.2.1. Then problem section, if it is separate from the introduction. The dynamic use of resources other than computation time, e.g., memory or fuel, may also result from placing an aggregate limit over a series of fitness cases. Specifically, with an aggregate computation time ceiling imposed over a series of fitness cases, evolved programs dynamically choose when to stop processing each fitness case. Describing the obvious parts of the result
“Obvious” is defined as any result that a graduate of our program would suggest as a solution if you pose the problem that the result solves. Describing unnecessary details
A detail is unnecessary, if its omission will not harm the reader’s ability to understand the important novel aspects of the result. However, this is too constraining if some test cases require more processing time than others. If you can, find two people: one person familiar with the technical matter, another only generally familiar with the area. Internet drafts must be marked “work in progress”. Repeating the abstract in the introduction is a waste of space. General evaluations of your algorithm or architecture, e.g., material proving that the algorithm is O(log N), go here, not in the evaluation section. The paper may or may not include formalisms. Avoid equations and math. Text in Arial:
Arial and other sans-serif fonts are fine for slides and posters, but are harder to read in continuous text. Rather than “We thank X for helping us with Y”, you might vary this as “X helped with Y.”. Plus, compared to cmr, it probably squeezes an extra 10% of text out of your conference allotment. It is now acceptable to include URLs to material, but it is probably bad form to include a URL pointing to the author’s web page for papers published in IEEE and ACM publications, given the copyright situation. The introduction must motivate your work by pinpointing the problem you are addressing and then give an overview of your approach and/or contributions (and perhaps even a general description of your results). Google or the ACM or IEEE digital libraries will help you find it. Source: http://www.cs.columbia.edu/~hgs/etc/writing-style.html
Posted in Essay The NSF requires text like “This work was supported by the National Science Foundation under grant EIA NN-NNNNN.”
Generally, anonymous reviewers don’t get acknowledged, unless they really provided an exceptional level of feedback or insight. Finally, write the abstract. In Section 2, we introduce ..Section 3 describes … Finally, we describe future work in Section 5.” [Note that Section is capitalized. (There are obviously exceptions, e.g., when the performance evaluation is the core of the paper. Note, however, that spell checkers don’t catch all common errors, in particular word duplication (“the the”). In this way, the intro sets up my expectations for the rest of your paper — it provides the context, and a preview. So make sure that the hard problems (and their solutions) are discussed and the non-obvious mistakes (and how to avoid them) are discussed. Architecture of proposed system(s) to achieve this model should be more generic than your own peculiar implementation. What other paper would you be talking about here? References such as
John Doe, “Some paper on something”, technical report. Acknowledgements

Acknowledge your funding sources. Highlight not just the problem, but also the principal results. Outline of the rest of the paper: “The remainder of the paper is organized as follows. Use cite{a,b,c}, not cite{a} cite{b} cite{c}. If you as the author didn’t take the time to spell-check your paper, why should the editor or reviewer take the time to read it or trust that your diligence in technical matters is any higher than your diligence in presentation? Realization: contains actual implementation details when implementing architecture isn’t totally straightforward. Having a citation
Jane Doe, “Some random paper”, to be published, 2003. Overview:
The following section surveys related work in both optimizing the execution time of evolved programs and evolution over Turing-complete representations. This should include all parameters used, indications of the number of samples that contributed to the analysis and any initial conditions, if relevant. Authors
The IEEE policies (Section 6.4.1) used to state the following about authorship:
The IEEE affirms that authorship credit must be reserved for individuals who have met each of the following conditions: 1) made a significant intellectual contribution to the theoretical development, system or experimental design, prototype development, and/or the analysis and interpretation of data associated with the work contained in the manuscript, 2) contributed to drafting the article or reviewing and/or revising it for intellectual content, and 3) approved the final version of the manuscript, including references. There are four types of technical results:

An algorithm;
A system construct: such as hardware design, software system, protocol, etc.;
One goal of the paper is to ensure that the next person who designs a system like yours doesn’t make the same mistakes and takes advantage of some of your best solutions. Use the usepackage{times} option for LaTeX2e – it comes out much nicer on printers with different resolutions. Mention briefly implementation language, platform, location, dependencies on other packages and minimum resource usage if pertinent. There are papers that combine the two elements, but most publication venues either only accept one or the other type or require the author to identify whether the paper should be evaluated as a research contribution or a survey paper. Any Internet Draft reference older than six months should automatically be suspicious since Internet Drafts expire after that time period. Avoid long URLs; it may be sufficient to point to the general page and let the reader find the material. Many people read abstracts and then decide whether to bother with the rest of the paper. Paper Structure

Typical outline of a paper is:

Abstract, typically not more than 100-150 words;
Introduction (brief!): introduce problem, outline solution; the statement of the problem should include a clear statement why the problem is important (or interesting). Abstract

The abstract must not contain references, as it may be used without the main article. Also gloss the results.In this chapter, we introduce a method that gives evolved programs the incentive to strategically allocate computation time among fitness cases. Papers can be divided roughly into two categories, namely original research papers and survey papers. We present experiments that show that programs evolved using this form of fitness take less time per test case on average, with minimal damage to domain performance. Readers won’t stick with you for three pages to find out what you are talking about. The goal of a paper is to describe novel technical results. Even in that case, something more specific is preferable, as in “Delay measurements of X” or “The quality of service for FedEx deliveries”.)
If you need inspiration for a paper title, you can consult the Automatic Systems Research Topic or Paper Title Generator. It’s not very entertaining to present lots of flat or linear lines. Be sure that the introduction lets the reader know what this paper is about, not just how important your general area of research is. Related work, if not done at the beginning
Summary and Future Work

often repeats the main result

Acknowledgements
Bibliography
Appendix (to be cut first if forced to):

detailed protocol descriptions
proofs with more than two lines
other low-level but important details

It is recommended that you write the approach and results sections first, which go together. Page numbers are nice, but optional. Exceptions: Your paper proposes E = m c 2. All of this information is readily available via the IEEE or ACM digital libraries. Last, give your paper a title. The search space of GP is large and many things we are thinking about putting into the supergpsystem will make this space much more colorful. Related Work (or before summary). Make sure that they have been replaced by newer versions or RFCs. Leave a space between first names and last name, i.e., “J. Always include at least one figure. Give the paper to somebody else to read. Spelling errors
With the availability of spell checkers, there is no reason to have spelling errors in a manuscript. Example bad introduction:
Here at the institute for computer research, me and my colleagues have created the SUPERGP system and have applied it to several toy problems. For example, it is beneficial to give evolved programs direct access to low-level data arrays, as in some approaches to signal processing cite{teller5}, and protein segment classification cite{handley,koza6}. In particular, the name of any protocol or system developed and the general area (“quality of service”, “protocol verification”, “service creation environment”) should be contained in the abstract. Then the conclusions, then the intro. Evaluation: How does it really work in practice? Doe”, not “J.P.Doe”. Avoid general motivation in the abstract. This type of system automatically performs more problem-specific engineering than a system that accesses highly preprocessed data. is useless, as the paper has presumably been published by now. Use it for software and other non-library material. Multi-letter subscripts are set in roman, not italics. in a bibliography unless list is very long (five or more authors). Write the intro last since it glosses the conclusions in one of the last paragraphs. Reporting Numerical Results and Simulations
In all but extended abstracts, numerical results and simulations should be reported in enough detail that the reader can duplicate the results. General URLs are also less likely to change. For conference papers, you MUST name the conference location, month and the full conference name, not just some abbreviation. We had previously fumbled with earlier versions of SUPERGPSYSTEM for a while. Does it follow some well-known other system behaviors such as standard queueing systems? begin{figure}
resizebox{!}{0.5textheight}{includegraphics{foo.eps}}
caption{Some figure}
label{fig:figure}
end{figure}

Things to Avoid

Too much motivational material
Three reasons are enough — and they should be described very briefly. Use Times Roman or similar serif fonts. Since the abstract will be used by search engines, be sure that terms that identify your work are found there. We also discuss the implications of such a time constraint, as well as its differences from other approaches to {it multiobjective problems}. It describes clearly what has been done before on the problem, and what is new. Unusual fonts are less likely to be available at the recipient and may cause printing or display problems. Cite the source, date and other identifying information. This is followed by a description of the aggregate computation time ceiling, and its application to Tetris in particular. If at all possible, provide confidence intervals. The description of the graph should not just repeat the graphically obvious such as “the delay rises with the load”, but explain, for example, how this increase relates to the load increase. If writing about networks or multimedia, use the network bibliography. In the latter case, gathering more samples is probably advised. The author subsumed into et al. (For example, “Our algorithm is based upon the work by Smith and Wesson.”)
Avoid use of “in this paper” in the abstract. Also, vary your expression between “section” being the subject of the sentence, as in “Section 2 discusses …” and “In Section, we discuss …”.]
Body of paper

problem
approach, architecture
results

The body should contain sufficient motivation, with at least one example scenario, preferably two, with illustrating figures, followed by a crisp generic problem statement model, i.e., functionality, particularly emphasizing “new” functionality. Hint: In the case of a conference, make sure to cite the work of the PC co-chairs and as many other PC members as are remotely plausible, as well as from anything relevant from the previous two proceedings. We then present experimental results, discuss other current efforts with Tetris, and end with conclusions and future work. You do not have to justify the importance of the Internet or explain what QoS is. You can never lay out the whole parameter space, so provide insight into which parameters are significant over what range and which ones are less important. All entries not found there should be sent to me. (Most research papers contain a “related work” section that can be considered a survey, but it is usually brief compared to the rest of the paper and only addresses a much narrower slice of the field.)
Research Papers
A good research paper has a clear statement of the problem the paper is addressing, the proposed solution(s), and results achieved. Is it linear? P. Avoid common phrases like “novel”, “performance evaluation” and “architecture”, since almost every paper does a performance evaluation of some architecture and it better be novel. For example,
x_{mathrm max}

For uniformity, use the LaTeX2e graphics set, not the earlier psfigure set:
usepackage{graphics}
… If there’s a “strange” behavior in the graph (e.g., a dip, peak or change in slope), this behavior either needs to be explained or reasons must be given why this is simply due to statistical aberration. Check if Internet drafts have been published as RFCs or if there’s a newer version. Introduction

Avoid stock and cliche phrases such as “recent advances in XYZ” or anything alluding to the growth of the Internet. This system allows the programmer to easily try lots of parameters, and problems, but incorporates a special constraint system for parameter settings and LISP S-expression parenthesis counting. It is acceptable, although not common, to identify work by author, abbreviation or RFC number. Figures should be chosen wisely. are useless. If in doubt, consult a dictionary such as the (on line) Merriam Webster. Previous or obvious approach:
(Note that you can also have a related work section that gives more details about previous work.)) One way to control the execution time of evolved programs is to impose an absolute time limit. LaTeX Considerations

There’s no need to enclose numbers in $$ (math mode). A pretty good introduction, drawn from Eric Siegel’s class:
Many new domains for genetic programming require evolved programs to be executed for longer amounts of time. Title

Avoid all but the most readily understood abbreviations. A listing of frequently-used references for networks is available. In the case of a journal or magazine, cite anything relevant from last 2-3 years or so volumes. However, evolved programs may require more time to execute, since they are solving a harder task. Book citations include publication years, but no ISBN number. Approach/solution/contribution:
The first sentence of a paragraph like this should say what the contribution is. may be your advisor or the reviewer… Note punctuation of et al.. Some sources have specific wording requirements and may prefer that the grant number is listed. To use computation time efficiently, evolved programs must take extra time when it is necessary to perform well, but also spend less time whenever possible. Unless somebody wants to see 10,000 Google results, nobody searches for these types of words.Use adjectives that describe the distinctive features of your work, e.g., reliable, scalable, high-performance, robust, low-complexity, or low-cost. Bibliography

Avoid use of et al.

No tags for this post.

Related posts