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 10 PM on
the night before class (Tuesday). Email
reviews
to
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 30 minutes. Please run through it beforehand and check the time (a good rule of thumb: generally 30 minutes ~ target 30-35 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 30 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.