Main CS97 Page
 
Top

Reading and Responding to Research Papers

Strategies for Reading

Tia Newhall's advice for reading research papers.

When you read a research paper, you will almost certainly encounter some terms or arguments that you don't understand. One of the important skills that you will develop as you gain experience is choosing whether you should pause and try to resolve your confusion or keep going in the hope that it will become clear later or that you can still get something out of the paper without understanding that point.

Both extreme strategies (dive deep on every little confusion, or blow by every in a sprint to the end) are Bad Ideas™, because you'll either never reach the end or get nothing out of the paper. So just monitor yourself. If reading a particular paper is taking forever, let a few things go. It may be better to read to the end and start over again. If you find that you've completely lost the thread of the paper, slow down, look up some definitions, see if you can pick it back up again.

Different communities have different styles ... [in progress]

Paper Responses

For each paper we read (except the one for which you are the discussion leader), you will write a short response. The purposes of this exercise are:

  • Writing the written response will encourage everyone to read the papers carefully.
  • They are a verification that everyone actually read the papers.
  • They will be due one day before we discuss the relevant paper in class, and will be used to help guide the discussion.

The written responses will be in the form of a few questions about the paper. Here are the kinds of questions that are appropriate.

  • Comprehension
    • There is something in the paper that you do not understand.
    • Good example: The authors say that their technique is useful for user-space processes, but not for OS kernel code. I don't understand why this is the case. Is it because user code and kernel code use different address ranges? Is it because of some permissions issue? I did a google search for the differences between user and kernel code, but didn't find an answer to my confusion.
    • Bad example: What is a device driver?
  • Challenge
    • There is something in the paper that seems amiss.
    • Good example: The authors claim that their technique will improve system performance by 20%. But I thought that the technique is only relevant to a subset of the entire system. So wouldn't the whole-system improvement be substantially smaller?
    • Bad example: The authors say they proved some asymptotic performance bound for their algorithm, but I don't believe the proof.
  • Broader implications
    • The paper made you curious about something that is related but beyond the scope of the paper.
    • Good example:
    • Bad example: Could this technique be used to cure cancer?

The point of all the good/bad example pairs is that you should spend a little time (maybe 5-20 minutes) following up on your own question and writing down what you find or think of. For each paper you should aim for about 3 questions and about a half a page of total text. The intention is that generating and writing down these questions should take no more than about an hour per week.

The grading for these questions will be a simple pass/fail. As long as you turn in something that demonstrates a little more thought than one one-line question, you'll be checked off.

Handing In

You should write your responses in LaTeX and compile them to a pdf file. Please organize your personal CS97 repository as follows:

  • cs97fa13_${USER}
    • PaperResponses
      • p01.tex
      • p01.pdf
      • p02.tex
      • p02.pdf
      • p03.tex
      • p03.pdf
      • ...
    • ...

Each response should include your name and userid along with your questions. Indicate which kind each question is (comprehension, challenge, broader implications) and try to avoid sticking to a particular kind for all of your questions.

Here is a very simple LaTeX starter file that you are welcome to use. You are also welcome to get as fancy with LaTeX as you like.

\documentclass{article}

\begin{document}

\title{Questions for ``A Super Monkey Collider Built with Valgrind and Pin''}
\author{Benjamin Ylvisaker - bylvisa1}
\date{}

\maketitle

Here is my first question

Here is my second question

Here is my third question

\end{document}

To turn in your response, do the following:

cd my repo directory/PaperResponses
pdflatex pXX
git add pXX.tex
git add pXX.pdf
git commit -m "Response questions for paper XX"
git push

NOTE: The first time you push to an empty git repository you have to type:
git push origin master

Your response is due at 5pm the evening before we are scheduled to discuss the paper in question (i.e., Mondays and Wednesdays). There are two reasons for this:

  • The instructor will use the submitted questions to shape the discussion.
  • It is often very beneficial to sleep on new concepts for at least one night.

The instructor will use an automated script to tag everyone's repositories at the appropriate time. Whatever is in your repo at that time is what you turned in.

Team-Choice Papers

TBA