Writing Technical Papers: Practical Advice for Computer Science Students - Prof. Kristen R, Papers of Database Management Systems (DBMS)

Download Writing Technical Papers: Practical Advice for Computer Science Students - Prof. Kristen R and more Papers Database Management Systems (DBMS) in PDF only on Docsity! 1 1 Writing Technical Papers: Some Practical Advice Kristen LeFevre Much content borrowed from Jennifer Widom (http://infolab.stanford.edu/~widom/paper-writing.html) 2 First, Some Caveats • Every area of CS is a bit different – Even conferences and journals within a sub-discipline have different expectations • Going to try to present an algorithm for writing a conference paper in database systems – Really, problem is “AI Complete” – Still, there are principles you can learn 3 Typical Paper Organization • Paper Title • Abstract • Introduction • Related Work** • Technical Body • Experiments • Conclusion, Future Work 2 4 (Fictitious) Running Example • New algorithm for external merge-sort • Reduces complexity from O(n log n) to O(n) by allowing some bounded “unsortedness” in the result • Plan to write up results for a conference 5 Paper Title • Can be long and descriptive – Linear-Time External Multipass Sort with Approximation Guarantees • Short and sweet – Approximate External Sort • Catchy and Cute – Floosh: A Linear-Time Algorithm for Approximate External Sort 6 Abstract • State the problem • State your solution and technical contributions • Short and precise • Do not repeat the abstract word-for- word in the introduction 5 13 Technical Body • Important Components (cont.): – Preliminaries: Set up notation and terminology; explain material that is not original, but is needed for the paper • Terminology & notation are like programming -- You need to declare them before you use them! • Strive for precision and simplicity in terminology and notation – Definitions and descriptions should be unambiguous – But, don’t introduce notation or terminology that is unnecessarily complex! 14 Technical Body • Important Components (cont.) – Content: Algorithms, system descriptions, novel analyses, etc. • Varies significantly based on the paper, but there are some general principles • Try to write “Top-Down”: – Start with the high-level idea, and drill down to details • Write for “skipability” – Use backward and forward “pointers” – When you refer to an idea elsewhere in the paper, indicate where it can be found 15 Experimental Evaluation • Many conferences and journals expect experiments – Not productive to run experiments just to produce graphs (some papers do) • Ask Yourself: Why am I running these experiments? 6 16 Remember the Scientific Method? (We are Computer Scientists…) 1. Define the question 2. Gather information, resources, observations 3. Form hypothesis 4. Perform experiment, collect data 5. Analyze data 6. Interpret data and draw conclusions (starting point for new hypothesis) 7. Retest (often done by others) 17 Experimental Evaluation • Rule of Thumb: For each table / graph, you should be able to describe – The question – The hypothesis – The experiment you did, and how it tests the hypothesis – Your conclusion • The above is an excellent way to write the text of your experimental section! 18 Running Example -- Hypothetical Experiments • Recall: Floosh runs in O(n) time; standard external merge-sort runs in O(n log n) • Hypothesis (High-Level): On standard equipment and “real” data, Floosh runs faster than SEMS • Experiment(s): Using data from several real data warehouses, observe the difference in (wall clock) running time 7 19 Running Example -- Hypothetical Experiments • Hypothesis (More Detailed): The performance of Floosh is influenced by the distribution of input data. On heavily-skewed data, it is slower than SEMS. • Experiment: – Consider using synthetic data for this – Vary the sort attribute’s skewness – Compare performance between Floosh and SEMS for different amounts of skew 20 Running Example -- Hypothetical Experiments • Hypothesis: In practice, the amount of “unsortedness” is often much less than the theoretical upper bound – (Assumes you have some way of quantifying unsortedness) • Exercise: What experiment would you use to test this hypothesis? 21 Experiments: More Thoughts • Easy to run experiments showing your idea in the best possible light – Many papers do; often transparent • Synthetic data / workload vs. Real data / workload? – Real data and workload illustrate some realistic setting – Synthetic often gives you more control to vary the parameters of the experiment • Think carefully about what is important to test – E.g., Performance experiments won’t tell you anything about interface usability.