Henning schulzrinne writing technical articles p3

The notes below affect technical papers in information technology and electrical engineering, with focus on papers in systems and systems.

Provide the paper to someone else to see. If you’re able to, find a couple: one individual acquainted with the technical matter, another only generally acquainted with the region.

Papers could be divided roughly into two groups, namely original research papers and survey papers. You will find papers that combine the 2 elements, but many publication venues either only accept either type or require author to recognize if the paper ought to be evaluated like a research contribution or perhaps a survey paper. (Most research papers have a “related work” section that may be considered market research, but it’s usually brief when compared with all of those other paper and just addresses a significantly narrower slice from the field.)

Research Papers

A great research paper includes a obvious statement from the problem the paper is addressing, the suggested solution(s), and results achieved. It describes clearly what’s been done before around the problem, and what’s new.

The aim of a paper would be to describe novel technical results. You will find four kinds of technical results:

1. An formula
2. A method construct: for example hardware design, software system, protocol, etc. One objective of the paper is to make sure that the next one who designs a method like yours does not result in the same mistakes and uses a number of your very best solutions. So make certain the hard problems (as well as their solutions) are discussed and also the non-apparent mistakes (and the way to prevent them) are discussed. (Craig Partridge)
3. A performance evaluation: acquired through analyses, simulation or measurements
4. A theory: composed of an accumulation of theorems.

A paper should concentrate on

• describing the outcomes in sufficient details to determine their validity
• identifying the novel facets of the outcomes, i.e. what new understanding is reported and important non-apparent
• identifying the value of the outcomes: what enhancements and impact will they suggest.

Paper Structure

• Typical outline of the paper is:
  • Abstract, typically only 100-150 words
  • Introduction (brief!): introduce problem, outline solution the statement from the problem will include a obvious statement why the issue is important (or interesting).
  • Related Work (or before summary). Hint: Within the situation of the conference, make certain to cite the job from the PC co-chairs so that as a number of other PC people much like remotely plausible, in addition to from anything relevant in the previous two proceedings. Within the situation of the journal or magazine, cite anything relevant from last 2-three years approximately volumes.
  • Outline of all of those other paper: “The rest of the paper is organized the following. In Section 2, we introduce. Section 3 describes. Finally, we describe future operate in Section 5.” [Observe that Section is capitalized. Also, vary your expression between “section” being the topic of the sentence, as with “Section 2 discusses. ” and “In Section, we discuss. “.]
  • Body of paper
    • problem
    • approach, architecture
    • results

    Your body should contain sufficient motivation, with a minumum of one example scenario, preferably two, with illustrating figures, adopted with a crisp generic problem statement model, i.e.

    

    functionality, particularly emphasizing “new” functionality. The paper might include formalisms. General evaluations of the formula or architecture, e.g. material showing the formula is O(log N), click here, away from the evaluation section.

    

    Architecture of suggested system(s) to do this model ought to be more generic than your personal peculiar implementation. Always include a minumum of one figure.

    Realization. contains actual implementation details when applying architecture is not totally straightforward. Mention briefly implementation language, platform, location, dependencies on other packages and minimum resource usage if pertinent.

    Evaluation. So how exactly does it truly operate in practice? Provide real or simulated performance metrics, finish-user studies, mention exterior technology adoptors, or no, etc.

  • Related work, otherwise done at the start
  • Summary and Future Work
    • frequently repeats the primary result
  • Acknowledgements
  • Bibliography
  • Appendix (to become cut first if made to):
    • detailed protocol descriptions
    • proofs using more than two lines
    • other low-level but important details

It’s suggested that you simply write the approach and results sections first, which are together. Then problem section, if it’s outside of the introduction. Then your conclusions, then your intro. Write the intro last because it glosses the conclusions within the last sentences. Finally, write the abstract. Last, provide your paper a title.

Title

• Avoid basically probably the most readily understood abbreviations.
• Avoid common phrases like “novel”, “performance evaluation” and “architecture”, since nearly every paper will a performance look at some architecture also it had better be novel. Unless of course somebody really wants to see 10,000 Google results, nobody looks for these kinds of words.

Use adjectives that describe the distinctive options that come with your projects, e.g. reliable, scalable, high-performance, robust, low-complexity, or low-cost. (You will find clearly exceptions, e.g. once the performance evaluation may be the core from the paper. Even just in that situation, some thing specific is more suitable, as with “Delay measurements of X” or “The caliber of service for FedEx deliveries”.)

Abstract

