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.  (We'll usually read 3 papers each week; just choose 2 to review.)

Each review should address the following (in any order):

• Give a summary of the paper in your own words (very brief, 2-3 sentences)
• What is the main contribution of the paper?
• What are the primary strengths and weaknesses of the paper?
• How convincing are the experiments?  If something specific is lacking, what should have been tested?
• Describe one specific way in which the work could be extended.
• Additional comments, including unclear points, connections you see between the papers
  

.

Check out Blackboard->CourseDocuments for examples of well-written reviews from previous classes.

Reviews are due by 10 PM on the night before class (Tuesday).  Email reviews to Kristen and Sudheendra, pasting the text directly into your mail (no attachments, please).  Include [CS395] in the subject header.

In weeks that you are presenting, skip writing the reviews.

 

Paper presentations

 
Each student (or team, depending on the total enrollment) will give a presentation in class covering 3 papers on a topic selected from the course syllabus list.  This presentation should overview the papers and explain technical details, and synthesize any underlying commonalities or highlight interesting distinctions.
 

The talk should be well-organized and polished, sticking to about 30 minutes.  Please run through it beforehand and check the time (a good rule of thumb: generally 30 minutes ~ target 30-35 slides total).

• Clear statement of the problem
• Why the problem is interesting, important, difficult
• Key technical ideas, how they work, main contributions, strengths and weaknesses
• Evaluation, summary of key experiments and data
• How the technical approaches agree/differ
  
• Open issues raised in the papers, likely extensions

Try to use applications to motivate the work when possible, and look for visual elements (images, videos) 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. when available, but be sure to clearly cite the source on each slide that is not your own. 

Check out Blackboard->CourseDocuments for examples of good paper presentation slides from previous classes.

 

 

Experiment presentations

 

For each topic one person will present the results of some experimental evaluation of some main idea in a paper we read.  Basically the goal 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 many papers, you may be able to find code or binaries provided by the authors online (see links on our course page schedule alongside the papers).  The goal is to help us gain a more complete intuition about the work we are studying.  You might:

• Experiment with different types of datasets
• Examine the method's sensitivity to relevant parameters
• Show a simplified example that highlights an expected strength or 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.  To avoid redundancy with the paper presentation, this presentation should not spend time explaining the methods of the papers; you can assume this is covered already.

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, in case others in the class can leverage your experience later when working on the project.  Be sure to explain the rationale for the outcomes, and conclude with a summary of the message(s) your example illustrates.

An experiment presentation should take about 20-30 minutes.  In addition to the presentation, make a simple webpage to outline the demo and include links to any existing code, data, etc. you may have used.  We'll point to that page for the rest of the class to reference.




Check out Blackboard->CourseDocuments for examples of good experiment presentations from previous classes.

 

 

Timetable for presenters:

One week before your presentation is to be given (by Wed): email slides to Kristen and Sudheendra, and schedule a time to meet and go through a practice run.

The week of your presentation: refine the slides based on input from the instructors, practice, and check time length of the talk.

The day of the presentation: send final slides (and web page URL for experiment presentation) to Kristen.

 

Projects

A project could be built around any of the following, and should be done with a partner:

• an extension to a technique we study in class
• an in-depth analysis and empirical evaluation of one or two existing related techniques
• design a novel approach and perform accompanying experiments
• a thorough survey/review paper summarizing and analyzing the work in a sub-area from the syllabus (this one only should not be done in partners)

Initial project proposals will be due before the middle of the term.  Details on the format will be given in class beforehand.