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 of those
assigned to review.)
See examples
of well-written reviews from previous classes.
Reviews
are
due by 9 PM on the night before
class (Thursday). Email reviews
to both Kristen and the TA, pasting the text directly into
your mail (no attachments, please).
Include [CS395] in the subject header.
In weeks
that you are presenting, you can skip writing the reviews.
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 20 minutes. Please run through it beforehand and check the time (a good rule of thumb: generally 20 minutes ~ target 20 slides total).
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.
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:
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 minutes. In your presentation, include links to any existing code, data,
etc. you may have used.
Here are a couple examples of good experiment presentations
from previous classes: example1
example
2.
A project could be built around
any of the following, and should be done with a partner:
Initial project proposals
will be due before the middle of the term.
Details on the format will be given in class beforehand.