The quality of our discussions will rely on how prepared everyone is when they come to class.† It is important to do the reading in order to actively participate.† Students are required to submit two paper reviews per week for the assigned papers.† (If we read more than 2 papers, just choose 2 to review.)
A good review includes a brief synopsis of the paper content, a thoughtful analysis of its contributions and strengths/weaknesses, and notes about points that are unclear.† Please address the following points (in any order) in your review:
∑ Give a brief (2-3 sentences) summary of the paper in your own words.†
∑ What appears to be the main contribution of the paper?
∑ What are the paperís primary strengths? weaknesses?† (These may refer to both technical strategies and clarity.)
∑ How convincing are the experiments?† If they appear lacking in some way, what would you suggest be tested?
∑ Are there any obvious (or less obvious) ways this work could be extended?
∑ Any additional comments, including questions it raises for you, or points that are not clear.
Check out Blackboard > Course Documents > Review examples for examples of well-written reviews.
Reviews are due by 10 PM on the night before class (Wednesday).† Please post each review using Google Docs (instructions are on Blackboard).† In weeks that you are presenting or giving a demo, it is not necessary to write any reviews.
Each student will give a presentation in class covering 2-3 papers on a topic selected from the course syllabus list.† This presentation should overview the papers and explain technical details, but also synthesize any underlying commonalities or highlight interesting distinctions.† The goal is to become familiar with some of the work in this particular area through the selected papers, and to relay it to the class with a polished, well-organized talk.†
The presentation should be approximately 30 minutes and include these components:
∑ clear statement of the problem (and scope of background reading)
∑ why the problem is interesting, important, difficult
∑ assumptions applied
∑ key technical ideas, how they work, main contributions, strengths and weaknesses
∑ means of evaluation: How are the methods tested? What kind of test data?
∑ open problems and issues raised in the papers
∑ specify potential points of discussion for the class
The key point is to synthesize the material and describe how the technical contributions fit together when possible.† Use applications to motivate the work, and look for visual elements to put in the presentation.† Check out the webpages linked on the class webpage, and also look at authorsí webpages for supplementary materials.† Itís ok to grab a few slides from conference talks etc., but try to organize your presentation around the themes/concepts, not just the separate papers.†
For each topic one person will present a ďdemoĒ or evaluation of some main idea in a paper we read.† When you are in charge of the demo, basically your job is to implement a distilled version of an essential technical idea in the paper, and show us some toy example of how this works in practice.† For a number of papers, you may be able to find code or binaries provided by the authors online.† The goal is to help us gain a more complete intuition about the work we are studying.
∑ experiment with different types of training/testing data sets
∑ examine the methodís sensitivity to relevant parameter settings
∑ show a simplified example that highlights an expected strength/weakness of the approach
Note that the goal here is not to recreate published results or to build systems as described in the paper.† Instead, you are looking to make a small illustrative demo that will let us more deeply understand what we have read.† Spend some time playing with your implementation, and put thought into what would be an instructive toy example to show the class.† The demo should allow us to learn something about the method, not just see it.† If you needed to implement something yourself, explain how you did it, and especially point out any details or choices that werenít straightforward.† Be sure to explain the rationale for the outcomes, and conclude with a summary of the message(s) your example illustrates.
A demo presentation should take about 20-30 minutes.† In addition to the presentation, make a webpage to outline the demo and include links to any existing code, data, etc. you may have used.
Timetable for presenters:
By the Thursday the week before your presentation is scheduled:
- Email slides to the instructor, and schedule a time to meet and discuss.
The week of your presentation:
- Refine slides, practice presentation, know about how long each part requires.
The day of your presentation:
- Send final slides (and, for demos, pointer to webpage) to instructor.
As part of this course, students will do research-oriented projects in pairs.† A project could be built around any of the following:
∑ an extension to one of the techniques studied in class
∑ an in-depth analysis and empirical evaluation of one or two related techniques
∑ design of a novel approach and accompanying experiments
Initial project proposals will be due before the middle of the term.† Proposal guidelines are here.†