• The abstract must not contain references, as it might be utilized with no primary article. It’s acceptable, while not common, to recognize work by author, abbreviation or RFC number. (For instance, “Our formula relies upon the job by Cruz and Wesson.”)
• Avoid utilization of “within this paper” within the abstract. The other paper will you be speaking about here?
• Avoid general motivation within the abstract. You don’t have to warrant the significance of the web or explain what QoS is.
• Highlight not only the issue, but the principal results. Lots of people read abstracts after which decide whether to concern yourself with all of those other paper.
• Because the abstract will be utilised by search engines like google, make sure that terms that identify your projects are located there. Particularly, the any protocol or system developed and also the general area (“service qualityInch, “protocol verification”, “service creation atmosphere”) ought to be within the abstract.
• Avoid equations and math. Exceptions: Your paper proposes E = m c 2 .

Introduction

• Avoid stock and cliche phrases for example “recent advances in XYZ” or anything alluding towards the development of the web.
• Make certain that introduction lets the readers understand what this paper is all about, not only how important your current section of scientific studies are. Readers will not stick to you for 3 pages to discover what you’re speaking about.
• The introduction must motivate your projects by pinpointing the issue you’re addressing after which give an introduction to your approach and/or contributions (and possibly a general description of the results). In this manner, the intro creates my expectations throughout your paper — it offers the context, along with a preview.
• Repeating the abstract within the introduction is a total waste of space.
• Example bad introduction:

At the institute for computer research, me and my colleagues have produced the SUPERGP system and also have applied it to many toy problems. We’d formerly fumbled with earlier versions of SUPERGPSYSTEM for some time. This technique enables the programmer to simply try plenty of parameters, and problems, but contains a special constraint system for parameter settings and LISP S-expression parenthesis counting.

Looking space of GP is big and lots of things we are planning on putting in to the supergpsystem can make this space a lot more colorful.

An excellent introduction, attracted from Eric Siegel’s class:

Many new domains for genetic programming require evolved programs to become performed for extended intervals. For instance, it’s advantageous to provide evolved programs immediate access to low-level data arrays, as with some methods to signal processing cite, and protein segment classification cite. This kind of system instantly performs more problem-specific engineering than the usual system that accesses highly preprocessed data. However, evolved programs may need additional time to complete, because they are solving a harder task. Previous or apparent approach. (Note that you could in addition have a related work section that provides additional information about previous work.)) One method to control the execution duration of evolved programs would be to impose a complete time period limit. However, this really is too constraining if some test cases want more processing time than the others. To make use of computation time efficiently, evolved programs will need to take additional time when it’s essential to succeed, but additionally cut back time whenever you can. Approach/solution/contribution. The very first sentence of the paragraph such as this should say exactly what the contribution is. Also gloss the outcomes.)

Within this chapter, we introduce a technique that provides evolved programs the motivation to strategically allocate computation time among fitness cases. Particularly, by having an aggregate computation time ceiling enforced over a number of fitness cases, evolved programs dynamically choose when you should stop processing each fitness situation. We present experiments that demonstrate that programs evolved by using this type of fitness take a shorter period per test situation typically, with minimal harm to domain performance. We discuss the implications of these a period constraint, along with its variations using their company methods to . The dynamic utilization of sources apart from computation time, e.g. memory or fuel, might also derive from placing an aggregate limit over a number of fitness cases.

Overview: The next section surveys related operate in both optimizing the execution duration of evolved programs and evolution over Turing-complete representations. Next we introduce the sport Tetris like a test problem. This really is adopted with a description from the aggregate computation time ceiling, and it is application to Tetris particularly. Then we present experimental results, discuss other current efforts with Tetris, and finish with conclusions and future work.

Body of Paper

Bibliography

• Avoid utilization of et al. inside a bibliography unless of course list is extremely lengthy (five or even more authors). The writer subsumed into et al. might be your consultant or even the reviewer. Note punctuation of et al..
• If covering systems or multimedia, make use of the network bibliography. All records not found there must be delivered to me. All of the frequently-used references for systems can be obtained.
• Internet drafts should be marked “work in progress”.
• Book citations include publication years, but no ISBN number.
• It’s now acceptable to incorporate URLs to material, but it’s most likely bad form to incorporate a URL pointing towards the author’s web site for papers printed in IEEE and ACM publications, because of the situation. Apply it software along with other non-library material. Avoid lengthy URLs it might be sufficient to suggest towards the general page and allow the readers discover the material. General URLs will also be less inclined to change.
• Leave an area between first names and surname, i.e. “J. P. Doe”, not “J.P.Doe”.

Acknowledgements

