Common issues in Lab 2

• If you reference data, code or figures in you text, those items should be in your text. Not in the appendix.
• If you have data, code or figures in your text, those items should be in a numbered item so that, in the text you can reference the item. For instance "As shown in Figure 4 ..."
• If you have a numbered item in your text, it should have a caption that defines what it is. You should be able to read the caption independent of the text and understand what that item. (The text is for interpretation, not basic understanding. So in figures, the caption should explain the axes, and briefly describe the data.
• Try to have them on the same page as the text that discusses them. Often this is not possible, but try.
• If you have a choice between a table and a graph, always choose a graph. If precision of the data really matters, you can put the table in an appendix or add data labels in your graph
• The text should never directly refer to an appendix except to say something like "for additional details see Appendix A".

This to avoid -- or at least worry about:

• Rhetorical questions: You get to use one per semester in your writing. Use it well.
• Overanalyzing data. Many/Most people assigned speed orderings to the "best case" data based on differences that were tiny. Were those differences in any way meaningful?
• Using meaningless units. For instance, if you say "times for were 1 second faster that times for B", without a lot of thought and referring to things outside of this sentence I do not know what this means. For instance, did A take 1 year? Better to say "times for A were 17% faster than times for B"
• "I assume", or any phrase like this. If you are assuming, you are doing something wrong. Occasionally, at most once per paper, a phrase like "I hypothesis that ..." might be appropriate, but if yo write this, you need to have some excellent login underlying the hypothesis.
• "facts not yet in evidence". No one actually used this phrase, it comes from courtroom dramas on TV. (Sadly, the one time I was on a jury no lawyer said this.) In your writing, watch for talking about something, especially in the intro, that you have not yet defined.
• Really long sentences. The winner this week was a sentence with 75 words. There were contenders for this crown.

If you state a fact, it should be either: common knowledge, experimentally proven, or cited.

For instance "Python has a recursion depth of 1000". Is this common knowledge in the community to whom the paper is written? If yes, the do nothing. If no, then either back this statement up with an authoritative citation -- in this case the Python documentation would be appropriate -- or experimental evidence. For instance, experimental evidence might take the form of a sentence like "a test (data not shown) with 3 difference recursive functions all showed that the default max recursion depth for Python is close to 1000".

Variance

Why are your numbers not consistent. Can you adjust your experimental protocol to reduce variance? What are the sources of variance? In general, you should be doing everything you can think of to reduce variance. In the end, running on a Unix box rather than you laptop will help. Look for other sources before going there.

Magic numbers

In this lab several people reported that -10 was used to get worst case numbers. Why -10? If it could be -11 and -199 then do not report the exact number, instead say something like "A number known to not be in the data being searched". If it really is a magic number, then worry a lot about what makes it magical.