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 (and their associated discussion points) for the
assigned papers. We'll usually
read 3-4 papers each week; just choose 2 of those assigned
to review. In weeks that you are presenting, you
can skip writing the reviews.
See examples
of well-written reviews from previous classes.
Keep in mind it's often easier to see flaws in a piece of
work in hindsight, or judging from a distance -- yet we
strive to comment on the good and creative things, too.
After writing your reviews, extract 2-3
"discussion points" based on your analysis. These
should be key observations, lingering questions, interesting
connections, etc. that fall out of your full paper
review. Think of it as a recap of the most salient
aspects of your paper review. Typically this part should
be about 2-3 sentences for each of the 2 papers you
reviewed.
Reviews
and
discussion points are due by 8 PM on the
night before class (Tuesday).
Submission: Please submit your review and discussion points separately via Piazza.
To submit your reviews, which will by default be shared only with the instructor, please follow the following format:
1. New
post - select type to be Note
2. Post to - select instructors (which is default)
3. Select
folders - select tag of homework (hwX), where X is the
week number.
4. Summary
- Use title with prefix "[Reviews]". The
format looks like:
[Reviews] hwX review by (your name)
5. Post
the paper review in Details box.
To
submit your discussion points, which will be shared
with the entire class, please follow the following format:
1. New
post - select type to be Note
2. Post to - select instructors (which is default)
3. Select
folders - select tag of homework (hwX), where X is the
week number.
4. Summary
- Use title with prefix "[Discussion]".
The format looks like:
[Discussion] hwX discussion by (your name)
5. Post
your discussion points in Details box.
Each student (or team, depending on the total enrollment)
will give a presentation in class covering the selected
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, about 15 minutes per paper. Please run through it beforehand and check the time (a good rule of thumb: generally 15 minutes ~ target a max of 15 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.