• Generally, anonymous reviewers do not get acknowledged, unless of course they provided a fantastic degree of feedback or insight. Instead of “We thank X in order to us with Y”, you may vary this as “X contributed to Y.”.

Reporting Statistical Results and Simulations

In basically extended abstracts, statistical results and simulations ought to be reported in enough detail the readers can duplicate the outcomes. This will include all parameters used, warning signs of the amount of samples that led to case study and then any initial conditions, if relevant.

When presenting simulation results, provide understanding of the record confidence. If possible, provide confidence times. Should there be a “strange” behavior within the graph (e.g. a dip, peak or alternation in slope), this behavior either must be described or reasons should be given why this is just because of record aberration. Within the latter situation, gathering more samples is most likely advised.

Figures ought to be selected wisely. You cant ever construct the entire parameter space, so provide understanding of which parameters are significant over what range and which of them are less important. It isn’t very entertaining to provide plenty of flat or straight line lines.

The outline from the graph shouldn’t just repeat the graphically apparent for example “the delay increases using the load”, but explain, for instance, how this increase pertains to the burden increase. Could it be straight line? Will it follow some well-known other system behaviors for example standard queueing systems?

LaTeX Factors

• You don’t need to enclose figures in $$ (math mode).
• Use cite. not cite cite cite.
• Make use of the usepackage choice for LaTeX2e – it comes down out much better on printers with various resolutions. Plus, when compared with cmr, it most likely squeezes an additional 10% of text from your conference allotment.
• Multi-letter subscripts are positioned in roman, not italics. For instance,
• For uniformity, make use of the LaTeX2e graphics set, not the sooner psfigure set:

Items to Avoid

• An excessive amount of motivational material: three reasons are sufficient — and they must be described very briefly.
• Describing the apparent areas of the end result: “Apparent” is understood to be any result that the graduate in our program indicate like a solution should you pose the issue the result solves.
• Describing unnecessary details: a detail is unnecessary, if it is omission won’t harm the reader’s capability to comprehend the important novel facets of the end result.
• Spelling errors: Using the accessibility to spell checkers, there’s pointless to possess spelling errors inside a manuscript. Should you because the author did not take time to spell-look at your paper, why must the editor or reviewer take time to see clearly or trust that the diligence in technical matters is any greater than your diligence in presentation? Note, however, that spell checkers don’t catch all common errors, particularly word duplication (“the the”). If uncertain, consult a dictionary like the (online) Merriam Webster .

Guidelines for Experimental Papers

“Guidelines for Experimental Papers” established for researchers article marketing towards the journal, Machine Learning.

1. Papers that introduce a brand new learning “setting” or kind of application should justify the relevance and need for this setting, for instance, according to its utility in applications, its suitability like a type of human or animal learning, or its importance in addressing fundamental questions in machine learning.
2. Papers describing a brand new formula ought to be obvious, precise, and written in a manner that enables the readers to check the formula with other algorithms. For instance, most learning algorithms may very well be optimizing (a minimum of roughly) a degree of of performance. A great way to describe a brand new formula would be to get this to performance measure explicit. Another helpful method of describing an formula would be to define just ideas it searches when optimizing the performance measure.
3. Papers presenting a brand new formula should conduct experiments evaluating it to condition-of-the-art algorithms for the similar or similar problems. Where possible, performance ought to be compared against a complete standard of ideal performance. Performance ought to be compared against a naive standard (e.g. random guessing, guessing the most typical class, etc.) too. Unusual performance criteria ought to be carefully defined and justified.
4. All experiments must include measures of uncertainty from the conclusions. These typically take the type of confidence times, record tests, or estimates of normal error. Proper experimental methodology ought to be employed. For instance, if “test sets” are utilized to measure generalization performance, no information in the test set ought to be open to the training process.
5. Descriptions from the software and knowledge sufficient to duplicate the experiments should be incorporated within the paper. When the paper has made an appearance in Machine Learning, authors are strongly advised to help make the data utilized in experiments open to other scientists wanting to replicate the experiments. A very good way to do this would be to deposit the information sets in the Irvine Repository of Machine Learning Databases. One other good choice is to include your computer data sets towards the DELVE benchmark collection in the College of Toronto. For proprietary data sets, authors ought to develop synthetic data sets getting exactly the same record qualities. These synthetic data sets may then be produced freely available.
6. Conclusions attracted from a number of experimental runs ought to be clearly mentioned. Graphical display of experimental data can be quite effective. Supporting tables of exact statistical is a result of experiments ought to be provided within an appendix.
7. Limitations from the formula ought to be described at length. Interesting cases when an formula fails are essential in clarifying the plethora of applicability of the formula.

The Conference Review Process

It’s difficult to generalize review process for conferences, but many trustworthy conferences operate based on these fundamental rules:

1. The paper is posted towards the technical program chair(s). Many current conferences require electronic submission, either in PostScript or PDF formats, from time to time in Word.
2. The technical program chair assigns the paper to a number of technical program committee people, hopefully experts within their field. The identity of the TPC member is stored secret.
3. The TPC member usually supplies a review, but can also be requested to locate between one and three reviewers who aren’t people from the TPC. They might be colleagues from the reviewer in the same institution, their graduated pupils or somebody indexed by the references. The graduate student reviews can be very useful, as these reviewers frequently provide more in depth critique instead of blanket dismissal. Worthwhile conference will make an effort to provide a minimum of three reviews, however, since conferences operate under tight deadlines and never all reviewers deliver as guaranteed, it’s not uncommon you get 3 reviews.
4. The technical program chair then collects the reviews and sorts the papers based on their average review scores.
5. The TPC, or usuaally a subset which will make the meeting, then meets Usually, the underside third and also the top third are rejected and recognized without (much) further discussion. The papers discussed are individuals in the center of the number, in which a TPC member feels strongly the paper wound up within the wrong bin, or in which the review scores differ considerably, particularly should there be 3 reviews.

Other References

• Bartleby has dictionaries, grammars, an encyclopedia, and Columbia Help Guide To Standard American British
• Berkeley Human Resources and Technology Publications style guide
• ‘cisco’ style guide
• Oded Goldreich authored an essay titled “What not write a paper”. with tips about style and organization.
• Don Knuth has online the TeX supply of a magazine on “Mathematical Writing” (also helpful for Information Technology).
• The dwelling of paper/report in Systems . by Michalis Faloutsos, U.C. Riverside
• The Weather of fashion. William Strunk Junior. and E.B. White-colored. Macmillan Publishing Co. New You are able to, 1979. It is really an amazing little book that you could read inside a couple of hrs. Your way of writing should never be exactly the same later on. This $8 book is the greatest investment you could ever make.
• Bugs on paper. Lyn Dupre’, (second erectile dysfunction.) A great book that expands on StrunkWhite-colored. It’s more examples, and it was compiled by a writer who edited numerous technical publications, a few of which were in information technology.
• The Chicago Manual of fashion. Univ. of Chicago Press. This is actually the bible for American academic style. It’s lengthy and high, but has all you ever need to know about style. While in doubt, or you get conflicting stylistic advice, following a Chicago Manual of fashion is the best option.
• A Guide for Scholars by Mary Claire van Leunen Alfred Knopf, Writer. This really is another helpful book written for publishing (computer) scientists.
• The UIST Guide for Authors is aimed at a particular conference, however the general process and guidelines act like a number of other conferences.
• The Science of Scientific Writing. George D. Gopen and Judith A. Swan, In American Researcher. Vol. 78, No. 6 (November-12 ,, 1990), pp. 550-558. This can be a helpful article that teaches scientists crafting single sentences and sentences.
• The Mayfield Guide of Technical and Scientific Writing. Perelman, Paradis and Barrett, Mayfield, 1998. It’s an extensive resource explaining crafting papers, reports, memoranda and Ph.D. thesis, steps to make high-performance slides and dental presentations, how to prevent common pitfalls and mistakes in British, etc. with lots of types of “good” and “bad” practices.
• Roy Levin and David D. Redell, An assessment from the ninth SOSP submissions -or- How (and just how not) to create a great systems paper. ACM SIGOPS Os’s Review17 (3):35-40 (This summer, 1983).
• Alan Snyder, Ways to get your paper recognized at OOPSLA. OOPSLA ’91 Proceedings. pp. 359-363.
• Rob Manley et al. Tips to get a paper recognized at OOPSLA. Panel at OOPSLA’93. pp 429-436.
• Craig Partridge, How you can Boost the Chances Your Paper is Recognized at ACM SIGCOMML. Generally helpful suggest that will also apply with other networking conferences.
• What types of papers does USENIX publish?
• Alan Jay Cruz, The Job from the Referee. IEEE Computer23 (4):65-71 (April 1990).
• Grammar, Punctuation, and Capital. NASA SP-7084
• Stylewriter software

Talks

Contributors

This site contains material supplied by Gail Kaiser, Craig Partridge, Sumit Roy, Eric Siegel, Sal Stolfo, Luca Trevisan, Yechiam Yemini, Erez Zadok.

Previous answers to this question

---

Get The Answer